Re: Big PING Ideas

On Apr 10, 2019, at 11:36 AM, Pete Snyder <psnyder@brave.com> wrote:
> 
> (Separate thread)
> 
> At the AC meeting, Jeff challenged us to suggest ideas that would improve privacy on the web, and not just prevent new standards from making it worse.  I think this is a great idea.

I think that’s exactly the right question to be thinking about: just mitigating against the problems introduced by new features is neither as satisfying nor as productive as exploring how we can improve user privacy on the platform generally.

I think we need to consider ways that we can make migrations (including deprecations) towards new features with better privacy practices. Otherwise, we will see this repeated debate of "feature X must have at least as poor privacy properties as alternative features A, B and C otherwise sites won’t adopt X". I’m facing this right now in discussing the ping attribute on hyperlinks, but we see the same in, for example, proposals about updating cookies to better match the same-origin policy or discussion of freezing, minimizing or replacing the User-Agent string.

Those debates won’t be purely standards questions: implementers will have a role to play in deciding which features to support and how to gracefully deprecate or limit functionality that is currently supported; site developers will need easy ways to migrate older content without sudden breakage. I think it’s something it would be valuable to discuss in an open and multi-vendor setting.

> Here are some large, partially thought through ideas, that I’d like to suggest for more discussion:
> 
> 1) Determine all rarely used browser functionality (difficult, but I have ideas!), any for any functionality behind a certain threshold, put it behind a permission prompt and / or block it until there is a user gesture in the frame and / or block access to it from 3p code.
> 
> 2) Use an APIs similar to Trusted Types (e.g. strings that know they’re different from other strings, or kinda-sorta a facsimile of taint tracking) to prevent values from storage syncs from moving across frame boundaries / network sinks.
> 
> 3) Flip the script on iframes; define a restrictive default feature-policy on all 3p frames.

I find this the most promising of your list, partly because I can see a strategy to get there. Standardizing feature policy (or even just iframe allow* attributes) and then setting a goal that the default is limited could give implementers a way to slowly ratchet it back, so that sites can explicitly choose what functionality they want to give iframes but we don’t remain in the situation where any embedded party (or any attack on any embedded party) gives widespread privileges. This is good security practice (least privilege) but it also has substantial advantages for privacy: both data minimization and explicit, observable requests for additional data and functionality.

> 4) Add idea of feature policy for scripts, define default restrictive feature policy for scripts, make this the default for sites taking advantage of Y new nice feature (HTTP3 / QUIC, etc.)

I understand the pushback here: we saw pushback in terms of limiting functionality to secure contexts over HTTPS as well, and I think it’s understandable. I think tying performance and other advantages to also include privacy advantages is one way to encourage migration, but I don’t think we should expect to rely on it, especially since (as Mark has already noted) different features get adopted separately and even by separate people.

As many browsers have indicated increased willingness to block requests that they think have negative privacy implications, that blocking could be connected to a more restricted and privacy-by-default set of policies. Safe or privacy-friendly policies on embedded content could be a signal to unblock and that policy could change over time. In order to aid that process, though, we would need to standardize ways for sites or embedded parties to explicitly specify their own policies and restrict data or functionality.

Thanks,
Nick