Elaborate the high-level threats section.

[jyasskin]

I framed the threats that came out of the TPAC discussion as the web's interpretation of the general threats in RFC 6973.

This explicitly describes same-site visit correlation as requested by #1, although it doesn't do so in the low-level goals section.

---

Preview | Diff

[jyasskin]

@martinthomson, does https://pr-preview.s3.amazonaws.com/jyasskin/privacy-threat-model/pull/6.html#hl-recognition-same-site capture the high-level parts of your #1? (There's still more to flesh out in section 6 on this topic, so just focus on the high-level problem here. :)

[martinthomson]

I think that what I had in mind was a framing of this capability as a platform capability that we wanted to preserve, albeit within bounds. This does a good job of establishing the threat though I would probably point more clearly at this being a core platform feature and that the risk only applies when the capability is present when not expected.

[martinthomson]

More often it is based on source IP. Not sure how useful that is in this context though.

[jyasskin]

https://w3c.github.io/fingerprinting-guidance/#passive includes source IP in "browser fingerprinting", although I'm not attached to this sentence if there's a better way to summarize how unexpected recognition happens.

[martinthomson]

"vs" is an abbreviation, so

Suggested change

	otherwise benign (vs [[#hl-sensitive-information]]). For example:
	otherwise benign (vs. [[#hl-sensitive-information]]). For example:

or

Suggested change

	otherwise benign (vs [[#hl-sensitive-information]]). For example:
	otherwise benign (versus [[#hl-sensitive-information]]). For example:

or even

Suggested change

	otherwise benign (vs [[#hl-sensitive-information]]). For example:
	otherwise benign (as opposed to [[#hl-sensitive-information]]). For example:

[jyasskin]

I used "as opposed to".

[martinthomson]

I would make it clearer here that this sort of correlation is entirely expected in most instantiations of the platform. But that the goal of the design is to ensure that users are in control over whether it is possible and numerous mechanisms exist that might be expected to break this sort of recognition. Then you can get into the list.

[jyasskin]

Good point. I've added an initial paragraph to describe how the web platform makes recognition expected in most cases.

[npdoty]

This is good work to expand the high-level list of threats (with useful citations to previous standards work in RFC 6973) with some direct connections to the Web-specific privacy threats we're most used to. I think we could refine this a bit now (for example, I don't think we should rely too heavily on "unexpected"), but then merging it should be useful even if we're keeping an ongoing list of issues of how to add, define or detail threats.

[npdoty]

I think "unexpected" may lead to some confusion over the privacy value and some unnecessary contention over analyzing threats and mitigations. I believe we typically mean that the privacy threat is unwanted same-site (or cross-site) recognition and that for those well-educated users who have strong control over their software settings unexpected recognition by the same or different sites is unexpected and a privacy violation because the user didn't want it and may have tried to protect against it and unexpectedly failed. Users who don't understand the intricacies of the platform may also suffer privacy violations of unwanted recognition, even some users who expect it to happen because they have given up any pretense of control.

That is, I don't think we could fully resolve this privacy threat by just increased education warning users that they may be strongly recognized all the time despite their best efforts. Making same-site or cross-site recognition universally expected does not provide all the advantages of privacy.

[jyasskin]

I like changing this to "unwanted".

[npdoty]

👍