Hey all, Thanks a lot for the really robust discussion here. There have been several important points raised here:
1. People are more comfortable with requiring HTTPS for new features than requiring it for features that are currently accessible to non-HTTPS origins. Removing or limiting features that are currently available will require discussion of trade-offs between security and compatibility. 2. Enabling HTTPS can still be a challenge for some website operators. 3. HTTP caching is an important feature for constrained networks. Content served over 4. There will still be a need for the browser to be able to connect to things like home routers, which often don’t have certificates 5. It may be productive to take some interim steps, such as placing limitations on cookies stored by non-HTTPS sites. It seems to me that these are important considerations to keep in mind as we move more of the web to HTTPS, but they don’t need to be blocking on a gradual deprecation of non-secure HTTP. (More detailed comments are below.) So I’m concluding that there’s rough consensus here behind the idea of limiting features to secure contexts as a way to move the web toward HTTPS. I’ve posted a summary of our plans going forward on the Mozilla security blog [1]. Thanks --Richard [1] https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ Some more detailed thoughts: 1. Obviously, lots of caution will be necessary if and when we start removing features from non-secure contexts. However, based on the discussions of things like limiting cookies in this thread, and other discussions in the “powerful features” threads, it seems that there’s still some interest in trying to find features where the degree of breakage is small enough to be compensated by the security benefit. So it makes sense to keep the removal or limitation of existing features on the overall roadmap, with the caveat that we will need to calibrate the breakage/security trade-offs before taking action. 2. While enabling HTTPS inherently involves more work than enabling non-secure HTTP, there’s a lot of work going on to make it easier, ranging from Cloudflare’s Universal SSL to Let’s Encrypt. Speaking practically, this non-secure HTTP deprecation process won’t be causing problems for existing non-secure websites for some time, so there’s time for these efforts to make progress before the pressure to use HTTPS really sets in. 3. Caching and performance are important, but so is user privacy. It is possible to do secure caching, but it will need to be carefully engineered to avoid leaking more information than necessary. (I think Martin Thomson and Patrick McManus have done some initial work here.) As with the prior point, the fact that this non-secure HTTP deprecation will happen gradually means that we have time to evaluate the requirements here and develop any technology that might be necessary. 4. This seems like a problem that can be solved by the home router vendors if they want to solve it. For example, Vendor X could provision routers with names like “router-123.vendorx.com” and certificates for those names, and print the router name on the side of the router (just like WPA keys today). Also, interfaces to these sorts of devices don’t typically use a lot of advanced web features, so may not be impacted by this deprecation plan for a long time (if ever). 5. We can take these interim steps *and* work toward deprecation. On Mon, Apr 13, 2015 at 7:57 AM, Richard Barnes <rbar...@mozilla.com> wrote: > There's pretty broad agreement that HTTPS is the way forward for the web. > In recent months, there have been statements from IETF [1], IAB [2], W3C > [3], and even the US Government [4] calling for universal use of > encryption, which in the case of the web means HTTPS. > > 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. Martin Thomson and I drafted a > one-page outline of the plan with a few more considerations here: > > > https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing > > Some earlier threads on this list [5] and elsewhere [6] have discussed > deprecating insecure HTTP for "powerful features". We think it would be a > simpler and clearer statement to avoid the discussion of which features are > "powerful" and focus on moving all features to HTTPS, powerful or not. > > The goal of this thread is to determine whether there is support in the > Mozilla community for a plan of this general form. Developing a precise > plan will require coordination with the broader web community (other > browsers, web sites, etc.), and will probably happen in the W3C. > > Thanks, > --Richard > > [1] https://tools.ietf.org/html/rfc7258 > [2] > https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ > [3] https://w3ctag.github.io/web-https/ > [4] https://https.cio.gov/ > [5] > https://groups.google.com/d/topic/mozilla.dev.platform/vavZdN4tX44/discussion > [6] > https://groups.google.com/a/chromium.org/d/topic/blink-dev/2LXKVWYkOus/discussion > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
