Confirmed users
1,247
edits
Thirdparty: Difference between revisions
→Implementation: Linkify bugs
(→Implementation: Linkify bugs) |
|||
| (7 intermediate revisions by one other user not shown) | |||
| Line 23: | Line 23: | ||
= Use cases = | = Use cases = | ||
To frame the following proposal and discussion, these are some simple examples of behavior on the web: | |||
#User visits multiple shopping sites, which have resources from ad sites embedded in iframes, images, or requests made directly from script. They are unaware the advertiser can track their movements across those sites. | |||
#User visits a site that embeds the Facebook "Like" button, but does not want their Facebook login cookies automatically sent. | |||
#User visits their credit union, which uses third party resources for banking functions, and wants those functions to work. | |||
#User visits a site that uses OpenID, Facebook Connect, or other federated login service, and wants to be able to log in to those services and use them with the site. ''Todo: OpenID may actually not require cookies on the first party site at all -- information is passed in a backchannel. Need to confirm. What about other authentication-related services?'' | |||
= Proposal Overview = | = Proposal Overview = | ||
| Line 37: | Line 36: | ||
Cookies are only sent back in situations where the double-keys are the same. For instance, when browsing buy.com, cookies set by an image hosted on ads.google.com would only be sent back when browsing buy.com; not when browsing another site. | Cookies are only sent back in situations where the double-keys are the same. For instance, when browsing buy.com, cookies set by an image hosted on ads.google.com would only be sent back when browsing buy.com; not when browsing another site. | ||
In addition, third party cookies are discarded after the session (i.e. on browser close). | In addition, third party cookies are discarded after the session (i.e. on browser close). ''This may be going too far -- it does not necessarily strike a good balance wrt UX/privacy. We might not want this as default behavior.'' | ||
''Definitions:'' | ''Definitions:'' | ||
| Line 67: | Line 66: | ||
== Rationale == | == Rationale == | ||
Again, let me reiterate -- what matters here is '''not''' ''how the user thinks of a particular action'', but ''whether the action is related, in an integral way, with the current site''. | Again, let me reiterate -- what matters here is '''not''' ''how the user thinks of a particular action'', but ''whether the action is related, in an integral way, with the current site''. This may seem counterintuitive, but: assume we have per-site cookie sandboxes; the problem now comes down to which sandbox to put each cookie into. This is less related to user perception than to how tightly coupled a given transaction is with a given sandbox. | ||
We have some hard data points here, but more is always better, and will allow us to make a more informed decision on how these changes will affect the web. | We have some hard data points here, but more is always better, and will allow us to make a more informed decision on how these changes will affect the web. | ||
| Line 86: | Line 85: | ||
:''Is the assertion really correct that open redirects should be first party? Counterexamples?'' | :''Is the assertion really correct that open redirects should be first party? Counterexamples?'' | ||
:''Random thought: we could introduce the concept of ''per-tab'' sandboxes (i.e. per docshell). A toplevel redirect could switch mode from double-keying by URIs to keying by docshell. This way, the concept of first party vs. third party disappears -- all cookies for that particular tab get their own sandbox. Complicates things a bit, but might solve the problem of deciding which sandbox a redirect goes into.'' | |||
:5. Consider two cases: ad popups, and login popups. Both need to be considered as having a first party domain of window.opener. By way of example -- Facebook Connect uses a popup window for the Facebook login; this login cookie then needs to be accessible from within an iframe on the original site. Otherwise, the Facebook content will not appear, and in fact the login process will entirely fail. The only way to fix this, with the predicate that iframe is third party, is to keep the popup window within the same sandbox. Conceptually, it makes some sense that popups be considered related to window.opener. | :5. Consider two cases: ad popups, and login popups. Both need to be considered as having a first party domain of window.opener. By way of example -- Facebook Connect uses a popup window for the Facebook login; this login cookie then needs to be accessible from within an iframe on the original site. Otherwise, the Facebook content will not appear, and in fact the login process will entirely fail. The only way to fix this, with the predicate that iframe is third party, is to keep the popup window within the same sandbox. Conceptually, it makes some sense that popups be considered related to window.opener. | ||
| Line 101: | Line 102: | ||
= Implementation = | = Implementation = | ||
Relevant bugs: | |||
* {{Bug|565965}}: Double-key cookies by (first party domain, setting domain). Work is in progress. | |||
* {{Bug|565475}}: Make third party cookies persist for the session only. This is controlled by a hidden pref, ''network.cookie.thirdparty.sessionOnly''. Landed on trunk. | |||
* Develop a more intuitive way for the user to indicate that they trust a certain site to interact with other sites. | |||
* Implement the first party carry-over rules described above, probably as a separate service such that localstorage etc. can use it. | |||
* Apply the rules developed here to localstorage and such. | |||
= Further Steps = | = Further Steps = | ||