Hey Katelyn, Thanks for bringing up these considerations.
On Thu, Apr 16, 2015 at 5:35 AM, Katelyn Gadd <k...@luminance.org> wrote: > I expressed my opinion on this subject at length on the Chrome lists > when they made a similar proposal. I'll summarize it here, though, > since I feel the same way about FF deprecating non-encrypted HTTP: > > I think HTTPS-everywhere is a great ideal if we can achieve it, but in > the vast majority of discussions it feels like people are > underestimating the difficulties involved in deploying HTTPS in > production. In particular, I think this puts a significant group of > people at risk and they don't necessarily have the ability to advocate > for themselves in environments like this. Low-income internet users, > teenagers, and people in less-developed nations are more likely to be > dependent on inexpensive-or-free services to put content up on the > internet. In the best case they might have a server of their own they > can configure for HTTPS (given sufficient public documentation & time) > but the task of getting a certificate is a huge hurdle. I've acquired > personal certificates in the past through the normal paid CA pipeline > and the experience was bad enough as someone who lives in Silicon > Valley and can afford a certificate. > Let me try to disentangle two threads here: 1. "Zero-rated" services [1]. These are services where the carrier agrees not to charge the user for data to access certain web sites. Obviously, these can play an important role for carriers in developing economies especially. HTTPS can have an impact here, since it prevents the carrier from seeing anything beyond the hostname that the user is connecting to. I would observe, however, that (1) most zero-rating is done on a hostname basis anyway, and (2) even if more granularity is desired, there are solutions for this that don't involve DPI, e.g., having the zero-rated site send a ping to the carrier in JS. 2. Requirement for free/inexpensive/hobbyist services to get certificates. Examples of free certificate services have been given several times in this thread. Several hosting platforms already offer HTTPS helper tools. And overall, I think the trend is toward greater usability. So the situation is pretty OK (not great) today, and it's getting better. If we think of this HTTP deprecation plan not as something we're doing today, but something we'll be doing over the next few years, it seems like deprecating HTTP and improved HTTPS deployability can develop together. > There are some steps being taken to reduce the difficulty here, and I > think that's a good start. StartSSL offers free certs, and that's > wonderful (aside from the fact that their OCSP servers broke and took > down a portion of the web the other day...) and if letsencrypt ships > it seems like it could be a comprehensive solution to the problem. If > unencrypted HTTP is deprecated it *must* be not only simple for > individuals to acquire a certificate, but it shouldn't require them to > interact with western governments/business regulations, and it > shouldn't require them to compromise anonymity. Anonymity is an > important feature of web services and especially important for > disadvantaged people. Unencrypted pages mean that visitors are > potentially at risk and their sites can be MITMd, but a MITM is at > least not going to expose their real name or real identity and put > them at risk from attack. Past security breaches at various internet > services & businesses suggest that if an individual has to provide > identifying information to a CA - even if it is promised to be kept > private - they are putting themselves at risk. Letsencrypt seems to > avoid this requirement so I look forward to it launching in the near > future. > I'm not sure what the state of the art with StartCom is, but when I got a certificate from WoSign the other day [2], they didn't require any identification besides an email address. As far as I know, Let's Encrypt will require about the same level of information. There's certainly nothing about the standards or norms for the web PKI that requires CAs to collect identifying information about applicants for certificates. > I also think there are potential negative consequences to deprecating > HTTP if the process of rolling out HTTPS is prohibitively difficult > for amateur/independent developers: In practice it may force many of > them to move to hosting their content on third-party servers/services > that provide HTTPS, which puts them at risk of having their content > tampered with or pulled by the service provider. In this scenario I'm > not sure we've won anything because we've made the site look secure > when in fact we've simplified the task of altering site content > without the author or visitor's knowledge. > Maybe I'm coming from a position of privilege here, but the difficulty of setting up HTTPS seems exaggerated to me. Mozilla already provides an HTTPS config generator [3], and I know Let's Encrypt is already having some conversations with platform vendors about adding more automation to HTTPS config. --Richard [1] http://en.wikipedia.org/wiki/Zero-rating [2] https://buy.wosign.com/free/ [3] https://mozilla.github.io/server-side-tls/ssl-config-generator/ > > On 16 April 2015 at 01:49, Gervase Markham <g...@mozilla.org> wrote: > > On 16/04/15 02:13, Karl Dubost wrote: > >> Definitely. The resistance in this thread is NOT about "people > >> against security", but 1. we want to be able to choose 2. if we > >> choose safe, we want that choice to be easy to activate. > > > > I'd have it the other way. If you even assume choice should be possible > > then: > > > > 1) We want to be able to choose > > 2) If we choose unsafe, we want that choice to be relatively hard to > > activate. > > > > In other words, "safe" should be the default. > > > > Gerv > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
