There have been a few times when I've got a legitimate red icon for bad certificates and what not. Pushing this to the rest of the web will mean I'll miss real errors through the noise because they happen so infrequently that I'll just stop checking if every website has a red icon.
Browsers completely stop the page from loading and show a full-page error for a certificate error. There's a huge difference between that and a small icon in the location bar. Plus, if the red icon that is suggested in that bug report is too loud, a less loud indicator could be used instead.
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.
Honestly, I'd prefer a heuristic that could determine whether https was significant on the current URL. Are there submitted values, cookies of importance, get parameters? There are a lot of reasons https is important and there are a lot of places where it's totally not important.
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.
> There are a lot of places where it's totally not important.
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.
FWIW, ~33% of all pages are loaded over HTTPS already in Firefox, according to the metrics collected by the browser. And, over 50% of all HTTP requests (including subresources like images and scripts embedded on a page) are over HTTPS, again according to the usage data collected by the browser.
I'd be willing to bet quite high all these HTTPS requests are all on the same specific services (facebook, gmail, google would already take most of them).
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.
This is not a user-oriented proposal, this is clearly directed at the website owners which are not going to want their users to see red stuff on the URL bar.
Not a bad strategy. Until the website owners take the path of least resistance between:
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.
That B strategy might have worked a few years back for grandmas that got Firefox installed by their geeky grandson, but Firefox is popular now. And people (geek or no geek) don't like being told the stuff they use is not good.
Here's an experiment you can do at home: Try telling an emacs user Vim is better.
Regarding (B): A few years ago Mozilla did some user research that showed that a significant percentage of people do perceive the passive[1] negative security indicators as indicating a problem with Firefox instead of the web page. Thus, such a change does have to be done carefully. But, I think it is worth trying to find a way to do it that users can understand.
[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.
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.
It shouldn't because getting a reliable certificate costs money and the knowledge to setup and (more importantly) secure that certificate. I don't want to pay for a certificate for every static project page I setup and worry about setting up the certificate (if I even can, which I can't if I use something like Github pages).
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.
Because no sensitive content is being transferred. Why put the extra hassle of getting and installing a non-self-signed certificate for a blog where the user doesn't even submit data? There's no reason for that connection to be secure.
> Because no sensitive content is being transferred.
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.
> "Why should you lock your door if you don't have anything expensive?"
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.
If HTTPS is used globally, people can't be flagged for using it (or the flags end up being useless). Right now, you are correct, people could hypothetically be flagged for using HTTPS. This would not happen if every static blog and what not out there would use it.
Thank you for reinforcing my point, I appreciate the help.
It leaks data on what articles the user is reading. It also leaks data on their browser configuration. On top of that, an attacker could modify the content delivered from the blog to influence user actions. Either technically (like put a link to a child porn site to get the target's computer to make such a request and cache it), or socially (like changing the message of the blog to provide a bad recipe for a cake, or misleading info on a political candidate).
>Because no sensitive content is being transferred.
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.
And the hostname of the server you are connecting to... if SNI is used because we don't have enough IPv4 addresses to host every single site on a unique IP.
IPv6 will bring back enough IP's to allow each site to be it's own IP, and no longer require SNI...
HTTPS does nothing for anonymity, though, right? It's only for protecting the actual content being transmitted? If so, there is no sensitive content being exchanged between a user and a static page that doesn't support login or anything.
Aggregating the content of the web pages you have read can be used to deduce your identity, and/or the content of the web pages can be used to select you for targeting, like in the article I linked to above.
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.
What about warning the user when they start to type in a login box on a non-https site? Browsers should already know what is a login box, since they know how to prompt you to remember the password.
The proposed icon is hard to parse. Better an open lock? And maybe in orange instead of jarring red.
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?)
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.
So... You're suggesting to do something that was at one point implemented in one of the major browsers, but isn't even implemented in that one currently.
What happens on the other browsers? Scary warning?
If a better/broader alternative to CAs comes along and is adopted (say, such as SPDY), I take it the icon would behave the same way. Your comment is really unwarranted...
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.
They should at least wait for DANE + DNSSEC, which is a tangible (and free) alternative to the CA system, even though it would still be quite a bit of effort.
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.
