On Fri, Mar 6, 2015 at 6:49 PM, Peter Eckersley <pde@eff.org> wrote: > The first significant issue we spotted is that the client will > (unfortunately) need to keep signalling whether or not it supports this > mechanisms even over HTTPS requests. The reason is that in many cases > HSTS needs to be set conditionally on this feature. > I don't understand why HSTS needs to be conditionally set. Presumably you're only redirecting "safely upgradable requests" to HTTPS if you're this spec's target audience. I'm quite uninterested in adding perpetual cruft to the platform. Could you explain the goals you have in mind? Perhaps there's another way of achieving them (for example, we could expose something like a `navigator.hstsEnabled` boolean to express our capability, which clever authors could use to trigger an HSTS-setting request (although, realistically, no one is ever going to do that (at least no one for whom Let's Encrypt's total automation of everything would be suitable))). We've put together a pull request for this change: > > https://github.com/w3c/webappsec/pull/209 Thanks, that makes things easier to talk about! Unfortunately that does mean this mechanism is going to add a lot of > bytes on the wire, and we should consider mitigations like shortening > the Prefer: header, or only sending the Prefer: header for magic HTTPS > URLs like favicon.ico (since it's just going to be there to refresh > HSTS once every so often). +Ilya and Yoav, who are poking at me about bytes on the wire in a separate thread. I assume they have thoughts that are relevant here. :) -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 Friday, 6 March 2015 18:44:44 UTC