Topic: Shrink/expand header persistence (SMF patch) (Read 365 times)

This would be great, and you would solve two problems with one smf patch.
I hope theymos accepts this update and I dont see any good reason why he wouldn't do that.
For better privacy I would remove everything when pressing shrink button, maybe even hiding word Bitcoin from the title Bitcoin forum.
Either way you choose it will be positive change.

I have some concern when I use my computer at public locations and worry that some people can look over my shoulder to see I am using the forum, have an account here and its username. It's pure privacy concern and if theymos can approve this patch, I will appreciate it a lot.

I like the first one because sometimes I need to read news on important updates from the forum and sometimes I need to use search.

Thank you doing the patch and going further by listening to community suggestion, it's long waiting time to get opinion of theymos / Cyrus, approve it or dismiss it.

I think this is a good measure, as it prevents third parties from knowing what my username is if they look over my shoulder.

But we can go further. Even if we shrink all of this, the word "Bitcoin Forum" will still appear. In other words, the person looking over my shoulder still knows that I allegedly deal in Bitcoin - at least I browse their forum.
Is there a solution for this?

Yep. This patch is just about fixing the persistence bug. But...

If theymos accepts this patch, then I'm thinking about doing another one to improve the logic a little. Loyce suggested something (~5 years ago) that makes sense to me:


The way I'm thinking of approaching this is to move the little +/- icon up one row (next to the SMF logo), and then making it so that when the header is collapsed, it'll look like this:



That way, Loyce's privacy concern (which I share) has a solution, and the header actually displays something useful when it's collapsed (I don't need help remembering my name or calculating "forum time", but I'd still like to see the news and maybe do a search).

For people that prefer to see nothing when it's collapsed, I guess I could make it so that it hides everything if you hold down some modifier key while collapsing it:



I mean, I guess that's still not everything, so maybe the secret fully-collapsed mode should just be:

Username won't be hidden when you shrink the header, only avatar profile image will be hidden with total time logged in, and few more lines of text.
Everyone can still see that your account is logged in, but you can always log out if you want to hide that information and only read posts.

It is personal likeliness and it means more for people who have to log in an account in public locations when they have no other choices.

When they are in public locations, hiding username, and avatar will be good for anonymity and some of forum members will like this extra feature from SMF patches. It's extra feature for personal choice so if you don't like it, just use default features and settings. If you have such needs for anonymity, and privacy, customize settings a little bit.

It's not about like or dislike, this is very useful feature for people who are using devices with smaller screen size, like smartphones and tablets, since we don't have responsive mobile theme yet.
And  btw in other smf forums this shrink/expand feature is working just fine by default, as it should.

You know your Watchlist is in the shrinked space so whenever you need you can just toggle the collapsed button. It's basically a personal likeliness. I see it looks good when the area is shrinked. The header part is much simpler.

I don't like the way the pages look when the headers shrink. I kind of feel naked without it. I am used to seeing my avatar in the top left. It also removes the Watchlist, a feature I often use to check for new replies in my own threads and posts in discussions I have previously participated in that are of interest to me.

I knew we had collapsible header but I did not know that moving to another page or refreshing it reset the toggle.

We had many updates of the original software many times but I don't know if we added a document for it. Without the document when theymos will not be around and someone else will handle the forum will be in great problem to smoothly running the forum.

I do not think anyone has used the feature much. It is almost unusable as it is, but if this patch gets implemented, I may switch completely to the collapsed version. Much better privacy when using the forum with people around.
I will only undo it when I want to visit the patrol page or check the latest News update.

Great work as always PowerGlove.

- Jay -

I am curious to know why smf_setThemeOption() was disabled, what risks disabling this was mitigating, and if there are any alternatives to mitigating these risks.

I would tend to disagree with option A because the settings won't persist across devices/browsers. IMO that is really not the expected behavior of an application that requires users to login.

I am really not familiar with the SMF codebase, so I can't comment on if the restrictions on val, th, and id are sufficient to address whatever underlying root cause that was the reason for disabling smf_setThemeOption() in the first place, but I guess it does at a minimum increase security incrementally.

SMF is open source, but the implementation (with modifications) that bitcointalk.org uses is not. So anyone can easily look at the code for SMF 1.1.19, which will generally match what the forum uses, but any customizations that theymos has implemented are not public.

There are pros and cons to doing it this way. On the one hand, if there is a vulnerability in a modification implemented, it might be difficult for a bad actor to find and exploit the vulnerability. On the other hand, a vulnerability will be more difficult for someone with good intentions to find, which might delay the closing of any potential vulnerabilities that could possibly be exploited undetected for some time. Extensive logging can potentially mitigate this drawback, but only to the extent that you are using something to monitor the logs.

Yup, they're publicly accessible... I began this whole SMF-patching arc (back when I did my first) by just downloading the archived sources for 1.1.19 (from here) and then getting them to run in an era-appropriate version of Debian inside a QEMU image.

But, over time, I've upgraded my branch of 1.1.19 to get it working within a more modern/comfortable environment (modern PHP version, modern MySQL version, etc.), which has resulted in hundreds of little modifications.

So, there are three versions of SMF that I need to consider when I put together a new patch (my version, theymos' version, and original 1.1.19). What I do is test things on my version (which includes the hundreds of little changes I mentioned earlier, and sometimes also includes some subset of my other patches), but, because that version includes many changes that were never in 1.1.19 and that theymos likely doesn't have in his version, at least, not in exactly the same places/forms, when I'm finished testing a patch, I carefully re-base it against original 1.1.19 (so that theymos has a constant backdrop to consider my diffs against).

I don't have access to theymos' version of SMF, but, even though I can't see it, it does influence the way I put together my patches. Because I know that theymos will be looking at diffs that he can't merge as-is (because they're not based against his version), I try to keep the number of "patch points" to a minimum and try to place them in spots that I figure are relatively stable between all three versions. If I could see theymos' version, then my patches would probably look a lot different than they do, but, for now, I'm basically stuck in a situation where I have to give theymos "impressionistic" diffs that I'm counting on him to be able to read/interpret and then carefully splice into his version while considering all the hazards that I can't see. (Part of the reason that the 2FA patch was such a challenging piece of work was because it's very security-sensitive code, and finding just the right way to express a high-consequence modification like that, given the constraints I've mentioned, took a great deal of effort/thinking.)

As above, in my own modified version of SMF. I crank all the logging/error-reporting stuff up to paranoid levels, and then basically just manually exercise SMF and make sure that the logs stay clean.

No problem. Thanks for suggesting it.

Haha, you didn't read my whole post, did you?

See the last line of the OP, quoted below:


@theymos: Looking at the first diff again (Fix A), it's actually kind of goofy to use the $settings array the way I did. Only the code in template_main_above() is affected by the new setting, and I don't see anything else ever needing access to it (the category collapse stuff works in its own distinct way), so I'd probably just base the three changed if-statements on a local variable instead (something like $force_collapse_by_cookie), with a similar comment to the one I left in template_init().

Thanks PowerGlove, that was super-fast and quicker than I expected
I am voting for Fix A because I think it is more simple to implement it, but we the forum members probably won't notice much difference if Fix B was selected by theymos.

PS
There are other elements in forum that have similar ''issue'', one of them is footer aka Info Center, but this is more useful than a header.
Footer has Recent Posts and Forum Stats.

Like you, I haven’t used it either neither do I give it much attention but obviously, there are those who do, users whom eventually needs more space to work with and I understand that.
Safe options are always going to be the best approach to have that which should the patches be considered, I guess “Patch A” would be the more appropriate. An option without risk of attack is better than having the memory comfort with a looming possibility of an attack.

It’s an unpopular belief that many users would login their accounts on just any device. Mostly, users stick to their personal desktop/laptop computers or their mobile device. I don’t randomly pick up just any device to login my account, have reluctantly done that on few occasions but, it’s really that rare and in those moments, you don’t seek much comfort.

Since the patch could be remembered on an already activated device, it’s cool.

By the way, I never used this feature much, but for those who use it a lot, the fact that the chosen option is not "memorized" can be annoying.

I believe Fix A is the most appropriate. In addition to being simpler to apply, it will not affect the security of the forum. Furthermore, we are all used to there being times when a certain configuration stored in a cookie disappears, due to reset or use of another device. So this turns out not to be a big inconvenience. Because, as the person uses their browser, this should happen very occasionally.

Congratulations PowerGlove on this patch. 

I think making the forum use disabled endpoints is a bad idea, because theymos must have disabled it for security reasons as you know. So I would prefer the first patch. Even though I never collapse the header myself honestly - it's just confusing.

Although I am aware that newer versions of Simple Machines do handle this collapsing properly for logged in users.

PS. Where are you pulling all these PHP files from - are they publicly accessible? And how do you test these things?

This one was suggested by dkbit98. (Thanks for kicking off the suggestions thread with an easy one; being able to quickly fix the first thing suggested makes me look badass, yo.)

The area at the very top of most pages looks like this:



That area can be "collapsed" (by clicking on the minus icon next to the date/time) to save some vertical space:



The problem is that the setting isn't being saved/persisted, so you have to keep collapsing it again and again as you navigate the site. What's interesting is that it is being persisted when you're not logged-in... That's weird, right? Why does it only remember to stay collapsed when you're not logged-in?

It turns out that there are two ways in which this setting gets saved: When you're logged-in, it gets saved as a so-called "theme option" via a JavaScript function named smf_setThemeOption that depends on a support endpoint (/index.php?action=jsoption), and when you're not logged-in, it gets saved as a cookie. (At least, that's how it's supposed to work.)

One of those two ways is still working (the cookie way), and the other is currently broken (the theme option way). I can only hazard a guess as to why smf_setThemeOption() no longer works, but I think what probably happened is that theymos disabled the support endpoint for it. Looking at the code for that endpoint, I can see why he might have done that (it's not a well-designed feature; it exposes too much attack surface relative to its usefulness).

So, I can see two ways to fix the problem:

Fix A

Since the feature still works as intended by using cookies when you're a guest, this fix just makes it so that the feature always relies on cookies (whether you're logged-in or not).

The advantage to fixing it this way is that the dodgy endpoint can stay disabled. The disadvantage is that the state is only persisted in a cookie, so if you sign in from a different device, or if you clear your cookies, then it'll "forget" (not a big deal, IMO).