My SMF 3.0 Dream

Started by Xarcell, October 06, 2011, 01:51:46 AM

Previous topic - Next topic

Oldiesmann

A couple of other things to keep in mind:
Most users don't even read license agreements and similar documents

More importantly, what happens if someone claims ignorance? SMF does not store previous versions of agreement.txt and does not specifically say that the user has agreed to the terms. There's also no guarantee that the "last modified" date on the agreement.txt file will match when you actually last modified it - especially if you have switched hosts at some point over the years.
Michael Eshom
Christian Metal Fans

SoLoGHoST

Ok, why not allow an admin to view all attachments sent over PM?  If this feature were implemented, it could be noted to the user in the same area where they attach files within their messages.  Stating the membergroups that will be able to view their Private Messages (to the user), and perhaps even make it able to be approved.  Since the Owner of the site may be held responsible for it, why not give them the option to do it, and provide a means for them to moderate it COMPLETELY!  Private messages should be private, but attachments in these message, to me, should be public to a select member group (that the admin decides).  But, most importantly, the user who sends the attachment(s) should be notified that they are sending a PUBLIC attachment within a Private message.  Public meaning, it is possible for the Admin and other membergroups to view the content of an attachment if they deem so, in order to make sure that the content is allowed on their forum, or not.

Quote from: Xarcell on October 06, 2011, 01:51:46 AM
Personally I think 2.1 should be skipped and go straight into developing on 3.0.

My 3.0 Dream:

1.| Use HTML 5 especially with the use of microdata. The way I see it, but the time 3.0 comes out, there will be a lot more support for it.

2.| Go Object Oriented.

3.| Keep your ground on not supporting third party software. jQuery "might" being the only exception, as some don't consider it third party. However, it should be discussed publicly on whether to support it or not. The pros may out-weigh the cons greatly.

4.| Add a BBC manager and a Menu Manager.

5.| Rename "Default Theme" to "Master Theme", and use the term "Default Theme" when applying a theme to run as the site default. This makes things a little clearer for newcomers.

6.| Remove most of the profile fields in profiles and let the custom profile fields do the work. If the admin wants them, he can create them.

7.| Remove the Calendar. I actually have mixed feeling about this, because I use the Calendar. I think it should be an "official" mod.

8.| Permissions need a make-over. Current system is to complicated to understand for newcomers. Adding options like "Accept" "Deny" and "Revoke" can be a game changer and help people understand it better. Using "Deny" means no permission, but can get permission that allows you from another group. However, using "Revoke" means no permission, regardless if you get permission from another group.

9.| Full UTF8 support by default.

10.| Look at "PHP Speedy"(uses GZIP compression to reduce browser overhead), this idea has potential. Can SMF have something similar by default, that combines all JS files into one file and CSS files into one file(including additional JS/CSS files from mods), and removes white-space and comments. This will reduce HTTP requests and file sizes. Not speed up not only page loading by a little bit, but increase browser load speed greatly on slower computers.

11.| Make notification a numbered queue like facebook alerts, rather than sending an email.

12.| Add user tagging, meaning I can tag a user in a message(@Xarcell) and receive an notification that my name was tagged. It lets me know a comment was directed towards me. To cut down on abuse, you should only be able tag users that are participating within that topic. Also have an option to ignore those notifications for a particular topic.

13.| More CSS3 support, less IE6 support.

14.| Default theme(or "Master Theme" if you will), should have better smart-phone/tablet support out-of-box. Heck, look at windows 8.

15.| Eliminate as many images as you can. SMF uses way too many icons. Many of them can be created using pure CSS, like the "new" button. Reduce HTTP requests and page load.

16.| Eliminate post page, expand Quick Reply and use ajax.

17.| Continue support for multiple database types.

18.| URL's need to be prettier. Site domain followed by the category name, numeric topic id, and then numeric reply id if any. Example: "simplemachines.org/smf-development/feature-requests/topic=31689/". Each reply go in numeric order, example: "simplemachines.org/smf-development/feature-requests/topic=31689/reply=1/".

19.| For the love of GOD, don't add a sidebar, it won't be flexible enough. All or nothing. If you want to do such as thing, then do it properly. Allow blocks of content to be displayed around the forum. Much like your common portals. Top, bottom, left, and right.

20.| Option to apply any age, gender, or custom profile field into a membergroup, so that it can be given permissions. This would allow sites to restrict content by age, gender, or custom profile field. This is something I have not seen any software do, but is always asked for as a mod/add-on.

21.| No more gifs! SVG should be used with a PNG fallback(javascript needed to do this until it becomes fully supported) where applicable.

22.| Scrap karma system for users and add like/dislike system based on posts.

23.| Use overlays where applicable.

24.| Profiles need a make-over, add more information and ditch the old YaBB look. Be sure to add page views a profile, and show what the user is currently viewing.

25.| Full Litespeed support.

26.| Allow multiple polls per topic.

27.| Expand buddy system to include following their activity & posts.

28.| Add option to appoint a membergroup moderator, which add add/remove users from that particular membergroup.

29.| Option to use custom on/off images per board.

30.| Use jQuery as library of choice and/or jQuery mobile.

31.| Add "drag & drop" for arranging for categories/boards, and profile fields. Also any other areas where useful.

32.| Option to add attachments in PM's.

33.| phpinfo should be shown in admin section.

34.| Add default avatar, brings uniform to forum.




Help Forums Evolve!

1.| There should be an option to display a topic as an "article", "page", "file", "thread", or "blog". Really if you think about it, the only different between the four is HOW the information is displayed. Selecting between the five options merely changes which template can be used to display that information.

Membergroup permissions determine what type can be used, along with what code such as BBC, HTML, or PHP. An example of default restrictions would be Page & PHP is allowed by the admin only.

If your wondering what "file" type is, then it's nothing more than taking a post with an attachment and display to look like a item download page. All the information is there, it's just a manner of how to display it.

It would also make it easier to make an add-on for it. Someone might want a custom "reviews" add-on, that mainly just displays the information within the post to look like a review page.

2.| All content of any type can all be found within the forum. No need for separate sections. Actions(such as the calendar) show even be allowed to placed into a forum category. So there should be an option for every action to do this or not(Google doesn't like redirects). Either way though, everything that a forum has, should have an option be able to be found within the forum itself, including the member base. The forum index should be the sitemap!

3.| I'm not for third party support, but I think people should be able to login and post using their Facebook, Twitter, OpenID, Yahoo, Live, and Google login's without registering or creating a profile.

1. Yes, agree.
2. Not sure if OOP would help SMF or hurt it.  I'm leaning more towards the latter...
3. Definitely.
4. I'm with Oldiesmann on this one.
5. Could be confusing to the Administrator to have a Master Theme and than a Default Theme that are both 1 in the same.
6. Agree, but thinking there should be some sort of selectable way for Admins to add these fields, so that it is easier to do.
7. Most forums come with a Calendar.  Doesn't matter to me whether it is there or not, but if not, should be a Mod Package for it to add it.
8. Yeah, I agree, permission system is a bit of a challenge in trying to understand at first.  And even now, I still struggle with it.  Mainly because it is just too complicated.  Permission Profile Groups in one section, Member Groups in another, etc. etc. just seems a bit scattered around to me.
9. Definitely.
10. Removing white-space and comments might help a bit with speed, but it would make it incredibly hard to debug though, unless the original file was stored somewhere for debugging purposes only.
11. Agree
12. Agree
13. Agree
14. Not sure, haven't seen the support for this yet, don't have a smart-phone/tablet to see what you mean here.
15. Agree
16. I would like to see this happen as well.

Well, that's all the time I have for today.  Those are my opinions though, take it or leave it.

Norv

Quote from: SoLoGHoST on November 07, 2011, 04:47:54 AM
Ok, why not allow an admin to view all attachments sent over PM?  If this feature were implemented, it could be noted to the user in the same area where they attach files within their messages.  Stating the membergroups that will be able to view their Private Messages (to the user), and perhaps even make it able to be approved.  Since the Owner of the site may be held responsible for it, why not give them the option to do it, and provide a means for them to moderate it COMPLETELY!  Private messages should be private, but attachments in these message, to me, should be public to a select member group (that the admin decides).  But, most importantly, the user who sends the attachment(s) should be notified that they are sending a PUBLIC attachment within a Private message.  Public meaning, it is possible for the Admin and other membergroups to view the content of an attachment if they deem so, in order to make sure that the content is allowed on their forum, or not.

That is a possibility. I lean towards NOT doing so, though.

Whether we like it or not, users will want to use PMs for sending files they wouldn't be comfortable with others seeing. (that's part of the reason why they'd use PM anyway, otherwise they'd post them in the boards). Moreover, the next question when this is possible, would be: so admins/these membergroups can read my PMs?
PMs are meant to be person-to-person, and therefore no interface for viewing them will be ever done in SMF. While that has nothing to do with "really confidential", it is still a relevant aspect for what SMF does and encourages.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

Xarcell

@SoLo

In regards in using "master theme" and "default theme" is by name only. Not 2 separate themes. The default theme should be called the "master theme"(because it's the core theme that modified and what other themes are usually based off of), but when selecting which theme to use as a user, it should say "default theme", because the admin decides which theme installed is the "default theme", which may not be the "master theme".

live627

QuoteNot sure if OOP would help SMF or hurt it.  I'm leaning more towards the latter...
OOP as in WP-like rat's nest or well-designed OOP?

SoLoGHoST

#25
Quote from: live627 on November 07, 2011, 06:50:39 PM
QuoteNot sure if OOP would help SMF or hurt it.  I'm leaning more towards the latter...
OOP as in WP-like rat's nest or well-designed OOP?
I'm not a fan of object orientation for the sake of object orientation. Often the proper OO way of doing things ends up being a productivity tax. Sure, objects are the backbone of any modern programming language, but sometimes I can't help feeling that slavish adherence to objects is making life a lot more difficult than it needs to be.  And than ofcourse objects clearly are not enough (as if they ever were), and we find ourselves needing frameworks, components, aspects, services (which, curiously, seems to bring us back to procedural programming!).

@ Xarcell, I think I understand you on this, not sure... sounds valid to me if your idea of expanding templates into any theme is implemented.  Otherwise, it wouldn't make sense to have a master theme to admins and a default theme for users that are both 1 in the same.  IMO, would be better to just have it as 1 name to everyone, or maybe I'm misunderstanding you on this still...?

@ Norv, I understand the meaning of Private, and should be this way.  Just a thought.  I also believe that Private Messages and the content within them should be kept private, however, I also agree that any content that you post belongs to the site (I believe this is in the User Agreement form by default upon Registering, if I'm not mistaken).  If the admin wants to view Private Messages by all members, they can simply go into the database and pull these messages out, so this is an action that the end-user can do, ofcourse, SMF provides this ability to do this, by storing Private Messages within the database and NOT encrypting them.  So in a way, SMF is already guilty of allowing the Admin and anyone who has access to the database, the ability to view PRIVATE and PERSONAL Messages!

青山 素子

Quote from: SoLoGHoST on November 08, 2011, 02:35:27 AM
SMF provides this ability to do this, by storing Private Messages within the database and NOT encrypting them.  So in a way, SMF is already guilty of allowing the Admin and anyone who has access to the database, the ability to view PRIVATE and PERSONAL Messages!

I believe this has been discussed before. If they were stored in an encrypted form in the database, the key would still need to be stored somewhere to allow users to actually read the messages.

If it's stored on the server, the admin has access and can still read messages should they want. If the key is stored on the user's machine (via HTML5 Web Storage or another mechanism) then that both limits the machines where messages can be read and sent and makes the contents permanently inaccessible if the key is lost from the user's computer. You also have to rely on the forum to not store a plaintext copy.

The privacy of PMs on all forums is subject to the difficulty of accessing the messages. With some forums, you can "impersonate" users, allowing access that way. Others have easy-to-find code that will allow direct reading. With SMF it relies on the fact that there isn't any easy-to-find code, nor way to "become" a user, forcing a database dive that most admins are too unmotivated or unskilled to do.

For more secure PMs over forums, the messages should be using PGP/OpenPGP encryption outside the forum itself.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


Antechinus

TBH, the reason I don't read people's PM's on the site I run, even though I could do it easily, is because it would be rude and unnecessary. It's the same principle as applies to a lot of social interactions.

SoLoGHoST

#28
Just pointing out that storing the actual message itself within the database, without any type of encryption whatsoever is just giving out, atleast to me, a contradictory message than that of what you seem to be saying within this topic about pms, on how personal pms should be.  Yet making them so easy to find in the database.  In any case, it doesn't matter to me.  I don't read other people's pms either, just so you know... not my style!

Erbros

This really sounds like a dream come true! :) Keep up the good work and continue developing the best forum software available! :)

Xarcell

@SoLo

Your confusing me. I think you are combining two suggestions. Basically, I'm just saying "default theme" should be renamed to "master theme", and that's all for that suggestion. Expanding templates is a different suggestion that nothing to do with whether it's master or default theme.

I only suggestion re-naming the "default theme" to "master theme" only because if the "default theme" is not selected to be the default theme to be shown, it doesn't make sense to call it the default theme. It actually creates confusion for user's trying to explain something in order to get support. Like right now. This suggestion can be made a reality by simply changing a few language strings and the actual name of the default theme, - to master theme. Kinda like "master copy" when it comes to documentation.

SoLoGHoST

Ohh, Ok, I see what you mean.  It's not that deep.  Well, again, a default theme to all users on a site, compared to a default SMF theme that comes with SMF are 2 different things, and it's fairly obvious to differentiate between the 2 IMHO.  Master Theme sounds a bit weird to me.  I like the name "default" because, this actually makes a ton of sense, because if language files don't exist within the theme, it defaults to using the default theme to try and load them, if templates don't exist, it defaults to using the default theme, again, to try and load them.  Honestly, even when you have a Custom Theme installed, you are using MANY MANY templates from the DEFAULT theme, not the Custom Theme.  So, in my opinion, default theme is the perfect name for this theme.  So this shouldn't be changed.  And if you just want to associate a default theme to Master Theme on the site when you change to a different default theme in the DP Admin for everyone to use by default, again, I still like the term default.  But to each their own...

OCJ

Calendar.
I spend a long time looking at forums and CMSs to provide an events based group. Only SMF does it/everything, 'out of the box' ...

Calendar view, list view, reply to event topic, announce to everyone, reliable mailing system - its perfect.
All I can say is having a good events calendar is becoming popular so why get rid of it - its a growing trend.

After testing many systems in December 2010
MyBB only made made several mods to do the same thing in April 2011.
VBulletin and InvisionPB were not as good as SMF and needed commercial mods (very busy error support forum). As far as I can remember they didnt send out announcements and on one, comments were not allowed. phpBB calendar mod was a mess - not linked to a thread.
SMF performed much better than many CMSs like Joomla and Wordpress for event management, announcement and discussion. Perhaps only Drupal competes but its a lot of work.

For groups that want to manage events, SMF is the best.

SoLoGHoST

Quote from: 青山 素子 on November 08, 2011, 12:25:52 PM
Quote from: SoLoGHoST on November 08, 2011, 02:35:27 AM
SMF provides this ability to do this, by storing Private Messages within the database and NOT encrypting them.  So in a way, SMF is already guilty of allowing the Admin and anyone who has access to the database, the ability to view PRIVATE and PERSONAL Messages!

I believe this has been discussed before. If they were stored in an encrypted form in the database, the key would still need to be stored somewhere to allow users to actually read the messages.

If it's stored on the server, the admin has access and can still read messages should they want. If the key is stored on the user's machine (via HTML5 Web Storage or another mechanism) then that both limits the machines where messages can be read and sent and makes the contents permanently inaccessible if the key is lost from the user's computer. You also have to rely on the forum to not store a plaintext copy.

The privacy of PMs on all forums is subject to the difficulty of accessing the messages. With some forums, you can "impersonate" users, allowing access that way. Others have easy-to-find code that will allow direct reading. With SMF it relies on the fact that there isn't any easy-to-find code, nor way to "become" a user, forcing a database dive that most admins are too unmotivated or unskilled to do.

For more secure PMs over forums, the messages should be using PGP/OpenPGP encryption outside the forum itself.

A simple base64_encode when inputting into the database and base64_decode after retrieving from the database would be sufficient enough IMHO.  Or even serializing and unserializing it.  But honestly, the fact that it is human readable tells me that you just don't care!

青山 素子

Quote from: SoLoGHoST on December 11, 2011, 11:11:37 PM
A simple base64_encode when inputting into the database and base64_decode after retrieving from the database would be sufficient enough IMHO.  Or even serializing and unserializing it.  But honestly, the fact that it is human readable tells me that you just don't care!

If one is just going to do that, why bother? I mean, seriously, how difficult is it to just decode it at that point? If you have enough skill to pull the right tables and display them, it's not even a hurdle to do a base64 decode on the column. As for serializing, plain text is plain text so that won't do anything at all.

One more sure way of "protecting" on the database side is to just use aes_encrypt and aes_decrypt with a key generated at random on an install. Of course, that still doesn't prevent an admin from just changing those calls to not be used and then it's all plaintext on the backend yet again. It also doesn't protect you from an admin that decides to try and login as you so they don't have to dive into the database.

See, that's the thing. Unless you are the only one that has the key, it's not private. Trying to use a forum's personal message system as a secure communication channel is stupid because you (usually) aren't the one with server and code access. Any "rogue" admin that really wants the messages can bypass any protection in the code.

Think of it like a cellular phone call. Communications are encrypted from handset to cell site (that's the base64 on your suggestion), but the network provider has the ability to switch that on or off, or even listen in on the content of any communication going across the network it owns. If you want to use secure communication over that medium, you have to resort to encryption or some secure code that doesn't depend on the medium over which it's being transferred.

So, all you are proposing is to burn CPU cycles on useless mechanisms to possibly make some people feel better for a bit of security theater. I'd rather use that CPU on something that's actually useful.

So, I suppose you are correct in the accusation that the developers don't care. They don't care to do things that will impact performance and provide absolutely no benefit.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


Matthew K.

Quote from: 青山 素子 on December 12, 2011, 12:35:41 AM
Quote from: SoLoGHoST on December 11, 2011, 11:11:37 PM
A simple base64_encode when inputting into the database and base64_decode after retrieving from the database would be sufficient enough IMHO.  Or even serializing and unserializing it.  But honestly, the fact that it is human readable tells me that you just don't care!

If one is just going to do that, why bother? I mean, seriously, how difficult is it to just decode it at that point? If you have enough skill to pull the right tables and display them, it's not even a hurdle to do a base64 decode on the column. As for serializing, plain text is plain text so that won't do anything at all.

One more sure way of "protecting" on the database side is to just use aes_encrypt and aes_decrypt with a key generated at random on an install. Of course, that still doesn't prevent an admin from just changing those calls to not be used and then it's all plaintext on the backend yet again. It also doesn't protect you from an admin that decides to try and login as you so they don't have to dive into the database.

See, that's the thing. Unless you are the only one that has the key, it's not private. Trying to use a forum's personal message system as a secure communication channel is stupid because you (usually) aren't the one with server and code access. Any "rogue" admin that really wants the messages can bypass any protection in the code.

Think of it like a cellular phone call. Communications are encrypted from handset to cell site (that's the base64 on your suggestion), but the network provider has the ability to switch that on or off, or even listen in on the content of any communication going across the network it owns. If you want to use secure communication over that medium, you have to resort to encryption or some secure code that doesn't depend on the medium over which it's being transferred.

So, all you are proposing is to burn CPU cycles on useless mechanisms to possibly make some people feel better for a bit of security theater. I'd rather use that CPU on something that's actually useful.

So, I suppose you are correct in the accusation that the developers don't care. They don't care to do things that will impact performance and provide absolutely no benefit.
+1

SoLoGHoST

#36
Well, atleast with using base64_encode, you force the user to have to use a script to decode it as opposed to just reading it directly from the database.  Security should not be compromised because it impacts performance.  Anyways, I suppose this is not really a huge security issue...  You could also create a hash and base64_encode that even.  Given the time of the personal message, we could even include this into an array, with the hashed message that is base64 encoded, as well as even the id from the database for it, serialize the array, and when we unserialize we check for the time to match the time of the PM in other columns of the table or the id.

Anyways, just offering up alternatives.  If you don't like them, or think it impacts performance too much, no problem.  Just ideas is all they are.

* Sorry for getting a bit off-topic here.

青山 素子

Quote from: SoLoGHoST on December 12, 2011, 10:25:09 AM
Well, atleast with using base64_encode, you force the user to have to use a script to decode it as opposed to just reading it directly from the database. 

See:
Quote from: 青山 素子 on December 12, 2011, 12:35:41 AM
If you have enough skill to pull the right tables and display them, it's not even a hurdle to do a base64 decode on the column.


Quote from: SoLoGHoST on December 12, 2011, 10:25:09 AM
Security should not be compromised because it impacts performance.  Anyways, I suppose this is not really a huge security issue...  You could also create a hash and base64_encode that even.  Given the time of the personal message, we could even include this into an array, with the hashed message that is base64 encoded, as well as even the id from the database for it, serialize the array, and when we unserialize we check for the time to match the time of the PM in other columns of the table or the id.

Not sure what you're suggesting there. Hashes are one-way, so you couldn't get back the plaintext. The best one could do is use it to see if the message was tampered with (a checksum). However, that doesn't protect against some crazy privacy-invading admin reading the messages. Actually, it doesn't even protect against changing the messages because the modified version can simply be re-hashed and would then validate against the new hash. That, or the forum could just have that little check always return "valid", which would be a lot easier.


Quote from: SoLoGHoST on December 12, 2011, 10:25:09 AM
Anyways, just offering up alternatives.  If you don't like them, or think it impacts performance too much, no problem.  Just ideas is all they are.

I'm not sure what you're actually trying to acomplish other than make it look like something is protected when it is actually not. That's an even more dangerous state because it can make others think there is actual protection, leading to complacency.

As I noted before, while SMF tries to make it a bit more technically difficult to spy on other users, it can't ensure perfect security (nor should it, IMO) and it certainly shouldn't offer fake security.

The key here is that unless you own the whole communication channel, you can't be sure it hasn't been modified to spy on you. If you're going to try to communicate securely on a channel over which you don't have complete control, you need to use proper encryption. That means you need to be the only one with the encryption key. Giving the key to some third-party just completely breaks security.


As an example of the whole "let the server encrypt stuff" mentality going wrong, I'll make reference to Hushmail. They are a service that allows you to send and receive OpenPGP encrypted communications. Their old-style method was to get your private key, passphrase, and the message plaintext and then encrypt the message on their server. Note that giving them that effectively gives them everything they need to be able to decrypt any messages to or from you using that key. They actually did that and turned over plaintext copies of messages to a US Federal Court Their newer service uses a Java Applet that does the encryption locally, but they have warned that they may be compelled by court order to send users an applet that stores and forwards them all the data.

So, yes, if you want message security you must own the entire communication chain or use encryption outside that chain and own that part. Doing silly stuff like using reversible encryption on the server, using base64 or uu encoding, or similar stunts doesn't do a thing to secure private messages.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


SoLoGHoST

Yeah, your right, wouldn't be secure, would just be harder to read and would impact performance a bit.  What I was suggesting with the hash, is that you see how hashes are used for file attachments in posts, well sort of the same method for this.  The hash can be stored in the database for this, within the pm table, and can be used when unserializing the array that contains the message.  But, yeah, I suppose it wouldn't make any difference, especially if everything is coming from within the database on the output of the message.

青山 素子

Quote from: SoLoGHoST on December 12, 2011, 02:20:44 PM
What I was suggesting with the hash, is that you see how hashes are used for file attachments in posts, well sort of the same method for this.  The hash can be stored in the database for this, within the pm table, and can be used when unserializing the array that contains the message.

Still not sure what you're suggesting there. Are you talking about using a hash an encryption key? Also, why would you store the message as a serialized array? It's just a plain text string.


Quote from: SoLoGHoST on December 12, 2011, 02:20:44 PM
But, yeah, I suppose it wouldn't make any difference, especially if everything is coming from within the database on the output of the message.

As long as the key is in the hands of a third party, there is no security. Trying to pretend like there is some is a great way to get one's self into trouble.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


Advertisement: