[Openid-specs-ab] [Browser Team] This looks like attempt to make first party sets workable

[Tom Jones]

I suspect that improving first party sets to include federation might be
the best way forward.

Peace ..tom

'Chris Fredrickson' via blink-dev
8:38 AM (1 hour ago)
to blink-dev Unsubscribe

Contact emails

{cfredric,chlily,davidben,kaustubhag,chrome-first-party-sets}@chromium.org

Explainer

   -

   Explainer <https://github.com/cfredric/sameparty>
   -

   Specification: will post when ready.
   -

   TAG review <https://github.com/w3ctag/design-reviews/issues/595>


Summary

Introduce a cookie attribute called SameParty, which allows web developers
to annotate cookies that are allowed to be set or sent in contexts where
all ancestor frames belong to the same party, as demarcated by First-Party
Sets <https://github.com/privacycg/first-party-sets>.

Motivation

In order to increase privacy on the web, browser vendors are either
planning or already shipping restrictions on cross-site tracking, such
as phasing
out third-party cookies
<https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html>.
Third-party cookies are currently defined
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Tracking_and_privacy>
as those associated with a site
<https://html.spec.whatwg.org/multipage/origin.html#sites> that is
different from the site of the top-level page. However, modern websites are
typically served over multiple domains/sites, many of which are owned by
the same organization. First-Party Sets
<https://github.com/privacycg/first-party-sets> provides a mechanism to
group domains/sites belonging to the same organization as being same-party
with each other, and thus defines a privacy boundary for websites.

The SameParty cookie attribute provides web developers a means to annotate
cookies that are allowed to be set or sent in same-party, cross-site
contexts; and hence should not be subject to obsoletion. In addition,
SameParty cookies are blocked in cross-party, cross-site contexts.

We are introducing SameParty now, early in the process of phasing out
third-party cookies, as a means for sites to test out the First-Party Set
behavior. While third-party cookies are still around today, we want to
provide ample opportunities for web developers to test that their sites
work with SameParty and to migrate their cookies to the new model far in
advance of third-party cookies' removal.

Risks

Interoperability and Compatibility

Little to no interoperability risk. The SameParty cookie attribute does not
reuse or alter a previously defined token, and should be ignored by
browsers that don't support it, as specified by RFC 6265bis
<https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05#section-4.1.2>.
Cookies set with SameParty will likely also specify SameSite=None, such
that SameParty can be used preferentially when supported, while browsers
that don't support SameParty will continue to apply SameSite=None (which is
more permissive than SameParty), such that no site breakage is expected.
Alternatively, cookies may be set with both SameParty and SameSite=Lax, so
that browsers that don't support SameParty continue to apply SameSite=Lax
rules (more restrictive than SameParty) to protect against cross-site
attacks.

No compatibility concerns, because without the SameParty attribute, cookie
semantics are unchanged.

Edge: Positive
<https://github.com/privacycg/meetings/blob/master/2020/telcons/12-10-minutes.md>
(supportive of continued discussion)

Firefox: Opposed to SameParty
<https://github.com/privacycg/meetings/blob/master/2020/telcons/12-10-minutes.md>,
opposed to First-Party Sets (considers harmful)
<https://github.com/mozilla/standards-positions/pull/360/files>

Safari: Positive (support for working together in a W3C CG)
<https://github.com/cfredric/sameparty/issues/2>

Web / Framework developers: Positive signals as demonstrated in W3C
PrivacyCG discussions
<https://github.com/privacycg/meetings/blob/master/2020/telcons/12-10-minutes.md>


Ergonomics

This attribute is to be used in conjunction with First-Party Sets
<https://groups.google.com/a/chromium.org/g/blink-dev/c/0EMGi-xbI-8/m/d_UxAJeiBwAJ>.
For the initial prototype in Chromium, a cookie that specifies SameParty
while the site is not in a specified First-Party Set will be subject to
SameSite enforcement rules, rather than SameParty rules. This is because
the First-Party Sets are to be delivered via Component Updater, and there
may be a gap between when the First-Party Sets are updated and when the
SameParty cookies are deployed, during which the cookies should not be
subject to SameParty enforcement to avoid site breakage.

Activation

To use this feature, sites will have to join a First-Party Set (process to
be detailed elsewhere). Developers will also have to change their Set-Cookie
headers and JavaScript document.cookie writes to apply a valid SameParty
attribute.

Developers can also perform end-to-end testing of their sites with this
feature enabled, without deploying a real First-Party Set, by using the
--use-first-party-set= command-line switch in Chromium.

Debuggability

We plan to update the DevTools Cookies panel to display the SameParty
attribute value, and show tooltips in the Network tab when cookies are
excluded due to SameParty enforcement. In addition, the Issues tab will
display warnings when the attribute is used incorrectly.

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?

No. This feature will be supported on Windows, Mac, Linux, Chrome OS, and
Android, but will initially not be supported on Android WebView. This
feature depends on First-Party Sets, which will initially not be supported
on Android WebView due to the Component Updater dependency during the
initial prototype phase.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5280634094223360
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210115/91fc0f4d/attachment.html>