- From: Mike West <mkwst@google.com>
- Date: Thu, 12 Feb 2015 11:42:50 +0100
- 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 -- 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