- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 20 Jul 2020 11:54:57 +0200
- To: Artur Janc <aaj@google.com>
- Cc: Yoav Weiss <yoavweiss@google.com>, Camille Lamy <clamy@google.com>, Nasko Oskov <nasko@google.com>, Ilya Grigorik <igrigorik@google.com>, Mike West <mkwst@google.com>, Tab Atkins <tabatkins@google.com>, Kinuko Yasuda <kinuko@google.com>, Ulan Degenbaev <ulan@google.com>, WebAppSec WG <public-webappsec@w3.org>, public-web-perf <public-web-perf@w3.org>
High-level question: are metadata and data distinct enough and can developers-at-large reason about their difference to make the right trade-offs? At least in terms of surveillance, metadata can tell a pretty damning story as we've come to learn and I know the network-security folks are trying their best not to give any bits to the network, e.g., https://blog.apnic.net/2018/03/28/just-one-quic-bit/. I worry a bit that what we're doing here isn't exactly sound from an information-security perspective. On Sat, Jul 18, 2020 at 6:42 PM Artur Janc <aaj@google.com> wrote: > 1. Use individual, per-feature HTTP headers to allow exposing individual properties of the response, or a single header (e.g. `Metadata-Allow-Origin` to collect opt-ins into a single header. If we do this, we could merge `Timing-Allow-Origin` into this header. Modulo the above, this seems fine. > 2. Use the presence of CORP as a signal that (some) metadata about the resource can be revealed. This seems scary at first glance, but setting CORP already serves as an opt-in to allow the resource to be embedded in COOP+COEP contexts, which may be able to read the whole resource from their process memory -- developers shouldn't set CORP: `cross-site` on authenticated responses that they're worried about leaking cross-origin. I don't like this. In the face of a Spectre-read gadget, CORP "equals CORS", but only then. Google's suggestion to switch from CORS to CORP for cross-origin isolated was good I think and gave me renewed hope that we'll eventually get rid of Specre either through hardware/kernel or changes in browser architecture. > 3. Extend Mike and Kinuko's Resource Policy proposal (https://github.com/mikewest/resource-policy/blob/master/README.md) to combine the two approaches above. Specifically, with an extended syntax, we could have the header specify both _who_ can embed a resource, and _how_ the resource can be used. I guess now that we have structured headers we need to relearn what the right amount of headers is. I think I personally side with Noam that unless they are intertwined it seems best to keep them separate.
Received on Monday, 20 July 2020 09:55:30 UTC