On Fri, Nov 21, 2014 at 10:09 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Fri, Nov 21, 2014 at 3:53 PM, Patrick McManus <mcma...@ducksong.com> > wrote: > > in action. Google talks loudly about all https (and has the leading track > > record), yet there it is. And google isn't special in that regard. > > Why would they be allowed to use OE? > The reasons why any individual resource has to be http:// and may (or may not) be able to run OE vary by resource. Of course only the content provider can know their reason for sure. I've tried to point out in this thread what some of those reasons can be and its really not very relevant whether you or I agree with them unless we own the content. I think the sweet spot for OE is transparent migration of legacy content from plaintext to ciphertext. But we also have an existence proof about OE and content that is compelled to stay http:// (for whatever reason) right now. Google.com is currently running some encrypted http:// based services via next-gen transports and Chrome does not require auth for them. They are doing this with opportunistic encryption (via the Alternate-Protocol response header) for http:// over QUIC from chrome. In the past they did this with spdy too (I'm unsure of current status of that). They don't want the open and standards track web to participate. It seems we can't be trusted to do what they're already proprietarily doing for their own services. See https://drive.google.com/file/d/0Bx2I7jYKXMpETlZSd1piaVpPMHM/view The linked screenshot shows a google https:// resource that does not load due to cert failure (I removed the required CA from my trust list) and it also shows the http:// version of the same resource being loaded successfully over encrypted QUIC with the same trust list (i.e. no auth). I used an add-on and a packet trace to identify the ciphered QUIC - the normal UI just shows normal http://. I know some will conclude they should dumb it down. I think we ought to smarten up instead - this serves an important use case. For our users that find themselves using the http:// version that ciphered quic interaction is much better than the plaintext h1 alternative. -P _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
