qutebrowser
qutebrowser copied to clipboard
Mark HTTP sites as insecure
Chromium starts marking HTTP (non-HTTPS) pages as "Not secure" starting July.
We should do something similar. Not sure yet about how it'd work. What I can think of:
- Show the whole URL in yellow, like after a SSL error
- Like above, but add a new setting for that color
- Show the http://example.com part in a different color (e.g. red)
- Show a "(Not secure)" in front of the URL
FWIW Chromium 68 which does this has been released today.
@The-Compiler commented on July 24, 2018 10:34 AM:
- Show the whole URL in yellow, like after a SSL error
- Like above, but add a new setting for that color
Aren't those already possible with colors.statusbar.url.success.http
?
My 2c on this is that just because chrome does some ui change, doesn't mean we should do it either. Many people use qb precisely because google cannot control its ui. Since we are already marking https
as "secure" with green, I don't think we need to push it any more. When I see 'red/yellow' I think more of 'errors' than 'no ssl' (and because of that, I would put the setting back to the default). Since most browsers don't do this, there's no "implicit standard" to follow here, unless chrome is setting the standard by itself.
Since people can already make the standard plain http color more distinct with their own theme if they want, I really don't think there's anything to do here.
The ability to set a custom status string for those would be nice, so I can put a padlock in there :^)
I'm all in favor of marking http sites as insecure, as I feel that https should be the standard on the web.
Be that as it may, that's not the reason I dug up this thread.
If you implement this, please also mark sites, that are https but contain forms that send over http like https://very.badssl.com/ as insecure (whatever stance you have on plain http sites, imho these chimeras should be marked as insecure as it is very surprising to have forms unencrypted while the rest of the site is)
Any javascript click handler that made an XHR request to an HTTP URL would fall under the same argument though and it isn't possible to enumerate all those possibilities before they happen. Saying that a site hasn't loaded any mixed resources and saying that it won't be allowed to are different things. I think we do have the ability to stop mixed requests via the interceptor API but we can't colour the status bar ahead of time.
That makes sense but is fine with me: I would like a popup to deny me submitting the form if it is http even better.
https://browserleaks.com/ssl reports qutebrowser loads mixed image contents. Firefox and librewolf behave differently.
@amano-kenji That seems to have nothing to do with what this issue is about. I opened #7226.