search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.14k stars 588 forks source link

Liberty: Support for CHIPS (Cookies Having Independent Partitioned State) #27405

Closed volosied closed 5 days ago

volosied commented 8 months ago

Description

To reduce the cross-site tracking, browsers will eventually restrict third-party cookies (such as Chrome by Q3 2024). The only allowed use of third-party cookies will be "partitioned" cookies. This new behavior means that no other website can access these cookies because they can only be used with their top level site.

For example, using the following scenario: Site A (top level) embeds site C and C sets a cookie. C can be an embedded map service, a chat box, ...etc.

Without Partitioning: If the browser goes to Site B (top level) which also embeds C then C can access the cookie from Site A.

With: If the browser goes to Site B (top level) which also embeds C then C cannot access the cookie from Site A. This this because the top level site has changed.

This is accomplished via the “Partitioned” attribute (used only with SameSite=None the secure flag). 
 Useful information and examples can be found here. However, not all browsers support the new attribute yet as it's still experimental. (Need to look into Safari and Firefox)

This will impact Liberty in a few ways:

New configurations will need to be added to enable / disable the “Partitioned” attribute.

User Experience / Implementation Proposal:

Our idea is to follow the SameSite precedence (see blog here) and create a new partitioned metatype on the samesite element. Partitioned is mostly a follow up to SameSite, and therefore, we are aligning them together.

When partitioned is enabled (default is false for channel and defer for webAppSecurity and httpSession. ), it would add the partitioned attribute to the specified cookies. Partitioned can only be added when SameSite=None and secure exist (note that secure is automatically added when SameSite=None). As an example: <!— sugarcookie would be partitioned , but chocolatechip would not be —> <samesite lax="chocolatechip" none="sugarcookie" partitioned="true"/> Result:

set-cookie: sugarcookie=someValue; SameSite=None; Secure; Partitioned;
set-cookie: chocolatechip=someValue; SameSite=Lax; Secure;

Another example: 

<httpEndpoint id="defaultHttpEndpoint"
              httpPort="9080"
              httpsPort="9443"
              samesiteRef="samesiteReference">
</httpEndpoint>
<samesite none="cookieOne" id="samesiteReference" partitioned="false"/>

Result: set-cookie: cookieOne=someValue; SameSite=None; Secure;

Similar logic would apply to httpSession and webAppSecurity. For example:

<httpSession cookieSameSite="None" cookiePartitioned="true"/>
<webAppSecurity sameSiteCookie="None partitionedCookie="true" />

Default Value - False / Defer (No Partition)

Other Info:

Partitioned will be added a a known cookie attribute (for cookie parsing), can then be added via HttpServletResponse.setHeader and HttpServletResponse.addHeader.

The Webcontainer SPI will also be updated to support Partitioned ( Note: Currently using this API to add anything but the SameSite attribute will be ignored.)

Documents

When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.

General Instructions

The process steps occur roughly in the order as presented. Process steps occasionally overlap.

Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").

Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.

If you need assistance, reach out to the OpenLiberty/release-architect.

Important: Labels are used to trigger particular steps and must be added as indicated.

Prioritization (Complete Before Development Starts)

The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.

Prioritization

Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID. Furthermore, each identified item places a blocking requirement on another team so it must be identified early in the process. The feature owner may check-off the item if they know it doesn't apply, but otherwise they should work with the focal point to determine what work, if any, will be necessary and make them aware of it.

Design Preliminaries

Design

No Design

FAT Documentation

A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it kind=noship or beta fencing it.
Code may not GA until this feature has obtained the Design Approved or No Design Approved label, along with all other tasks outlined in the GA section.

Feature Development Begins

Legal and Translation

In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.

Legal (Complete before Feature Complete Date)

Innovation (Complete 1 week before Feature Complete Date)

Translation (Complete by Feature Complete Date)

In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.

Beta Code

Beta Blog (Complete by beta eGA)

A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.

Feature Complete

Focal Point Approvals (Complete by Feature Complete Date)

These occur only after GA of this feature is requested (by adding a target:ga label). GA of this feature may not occur until all approvals are obtained.

All Features

Design Approved Features

Remove Beta Fencing (Complete by Feature Complete Date)

GA Blog (Complete by Friday after GM)

Post GM (Complete before GA)

Post GA

volosied commented 6 months ago

User Experience / Implementation Proposal:

Our idea is to follow the SameSite precedence (see blog here) and create a new partitioned metatype on the samesite element. Partitioned is mostly a follow up to SameSite, and therefore, we are aligning them together.

When partitioned is enabled (default is false), it would add the partitioned attribute to the specified cookies. Partitioned can only be added when SameSite=None and secure exist (note that secure is automatically added when SameSite=None). As an example: <!— sugarcookie would be partitioned , but chocolatechip would not be —> <samesite lax="chocolatechip" none="sugarcookie" partitioned="true"/> Result:

set-cookie: sugarcookie=someValue; SameSite=None; Secure; Partitioned;
set-cookie: chocolatechip=someValue; SameSite=Lax; Secure;

Another example: 

<httpEndpoint id="defaultHttpEndpoint"
              httpPort="9080"
              httpsPort="9443"
              samesiteRef="samesiteReference">
</httpEndpoint>
<samesite none="cookieOne" id="samesiteReference" paritioned="false"/>

Result: set-cookie: cookieOne=someValue; SameSite=None; Secure;

Similar logic would apply to httpSession and webAppSecurity. For example:

<httpSession cookieSameSite="None" cookieParitioned="true"/>
<webAppSecurity sameSiteCookie="None partitionedCookie="true" />

Default Value - False (No Partition)

Other Info:

Partitioned will be added a a known cookie attribute (for cookie parsing), can then be added via HttpServletResponse.setHeader and HttpServletResponse.addHeader.

The Webcontainer SPI will also be updated to support Partitioned ( Note: Currently using this API to add anything but the SameSite attribute will be ignored.)

volosied commented 5 months ago

Our CHIPS implementation attempts to use the samesite config as the baseline and any overriding changes (i.e session / security) are applied on top.

I think this overriding makes sense.

However, there are two notes: 1) By default SameSite / Partitioning is disabled.
2) Partitioned is only accepted by browsers when SameSite=None. Liberty tries to only set Partitioned on SameSite=None (see first expected scenario) 2) Partitioned isn't set unless samesite is specified. However, session doesn't know what the samesite config is, so we have to set the values on it. This creates an unexpected scenario (see last)

List of scenarios with Liberty's current implementation:

Expected Scenarios:

Scenario:

    <samesite/>
    <httpSession cookieSameSite="Lax" cookiePartitioned="true" />

Result: Partitioned is ignored since it doesn't apply Regular Cookie:
Session Cookie: SameSite=Lax;

Scenario:

    <samesite/>
    <httpSession cookieSameSite="None" cookiePartitioned="true" />

Result: Regular Cookie:
Session Cookie: SameSite=None; Partitioned

Scenario:

    <samesite none="*" partitioned="true"/>
    <httpSession />

Result:
Regular Cookie: SameSite=None; Partitioned Session Cookie: SameSite=None; Partitioned

Scenario:

    <samesite none="*" partitioned="true"/>
    <httpSession cookiePartitioned="false"/>

Result: cookiePartitioned overrides samesite's partitioned Regular Cookie: SameSite=None; Partitioned Session Cookie: SameSite=None;

Scenario:

    <samesite none="*"/>
    <httpSession cookiePartitioned="true"/>

Result: Split config; only session cookie is partitioned Regular Cookie: SameSite=None; Session Cookie: SameSite=None; Partitioned

Scenario:

    <samesite partitioned="true"/>
    <httpSession/>

Result: No samesite, so no partitioned Regular Cookie: Session Cookie:

Unexpected Scenario:

Scenario:

    <samesite />
    <httpSession cookiePartitioned="true"/>

Result: Unexpected -- samesite is not set, but partitioned exists. However, we don't have a way to check samesite config from the session code. Regular Cookie: Session Cookie: Partitioned

volosied commented 5 months ago

With the time crunch, and I think we should let this one unexpected scenario slide by for the following reasons:

1) https://github.com/privacycg/CHIPS?tab=readme-ov-file#using-set-cookie-with-partitioned 

User agents may only accept Partitioned cookies if their SameSite attribute is None.

Note: a Partitioned cookie without SameSite=None is effectively just a same-site cookie which cannot be sent in a third-party context anyway.

This mean browsers won't do anything since SameSite=None is missing.

2) I don't expected many users to only set partitioned on -- any support cases will just tell them to disable it if they won't want it.

Security cookies might also encounter this too, but I think that the same reasoning above also applies.

chirp1 commented 2 months ago

Based on a slack with David, Volodymyr, and me, Volodymyr will have blog post and an autogenerted metatype. No doc need from the ID team. Approving the epic.

volosied commented 3 weeks ago

Issue to GA CHIPS: https://github.com/OpenLiberty/open-liberty/issues/28070