While we're fixing the UI for SSL, can we do something about unsecure connections to devices on my home network? At best I get a huge security warning that makes me jump through hoops to get past it, sometimes Chrome won't even let me get past without knowing the secret code. Surely we can figure out how to tell that a connection is only on the local network, and then give the user a one-time option to not worry about encryption for such local connections?
An Update on the Lock Icon
71–80 of 169 posts
Re: An Update on the Lock Icon
#72Think of all the webpages that tell people to look for a padlock icon in their browser? All the books, all the training materials, videos, etc. This doesn't seem like a good idea at all.
[deleted]
Re: An Update on the Lock Icon
#73Earlier quoted context omitted.
> it supports SSL for some unfathomable reason. "neverssl.com now supports ssl, as some browsers and sites automatically use https even when you don't type that in. You get a browser-cacheable page that still helps you get online by forcing a request that ... never uses ssl." -- https://twitter.com/NeverSSL/status/1456310362551164928 They're trying to solve the "how do log into this captive portal" problem, and they…
Wow. Unfathomable indeed; that action and that explanation make no sense to me, and they haven’t even updated the HTML served—it still makes the claim of “never SSL” they’ve reneged on.
Re: An Update on the Lock Icon
#74It'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 so common that we don't even need UI for it anymore.
Re: An Update on the Lock Icon
#75If you're using Chrome, right-click the URL bar and check "Always show full URLs", so you can see the https:// prefix like it's 1999. This also fixes a variety of UX problems with editing URLs. By the way, does anyone know of a good alternative to http://neverssl.com ? I had been using this for years, but now it supports SSL for some unfathomable reason.
For forever I used yahoo.com to login to a captive portal. I don't know why, but for some reason it worked for me when typing google.com, etc didn't work. Somehow I figured that out and stuck to it. I haven't done it in a while, though, not sure if it would still work.
I always figured this was due to DNS caching: if you got a domain you never visit, it has to actually fetch it and that triggers the captive portal login .
Re: An Update on the Lock Icon
#76Such a cryptic lock is even more confusing. I propose a very simple, easy to understand solution: http should simply be RED https should not be indicated at all A curated list, preferably by the gov. should indicate which SSL certificates are allowed to be green.
Any tech curated by the government is likely shit. Better to avoid.
Re: An Update on the Lock Icon
#77Earlier quoted context omitted.
neverssl seems to be doing some weird thing where it uses Javascript to load a non-https link rather than an actual redirect. I can't for the life of me guess why that would be better than a simple 301 redirect.
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?
Re: An Update on the Lock Icon
#78While we're fixing the UI for SSL, can we do something about unsecure connections to devices on my home network? At best I get a huge security warning that makes me jump through hoops to get past it, sometimes Chrome won't even let me get past without knowing the secret code. Surely we can figure out how to tell that a connection is only on the local network, and then give the user a one-time option to not worry abou…
I think the concerns/difficulties are:
1) Business contexts. A local network maybe shouldn't be trusted, there, for security purposes. "OK, but they should set that with policies" which, yes, sure, but defaults do matter, so... I dunno, I can see why they'd prefer the safer default.
2) Lying DNS servers on a local-but-actually-public network (think: coffee shop wifi) directing you to a local address to bypass SSL protection while it proxies Amazon or your bank website or whatever, and steals your credentials.
3) IPv6 is supposed to render these distinctions rather moot (although, LOL, and also that's precisely one thing some folks don't like about it, but that's another topic)
Re: An Update on the Lock Icon
#79Earlier quoted context omitted.
If you had a tornado siren go off every 20 minutes every single day of the year, how long before you stopped ignoring the siren? How surprised would you be when a tornado hit 2 year later? "This product causes cancer" is ineffective when the warning is plastered on everything. Same goes for warning in computer systems.
San Francisco had a tsunami warning siren that was sound tested every Tuesday at 12pm for 30 seconds. It was fun! It needed repairs so they dumped it. Few weeks later there was the 1st tsunami warning in ages but it went thru telephone since they dismantled their warning siren.
Every week? Damn, that's a lot. We do once a month for tornado siren tests, where I am. And not all year, but of course tsunamis aren't seasonal.
Re: An Update on the Lock Icon
#80I'm glad they continued the "An Update on X" = "X is getting axed" tradition at google. It's one of the few constants. Maybe they even have a UX guideline about it by now :D PS: I'm not writing this out of spite, btw. It just came to my mind when I saw the title and I was surprised I was right
Betteridge would ask, "Is X Staying?" https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...