Currently trying to write a dark theme solution for the security blog in pure JavaScript (no jquery).

This is way easier than I thought!

With cookies to save theme?

So you're altering the css afterwards? Sounds wrong to me 🤔

@FrodoSwaggins I don't understand how people can still survive with noscript. Like every page nowadays practically is one huge javascript. Mustn't the whole web be completely broken for you?

I don't think you should though, just use a seperate stylesheet for dark theme and trigger it via set cookie for example. The way you implement it now, sounds a lot like the sun-effect of getting blasted with white for a second might happen.

@FrodoSwaggins Well, in the end, if you'd like that dark theme, that's your problem ;)

@romangraef Nope, but just one button/link click.

why would a framework even be considered? especially jQuery and it security problems

@JoshBent I'd rather use JavaScript than setting a cookie tbh, am I weird now?

@linuxxx Yeah you are 😄

@Forside Why'd it be weird to rather use JavaScript than a cookie though?

@FrodoSwaggins @IllSlapU it's sad that this has to be a thing though (thanks to tor bypass, cryptominers, ..), since then you can't even have onclicks working - also most websites use angular or something similar, without any fallback, meaning you just get a white page - take https://angular.io/ as an example.

@calmyourtities sources to security problems jquery introduces?

@linuxxx well first of all as you see, your target audience is blocking javascript left and right, so that wouldnt work for them, second of all, altering entire stylesheets after any load, never ends well imho.

@JoshBent Fair enough but also keep in mind that some might block cookies or remove them right after leaving the page (I do this).

Altering an 'entire' stylesheet? I just change about 3-4 values

@linuxxx another alternative would be to have a subdomain night.much-security.nl (with the dark theme css file loaded either via php or via nginx rewrite based on domain requesting the stylesheet) and redirect there with a little dark moon on the top right (and a sun in the dark theme to represent the light theme domain) - this would prevent people from being able to save it though, but they could bypass that limitation by just bookmarking that specific domain I guess.

@linuxxx Well yes, you don't have much style on that page. But effectively you're loading one style and then overwrite everything. I would not consider that clean?

@linuxxx well what I meant is big chunks of the website, for example background color, which can flash for 1 second based on machine used, browser and many more factors

I also usually do it with cookies (if it's not saved in a profile). Then check the cookie on the PHP side and generate the html code for loading the appropriate stylesheet on the backend, so the browser will directly get the correct command for loading the desired sheet.

@IllSlapU Eh, only if you command it to do so.

@IllSlapU
"Also I am not a webdev" - I noticed.

https://w3schools.com/jsref/...

"Execute a JavaScript when a [...] is clicked"

@IllSlapU it does not on default, you have to set it to delete cookies on exit, atleast I really hope they don't enforce it as default recently.

@linuxxx don't you just use scripting to toggle a class on the body element and then everything is handled by the stylesheets from there?

@Flygger Nope it's multiple elements and the only thing I do for each one is just change a color so I thought that would be pretty pointless (I'd need to create just as many classes as colors I'm changing now)

@linuxxx ohh, no no, just a single class per theme, like this;
/* light theme */
body {
font: <something general>;
background: <light>;
color: <dark>;
}
p {
color: <lighter>;
}
h1 {
font-weight: bold;
color: white;
}

/* dark theme */
body.dark {
background: <dark>
color: <light>
}
.dark p {
color: <darker>;
}
.dark h1 {
color: black;
}

@Flygger Yeah but I've got different paragraphs and headers with different colors :/

@linuxxx just do subdomains and have three stylesheets, one that contains everything else that doesnt need to be changed from white to dark theme and then two for white and dark theme, with just the things changing, easiest solution and fits everyones shoesize.

@JoshBent Wait I don't get the three part?

@JoshBent That way, if someone posts a link to a post, you will see the theme provided by the link. You also cannot set a default, so you always have to type in the subdomain.

@linuxxx I suggest doing both. A subdomain (or what I would prefer, a GET parameter) for setting the theme, plus a cookie.
So if the parameter is set, the cookie will be set. If cookies are enabled, the theme will be remembered on next visit.

@linuxxx default.css dark.css light.css

- default contains paragraph sizes, font-family of the body etc.
- dark.css contains all the colors that have to be changed for the dark theme
- light.css contains all colors that have to be changed for the light theme

@Forside to be honest, I feel like you never actually read what I write, I have mentioned that and how to bypass it too, also the positive of using that method.

@Forside its much cleaner not having 500 ways of triggering the dark theme (and avoiding cookies alltogether, for the security feeling I guess), just a clean subdomain, which is a lot easier to implement too, with rewrites in nginx for example as mentioned based on domain.

@JoshBent Yeah I read over that one post of yours. But still I think it's weird behaviour if a theme is only available via a subdomain and always resets when you open a link from somewhere else.
Personally this would drive me crazy and call it bad dev decision.

@linuxxx yeah, I updated my comment to better reflect... I can't see how anything could be simpler ;)

@Forside with cookies you would be greeted with the white theme default each time you restart your browser, since thats the behaviour most here follow through - so what is better, guess the chances of each one happening.

@Forside Ultimately the way I explained is not that much at all.

1. Check if theme parameter is set
2. Yes -> set theme cookie with parameter
No -> set theme cookie with default theme
3. Load theme from cookie and make html code for loading the corresponding stylesheet

@Flygger if by scripting you mean javascript, then for example avoiding scripting at all, since if you read half the thread - people block all things javascript.

Your idea could be recycled though, to add a .dark class to the body on serverside based on the domain, which would eliminate the need of multiple stylesheets, which imho isn't better than just having them seperate though.

@JoshBent Yeah, but the cookie wouldn't make it worse. The parameter (or subdomain) would still work, even with cookies disabled. It's just an extra for remembering the theme.

@JoshBent Only problem I see here, is if someone posts a link with the theme parameter set, it would overwrite your cookie. But you'd see the theme set by the link anyways, with or without cookies.

@Forside night.much-security.nl/?theme=light what to load now, do you see how it would create more work to maintain all methods and prioritize some cases over others, instead of just sticking with one method, which would solve both javascript blockers and cookie destroying browser.

@JoshBent I didn't say both ways should be implemented 😆 Just either subdomain or GET.

@Forside GET is connected with cookies, which get fully deleted by most (once again, if you read the thread, even @linuxxx does..) after browser session end, so each time they would visit the website again, they would get flashed by the white flashbang theme first, I really don't know how much more clear it can get?

@JoshBent you just that one way of doing it right, right? I said "scripting" because I didn't mean any specific way, just the one or ones that makes sense; it could be any and all from the (prioritised) list below (and probably more):
- subdomain (injects class)
- URL fragment (could probably be hacked in an okay way)
- cookie
- JavaScript to toggle real-time and save cookie

@JoshBent I also don't know how much more clear I could get. Using a cookie for storing the theme woudl have ABSOLUTELY NO EFFECT on the parameter method. You can always include the parameter. And if you don't block cookies, you don't need the parameter anymore. But the sheet would be loaded the same way either time. Without any flashbang.

@Flygger

"- subdomain (infects class)"

I addressed that in my previous message already.

"- URL fragment (could probably be hacked in an okay way)"

no need to hack, it can be done via url fragment (by that I guess you mean domain.com/night/post/introduction for example) - which would be literally like a subdomain, just making less sense, as those things shouldnt be part of the actual rightside domain imho

"- cookie"
"- JavaScript to toggle real-time and save cookie"

read above, why cookies are useless - once again.

As you can see, the options get limited by javascript being blocked and cookies getting deleted, I am not saying thats the only method, but thats the one that I can best think of and argument for right now, while everyone else still fights the wall with cookies and javascript.

@Forside so now imagine, you use the rss feed and go to the blogpost directly, obviously without any ?get set, what happens, what do you think? please, this is getting really too ridicilous to explain anymore.

@JoshBent It would give you either the default theme because theres no theme parameter set, or it would give you the theme set by your cookie. Exactly what you'd expect. Where is the problem?

@JoshBent As the rss is currently created manually, neither GET nor subdomain would make a difference here. If linuxxx decides to let the rss be generated upon loading the url, subdomain and GET would work for creating the correct links with theme included.

@Forside ok, I'll write it slowly, so you can read it slowly - cookies - deleted - white theme always first.

@JoshBent Now for you: cookies deleted - theme param set - load theme from param. No white theme first.

@Forside I was writing already too that including two links in the rss feed would work, but again:

- open domain.com/?theme=night&post=introduction
- close browser with tab open
- next day open browser and get greeted by white theme

now with subdomains, you wouldn't have that.

Also not to mention that random get parameters would break the idea of rewriting the blogposts not to have GET parameters to begin with but being more cleaner like: much-security.nl/post/introduction as mentioned in the other rant.

@JoshBent I'd use subdomain as the least deciding factor so it only sets the theme if none of the others does.

URL fragment is a well defined part of the URL; the # and everything after it. And this might be possible to use to toggle themes by in CSS.

Cookies and JavaScript is only to enhance experience for those who support it :)

@JoshBent nevermind about that last one actually, since the get would be still set I believe for that specific tab, but as soon as you leave it, you would have to keep track of it or it would get deleted from the url (where the subdomain wouldn't)

@Flygger damn, another thing I forgot to mention during the heat of this conversation - indeed, to have it fully correctly support _everything_ you would have to implement them all and check for them all, which imho is much more trouble than going the way of assuming nobody has javascript and nobody has cookies.

@JoshBent Why would he be greeted by white theme? If the param is still set, it will still load the dark theme.

Here are all 4 scenarios, just for you:

Cookies disabled:
- no param set -> load white theme
- param set -> load dark theme

Cookies enabled:
- no param set -> load theme from cookie, white theme if cookie set, save white theme to cookie
- param set -> load theme from param, save to cookie

Not flashbang, no problematic with parameters, no problems. And no, you don't have to check if cookies are enabled. If they are disabled, they will just be ignored and the first two scenarios are applied.

@JoshBent In fact, only the last two scenarios are always applied. Because cookies are always available, at least for the current window, even if they are deleted afterwards.

@Forside now read how I corrected myself above already, basically saying exactly that, but giving another scenario where it would be more hassle to use it, when cookies are disabled.

@JoshBent Yeah, that wasn't displayed while I was writing.
To sum it up: My way does not assume anybody to have anything enabled. It easily works in any case without downsides, but with the plus of remembering the set theme if cookies are enabled. I never said a param or sub for setting the theme is bad, but it can also be used for storing that theme at the same time.

@Forside "It easily works in any case without downsides" - this gives me the impression, you again did not read the last post, its useless to argument with you, since you only read parts and then give out such statements, it has downsides and it does assume the user has the get parameter either across _all_ visited pages or has cookies enabled.

@JoshBent Honestly I didn't understand your last post and where you see a problem in it.
But does your way not assume the user has the subdomain across all pages?

@Forside in what situation would a subdomain get wiped all of the sudden?

@JoshBent It wouldn't, but it has to be used all the time. As I said, my way would work with param and subdomain. Of course a sub is easier to keep track of instead of appending the param to every link on the page, I don't deny that.

@Forside "Honestly I didn't understand your last post", I feel that's often a problem when you adress some of my or others comments, whenever I come across some of your replies, it's like you quickly skim through and then already typed half your message, take some time, theres no competition in sending your message first. I really don't understand anyway, how you can assume there is "no problems" with your solution, if there is one presented, but you just did not understand it.

@Forside

"It wouldn't, but it has to be used all the time."

How surprising, I have to go to devrant.com whenever I want to go to devrant, so would somebody that wants the dark version also just visit dark.domain.com..

"As I said, my way would work with param and subdomain." - so now you do mention all of the sudden again the by me mentioned problem at the very start, but this time you decided to go the other way:

"I didn't say both ways should be implemented 😆 Just either subdomain or GET."

do you read what you write yourself?

@JoshBent I have lots to do and don't always have time to read every single comment, but I try my best to give qualified content.

It seems we're standing at the same spot right now. You see no problem in your approach and I see no problem in my approach. Lets just wait what linuxxx thinks about it.

Go ahead with JS. People that has noscript can enjoy light theme.

1. Yes, but the domain doesn't make any modification. A sub that sets your preferred theme has to exist everytime you want to use it. Open a link form somwehere else and it's gone (just like with a param of course).

2. So what's the problem now? The dev can decide to go either for sub or param. My way can be adapted to both.

To take it from another point of view:
Lets say it's done exactly the way you want it.
Only addition: When the subdomain is set, the theme is written to a cookie. Now if no subdomain is set, the theme is loaded from the cookie instead of using the default theme. If there's no cookie because they are disabled, just use the default theme like always. What's wrong with that?

@Forside If you are such a busy person and can't read an entire comment (yes, one, you have proven that you can misread just one), how can that be counted anywhere near "quality"?

Regarding the rest of your numbered answers: you once again didn't read an entire comment, saying that another thing suggested was prettifying the urls via rewrites, where your implementation would be another itch down the crack.

Setting cookies with subdomains, thats finally not a too bad idea though, as it would combine the benefits of both and drop issues with others.

@JoshBent jQuery's xss bug:

https://stackoverflow.com/questions...

and one more I cannot remember atm

@calmyourtities "So this becomes a problem if and only if you put untrusted user data inside the jQuery selector function."

Hm.

@JoshBent Thanks for the last sentence.
Regarding rewrites, I didn't address them because this is a whole other topic. Switching to rewrites afterwards can easily result in reworking parts of the framework, so I was talking about the themability as an atomic feature. If linuxxx decides to want both included, we can think about how to combine it. Using subdomains could possibly make it easier here, but I believe it should be fairly easy to insert the theme as a param here too (like /post/about/theme/dark).

One other thing that just came to my mind: What if he actually wants to use subdomains with real subpages, not as a modifier. Then he would need to check if the given sub is a theme or a page or whatever.

@JoshBent

hey.

that doesn't matter.

back when this bug was around jQuery was heavily used, and shouldn't be vulnerable to such a silly bug. jQuery fixed it because they identified it as their bug and they fixed it.

its a security vulnerability, nothing do debeted about that.

@Forside You are now trying to address issues that are only theoretical, where as rewrites were actually considered by @linuxxx already.

Also adding /dark at the end would again have the same problem as parameters - you would have to keep track of them and have them always at the end, limiting the depth your urls can go, without having to do awkward hacks or rerouting your app.

@calmyourtities so they fixed it, after the issue got raised, whats the problem with jquery now, are you implying all software has to be bug free to be considerable?

@JoshBent I'm just talking about possibilities.
Params are a possiblity (probably with awkward hacks, right) and subdomains are a possibility. The latter should work fine as long as he doesn't want to use subs for something else. I never said something against that.

@Forside It's really just about not what will survive the blast, but the long effect of it, params clearly won't, as they bring too much issues up in the very near future (even as rewritten params as you see) and present, via constant theme resets, because of missing cookies or page change. Also having to reroute each time you want to add depth to your urls, is just beating a dead horse.

The only actual reasonable suggestion you did, was the combination of subdomain and cookies, which would as said, combine both worlds and I didn't yet see any problem with that.

@JoshBent Great! That's all I wanted.
My point was, we have the possibility to define a theme by either param or sub.
And after that we can store the theme in a cookie from either way. Independently.
That's all I wanted to point out.

I'm happy we came together now.

Just one more question: I believe cookies are deleted after leaving the whole page or even just when the browser is closed, but not every time you navigate to another location on the same website? If that's the case, you would not even have to apply the theme param to every link, because it's stored in the cookie as long as you don't close the site.

Edit: Pretty sure that's the case, or else you couldn't stay logged in anywhere in the current session.

@JoshBent no I'm implying that software with bugs in the past are more likely to get bugs in the future

@Forside nice catch, indeed, though that does not remove all the other issues.

@calmyourtities that again, makes no sense, any software out there had bugs and will have bugs.

@JoshBent I'm just saying if a program has had bugs in the past, it probably will have more in the future.

@calmyourtities I guess every software ever made had have bugs. Which can be fixed. And with new features there's potential for new bugs to come, which need to be fixed again.

@calmyourtities Every substantially sized software has bugs. Whether it be a framework, app, script, whatever.

Something will go wrong somewhere. There's so many variables that can go wrong. Especially projects with large amounts of contributors.

I wouldn't hate on jQuery because of one very specific security bug which was patched long ago. jQuery is losing a lot of traction these days anyways thanks to more modern frameworks.

@calmyourtities the only problem that would prevent people from reasonably using it, would be that there is active security bugs, that are not getting fixed or are getting denied, which none of those is the case here, saying that "there was [big,small,..] bugs in the past, so there will be new [big,small,..] ones too" is non-sense, as thats literally always the case, bugs happen, the only problem mostly is, if they get put under a carpet or sold to the gov. agencies and then leaked.

@FrodoSwaggins I was not thinking about putting logic onto the client side, but if I'm not wrong, alle the modern frameworks like angular, vue, whatever go for a full html+js client side, where all data is pulled from the server via ajax. So with noscript, a page using such framework would stay pretty blank.
Correct me if I'm wrong.

@FrodoSwaggins how would you tell if something runs via node.js? also you don't use any services that need atleast ajax to pull in status from the queue/conversion?

@FrodoSwaggins also a lot of things designwise can't be done without basic javascript binding to the elements, since not everything has a css hack to make it work (especially not live update, in-site content refresh etc.), the web is not only text and images anymore imho, so the approach of blocking basic signatures, trackers etc. is for me easier (and achieves exactly the same in the end I believe?), than completely breaking nearly 95% of the websites I use (including devrant, which uses ajax to pull new content in iirc)

@FrodoSwaggins The devrant app is actually also built on something similar to cordova (like many other apps), which in the end is just a packaged browser showing an app/website and since devrant needs an internet connection (like most), there could be easily user behaviour tracking implemented, do you check those apps via some ssl mitm or does it only stop at the browser you use on your pc? Its just really hard to get around javascript and its sad abuse sometimes, but mostly it actually does serve some harmless purpose.

@FrodoSwaggins You're right. I was also wondering why nowadays everything needs to be loaded dynamically. Back then when I was developing websites, there was no react or angular. I generated everything server side with PHP and that's still possible.

I think one of the hugest advantes of javascript and ajax is the possibility to apply changes and load content dynamically without reloading the whole page. Like posting a comment. It posts a simple json string to the server, receives a true or false result and displays the message on the page. All without reloading the whole page and loading unnecessary amounts of data from the server. This would actually reduce the workload on the server and the client.

@FrodoSwaggins
Ah, you probably mean websocketted websites that communicate with a nodejs server, not something like express.

It doesn't have to be flying, it can be things like a simple button and its onclick event, without redirecting the entire website via a form submitted via that button. It would be really a pain both for the user and developer, having to smash forms everywhere a button function is needed and having the page to fully reload all its content/resources. (especially because there is no content change in those reloaded resources)

The drinking argument was great though 😆

@JoshBent You can still put a button inside an <a> tag. But yes, would still be a full redirect.

@Forside and then what, have exactly the same result still? form or link, the page still fully reloads without js preventing the default.

@JoshBent Correct, just wanted to point that out 😅

As a privacy focused site, you should ask for permission to use javascript, then if they accept, and only if they accept load in the script(s)

@incognito Although it's somehow weird to do that, it's a good idea! Fits the site. On the other hand, one would need a cookie to remember the answer...
In the discussion before I thought about using PHP session, but that's also just cookies.

@Forside hmm but what if a user accepts javascript, but not cookies? Also how do you store or remember the fact that the user doesn't allow cookies? (maybe say you would create a cookie non the less, but if the user doesn't allow for cookies, only write that?)

And inform them of doing so

@incognito Either do nothing so that the question appears over and over, or set the cookie alive time just for the session, so they will automatically be deleted when the tab or window is closed.

I haven't read all answers and maybe it had already been said. How about using url parameters (and maybe cookies) like ddg and change the theme Serverside

@xenira @JoshBent What do you think about this? 😄

@linuxxx just use React 😂

https://just-a-blog.firebaseapp.com/...

@xenira @Forside Oh, here we go again, huh.. 😥 please read the thread, we discussed this in such a detail, why thats not a great idea.

@camelCase using react would end in completely being rendered blank on javascript blocking browsers, right? (just like angular)

@JoshBent yep 😅

@camelCase React is a no go for me since Facebook developed it :)

@linuxxx but it's open source and MIT! 😞

@linuxxx I think react is also kinda bad compared to angular and vue? Don't know much about it and haven't used any of those, but from what I've read I would personally go for vue atm.

@camelCase Used to be under a restrictive license and still the fact that its developed by Facebook and there are many alternatives makes it a no go for me :)
@Forside have heard that as well!

@linuxxx have you read the entire discussion about the methods above?

@JoshBent Not entirely yet, had a bad day and hardly motivated to do any fucking thing right now. Installing an email server though.

@linuxxx last time I installed a mailing server, I had a bad day too, maybe just move doing something at all to another day 😅