| |
| ▲ | schoen 2 days ago | parent | next [-] | | https://en.wikipedia.org/wiki/Preparedness_paradox | | | |
| ▲ | sam_lowry_ 2 days ago | parent | prev [-] | | How do browsers distrust HTTP, exactly? | | |
| ▲ | JoshTriplett 2 days ago | parent | next [-] | | They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure...) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-only resources anymore), they require HTTPS for HTTP/2 and HTTP/3, they increasingly attempt HTTPS to a site first even if linked/typed as http, they warn about downloads over http, and they're continuing to ratchet up such measures over time. | | |
| ▲ | foobiekr 2 days ago | parent | next [-] | | If browser vendors really cared, they would disable javascript on non-https sites. | | | |
| ▲ | fc417fc802 2 days ago | parent | prev [-] | | > they increasingly attempt HTTPS to a site first even if linked/typed as http And can generally be configured by the user not to downgrade to http without an explicit prompt. Honestly I disagree with the refusal to support various APIs over http. Making the (configurable last I checked) prompt mandatory per browser session would have sufficed to push all mainstream sites to strictly https. | | |
| ▲ | JoshTriplett 2 days ago | parent [-] | | > And can generally be configured by the user not to downgrade to http without an explicit prompt. Absolutely, and this works quite well on the current web. > Honestly I disagree with the refusal to support various APIs over http. There are multiple good reasons to do so. Part of it is pushing people to HTTPS; part of it is the observation that if you allow an API over HTTP, you're allowing that API to any attacker. | | |
| ▲ | fc417fc802 2 days ago | parent [-] | | > if you allow an API over HTTP, you're allowing that API to any attacker. In the scenario I described you're doing that only after the user has explicitly opted in on a case by case basis, and you're forcing a per-session nag on them in order to coerce mainstream website operators to adopt the secure default. At that point it's functionally slightly more obtuse than adding an exception for a certificate (because those are persistent). Rejecting the latter on the basis of security is adopting a position that no amount of user discretion is acceptable. At least personally I'm comfortable disagreeing with that. More generally, I support secure defaults but almost invariably disagree with disallowing users to shoot themselves in the foot. As an example, I expect a stern warning if I attempt to uninstall my kernel but I also expect the software on my device to do exactly what I tell it to 100% of the time regardless of what the developers might have thought was best for me. | | |
| ▲ | JoshTriplett 2 days ago | parent [-] | | > More generally, I support secure defaults but almost invariably disagree with disallowing users to shoot themselves in the foot. I agree with this. But also, there is a strong degree to which users will go track down ways (or follow random instructions) to shoot themselves in the foot if some site they care about says "do this so we can function!". I do think, in cases where there's value in collectively pushing for better defaults, it's sometimes OK for the "I can always make my device do exactly what I tell it to do" escape hatch to be "download the source and change it yourself". Not every escape hatch gets a setting, because not every escape hatch is supported. | | |
| ▲ | fc417fc802 2 days ago | parent [-] | | > escape hatch to be "download the source and change it yourself" In theory I agree. In practice building a modern browser is neither easy nor is it feasible to do so on an average computer. Given that a nag message would suffice to coerce all mainstream operators (thus accomplishing the goals I've seen stated) I'm left unconvinced. That said, I'm not particularly bothered since the trivial workaround is a self signed certificate and the user adding an exception. It's admittedly a case of principle rather than practice. |
|
|
|
|
| |
| ▲ | castillar76 2 days ago | parent | prev | next [-] | | They’ve been making it harder and harder to serve things over HTTP-only for a while now. Steps like marking HTTP with big “NOT SECURE” labels and trying to auto-push to HTTP have been pretty effective. (With the exception of certain contexts, I think this is a generally good trend, FWIW.) | | |
| ▲ | g-b-r 2 days ago | parent [-] | | I have to change two settings to be able to see plain http things, and luckily I only need to a handful of times a year. If I'm really curious about your plain http site I'll check it out through archive.org, and I'm definitely not going to keep visiting it frequently. It's been easy to live with forced https for at least five years (and for at least the last ten with https first, with confirmations for plain http). | | |
| ▲ | castillar76 a day ago | parent [-] | | I was genuinely taken aback by visiting a restaurant website last night that was only served over HTTP. (Attempting to hit it with HTTPS generated a cert error because their shared provider didn't have a cert for it.) These days, I'd gotten so used to things just being over HTTPS all the time that the warnings in the browser _actually worked_ to grab my attention. It's a restaurant that's been here with the same menu since the 1970s, and their website does absolutely nothing besides pass out information (phone number, menu, directions), so they probably put it up in 2002 and haven't changed it since. It was just a startling reminder of how ubiquitous HTTPS has gotten. |
|
| |
| ▲ | 0xCMP 2 days ago | parent | prev [-] | | If you try to open anything with just HTTP on an iOS device (e.g. "Hey, look at this thing I made and have served on the public internet! <link>") it just won't load. This was my experience sending a link to someone who primarily uses an iPad and is non-technical. They were not going to find/open their Macbook to see the link. |
|
|
