Hacker News new | ask | show | jobs
by politelemon 1139 days ago
Reading through this it's making a lot of sense, the lock icon was added to convey that the 'connection is secure', while making the assumption that the user understood it's talking about the transport layer behind the scenes. Of course, most users cannot be expected to know that kind of detail, so they would associate it with the thing in front of their eyes, the website itself.

I am sticking to Firefox but as changes go, this wouldn't be a terrible one for non-Chrome browsers to converge upon. I don't think it's a good idea to hide the option away entirely though; a lack of available information and options for a user on a platform can often lead to the platform itself deciding it needs to become the arbiter of information, but I assume the iOS limitation is Apple's usual user-hostile behaviour.

3 comments

When we were hosting custom websites for various university departments on the cheap, at this point it was difficult to do HTTPS on a site that shared IPs (which I gather has been corrected). One group insisted on it, despite that their form results, which weren't exactly secret squirrel knowledge, got stuffed into plain ole SMTP emails. I explained this carefully.

"But it has a LOCK on it ..." It was impossible to get them to understand that SSL only protected one part of the movement of data. All they got was LOCK.

So, yes, I agree that the lock offers a kind of false sense of security to people who will latch onto that symbol even as the people providing the hosting tell them otherwise.

> (which I gather has been corrected)

Indeed. In two different directions, even. First, a server can send a certificate with a large number of domain names in a field called "Subject Alternate Name" (SAN). If a server host a small number of static names, that's an easy solution.

Second, the client can use a TLS extension called "Server Name Indication" (SNI) to tell the server what name it's attempting to connect to. This is more recent than the SAN approach, and allows a single host to work for truly ridiculous sets of different names, even changing them dynamically.

while making the assumption that the user understood it's talking about the transport layer behind the scenes

I remember using an early (90s?) browser that explicitly said "Secured Connection" in the status bar with an icon that featured a depiction of a network cable. I don't remember the details, but I think that may have been in the early days of SSL.

imo it's the use of the word "secured" at all that's the problem, not the context to which it's applied. "Secured" can mean many things to many people, whereas "Encrypted" is much more descriptive as to what's actually happening and much less subject to interpretation.
The lock icon is tappable in other iOS browsers (Firefox, Brave, DDG, the list goes on). Chrome chooses to put site settings and SSL info in a different menu in the iOS version. I'm not sure which iOS platform limitation you're referring to.