- From: Gabriel Fernandez <gbrlfrnndz@outlook.com>
- Date: Thu, 29 Jan 2015 14:29:16 -0500
- To: David Singer <singer@apple.com>
- CC: Mike O'Neill <michael.oneill@baycloud.com>, Wendy Seltzer <wseltzer@w3.org>, "public-privacy@w3.org" <public-privacy@w3.org>
> On Jan 29, 2015, at 1:27 PM, David Singer <singer@apple.com> wrote: > > >> On Jan 29, 2015, at 19:09 , Mike O'Neill <michael.oneill@baycloud.com> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >>> Interesting mix of norms and tech -- and yes, a different privacy threat >>> model from the one many of us are accustomed to considering. Here, we're >>> trusting the server to share our interests and want to help us enforce >>> the contextual boundaries we choose, even if its knowledge could span >>> those boundaries. >>> >>> This model is a better match with the Web Origin security model -- where >>> an origin site is presumed to have control of the web application >>> security, and the end-user must choose to trust the origin (with limited >>> user-side overrides) or not visit the site. >>> >>> I wonder what sorts of feedback could help to reinforce to end-users >>> that their trust was in fact merited. >>> >>> --Wendy >> >> >> It would have to include all the servers being accessed, third-parties also. I think David's header would be seen all of them, and it would only take one to ignore the contextual boundaries, decide to combine multiple personas with other data in a PII keyed database, then broadcast it to the world (and UA based UUIDs are far more reliably user-identifying than IP addresses which are usually ephemeral and non-unique). > > True, but donĄ¯t forget weĄ¯re coming from a state where the servers donĄ¯t even know of the desire. I donĄ¯t mind machine-based discoverability, but itĄ¯s tricky to work out how to include transparent proxies and caches in that. > >> > Cookies and NAT/proxy inspection are entrusted along with explicit disclosure of user information to the server of origin, of course. But there should be a specification for http::forbidden and alternative error code interpretation so for the proxy-server connection policy makers can declare such in terms of use. Gabriel DB Fernandez pgp: 9425a6af
Received on Thursday, 29 January 2015 19:29:45 UTC