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

Discussion of high level threats should include clearer normative statements #37

Open jyasskin opened 4 years ago

jyasskin commented 4 years ago

https://w3cping.github.io/privacy-threat-model/#high-level-threats currently starts with

User agents should attempt to defend their users from a variety of high-level threats or attacker goals, described in this section.

but most of the individual threat descriptions don't follow this up by saying what UAs should do about them. For example, https://w3cping.github.io/privacy-threat-model/#hl-recognition-cross-site could add something like

UAs should prevent entities from tracking a user across different sites without that user's intent.

The RFC2119 aspect of "SHOULD" that "there may exist valid reasons in particular circumstances to ignore a particular item" then gets elaborated in the high-level threat's detailed threat model.

I think this matches @pes10k's request for more principles in the document.

pes10k commented 4 years ago

(apologies for the delay in following up on this)

I think it would be ideal to have something further in the document. Specifically text covering the following:

  1. The user expectations and privacy boundaries we think the platform should uphold
  2. The level of technical sophistication we expect users to have, to meet the above expectations (e.g. when is the privacy loss the users "fault", and when is it the browser's "fault" to fail to meet those privacy expectations)
  3. In what cases, if ever, are vendors allowed to deviate from the above?

So, one straw-example following the above template would be:

  1. When a user visits a site owned by a single entity (defined as a single eTLD+1 in the top level frame), no other eTLD+1 should be able to tie that visit to a user's activities on another web entity (again defined as a eTLD+1, in the top level frame)
  2. Users are expected to understand what a web host is, that different top-level eTLD+1s are different logical entities.
  3. The above expectation can only be loosened when a user gives explicit permission, such as in the form of a consent dialog

Another might be:

  1. Users should be able to sever an association to all previous browsing behavior, such that a website (again, top level eTLD+1) cannot link a user's behavior before the "severing" action to behavior after the "severing" action.
  2. Users are expected to understand the metaphor of a profile (though possibly expressed through a different metaphor), and that behaviors in a single profile are linked; behaviors across profiles are no linked.
  3. The above expectation should only be loosened when the user explicitly and unambiguously chooses to re-identify with the site, such as re-using authentication credentials.

I'd be interested to know if others think this model is a useful way of framing the document (independent of whether the above to straw-examples are good instances of the model).