SoylentNews is people
SoylentNews
from the it's-the-end-of-the-web-as-we-know-it-and-i-feel-fine dept.
Phoronix reports the Mozilla Security Engineering team is planning to make their browser useless for browsing much of the World Wide Web, by deprecating insecure HTTP.
Richard Barnes of Mozilla writes:
In order to encourage web developers to move from HTTP to HTTPS, I would like to propose establishing a deprecation plan for HTTP without security. Broadly speaking, this plan would entail limiting new features to secure contexts, followed by gradually removing legacy features from insecure contexts. Having an overall program for HTTP deprecation makes a clear statement to the web community that the time for plaintext is over -- it tells the world that the new web uses HTTPS, so if you want to use new things, you need to provide security.
See also this document outlining the initial plans.
(Score: 4, Informative) by Marand on Wednesday April 15 2015, @08:21AM
Encryption can't fix that. The browser at an access point might still insert anything into the page source, post-decryption.
I don't think you're talking about the same thing I am. A "public access point" generally means an open wireless AP, such as what you find in places like stores, restaurants, and coffee shops. You connect with your tablet, phone, or laptop and browse using your hardware on their network. HTTPS does limit the abuse potential in those cases. You seem to be thinking of a public computer, like what you find in a library.
Maybe, but we're not talking about encryption by default (à la HTTPS-Everywhere). Rather, we're talking about deprecating plain HTTP, which IMO is not a good idea. Lose the human readability of a data stream and you'll lose not just the ability to tamper with the stream, but the ability to check what's going in and out of your LAN too.
Telnet and FTP are deprecated in favour of secure counterparts, why not HTTP as well? You lose the ability to tamper with streams you don't initiate, but that doesn't mean you'll suddenly lose the ability to interact with HTTP outside of browsers. You can use other tools [superuser.com] to initiate and interact with SSL connections the same way you can telnet to port 80 and manually interact with HTTP.
As for the LAN diagnostic argument, the benefits of non-encryption don't outweigh the disadvantages, in my opinion. Even with universal encryption, you can still see what host and port is responsible for suspicious or excess traffic and, if needed, use physical access to the hardware to determine what's going on. Netstat to find what process is responsible, maybe poke around memory to find out what the program is doing.
You don't need deep packet inspection, nor does anybody else; it's just privacy invasion for the sake of convenience. Attitudes like that are why we need universal encryption at all.