Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Update on the Lock Icon

blog.chromium.org

Post reply on HN
Print view View original

111–120 of 169 posts

Re: An Update on the Lock Icon

#111

Post by sedatk »

ladon86 wrote: post #50

It’s a continuation of the trend that led to them removing Extended Validation indicators: https://duo.com/decipher/chrome-and-firefox-removing-ev-cert... Here’s how they used to appear: https://pbs.twimg.com/media/EBxdA7EWsAIQtc0.jpg While I buy the reasoning that consumers simply ignore them, EV indicators would be really useful in a corporate setting to mitigate phishing attempts against employees. It’s much easie…

> EV indicators would be really useful in a corporate setting to mitigate phishing attempts against employees

I believe that kind of "negative awareness", the awareness that need you to keep checking if something has disappeared constantly doesn't work well in practice. You naturally develop blindness to that element, and therefore to its absence too.

Re: An Update on the Lock Icon

#112

Post by GuB-42 »

kaycebasques wrote: post #74

It's been interesting to watch the web landscape change over the last 8 years. Back in 205 when I joined Google's Web DevRel team, I worked with Chrome security engineers to create a persuasion article [1] about why all sites should be encrypted with HTTPS. The fact that they felt the need to create that page at all indicates that HTTPS was not that common. In 8 years the ecosystem has got to a place where HTTPS is s…

And even before that, you got a popup when https was used. Something along the lines of "Warning: this site is secure".

Re: An Update on the Lock Icon

#113

Post by noduerme »

dadrian wrote: post #100
p1mrx wrote: post #25

Earlier quoted context omitted.

Chrome redirects to https://example.com , so that's no bueno for testing http:// in your URL bar. Edit: I'm running Chrome OS 113 beta. Maybe they changed something recently, to automatically use HTTPS unless prohibited by the server? This also happens in Guest mode with no extensions.

In (50%) of Beta, Chrome attempts HTTPS and silently falls back to HTTP on all HTTP links. We're still poking around with opt-outs, currently if you allow insecure content via Page Info / Site Controls, we stop upgrades.

Somewhere in the past six months, on a page where we have to force users to HTTP, Chrome on Android has broken about 90% of the time with "too many redirects" and no way to even type "http://" into the URL bar without Chrome changing it. Finally had to just give users a raw IP address. I would love if your team could fix this or provide some opt-out.

For context, each of the retail locations of our company runs its own local MAMP server that serves a web app used all day by the employees on their tablets. It's accessible only on the LAN. Rather than have every employee need to know or type the local IP address for these (which change sometimes), we serve a centralized web page at http://ourcompany.com/employeeApp that just keeps a live list of the local (192.x.x.x) IP addresses harvested from each server in each location, and opens a connection to the local server in an iFrame. Because of what's now a hard ban on loading insecure HTTP content within an HTTPS page, we must serve that central iFrame wrapper page over HTTP. Unfortunately, we now need to give Chrome users a raw IP address for ourcompany.com, to avoid them being redirected infinitely to HTTPS and back.

[edit] I should add that the oddest thing is that it doesn't always overflow with redirects, and on a new device it often is able to go to the HTTP site. But once someone does type https:// or leave out the http:// by mistake, no level of cache clearing seems to remove Chrome's insistence on trying to force HTTPS on that page forever afterwards.

[edit2] The rationale for not setting up local DNS and SSL is that these servers are on all kinds of different local networks in stores around the country, are switched on and off by non-technical managers onsite, and I'm the author of the web app and the only tech support for it. It needs to be as simple as possible so that I'm not spending all my time tunneling into those servers, walking them through router problems and stuff like that.

Re: An Update on the Lock Icon

#114

Post by madeofpalk »

sedatk wrote: post #107
mholt wrote: post #24

For my masters thesis, I proposed replacing the security indicator with a risk indicator: "After HTTPS: Indicating Risk Instead of Security" - https://scholarsarchive.byu.edu/etd/7403/ Turns out there are lots of localized, privacy-preserving cues you can observe to determine whether a user may be at some level of risk, that doesn't involve a centralized blocklist or a boolean answer; and users really appreciated the…

Microsoft Edge already does that. They show a quite prominent "Not secure" sign with an exclamation mark instead of the regular hollowed out (aka very indistinguishable) lock icon when the connection isn't trusted HTTPS.

All browsers to do this now, to varying levels of severity.

Firefox gets a padlock with a red slash through it, Chrome gets that warning icon with "Not secure", and Safari just says "Not secure".

Re: An Update on the Lock Icon

#115

Post by userbinator »

politelemon wrote: post #10

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 chang…

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.

Re: An Update on the Lock Icon

#116

Post by anon3242 »

Wowfunhappy wrote: post #106

> The new icon is scheduled to launch in Chrome 117, which releases in early September 2023, as part of a general design refresh for desktop platforms. I downloaded Chrome Canary to take a look at this "general design refresh" and... sigh. The new browser UI is now 10 pixels taller than the old one. I realize 10 pixels isn't a lot. But it's also not noting—it's half the height of the top bar on Hacker News. And this…

It is not just about pixels... The line-height of the text in the address bar simply feels wrong to me. We now have more spaces but smaller, harder to see text. Feels like going backwards for me. Reminds me of the new Steam download UI, the elements are larger while the download speed is much harder to discrern. I rememember lying on bed checking on the game download speed in my high school years, now I have to get real close to see the current speed.

The rest of the "refresh" actually seems not unacceptably bad.

Some 'designers' just blatantly waste advanced technology and screen real estate. Like I finally built a PC that can open right-click menus in an instant wihout having to watch the spinner, and then windows 11 decided that having (unskippable!) transitions to open menus is a good idea. I went out of my way to make sure I have the lowest-latency mouse and monitor, and websites use these custom css scrollbars that have nearly 2 frames of more latency that the system one, also dragging windows in and out of Stage Manager make your mouse have massive latency for a while.

I am at least happy with macOS though, at least the line-height is not going wild. Seems Apple have some of their soul left, though they may be lost soon. Even just being a novice macOS user I can immediately tell whether any animation is done pre or post 2020.

Re: An Update on the Lock Icon

#117

Post by verdverm »

hbn wrote: post #94
thetinguy wrote: post #91

Earlier quoted context omitted.

Good luck describing that icon in words over the phone.

"See the 2 people with all their limbs cut off, staring up at the clouds?"

My first impression was 69, but I may be biased since it is the month & day of my birth

Re: An Update on the Lock Icon

#118

Post by _23sd »

politelemon wrote: post #10

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 chang…

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.

Re: An Update on the Lock Icon

#119

Post by re »

shawnz wrote: post #77
re wrote: post #46

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=35792149 The primary goal of NeverSSL is to be useful on networks with captive portals that intercept HTTP and block HTTPS (until you have signed in). The JavaScript redirect is at least browser cacheable, whereas a 301 redirect sent via HTTPS would be useless in that scenario as it would fail to load.

Isn't a 301 response cacheable?

Yes, sorry: the other piece is that NeverSSL wants to redirect to a new domain every time you visit to ensure that the page that you was actually loaded from the network and not from a cache, which a cached 301 to a fixed address wouldn't accomplish.

https://twitter.com/NeverSSL/status/1136488879106666496

Post reply on HN