[helthanatos]

Let me tell you why this is very dishonest: 1. The internet was built without trust in mind because it was a simple connection between universities and government. There wasn't much need for security. Now that the internet exists, there is a great need for security. 2. Https is better than http. It's an evolution. It's not impossible to get a certificate. To verify who you are and to protect your users. 3. If you don't care about your users' privacy, perhaps you shouldn't be hosting sites. To be completely honest, Google is a bit slow with this. I know the difficulty it posses, but it's worth it. We need to stop passing unencrypted data. We need the internet to finally care about security and privacy. The internet has evolved, ipv4 has been used up (in terms of devices). It's time.

[twtw]

None of these statements convince me that http sites should be default flagged as insecure. Take this site, for instance: http://wilsonminesco.com/6502primer/65tutor_intro.html. It is a great resource, but is not available over https. yeah, it's possible that someone could MITM it to provide me with incorrect info on the 6502, but I don't see the disregard for my privacy. I'm never going to put in any of my own information, even if someone uses MITM to ask for my credit card or something.

Could you explain why browsers should flag sites like this? It's possible that I'm too naive to realize the issue, and I would appreciate some education on it.

EDIT: changed "blocked" to "flagged"

[chias]

It's not just about modifying the data, but also about anyone on your network or between you and the end-host being able to determine that you visited that site, and what pages you visited, and when.

The common refrain is to think about repressive governments and what they can (and do) do with this information, but even here in the States think about your ISPs selling your browsing history to advertisers. Or think about ISPs being required to report to the US Government whenever you visit some informative but http-only page about terrorism / chemistry that happens to also be used in explosives / infosec topics / etc. Consider being put on a watchlist simply for having viewed StackOverflow questions relating to XSS or SQLi vulnerabilities.

If you determine the word "insecure" to mean that security or privacy expectations held by the average user are being violated, then all HTTP-only pages are insecure -- not because you may be viewing modified information or because you may be submitting sensitive information, but because the fact that you visited that page while alone is something that the average user likely suspects is secret and/or private, but isn't. To put it bluntly: would you browse an HTTP-only porn site? I wouldn't.

[libeclipse]

Blocking HTTP sites is a bit too far, but an insecure warning is perfectly reasonable as, let's be honest, it is not secure.

[Brian_K_White]

Saying a site like that is not secure, is like the famous old advertizing campaign where one of two competeing food products claimed, perfectly truthfully, that there bread or milk or whatever it was, didn't contain any bleach. It's a technically true, yet grossly disingenuous statement. No one's milk had any bleach in it, and that site has no obligation to be secure.

[twtw]

I edited my post before your response to change it to "flagged," but failed to call out the change initially. Sorry, it's fixed now.

For a lot of people, a big scary warning page that says that a page is insecure is essentially a block. Yeah, you can still access it, but a lot fewer people will.

> let's be honest, it is not secure.

My original post is asking for an explanation of how it isn't secure. I would totally understand a browser warning if a user tries to submit a form over http, but for a page like the one I linked I don't see how it can adversely affect the user.

[tylerhou]

I could, in a very tame example, inject a fake donation button which pointed to my own account instead of the author's. In a more extreme and dangerous example, I could inject malicious JavaScript which exploited an unpatched CVE (Meltdown, Spectre) or vulnerabilities in plugins like Flash, if enabled, to gain control of the user's computer.

It's true that these things could also happen over an HTTPS connection, but then the prevention method is "don't go on sketchy websites." It's far more dangerous over HTTP because a user might already trust the site or author themselves.

[twtw]

Thank you for answering.

I still don't see why either of those justify warning the user about the whole page. For the donation button, the browser could easily warn you with a big "insecure!" page when you click on the button. Regarding js exploits, I don't think https fixes that even for non-sketchy websites: I'm thinking of the js malware in ads and the recent cryptocurrency-mining ads on youtube.

[tylerhou]

> the browser could easily warn you with a big "insecure!" page when you click on the button.

But this implies that whenever you click on any link on a page served via HTTP, the browser should warn you with a big "insecure!" page. I think this is far more obtrusive than a simple "not secure" banner next to the URL.

> I don't think https fixes that even for non-sketchy websites

You're right, if the website served over HTTPS injects random JavaScript/is poorly designed. However, the danger with HTTP is that every single website is vulnerable to this attack, not simply the ones served by malicious or incompetent hosts.

[foo101]

The donation request may not always be in the form of a button. Sometimes it may be a request to make the donation by another means such as by sending bitcoins to a specific address.

[tewha]

My ISP used to inject things into web pages. I don't think they do anymore, but some WiFi access points still do.