GitHub Dark – Switch off the lights
cquanu.github.io
cquanu.github.io
Dark Background and Light Text by Mikhail Khvoinitsky https://addons.mozilla.org/en-GB/android/addon/dark-backgrou...
It just works™ about everywhere. It is also available on the desktop version, although I've never tried it myself.
It took some googling because I didn't know the terminology, but this is what I am talking about: A "Pivot" screen for the Mac by Radius.
http://lowendmac.com/wp-content/uploads/radius-pivot-display...
Another example of this is street signs. The oldest sign standards (speed limits, street names) are black text on white backgrounds. But the newer ones (highway information signs) are normally white on a dark green background, which is much easier to read at night.
This is an unfortunately common misconception. Sometimes yes, sometimes not. It is highly dependent on condition, in particular with what part of the field is obscured/impaired. I lack around 90% of my FOV - no central vision - resulting in ~20/200 acuity and while I find black on white to be incredibly discomforting I also don't get on with many 'high contrast' dark schemes. At the same time many of my friends with similar acuity but different conditions would be driven screaming from the room by some of my color scheme choices.
The contrast/color sweet spot varies (anecdotally, at least) greatly across both conditions and individuals.
The scientific literature on readability does not back this up. Results show large individual variability with a small overall preference for dark-on-light.
Some old papers cited here: https://www.joedolson.com/2006/08/on-the-readability-of-inve...
EDIT: Also here is a good example of how reading white on black is hard: http://www.ironicsans.com/owmyeyes/
After coming back to HN from that site, I've been seeing text superimposed everywhere.
Furthermore, white-on-black isn't really the best. It's just the inverse of what we see on most sites/devices. Try green, or red on black. It has a very different effect as it is better tuned to the biology of the human eye, which is why it works better in low-light conditions such as driving.
For late-night, in the dark work I often use the darkroom mode of F.lux instead.
Not sure about the effects, possibly none. Not sure if I want to be part of the experiment.
Regardless, I've been using a dark GitHub theme¹ and a dark Firefox theme², as well as a variety of other dark themes (e.g. Emacs tao-theme, dark terminal themes, dark Thunderbird) with no ill effects (so far)—on the other hand, my vision is not the best anyway.
--
¹ https://github.com/StylishThemes/GitHub-Dark
² https://addons.mozilla.org/en-US/firefox/addon/ft-deepdark/
When designing an inversion its important to increase contrast to maintain a perceived equivalence in overall dynamic range with the original.
Typography is affected, as well, in that the darker color is dominant over the brighter which results in small negative spaces seeming smaller and large ones larger. A slight increase in tracking and a reduction in word spacing is the typical approach for setting inverted type to maintain both legibility and readability.
https://bugs.chromium.org/p/chromium/issues/detail?id=21798
https://bugs.chromium.org/p/chromium/issues/detail?id=470669
This dark theme, however, did work: https://userstyles.org/styles/37035/github-dark
If you find any bugs/problems, please tell me. I'll release a fix within 24 hours. Appreciate all positive and negative feedback.
I haven't added this to my browser, but how well does it display code too?
In Stylish, install this theme https://userstyles.org/styles/128271 or this one http://userstyles.org/styles/37035
Has this problem been solved shy from using lynx/emacs/ect?
I really, really hate what the web has become. Twenty years ago I could set my foreground and background colours and everything Just Worked™. Now … forget about it!
JS-based styles are still subject to a bit of delay because of script parsing/executing in case you're using those.
Only do that if you don't mind that it is completely insecure. The password you sign in is used to encrypt the master key for your account (which means that if you can remember your password, Mozilla can decrypt your synced data). Worse, the login code is JavaScript served from Mozilla's servers, so they can at any time target one a send one's password anywhere they wish.
But hey, you'd still be running Mozilla's code in and as your browser. As you say, they can "decrypt your synced data" and "at any time target one a send one's password anywhere they wish" even if you self-host the sync and auth servers.
But at least Mozilla has a history of standing for the consumer and protecting user rights. And Firefox is perhaps the only browser that allows hosting your own sync and auth servers without having build your own copies of the browser.
Only a server which you physically control — if it's in the cloud, it could be tampered with without your knowledge. And you must still use a high-entropy, unmemorable password.
> But hey, you'd still be running Mozilla's code in and as your browser.
There's a difference between trusting code at a point in time and trusting every single response ever. Sneaking a trojan into code which is visible to the world is hard; sneaking a trojan into a single targeted response is easy.
> But at least Mozilla has a history of standing for the consumer and protecting user rights.
Sure, but that doesn't protect you against a single bad employee or against any government which Mozilla is subject to.
> And Firefox is perhaps the only browser that allows hosting your own sync and auth servers without having build your own copies of the browser.
Yes, and I appreciate that. What really hurts is that Firefox used to have great sync security. I ran my own sync server for years, and was very happy with it. But when they revised the protocol they destroyed its security. Firefox Sync is unacceptable for password storage (as is every other sync system of which I'm aware).
It's a distressing situation.
Oh, I'm unknowledgeable about this. Could you expand a bit on why it is insecure or what they did to it to make it insecure etc. Even just links would be enough.
Sure thing. I'm referring to https://blog.mozilla.org/warner/2014/05/23/the-new-sync-prot... for details of the new protocol.
Your synced data is encrypted with a 256-bit key kB. So far, so good. The problem is that kB is encrypted using a function of your Firefox Account password: if someone can guess or intercept your password, then he can decrypt kB and then decrypt any synced data.
So, how hard is it to guess or intercept your password? Well, if you can remember your Firefox Account password, it's almost certainly guessable given enough machines. Human-memorable passwords almost never have high enough entropy to survive sustained attack.
But maybe you store a truly high-entropy password (e.g. i2FH9E0G6PoCZm41C0pIJdLg1uOcGaA0GfhxKUtSQ) elsewhere, and enter it into the Firefox Account sign-in screen. Now no-one can guess your password, and that means that you're secure, right?
Wrong: the Firefox Account sign-in screen (https://accounts.firefox.com/signin) is served from Mozilla's servers, which means that any time you visit it they may choose to serve JavaScript which transmits your password to them (normally they would perform all operations on your password locally).
'But I trust Mozilla to write Firefox!' you might argue. Sure, but it's (theoretically) possible to verify the Firefox source and binaries once; it's (theoretically) possible to verify that the source or binary they serve you is the same as that they serve to the rest of the world. With code delivered online, an attack can be targeted just once, at a single person: if you're not logging each and every login form's source code then you're exposed. A malicious (or compelled) Mozilla employee (or employees) could target a user; moreover, any government Mozilla is subject to could compel it to target a user.
Their old system performed all operations locally, always; it never downloaded and then executed source. It was secure. Their new system is not much better than, 'trust us.'