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

161–169 of 169 posts

Re: An Update on the Lock Icon

#161

Post by mananaysiempre »

function_seven wrote: post #85
reaperducer wrote: post #12

Earlier quoted context omitted.

Aren't we supposed to hate skeuomorphism? I forget whether it's cool or not this week.

What icons have ever not been skeuomorphic? I hate skeuomorphism when it's used wantonly, beyond the purpose of communicating how the UI works. Like that first version of the Apple Podcasts app that had a reel-to-reel animation¹, for example. But icons... it's like the definition of the term. > I forget whether it's cool or not this week. I think it might be trending upward again. We all hated it in 2012, then the pe…

> What icons have ever not been skeuomorphic?

The download/,upload ones. For extra points, they're also an English-specific visual pun. I can't think of a language-neutral version, though, unfortunately.

(Was also going to mention play/pause/stop, power, and standby, but you edited those in already. Still throwing this out there in case anyone knows a solution to the download problem.)

Re: An Update on the Lock Icon

#162

Post by scrollaway »

jbverschoor wrote: post #43
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.

So they hid this setting in the address bar :D

And I'm sure some googlers will look at the telemetry and happily remove the setting when they realize "It turns out nobody is enabling that!".

Bloody hell. Thanks GP, enabled it.

Re: An Update on the Lock Icon

#163

Post by luckystarr »

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.

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

http://http.rip/ was shared (here?) recently.

Re: An Update on the Lock Icon

#164

Post by iudqnolq »

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…

Can you change to employeeApp.ourcompany.com?

Then you can support both http & https on ourcompany.com but only http on employeeApp.ourcompany.com.

That should at least be simpler than changing to a raw ip.

Another option might be redirecting to the local ip rather than framing.

Re: An Update on the Lock Icon

#165

Post by noduerme »

iudqnolq wrote: post #164
noduerme wrote: post #113

Earlier quoted context omitted.

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…

Can you change to employeeApp.ourcompany.com? Then you can support both http & https on ourcompany.com but only http on employeeApp.ourcompany.com. That should at least be simpler than changing to a raw ip. Another option might be redirecting to the local ip rather than framing.

Interesting. You mean Chrome wouldn't do this if there was no ssl on the whole subdomain? Might be worth trying.

Redirecting isn't really a great option because the wrapper app is usually saved as a shortcut to the tablet homescreens to run in full screen mode... saving the redirected url would break more frequently. Also the wrapper iframe polls lots of known local addresses and sees which one loads.

Re: An Update on the Lock Icon

#166

Post by noduerme »

pabs3 wrote: post #130
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.

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…

In chrome on Android it seems basically impossible.

Re: An Update on the Lock Icon

#167

Post by iudqnolq »

noduerme wrote: post #165
iudqnolq wrote: post #164

Earlier quoted context omitted.

Can you change to employeeApp.ourcompany.com? Then you can support both http & https on ourcompany.com but only http on employeeApp.ourcompany.com. That should at least be simpler than changing to a raw ip. Another option might be redirecting to the local ip rather than framing.

Interesting. You mean Chrome wouldn't do this if there was no ssl on the whole subdomain ? Might be worth trying. Redirecting isn't really a great option because the wrapper app is usually saved as a shortcut to the tablet homescreens to run in full screen mode... saving the redirected url would break more frequently. Also the wrapper iframe polls lots of known local addresses and sees which one loads.

A quick skim of what I think is the relevant file[1] in the chrome source suggests that would work. So worth a shot. If you can deploy enterprise chrome settings to the tablets that's also apparently an option.

Here's what I'm assuming is the relevant bugtracker entry for the implementation [2].

[1]: https://chromium.googlesource.com/chromium/src/+/19719792bbd...

[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=139491...

Re: An Update on the Lock Icon

#168

Post by pabs3 »

hddqsb wrote: post #158
pabs3 wrote: post #133

Earlier quoted context omitted.

That one has some sort of weird forever-loading TLS unfortunately.

I believe that's the point! (Would probably be more user-friendly if it sent a RST instead of silently dropping the connection and letting it time out.)

Getting connection refused would be the best way to do this.

Re: An Update on the Lock Icon

#169

Post by Dandy3556 »

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 https://nonhttps.com/
Post reply on HN