Late to the thread, but I'll use this reply to say we're very supportive of the proposal at CDT.
On Mon, Apr 13, 2015 at 4:48 PM, <ipart...@gmail.com> wrote: > I have given this a lot of thought lately, and to me the only way forward is > to do exactly what is suggested here: phase out and eventually drop plain > HTTP support. There are numerous reasons for doing this: > > - Plain HTTP allows someone to snoop on your users. > > - Plain HTTP allows someone to misrepresent your content to the users. > > - Plain HTTP is a great vector for phishing, as well as injecting malicious > code that comes from your domain. > > - Plain HTTP provides no guarantees of identity to the user. Arguably, the > current HTTPS implementation doesn't do much to fix this, but more on this > below. > > - Lastly, arguing that HTTP is cheaper than HTTPS is going to be much harder > once there are more providers giving away free certs (looking at StartSSL and > Let's Encrypt). > > My vision would be that HTTP should be marked with the same warning (except > for wording of course) as an HTTPS site secured by a self-signed cert. In > terms of security, they are more or less equivalent, so there is no reason to > treat them differently. This should be the goal. > > There are problems with transitioning to giving a huge scary warning for > HTTP. They include: > > - A large number of sites that don't support HTTPS. To fix this, I think the > best method is to show the "http://"; part of the URL in red, and publicly > announce that over the next X months Firefox is moving to the model of giving > a big scary warning a la self-signed cert warning if HTTPS is not enabled. > > - A large number of corporate intranets that run plain HTTP. Perhaps a > build-time configuration could be enabled that would enable system > administrators to ignore the warning for certain subdomains or the RFC 1918 > addresses as well as localhost. Note that carrier grade NAT in IPv4 might > make the latter a bad choice by default. > > - Ad supported sites report a drop in ad revenue when switching to HTTPS. I > don't know what the problem or solution here is, but I am certain this is a > big hurdle for some sites. > > - Lack of free wildcard certificates. Ideally, Let's Encrypt should provide > these. > > - Legacy devices that cannot be upgraded to support HTTPS or only come with > self-signed certificates. This is a problem that can be addressed by letting > the user bypass the scary warning (just like with self-signed certs). > > Finally, some people conflate the idea of a global transition from plain HTTP > to HTTPS as a move by CA's to make more money. They might argue that first, > we need to get rid of CA's or provide an alternative path for obtaining > certificates. I disagree. Switching from plain HTTP to HTTPS is step one. > Step two might include adding more avenues for establishing trust and > authentication. There is no reason to try to add additional methods of > authenticating the servers while still allowing them to use no encryption at > all. Let's kill off plain HTTP first, then worry about how to fix the CA > system. Let's Encrypt will of course make this a lot easier by providing free > certs. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
