121–130 of 463 posts
Earlier 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.
Https existed before icon, it shows in url. What's the point of icon when it's already written before?
Strange 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...
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
I just tried many http websites on Safari and am still not sure what you are talking about. They all work perfectly fine, without any warnings. > Not every browser gets upgraded to the latest HTTPS The solution to that isn't to compromise on security and privacy but rather make these devices upgradable/moddable.
I just tried many http websites on Safari and am still not sure what you are talking about. They all work perfectly fine, without any warnings. Then I will thank Apple for changing things and making them less scary already. The fact is that this is exactly how Safari used to handle things. I know because I got many angry screenshots from C-level people in my company when some of our web sites started showing up that…
Earlier quoted context omitted.
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!
Hat off to your determination!
Earlier quoted context omitted.
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.
I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they deci…
let's encrypt with *.lan.mydomain.com via DNS validation, installed all over where needed, and annoying to update every 90 days because it's in weird/internal/non-standard places :)
I simply cannot make any assumption about the network these devices will run, and can certainly not rely on any sort of DNS validation. Virtually 100% of the time the devices are addressed directly by IPv4. I really can't think of a solution for this situation.
For network you control your solution makes a lot of sense though.
Earlier quoted context omitted.
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 fro…
So, it sounds like FF is sending something that's causing an RST to be emitted from either the website or (more likely) your appliance. Next step would be to pcap/tcpdump a connection from both a working browser and FF, and see what the difference is. That kind of information is a lot more useful to FF devs than "something is happening that causes an RST from someone".
Earlier quoted context omitted.
It's a huge security improvement. The HTTP->HTTPS redirection is not secured in any way. [edit: it's not really because it falls back]
The info "is https available" is not secured either. The ISP can just block any packet on port 443 and force http that way. It would break links but wouldn't break people entering the address via the URL bar. A real improvement in security would be Google caching the data, and either offering it via a custom API or just signing it and appending it to their 8.8.8.8 DNS responses. Per default, Chrome already sends the…
And the scenario where an ISP blocks https connections is unrealistic, the server can simply refuse to serve content on http other than redirects.