You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I think it would be ideal to have something further in the document. Specifically text covering the following:
The user expectations and privacy boundaries we think the platform should uphold
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)
In what cases, if ever, are vendors allowed to deviate from the above?
So, one straw-example following the above template would be:
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)
Users are expected to understand what a web host is, that different top-level eTLD+1s are different logical entities.
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:
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.
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.
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).
https://w3cping.github.io/privacy-threat-model/#high-level-threats currently starts with
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
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.
The text was updated successfully, but these errors were encountered: