Right, can it please stop hiding it though? URLs aren't prose
Right-Click the URL bar, and select "Always show full URL."
And on my tablet and phone?
Chrome’s address bar will use https:// by default
71–80 of 463 posts
Re: Chrome’s address bar will use https:// by default
#72Right, can it please stop hiding it though? URLs aren't prose
Hiding it? Just enable "Always Show Full URLs" in the omnibar.
Huh. I didn't know that setting existed. And I make a habit of systematically going through the settings pages of every app I use (and in Chrome's case, also chrome://flags), to find out about things like this. It looks like that option exists only in the right-click menu, and not in chrome://settings. That's a problem!
Re: Chrome’s address bar will use https:// by default
#73Earlier quoted context omitted.
> The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason.[...] I'm not entirely sure how it's working, but I seen a few other people with these issues at the mozilla bug tracker and it's always just sort of either ignored or dismissed. This sounds like you have some expensive enterprise equipment that is doing funny things with your TLS connection, but instead of complain…
I mean that's fair, but it's really frustrating that for whatever reason all the other clients work. I just want to figure out what's going on and how the firewall knows to target firefox. Like I said IT's response is "well who cares just use Chrome".
Try comparing the packet conversation using Wireshark to see if Firefox is doing something different from Chrome.
Re: Chrome’s address bar will use https:// by default
#74Earlier quoted context omitted.
I'm curious if that includes falling back to HTTP when HTTPS has worked in the past. I only ask because I'm curious what this will do with captive portal nonsense.
I've found http://neverssl.com very helpful for captive portals. It does what you'd expect - hosts a HTTP-only page that allows captive portals to work correctly. Since it's only ever HTTP, it sidesteps the certificate errors or HTTP downgrades that normal sites are hit with during captive portal interception. I am curious what happens to captive portals as HTTPS adoption rises. Some OS's (Android, OSX) already detec…
Yep, I use neverssl.com, when I remember it. Though, mostly I use example.com, since that works without SSL as well. I guess now I'll need to remember to type http://example.com .
Based off my experience, more and more captive portals appear to be letting the requests the OS makes to captive.apple.com or whatever through but still try to present a captive portal to the user. I can guess as to the motivation, but as a user it's danged annoying.
Re: Chrome’s address bar will use https:// by default
#75Strange to see what kinds of things that Chrome leads the way on, and what things it's a distant follower to other browsers on. I'd wonder what value Google would derive from staying with HTTP as a default, but I can't think of anything offhand.
In this case Firefox was first with a slightly different implementation (a warning instead of directly falling back to http). https://blog.mozilla.org/security/2020/11/17/firefox-83-intr... I think the idea originally came from the extension HTTPS Everywhere and its EASE mode back in 2018. https://www.eff.org/deeplinks/2018/12/how-https-everywhere-k...
> a slightly different implementation
That is an option you can enable, while this post is about changing the default.
Re: Chrome’s address bar will use https:// by default
#76Earlier quoted context omitted.
What's the point in having the protocol spelled out when you have the lock icon anyways? I don't think this would be a useful default.
One thing that was quite annoying to me is the URL changing under my cursor on double-click if the protocol is hidden. However, I can see that editing the URL is a niche use case. Fair enough.
I hate that editing URLs is practically impossible in Chrome on iOS (not sure about Android or other iOS browsers). There seems to be no equivalent of arrow keys to navigate around inside the address bar. If I screeenmash enough I think I can sometimes get it to go to the very start or end of the URL, but anything in between is hopeless.
(Posting this partially in hopes that someone tells me how to do it to prove me wrong...)
Re: Chrome’s address bar will use https:// by default
#77When the big push to HTTPS came around, I was all in favor of it. Now... I'm more skeptical. Not everything has to be HTTPS. And I've become aware that many of the sites I visit are HTTP only and will never become HTTPS because of their age, or the lack of technical ability of their owners. HTTPS also has the side effect of obsoleting older hardware for no real reason. I have devices that work perfectly fine, but can…
A reason for pushing everything to HTTPS (even local historical societies) is that it protects the rest of us from a weapon like China's Great Cannon.
Re: Chrome’s address bar will use https:// by default
#78Earlier quoted context omitted.
"For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails." MITM is still an issue. At some point I hope browsers can switch to "you have to type http:// if you want HTTP", and this is a step in that direction. (Disclosure: I work for Google, speaking only for myself)
It might still be an issue, but this is still a huge improvement. If the browser is going to pick a protocol on behalf of the user, it ought choose a stronger protocol first.
If the browser chooses the stronger protocol it should force the user to opt-in to any fallback behavior which might downgrade security. The current behavior of the browser in most cases is if you enter an 'https' url and the request fails or the cert is invalid you get a failure or warning message. I'd like to see this behavior kept in this case. It communicates what the browser is doing instead of silently downgrading the protocol based upon fuzzy failure signals.
Re: Chrome’s address bar will use https:// by default
#79Earlier quoted context omitted.
The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason. I get these random websites that refuse to work in Firefox, but they always work fine in Chrome. And it's not certificate errors, it's just "connection reset by peer". I'm not entirely sure how it's working, but I've seen a few other people with these issues at the mozilla bug tracker and it's always just sort of eit…
> The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason.[...] I'm not entirely sure how it's working, but I seen a few other people with these issues at the mozilla bug tracker and it's always just sort of either ignored or dismissed. This sounds like you have some expensive enterprise equipment that is doing funny things with your TLS connection, but instead of complain…
Huh? If everything but one browser works, the suggestion will be to avoid using that browser unless you can show the expensive equip is doing something wrong.
So firefox doing nothing more than a connection reset message does not help at all.
A trouble ticket that says chrome works, wget works, curl works, IE works, but my firefox browser with 10 privacy plugins does not work - is NOT going to get a good response from you support contact.
Re: Chrome’s address bar will use https:// by default
#80That makes a lot of sense. HTTPS adoption is now very high[1], and this might push it a little bit further for sites that don't redirect to HTTPS automatically. I've been using Firefox in the experimental HTTPS-only mode, and the web is quite usable without cleartext HTTP. [1] https://transparencyreport.google.com/https/overview It's not a big change from security perspective though. HTTP requests shouldn't be gettin…
>HTTPS adoption is now very high[1] I posted this in a separate comment and I will post it again. https://certbot.eff.org/hosting_providers HTTPS adoption is hard enough that the wast majority of shared hosting providers haven't automated cert provisioning and are delegating this process to their users. The push towards forced HTTPS has significant costs, which most people in this filter bubble don't want to honestly…
> The push towards forced HTTPS has significant costs, which most people in this filter bubble don't want to honestly discuss.
I agree, but I'll push back by saying that delaying HTTPS adoption and getting lax about it has a much higher cost -- and that is similarly a cost that most people pushing back against HTTPS either downplay or refuse to acknowledge.
And more than that, those critics have shown that they're not interested in solving the problems that they bring up or in finding ways to mitigate them. So it's not like we can wait a year and adoption will suddenly get easier. The critics of HTTPS aren't moving forward. They don't want HTTPS adoption to slow down while they catch up, they want it to stop so that they don't need to move forward at all.
We've seen significant improvements in usability for HTTPS for ordinary people, from LetsEncrypt, to Cloudflare, to Netlify. Holdouts like Gitlab and Github don't provide an easy way to provision certs by default. A lot of other smaller hosting providers are ignoring the problem entirely. This will get better over time as more hosting providers realize that this is a feature they have to provide to be competitive.
But that's the thing. Smaller hosts are ignoring the problem and they will continue to ignore the problem until they're forced to upgrade their infrastructure to support solutions like Certbot. Because MITM attacks aren't their problem, client privacy isn't their problem. They are not going to get better support until they literally don't have any other option.
That changes our calculations; where a decade or two ago we might honestly argue that immediate, harsh incentives to switch to HTTPS had too many downsides, we're now in a position where we realize that harsh incentives are the only way that HTTPS infrastructure is going to improve at all.
And that has significant implications for people's privacy and security online. We're at the point where even though it's a barrier of entry for some people, everyone should still be using HTTPS on any public site that they build, period. Honestly, I'm in the process of trying to find good HTTPS schemes for intranet sites too. We need to move forward on security.