search

w3cping / privacy-threat-model

A target privacy threat model for the Web
https://w3cping.github.io/privacy-threat-model
Apache License 2.0
23 stars 7 forks source link

Add more states to threat model for goals we haven't blocked yet #38

Open jyasskin opened 4 years ago

jyasskin commented 4 years ago

Several of the cells in https://w3cping.github.io/privacy-threat-model/#model-cross-site-recognition are currently possible (in some or all browsers), but we either have concrete plans to make them impossible, or we're actively working on finding ways to make them impossible.

Threat model table after #33

For example, in browsers that still allow third-party cookies, loading iframes on both sides of a navigation currently allows a tracker to transfer a user ID between those frames. We know how to prevent this and have a plan to do so. We can mark this with … maybe a ⏳ emoji indicating that time is running out?

On the other hand, an attacker who can run Javascript as the first party on both sides of a navigation can transfer an ID through query parameters. We'd like to block this link decoration, but (as far as I know) we don't yet have any better ideas than stripping query parameters like fbclid or clearing storage tainted by any query parameter. We could mark these open research questions with … 🤔?

We should be sure not to compromise API designers' ability to use the table to see what capability/goals pairs they must not allow (anything other than a "✓"). Maybe we should mark those with a background, or add a checkbox to the document to turn all the "don't allow this" squares back into "✘"s.

We should be sure to mark all these states with an accurate aria-label and/or title to make them easier to read. I think making each of them into a parameterized Bikeshed include file will make it easier to keep everything consistent.

kdzwinel commented 4 years ago

  1. This table is great, thank you for putting it togheter! I don't fully understand though why we'd want to put it into the "Target Privacy Thread Model" as it's capturing current state of things and not the said "target". I assume that our goal should be to get rid of all of those "✓" at some point, even if we don't see the solution today. "✓" seems to be saying that API designers are free to create new ways to enable those forms of cross-site recognition which can only make them harder to block in the future.

  2. We should be sure to mark all these states with an accurate aria-label and/or title to make them easier to read.

👍 , but since we are talking about ease of reading… both tables are either partially or completely unreadable on FF and Safari because of overlapping labels. Should that be a separate issue on this repo? (I was hesitant to open one because it seems awfully technical, while all other open issues are about the contents of the doc.)