Re: [Proposal]: Set origin-wide policies via a manifest.

On Thu, Jul 28, 2016 at 3:03 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Jul 28, 2016 at 2:58 PM, Mike O'Neill
> <michael.oneill@baycloud.com> wrote:
> > Giving a privacy aware user potentially worse performance is
> problematic, though I expect it would be rare.


Servers need to make decisions about what they send to the client. One way
they can make more intelligent decisions is by asking the client for more
information about their environment. This is the core of the kinds of
headers that proposals like Client Hints and Cache Digest are aiming for.
Origin Policy looks like it's going to go in the same direction.

Those headers expose additional information about the user's environment by
their very nature. Not exposing that information provides a marginal
increase in privacy, but makes it difficult for the server to intelligently
tune the data they send on your behalf.

That's a trade off, to be sure. But it's not clear that it's one we can
avoid.


> But this still suffers from the transparency argument, how does the user
> know that an origin has made the Origin-Policy response have a  UID in it.


I don't think this is something the user should need to care about: if the
user wishes to remove potential identifiers for an origin, they can use
whatever interface their user agent provides to do so. That interface
should take care of origin policy data under the hood, along with cookies,
and channel IDs, and bound tokens, and service workers, and appcache, and
cached site data, and IDB, and so on.

If you're expecting to sift through a detailed list of everything a site
might have stored, then I'd suggest that you're a) not a typical user, and
b) bound to miss thing that are important.

An alternative maybe to use the cookies. If the cookies are present (not
> blocked) then one of them could be Cookie: __Origin-Policy: I-want-this-one
> then the server sees that and supplies that version along with its hash in
> the request header. The user is no worse off privacy wise because they can
> use the browser UI to see what’s happening, and there hasn’t been yet
> another possible fingerprint vector created.
>
> I don't see how that's an alternative. If they are blocked you still
> get worse performance.


I agree with Anne here. Also, note that cookies don't respect the
same-origin policy (they ignore ports entirely, for example). It's not
clear that we'd be able to build this out as a delivery mechanism that tied
a policy to an origin in a reasonable way.

-mike