Switch generic icon to negative feedback for non-https sites
bugzilla.mozilla.org
bugzilla.mozilla.org
There's a lot more to designing a UI for this than just changing the icon. For example, when you type "foo.com" into the address bar, browsers generally default to "http://foo.com" instead of "https://foo.com." And, consequently, browsers tend to show "http://foo.com" as "foo.com" to suggest that you don't need to type the "http://" part. All of that needs to change to become a lot smarter in order for this type of idea to succeed. However, it doesn't seem completely unreasonable to consider making all those changes. In fact, I think these changes should be a high priority for browsers makers.
tl;dr: I suggest people brainstorm ways to improve upon the idea to make it workable, instead of trying to shoot it down.
If it goes ahead with certificate"less" https by default i'd wonder if they would use that icon for https websites which dont have a certificate ;)
If you draw people's attention to something that isn't seriously important, then those times when the whole screen sends a warning you go, "oh well, I had that red warning going all along and it didn't matter, so why do I care?"
I am saying that by pushing a warning where it's not necessary, you diminish the value of any warning.
See my other replies on this page for some reasons why I think there are no pages where HTTPS is not important.
I agree with you regarding the UI issues and the potential to generate apathy by crying wolf. That's why I think that the specifics of the linked-to proposal won't work. But, I think the general idea is worth investigating. It just requires some user research.
Also, the fact that browsers support a non-HTTPS mode at all is really the bigger UI issue. Imagine if HTTPS was the only option. The biggest UI security problems would instantly vanish! That's a big reason why a lot of people are actively working so hard on finding ways to make HTTPS work for everybody on every site.
Not all sites exchange data worth the SSL-layer...let's say, 30-50% of the sites...that means for roughly half a user's non-email/social-networking web-browsing, they're going to either be saturated with a warning message that, if psychology research is to believed, is going to be promptly ignored like your apartment's super-sensitive smoke detector or the boy watching out for wolves.
What's the actual reasoning in OP's mind here? That the average web user is someone who, when the computer gives some warning sign that is disconnected from any kind of discernable threat, that the user will automatically take it seriously? That they'll demand to know why they're in danger, and then will rise up and petition the Internet regulatory commission to make all sites do what it takes to make that red icon go away, and the web will be more secure?
I don't want to be overtly negative towards well-intended idealism, but this is such a bizarrely naive viewpoint that it must be openly challenged. That, and it just blithely ignores all the research showing what happens when humans are overloaded with impotent warning signs. This is the kind of idealism-without-consequences that can end up causing more harm than good.
A. Reconfiguring their stack to use SSL.
B. Putting a Javascript-powered banner helpfully informing all Firefox users that their browser has a security flaw ("that's why that red icon is there") and they should follow the included hyperlinks to install the latest versions of Internet Explorer or Chrome and then delete Firefox from their systems.
[1] Passive indicators are things like the red/broken lock icon. Active indicators the the things that stop the page load, like the "Stop! This is probably a phishing page!" error page. IIRC, users overwhelmingly appreciated the active indicators but tend to misunderstand the passive ones.
Here's an experiment you can do at home: Try telling an emacs user Vim is better.
For example, let's say you wrote a blog post about fixing a configuration issue for touchpad issues on a ThinkPad X1 Carbon on Ubuntu 12.04. Imagine that a passive MitM saved the IP address of everybody who read that blog post in a database. Then, if an "interesting" person is known to be a ThinkPad X1 Carbon owner that uses Ubuntu 12.04. They can use that list of IP addresses of readers of that specific blog post to help narrow the search for the possible locations (via geo-IP) of that user.
Right now it is pretty easy to distinguish which webpage on your blog the reader is reading through traffic analysis, even when HTTPS is being used. But, people are working on things that make that traffic analysis more difficult.
There's a parallel universe where ssh is plaintext, and only "sensitive commands", such as "sudo", are encrypted. In that universe though, plaintext HTTP doesn't exist and they're making fun of us.
You're answering "why" instead of answering "why not" again. "Why should you lock your door if you don't have anything expensive?"
Plaintext HTTP should not exist, then we wouldn't be having this discussion. I wouldn't have to come up with elaborate scenarios where having HTTPS from the get go would have saved lives, and you wouldn't have to come up with crazy "but that'll never happen" retort to them.
Unfortunately, plaintext HTTP exists, so here we are, with me telling you that the pro-gay rights piece you wrote on your static blog contains keywords that make it be viewed as extremism/terrorism by Russia's automated monitoring systems and anyone reading it gets immediately added to a watchlist. Unfortunately, a few of your readers are from russia and six months later those readers join a political protest against the killing of kittens or something. Their government notices that and makes sure to "take action". And to think HTTPS could have avoided that.
Locks come standard on every door, they don't expire after a given time and every child knows how to use them. See how your comparison to acquiring, setting up and maintainning an SSL certificate is nonsensical?
> And to think HTTPS could have avoided that.
If the NSA tags people who look for info on TOR as extremists, an hypothetical state might tag people who use HTTPS. And to think that HTTP could have avoided that! I mean, if every argument is an hypothetical, anything is possible.
Thank you for reinforcing my point, I appreciate the help.
Define "sensitive".
If there is a network attack[0] then the metadata of who is viewing which pages on your blog is revealed. With TLS, only the client/server address pair is leaked.
IPv6 will bring back enough IP's to allow each site to be it's own IP, and no longer require SNI...
One day, HTTPS may organically become the default for all websites, but pretending that it can happen over-night is crazy and that is what this change is basically expecting people to do.
For example, I host my personal sites and a bunch of my friends and friends' businesses' sites for free. Sites that otherwise wouldn't be online. I do it via the Rackspace Cloud Sites platform because it has better performance than typical 'shared' hosting. If I want an SSL certificate running on one of them, it's $20 per month per domain... in addition to the actual yearly cost for the certificate. I don't have that for sites I give away for free.
That's in addition to the hassle for the 3 days and multiple faxes and phone calls it takes for me to renew my businesses that do use SSL certs from reputable providers (as opposed to the $10-$20 a year providers that don't bother to even check who is buying the cert).
The SSL cert setup isn't terribly secure, is a big hassle, and costs a prohibitive amount of money for most smaller sites.
After a transition period, all plaintext protocols should be completely deprecated except for extremely special use, much like telnet was.
Or even better, make the secure icon something universally positive, like a green smiley face or a check mark. Then the insecure icon can be an orange sad face or X mark. (Lock icon can be ambiguous to non-techies. i.e. why is the url locked? or is that a suitcase/purse?)
I like this idea, but not when it puts more money in the pocket of the CAs.
Not to mention this is just some random guy. It's not like mozilla is actually thinking about this (they really should).
Not really - changes like this don't exist in a vacuum. Anything that makes the existing CA's more indispensable (say, by driving customers their way by making it appear bad to not do business with them) is a net negative.
In actual use, it works like this: • You implement DNSSEC (easier when it's done automatically; going forward, my proposal is that every DNS registrar must support DS records in order to renew their registrar licence - adapt or die: I'm looking especially at you, Namecheap) • You publish a TLSA record • This contains a hash of a certificate's public key (other options are available, like hashing the whole certificate, or even including the whole certificate, but this is the most sensible one) and a pinning mode, one of: - 0: CA Constraint - Certificate must be trusted by browser, AND this particular CA must sign it - 1: Service Certificate Constraint - Certificate must be trusted by browser, AND it must be this particular certificate - 2: Trust Anchor Assertion: This particular CA must sign the certificate - 3: Domain-Issued Certificate: It must be this particular certificate
Basically, this is a way to 'pin' certificates to DNSSEC, either additionally (0,1) or instead of (2,3) the PKIX CA system. Already implemented in Chrome as a test but taken out because no-one used it - it can come back. If clients implement it, we can replace/augment the CA system as necessary.
You're welcome.
What happens on the other browsers? Scary warning?
I'd be curious to know how this would affect local servers in the intranet. Surely we wouldn't want to have to start issuing certs for everything inside the firewall as well?
I think this is a bit too shortsighted of a bug report. Anyways, since this is not an official proposal, I think it will just be closed as invalid by Mozilla.