[HN Gopher] An Update on the Lock Icon
___________________________________________________________________
An Update on the Lock Icon
Author : semenko
Score : 163 points
Date : 2023-05-02 16:06 UTC (6 hours ago)
(HTM) web link (blog.chromium.org)
(TXT) w3m dump (blog.chromium.org)
| CharlesW wrote:
| What's with the naming and visuals of the "tune" icon, which
| seems to be a "site settings" icon with weird left- and right-
| justified radio buttons?
| samtho wrote:
| It is a simple representation of those on/off toggle switch UI
| elements.
| djur wrote:
| "Tune" as in "adjust settings".
| CharlesW wrote:
| The mental model of "and here's where you tune the website"
| seems so strange to me, but thank you for the credible
| explanation!
| [deleted]
| Wowfunhappy wrote:
| > 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 is after
| Google _already_ made their UI much taller in their last refresh.
| If you make the UI take up more and more space with each
| redesign, it adds up.
|
| Yes, I have a bigger monitor today than I once did. But I bought
| that monitor so I'd have more space for actual content, not the
| browser UI.
|
| Remember how Google chose the name "Google Chrome" because it was
| designed to have a minimal UI that gets out of your way and lets
| you focus on page content?
| jbverschoor wrote:
| Such 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.
| throwawaaarrgh wrote:
| So as long as you're not color blind or vision impaired or from
| a country where red doesn't mean danger, sounds fine
|
| Government oversight of TLS certs? No way this could possibly
| go wrong
| Clamchop wrote:
| Traffic lights.
|
| Everyone everywhere knows red, yellow, and green now, and how
| to navigate around colorblindness (both red and green lights
| are tinted to be distinguishable).
| deathanatos wrote:
| Traffic lights are a combination of color and position;
| even if one is completely colorblind, the position of the
| lit lamp is sufficient to discern the signal.
|
| The above suggestion doesn't have that sort of double-
| encoding of the data.
|
| (This holds even for the odd horizontal signal, though I
| would expect most non-colorblind people would not be able
| to tell you the orientation from memory.
|
| ... and ... there are plenty of drivers on the road who,
| judging from their behavior, would appear to be incapable
| of determining the color of the signal.)
| Clamchop wrote:
| Traffic lights still work without position, as they'd
| have to at night, in fog, in glare, and so on.
|
| Point is, the meaning of the colors appears to be
| universally understood thanks to driving, and
| distinguishing the colors has been addressed.
|
| If there are exceptions, I suppose localizations and
| accessibility modes are just the thing.
| renewiltord wrote:
| Any tech curated by the government is likely shit. Better to
| avoid.
| dadrian wrote:
| > We will continue to mark HTTP as insecure.
| politelemon wrote:
| 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.
| at_a_remove wrote:
| 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.
| chowells wrote:
| > (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.
| rootusrootus wrote:
| 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?
| yamtaddle wrote:
| 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)
| rootusrootus wrote:
| I agree there are things that would have to be worked out, to
| prevent opening new exploitable holes. How about we just add
| some ability to the browser to remember the site (fingerprint
| it somehow, perhaps) so that the security policy only has to
| be agreed to once. Kinda sorta similar to SSH remembering
| known hosts. Once I've told Chrome that my Unifi Dream Router
| is okay, or my Iotawatt, or Home Assistant, etc ... it should
| stop making me jump through hoops every time until something
| changes. And I don't _ever_ want it to flat out tell me no, I
| cannot reach something on my home network with a low quality
| SSL implementation unless I blindly type "thisisunsafe" into
| the security window.
|
| It's a pet peeve of mine, as you may have noticed. I have a
| lot of little random devices on my home network and many of
| them have no way (or no simple way, at least) of protecting
| with a real SSL certificate. Sometimes I'll go through the
| trouble of using nginx as a reverse proxy to hide the
| insecurity, but that isn't always easy to get working either.
| dadrian wrote:
| Chrome remembers certificate click-throughs for 2 weeks.
| That being said, there's definitely a bunch of room for
| improvement with local networks that we haven't quite
| sorted out yet.
| kaycebasques wrote:
| 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 so common that we
| don't even need UI for it anymore.
|
| [1] https://web.dev/why-https-matters/
| matthewaveryusa wrote:
| "You know that green lock in your browser?" used to be how I
| explained what I did in 5 seconds. Now what am I supposed to do?!
|
| I like this update, I think this is an excellent UX change
| jeroenhd wrote:
| "Click the button that looks like two magnifying glasses
| pointing left and right" clearly!
|
| I get what they were going for with this design, but it's
| impossible to describe this over the phone. I guess they want
| you to use Chrome Remote Desktop if you ever need to support
| someone remotely.
| chrismsimpson wrote:
| Apple will do this in 3 years and call it innovative
| jackson1442 wrote:
| Good change imo. They didn't mention in the post but I do hope
| they continue to show the "Not Secure" warning for HTTP-only
| websites.
| billyhoffman wrote:
| > We continued to mark HTTP as insecure in the URL bar.
| dfabulich wrote:
| They did mention it in the post. "On all platforms, we will
| continue to mark plaintext HTTP as insecure."
| layer8 wrote:
| I wonder how many ordinary users have any notion of what the
| "tune" icon [0] is supposed to indicate.
|
| [0]
| https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg...
| Spivak wrote:
| It looks odd in isolation but I was surprised how natural it
| looks in the bar.
|
| https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh...
| happytoexplain wrote:
| This settings/configure/adjust icon seems to be in the middle
| of a transition between abstract and universal. Something like
| a magnifying glass didn't need any transition period because
| humans already associate it with "searching" from fiction.
| Other icons required reinforcement to learn (e.g. the share
| icon - or, even more well learned, the pause icon). One of the
| downsides of the modern hyper-focus on metrics in UI is that it
| dictates that iconography _already_ be intuitive. Sometimes we
| need to ignore this rule in order to teach users a new icon,
| which then helps us improve interfaces by communicating more
| without words.
| dfabulich wrote:
| I approve of getting rid of the lock icon, showing only a broken
| lock for HTTP and no lock for HTTPS. It's always been weird to
| have site permissions settings revealed by clicking that lock.
|
| But the replacement icon looks really strange to me. They're
| calling it a "tune icon," but I've never seen a tune icon like
| this, with just two circles and two lines. Looks weird. I'm
| surprised that it fared well in the experiment.
|
| I would prefer it if they'd use a gear icon, which is normally
| used for settings like this. You can see a gear icon at the
| bottom of the tune menu for "Site settings," which makes it all
| the weirder that they're using a tune icon in the URL bar and a
| gear icon in the menu for site settings.
| coldpie wrote:
| 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.
| thetinguy wrote:
| Good luck describing that icon in words over the phone.
| hbn wrote:
| "See the 2 people with all their limbs cut off, staring up
| at the clouds?"
| happytoexplain wrote:
| This icon is gaining traction fast. I've seen it a lot over the
| past few years. "Tuning" and "adjusting" is a slightly more
| specific concept than "settings". I think users associate the
| "settings" gear with whole-app settings, or
| "technical"/"system" settings, and it might be something
| they're loathe to click on because that's typically a large
| forest of things they don't care about or understand.
|
| Also, I think using not-well-known icons is actually _under_
| rated (see my comment here:
| https://news.ycombinator.com/item?id=35793362)
| benatkin wrote:
| The tune icon makes a lot of sense. It's unobtrusive. A gear
| icon would be highly obtrusive.
| pavon wrote:
| Firefox currently uses the same icon to configure site
| permissions (microphone, location, etc). However, it is only
| displayed if you have granted permissions. You can see it here:
|
| https://support.mozilla.org/en-US/kb/site-permissions-panel
| noja wrote:
| The icon looks like something from audio equipment. I get it.
| reaperducer wrote:
| Aren't we supposed to hate skeuomorphism?
|
| I forget whether it's cool or not this week.
| adrianmonk wrote:
| There are plenty of settings dialogs that use a bunch of
| horizontal slider widgets to tweak values, so I guess it's
| not entirely skeuomorphism.
| function_seven wrote:
| 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
| animation1, 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 pendulum swung so far toward "flat
| design" that I (we?) would love to have too much of it
| again, if the alternative is not enough of it.
|
| [1] https://www.flickr.com/photos/atmasphere/8320805931/
|
| EDIT: Just thought about it some more and realized some
| icons are good abstractions of a non-physical thing. Play,
| Pause, and the rest of audio controls, for example. And of
| course Back and Refresh are just arrows.
|
| But for something like "settings", or "info", you're going
| to have to draw some sort of picture for that. Gears and
| lists of sliders are two already-recognizable things that
| people know means "guts of the machine" and "control
| console panel thing".
| notatoad wrote:
| i think it's a fairly recognizable and standard icon, i've
| definitely seen it used for this sort of thing before. i've
| never heard it called a "tune icon" before but the name
| ultimately doesn't matter much
|
| https://www.google.com/search?q=preferences+icon&tbm=isch
| PaulHoule wrote:
| They just want people to be really confused, don't they?
| mattl wrote:
| Think 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.
| post-it wrote:
| They'll change. Maintaining backwards compatibility with third-
| party training material is the least-useful form of maintaining
| backwards compatibility.
| [deleted]
| computerfriend wrote:
| That advice didn't seem to be a good idea.
| mattl wrote:
| It's still true of virtually every browser other than future
| versions of Chrome and possibly browsers based on Chromium.
| djur wrote:
| That advice has been deprecated for years and has never been
| sufficient. The reverse is true now: the browser will warn
| about an insecure connection.
| shadowgovt wrote:
| This is forever the problem with documentation: it checkpoints
| a description of a system at a point in time.
|
| You can make an extremely valid similar argument regarding C++
| tutorials written in 1995, but the end-response is the same:
| "Update your sources, learn the new thing, and most importantly
| don't assume anything computer-related that is more than 5
| years out of date is relevant, especially for something
| Internet-related."
| mattl wrote:
| Okay but unless other browsers make the same change now you
| have two sets of information and now users need to know their
| underlying browser's engine too?
| shadowgovt wrote:
| That's going to be up to the other browser vendors. Some
| would argue that multiple approaches to these problems is a
| virtue of the ecosystem. (I'm not sure I'm one of them, but
| if one accepts that premise than "This documentation varies
| based upon what browser you're using" is an expected side-
| effect).
| xPaw wrote:
| This is a good move for the secure-by-default move.
|
| In The Lounge IRC client, we've also opted to this approach years
| ago, where secure connections show no icon, and insecure
| connections show an insecure icon.
| 8lahaj wrote:
| [dead]
| ladon86 wrote:
| 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 easier to
| train employees to "look for your company's name in the green
| bar" before they sign into a site, than to understand how domains
| work and why login.yourcompany.com is OK but login-
| yourcompany.com isn't.
|
| Does anyone know if it's possible to restore EV indicators in
| Chrome via MDM software or similar? Does anyone work at a company
| that does this?
| bmicraft wrote:
| A better approach would probably be to wildcard ban domains
| with your company name on the dns server (except for the real
| one).
| ladon86 wrote:
| Good idea, that sounds very viable. Thank you!
| throwawaaarrgh wrote:
| > EV indicators would be really useful in a corporate setting
| to mitigate phishing attempts against employees.
|
| Our company puts a big red banner on the top of all emails that
| come from an external source or don't have DMARC/SPF/DKIM/other
| security protections. Literally nobody ever checks the banner.
| It has no effect on phishing click rates. People do not read,
| or think. They just look for wherever it is expected for them
| to click something/fill something out, or just click random
| things to see what something might be.
|
| The only thing that has marginally improved click rates is when
| we either gamify it, or put all external mails in an external
| mail folder marked NOT SAFE.
| pixl97 wrote:
| 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.
| andirk wrote:
| 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.
| yamtaddle wrote:
| 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.
| deathanatos wrote:
| Yeah, weekly. (Can confirm.)
|
| I always felt like it sounded like it was saying
| "noooooooooooooooooooooooooooooon on a Tuesday" to me.
| Lunch time.
|
| Also always felt like around noon on Tuesdays, we were
| completely vulnerable; if anything were to happen I would
| have heard the siren, and wandered outside looking for
| grub.
|
| There is a subset of San Franciscans that do not hear the
| siren, too. On a pretty common basis we'd discover
| someone in the office who had "never heard the siren",
| somehow. I'm not exactly sure how. It's easily audible
| inside in the FiDi, and it was audible in the North Beach
| when I worked there.
| andirk wrote:
| At my doorslam job, they hired a Director of Engineering
| Architecture or whatever title. He had a strong background in
| security, they said. Yeah well turns out his background was
| he led the offshore team that built an anti-virus company's
| .mobi website for 9 years. 1st hour of 1st day, he clicked
| the anti-phishing test "Click here to update your drivers"
| phishing email.
| jve wrote:
| Long ago I was reading someone registered corp in some other
| jurisdiction with the same company name which he wanted to
| impersonate with EV cert. And succeeded.
|
| So what are you proposing is of questionable value.
| X-Cubed wrote:
| That researcher was Ian Carroll, who created a new "Stripe,
| Inc" company in Kentucky, a clone of the one registered in
| Delaware, and was therefore able to get an EV certificate
| issued for his new company that looked very similar to one
| issued for the Delaware company.
|
| His original research site appears to no longer be online
| (https://stripe.ian.sh/), but you can read more about it in
| these articles:
|
| https://www.bleepingcomputer.com/news/security/extended-
| vali...
|
| https://arstechnica.com/information-
| technology/2017/12/nope-...
| 015a wrote:
| I think its possible there could be a backlash against this
| change, as even though many peoples' understanding of the
| security implications of the lock icon didn't align with reality,
| their _expectation_ vis a vi "lock icon means secure, no lock
| means insecure, be careful if there isn't a lock" could force a
| broad unlearning of something that the security community has
| tried to teach over the past ten to fifteen years.
|
| > Despite our best efforts, our research in 2021 showed that only
| 11% of study participants correctly understood the precise
| meaning of the lock icon.
|
| It doesn't seem to me that this is the right thing to be
| measuring. What matters more is: how many people _critically
| misunderstand_ what the lock icon means, leading to the potential
| for trusting sites which shouldn 't otherwise be trusted. The
| study itself goes on to better answer this, though its absent
| from the article: only 23-44% of respondents referred to the
| padlock at all when asked to evaluate the trustworthiness of a
| website. Its safe to say that some subset of that group would be
| shared with the group who critically & negatively misunderstand
| what the padlock represents, but its also safe to say that the
| entirety of the 11% "we know what the padlock means" group is
| also in the center of this venn diagram.
|
| In other words: not more, and likely less, than a third of users
| were being misled by the padlock to the point of compromise.
| That's still a lot of people and its worth improving, but its a
| far cry from the 89% the blog post advertises.
|
| When combined with the notion that the padlock's _absence_ could
| cause harm; a different kind of harm, moving from "yeah this
| site is trustworthy I'll enter my credit card" when it isn't, to
| "no way this site is trustworthy I'm out of here" when it is
| trustworthy for some in that 23-44% group; I'm not sure this is a
| positive change.
|
| I get that the world of HTTPS is evolving, and its very broadly
| default-on instead of default-off nowadays, but it seems to me
| that this is something of an expedient and ineffectual solution
| to something much harder: education. The article says "Despite
| our best efforts, our research in 2021 showed that only 11% of
| study participants correctly understood the precise meaning of
| the lock icon", but I'm at a loss for what exactly Google means
| by "despite our best efforts". I don't intend to be mean or
| combative with this observation. Education is really difficult;
| but when viewed through a more critical lens this article and the
| associated change really smells like "We failed to correctly
| educate our users about internet security, so we're changing an
| icon to absolve ourselves of the responsibility of the previous
| icon's inferred meaning."
| minaguib wrote:
| We have collectively taught all the non-tech folks not to enter
| sensitive information, such as credit card numbers, in non-
| secure forms that don't show the lock.
|
| This used to mean a lot when certificates were harder and more
| expensive - the rationale was fly-by-night bad actors wouldn't
| bother. This is most definitely not the case now.
|
| Realistically as well, it's mostly to guard against man-in-the-
| middle interception - as we all know once it hits the server
| handling the SSL termination, all security bets are off.
|
| FWIW Chrome does (and I assume will continue) saying "Not
| secure" where the padlock used to be, for HTTP sites. So there
| is at least that as a warning.
| mqus wrote:
| I'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
| dadrian wrote:
| Believe it or not, the title began as a placeholder title
| before I realized it was a Google-ism for shutting things down.
| kmoser wrote:
| Betteridge would ask, "Is X Staying?"
| https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
| mholt wrote:
| 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 "heads up".
|
| I think a control panel like this is a good step forward after
| ubiquitous HTTPS. I also think user agents can do more to protect
| and warn users in ways that are less easily spoofed by malicious
| sites. Looking forward to seeing future developments!
| sedatk wrote:
| 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.
| p1mrx wrote:
| 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.
| hgj4dfshgf43 wrote:
| > By the way, does anyone know of a good alternative to
| http://neverssl.com ?
|
| http://http.rip/
| DiggyJohnson wrote:
| httpforever.com is my go to.
| p1mrx wrote:
| Nice. I see that https://httpforever.com/ exists with a 301
| redirect to http://httpforever.com/, but that's probably good
| enough for most practical purposes.
| notatoad wrote:
| that appears to also be what neverssl is doing - they
| support https only for the purposes of redirecting to a
| non-ssl domain
| p1mrx wrote:
| Nope, when I go to neverssl.com, it ultimately lands on
| an HTTPS url, e.g.
| https://shinyquietbrightsong.neverssl.com/online/
|
| 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.
| marcosdumay wrote:
| It is your browser doing that redirect, not the side.
|
| The http://neverssl.com ends up on an http page, and so
| does https://neverssl.com. But that final page (the one
| you posted) does not itself redirect from https to http.
| 0xffff2 wrote:
| Do you have HTTPS Everywhere or a similar plugin
| installed? If you look at the page source, it's
| "redirecting" in a script with this line:
| window.location.href = 'http://' + prefix +
| '.neverssl.com/online'
|
| I get a plain http page on Firefox/Ubuntu.
| 0xffff2 wrote:
| 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.
| re wrote:
| 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.
| shawnz wrote:
| Isn't a 301 response cacheable?
| jefftk wrote:
| _> 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 needed to make this change to handle
| that typing "neverssl.com" now often evaluates to
| "https://neverssl.com".
| chrismorgan wrote:
| 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.
| lozenge wrote:
| http://http.rip
| listenallyall wrote:
| > they've reneged on.
|
| Damn straight. Demand your money back!
| [deleted]
| llimllib wrote:
| I used zombo.com for a long time before they finally, sadly,
| added https
| afandian wrote:
| Seems you can't do _absolutely_ everything.
| WrtCdEvrydy wrote:
| Same thing happened to ross-tech: https://www.ross-tech.com/
| Chrome adding HTTPS for whatever reason.
| zeven7 wrote:
| 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.
| rippercushions wrote:
| 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 .
| MarkSweep wrote:
| http://captive.apple.com/ is what iOS uses.
| dmitrygr wrote:
| Example.com
| seanhunter wrote:
| 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
| runnerup wrote:
| Thank you. I searched and found a similar option in Safari
| settings but it doesn't permanently show the protocol prefix.
| It also gets overridden on google searches where it just shows
| your search terms, not the URL.
| rzzzt wrote:
| It should always be possible to reach http://example.com (also
| .org and .net) over HTTP.
| p1mrx wrote:
| 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.
| dadrian wrote:
| 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.
| hbn wrote:
| 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?
| amluto wrote:
| I use example.org. An explicit http://example.org does the
| trick when needed.
| aaronbrethorst wrote:
| Me too. Visiting the aforementioned URL is the only way I can
| consistently get captive portal login WiFi networks to work
| on my Mac. Amazing how busted this experience is...
| CarVac wrote:
| Firefox always gives me a button that directly opens the
| portal login page.
| cmckn wrote:
| http://www.alwayshttp.com
| jbverschoor wrote:
| So they hid this setting in the address bar :D
___________________________________________________________________
(page generated 2023-05-02 23:00 UTC)