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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The point I was making about cookies is that it up to the server, it can get the policy from the Origin-Policy header or the Cookie header, it makes no difference to it. Why add another mechanism for sending UIDs if it is not necessary?

The reason using cookies is better is because there is already UI than shows them on a per origin basis. There are also browser extensions e.g. PrivacyBadger that manages them to give the user better privacy. They might not look themselves (I admit I am a bit different in that regard), but plenty people worry about privacy i.e. automated decisions made about them beyond their ken, so install an extension or use a more privacy oriented UA.

Of course the spec could require Origin-Policy headers to be covered by all the rules on cookies including the extension APIs but why go to all that bother?






From: Mike West [mailto:mkwst@google.com]
Sent: 28 July 2016 14:14
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Mike O'Neill <michael.oneill@baycloud.com>; Brad Hill <hillbrad@gmail.com>; Patrick Toomey <patrick.toomey@github.com>; Joel Weinberger <jww@google.com>; Devdatta Akhawe <dev.akhawe@gmail.com>; WebAppSec WG <public-webappsec@w3.org>
Subject: 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using gpg4o v3.5.54.6734 - http://www.gpg4o.com/
Charset: utf-8

iQIcBAEBAgAGBQJXmhVtAAoJEOX5SQClVeMPWzYQAIocrM/xrzBtvHNQEeV1NJrB
wFBIdLG8kJ3guuhR7EY+oBGpL3AOC0FIEv88DcGMmsQImxyPNcotv5yDqo7f40RE
eNsvdUmqOuJPEVHUVDVes/k1/DFCARhcz5muG3DV0hRimNKAuo4jkCUqTe8HywDn
y8DcDOujiRdLrTsrmN5ixOqBZrPVxQ6wvzPWySuJy+Lg+knKC6kdmAiVuiuYBQa3
sUfOPPyuVTxucYvVcpasXtnL7iVMN4QdEESuYE+OPP3+TaDZQDFFslu+MLp0Nmr2
9my0sVnNmJe6dwx6d5zs8rDRQJVJXOxcLyfw8dMovtlnuSJQGrFR/DWABUgg/0JM
MN6KKiODaKEb45eMES3ss90iwQxQyYgiGcCku1KbavZeigQU9LXgUEMMEgops8L/
xzzOqJKSnRc9GEi8/SqZa4cJ4MUmYWaHUUAfQRHQFAbLQ7giuFGs8W2MJsb+drS0
+EYSEQByF4wSunDAjrN9CKTHFgqvXT7ucJiuF6m6orY5prc13XrSWHl7dvJJWtwn
/RugoOTK8dvBWNM8tWyAv/+jsVsRxIdWhgVTbD30+imMGrcVPlHJigeKIU3Rjunh
/XPvNOaG6wfahpCdxLkZeUg9IBR2EC2/2JKVKZYtSRBqqbNcl8ySVzkqYxky1Cwf
w8usq2wbQWzDaoDc+UN6
=RW3d
-----END PGP SIGNATURE-----

Received on Thursday, 28 July 2016 14:24:21 UTC