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

Re: UPGRADE: Feature detection?

From: Mike West <mkwst@google.com>
Date: Thu, 12 Feb 2015 11:42:50 +0100
Message-ID: <CAKXHy=fxo11gxKABTxjohfE1hu61_Dtyxf5efUG01SkV8pLY-Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Peter Eckersley <pde@eff.org>, Eric Mill <eric@konklone.com>, Jacob S Hoffman-Andrews <jsha@eff.org>
On Thu, Feb 12, 2015 at 11:38 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> I think a lot of this can be managed through the explicit opt-in.
> That would require that the site a) be warned of the dangers and b)
> takes some extra steps to ensure that they aren't exposing themselves
> to those dangers.

Right. That'd be my response to most of this. If we force a site to
opt-into the behavior, then in the best case, they're doing the
calculations in order to determine whether or not an upgrade is
appropriate for their content.

> I know that extra knobs have their own costs, but would a two-stage
> opt-in be a way to manage this?  One for passive-only and a second for
> an unconditional rewrite.  Most sites probably won't need to rewrite
> XHR or form submissions, but I can see them being a little cagey about
> something that might pwn them if they missed something.  Conservative,
> or maybe just lazy.

What might that look like? "Two-stage" isn't really clear to me... Or
you you mean a multi-state opt-in, as some folks have proposed on a
separate thread (like `upgrade 'none'`, `upgrade 'blockable'`,
`upgrade 'all'`?). I'm a little concerned about ever-increasing
complexity, but it might be a reasonable approach.


Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Thursday, 12 February 2015 10:43:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC