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

121–130 of 169 posts

Re: An Update on the Lock Icon

#121

Post by [deleted] »

seanhunter wrote: post #58
p1mrx wrote: post #16

If 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.

Depending on what you're trying to do one of the "captive" ping urls works eg http://captive.apple.com This is the url that apple devices ping to get the login box up for things like hotel wifi. There's a mozilla one also which is http://detectportal.firefox.com/canonical.html [1] , but that returns a redirect which may or may not work for your use case. [1] https://support.mozilla.org/en-US/kb/captive-portal

[deleted]

Re: An Update on the Lock Icon

#122

Post by Gigachad »

thetinguy wrote: post #91
coldpie wrote: post #9

Earlier quoted context omitted.

It represents a vertical list of toggle icons, commonly seen these days in preferences panes, including the flyout shown in the same image: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh... A gear icon would work as well, but the intent was immediately obvious to me.

Good luck describing that icon in words over the phone.

“To the left of the url, an icon that looks like two slide toggles”

Re: An Update on the Lock Icon

#123

Post by derefr »

noduerme wrote: post #113
dadrian wrote: post #100

Earlier quoted context omitted.

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…

Why not use Talescale / ZeroTier / etc to get those local boxes connected together into a single virtual overlay network with that gateway (which, from the client site's perspective, is basically just "install app, paste pairing token", and is zero maintenance from then on); and then make your web iframe "gateway" discover these devices that are now on its network, and act as an actual request-proxying gateway for them?

This is similar (though simpler!) to how e.g. Plex's "watch from anywhere" cloud integration works. Your local plex-server install starts a (plaintext HTTP, Bearer-auth) HTTP server on some uPnP port on your local network; derives a public URL for that server via TURN/STUN; connects to Plex's cloud service, and registers that URL to your Plex account. Then, when you visit https://app.plex.tv/ from any device, the plex webapp talks to the backend of their cloud service; and that cloud backend takes your HTTPS request payload, and makes equivalent plaintext-HTTP requests to the registered Plex server on your local network.

Re: An Update on the Lock Icon

#124

Post by zeckalpha »

chrismorgan wrote: post #70
jefftk wrote: post #18

Earlier 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.

TLS isn't SSL.

Re: An Update on the Lock Icon

#125

Post by zbrozek »

hbn wrote: post #92
p1mrx wrote: post #16

If 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.

My latest annoyance with the Chrome URL bar is when certain things autofill (it might be bookmarks, but I think I see it in other frequently-visited addressed too), instead of it populating with the full URL so I can edit it, it just pops up as a piece of text to the right of where I'm typing, so I can see the URL that will fill if I hit enter but I can't edit it. It just started doing this a few months ago maybe?

Firefox on Android does this and it drives me nuts. It also means that all of the search entries are now useless as it auto-populates something and excludes what would've been reasonable hits. I'm constantly deleting that content so I can select something else.

Re: An Update on the Lock Icon

#126

Post by mattnewton »

p1mrx wrote: post #16

If 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.

I always use captive.apple.com

Re: An Update on the Lock Icon

#127

Post by pabs3 »

lozenge wrote: post #73
chrismorgan wrote: post #70

Earlier quoted context omitted.

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.

http://http.rip

That isn't useful, because https://http.rip goes to a self-signed cert.

Re: An Update on the Lock Icon

#128

Post by pabs3 »

seanhunter wrote: post #58
p1mrx wrote: post #16

If 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.

Depending on what you're trying to do one of the "captive" ping urls works eg http://captive.apple.com This is the url that apple devices ping to get the login box up for things like hotel wifi. There's a mozilla one also which is http://detectportal.firefox.com/canonical.html [1] , but that returns a redirect which may or may not work for your use case. [1] https://support.mozilla.org/en-US/kb/captive-portal

Those both support TLS, although they don't mandate it.

Re: An Update on the Lock Icon

#129

Post by pabs3 »

amluto wrote: post #38
p1mrx wrote: post #16

If 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.

I use example.org. An explicit http://example.org does the trick when needed.

That one supports https too :)

Re: An Update on the Lock Icon

#130

Post by pabs3 »

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.

There are tons of sites where http and https are different content; for example the https might be an admin interface, or the IP could have multiple domains but only a couple of them support https, or the vhosts could be very misconfigured. The HSTS and other browser things that force https often do not allow any way to get around this. I often have to resort to creating a new browser profile from scratch and trying hard to avoid https when loading the page. So please allow some way to deal with this sort of issue, for technical folks at least.

Edit: if you search for "forget HSTS", you will see how hard it is to avoid this on some browsers.

Post reply on HN