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 07:51:43 +0100
Message-ID: <CAKXHy=egwBbTSjZUSh7L9ht4VE1w6JwTVmuPynpHVuX2wEGqOQ@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: "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 Wed, Feb 11, 2015 at 8:52 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:
> This seems like it might introduce more problems on the server side than
> it solves.

I think I agree with Jacob's analysis:

1. This isn't a problem for browsers that support upgrade, as they'd never
have made the insecure subresource request in the first place.

2. Moreover, there's no harm in redirecting _all_ non-HTML/non-Worker
requests to HTTPS, is there? That would simplify server-side logic. :)

> Does CSP itself offer any feature-detection capabilities?

No. Working on a JavaScript API for CSP3, and we send a `CSP: 1` header in
order to mitigate the risk of leakage (as described in
https://w3c.github.io/webappsec/specs/content-security-policy/#csp-request-header).
We could certainly expand that header in various ways to advertise
capabilities.

I don't think that addresses Anne's central point about header bloat, but
it's not clear to me what kind of advertisement mechanism we can use that
doesn't fall into that trap. Client hint-style opt-in from the server side
might be interesting (
http://igrigorik.github.io/http-client-hints/#rfc.section.2.2.1), but it
leaves the first request in an indeterminate state. That might or might not
be ok.

-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 06:52:31 UTC

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