Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jyasskin opened this issue Jun 4, 2020 · 1 comment
Assignees

Comments

@jyasskin
Copy link
Member

jyasskin commented Jun 4, 2020

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
Copy link
Collaborator

pes10k commented Jun 30, 2020

(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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants