W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [UPGRADE]: What's left?

From: Ilya Grigorik <igrigorik@google.com>
Date: Wed, 11 Mar 2015 11:42:55 -0700
Message-ID: <CADXXVKo=iKSChgotoaRAZu5UtSGer4rZhNYrqq=8hs=wFZBBjA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>, Eric Mill <eric@konklone.com>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Yves Lafon <ylafon@w3.org>, T Guild <ted@w3.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>, Yoav Weiss <yoav@yoav.ws>, Mark Nottingham <mnot@mnot.net>
On Wed, Mar 11, 2015 at 9:33 AM, Mike West <mkwst@google.com> wrote:

> On Wed, Mar 11, 2015 at 5:20 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>> Sure, but the UA automatically makes this decision on users behalf each
>> time, so effectively it is a conditional server redirect, but with a whole
>> bunch of gotchas:
>>
>
>
>> the server has to render full (200) response in case the client is not
>> "capable"
>>
>
> This isn't unique to my proposal. Your proposal has the same drawback, as
> the server doesn't know whether the client is capable until it opts-in to
> receiving the signal. That has the additional drawback of keeping the user
> on an insecure connection until the next navigation, and triggering all the
> associated insecure resource requests.
>

There is a difference. In the 200+implicit redirect case, presumably the UA
wouldn't even render the content of http response, but it's still forced to
download it, which means the user is incurring bytes without even being
aware of it.

Between all the issues introduced by adding another redirect mechanism and
forcing "Prefer" on all outbound http:// requests, I'd actually
(reluctantly, but its "less worse" in my books) prefer the latter.. which
would then trigger a 3XX and reuse existing concepts without breaking HTTP
semantics, tooling, etc.


> Again, non-unique. Note also that the opt-in mechanism would also require
> _rendering_ all of this, which is even slower. :)
>

Yes, but this seems like a micro-optimization.. Yes you don't get https://
on "first" visit, but your first request is going out on http:// anyway so
a MITM can downgrade you anyway, so we're not losing much.. We're talking
about a tradeoff of https on second visit VS. sending a header on every
outbound request.. personally, I prefer the opt-in route with https on
second visit.

ig
Received on Wednesday, 11 March 2015 18:44:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC