Third party cookie investigation for embedding about metabase HOT 5 CLOSED

Alternative solutions

Cookies Having Independent Partitioned State (CHIPS)

https://developers.google.com/privacy-sandbox/3pcd/chips

New "Partitioned" attribute
Requires "Secure"

With partitioned cookies, when a user visits site A and embedded content from site C sets a cookie with the Partitioned attribute, the cookie is saved in a partitioned jar designated only for cookies that the site C sets when it's embedded on site A. The browser will only send that cookie when the top-level site is A.

For metabase:

Probably good. The only downside I can see is that if people are logged in on metabase-instance.com they will not be logged in automatically in the iframe on company.com/analytics

Storage Access API

https://developers.google.com/privacy-sandbox/3pcd/storage-access-api

New set of API that can only used from iframe.
It requires the user to have interactive with something before asking the permission
The user can deny access
The user needs to have interacted with embedded resource in a top level domain -> not suitable for most interactive embedded solution.

It's meant for use cases where both the following are true:

• The user will interact with the embedded content—that is, it is not a passive iframe or a hidden iframe.
• The user has visited the embedded origin in a top-level context—that is, when that origin is not embedded in another site.

For metabase:

Probably not a good solution for people whitelabeling and not providing top level access to MB.
The need of interaction to ask, and the need to ask/prompt is probably a big NO for most use cases

Related Website Sets

It requiers submitting to google the json of the related websites on github
It simplifies the Storage Access API by making some requirement looser, but it still seems more work than needed and not really pratical.

Federated Credential Management API

Experimental thing, it seems it's implemented by all browsers but I haven't looked into it as it seems to require a lot of changes

from metabase.

I managed to get it to break embedding:

• when using different domains for metabase and the hosting app (not just different subdomains, different domains entirely)
• on chrome beta (Version 125.0.6422.26 )
• with the flag #test-third-party-cookie-phaseout set to Enabled
• with MB_SESSION_COOKIE_SAMESITE=none(otherwise, from my testing, it never works with different domains), note that as we point out, this will make it not work at all with safari

Demo:
(chrome without flags on the left, with the flag on the right)
(some requests are slow because of the reverse proxy used for the domains)

Note that (at least now, let's see when this feature will get rolled out) there is a UI that allows to re-enabled them for 90 days, but it's likely something users will not do, as there is no UI that warns about the cookies being blocked (it only shows up in the console, which normal users don't watch).

from metabase.

CHIPS / "Partitioned" cookies experiment

I tried to use Partitioned cookies with the following diff:

diff --git a/src/metabase/server/middleware/session.clj b/src/metabase/server/middleware/session.clj
index e4c392ca8a..55dcc96d24 100644
--- a/src/metabase/server/middleware/session.clj
+++ b/src/metabase/server/middleware/session.clj
@@ -190,6 +190,7 @@
   (let [cookie-options (merge
                         (default-session-cookie-attributes session-type request)
                         {:http-only true}
+                        {:partitioned true}
                         ;; If permanent cookies should be used, set the `Max-Age` directive; cookies with no
                         ;; `Max-Age` and no `Expires` directives are session cookies, and are deleted when the
                         ;; browser is closed.

The results are promising, interactive embedding is working across two top level different domains.

Partitioned cookies/CHIPS means that if a resource from domain A is embedded in a page on domain B, then the cookies of the embeded resources will saved in {top level domain}/{embedded domain}, this means that the cookies of the iframe of domain A will be isolated from the ones from domain A accessed directly.

Let's assume the customer is hosting their app on customer.com, and their mb instance is mb-cloud.com.

IF they have an iframe with src="mb-cloud.com/dashboard/1" (instead of ttps://company-example.com/sso?return_to=${mb_url}/dashboard/1 as we suggest) this is something that could happen:

• if the user is logged in on mb-cloud.com
• if for some reason they are not logged in on customer.com
  then
  -> with partitioned cookies: they will not be auto logged into metabase, as they cookie for mb-cloud.com is not accessible from mb-cloud [embedded in] [customer.com](http://customer.com)
  -> without partitioned cookies: they will be logged in into the iframe (this is assuming they're not in the 1% group)

I initially didn't consider that this would only happen if they're not logged in into their jwt provider, so I think this is a super edge case we can probably ignore.

That said, we should probably think if we should allow the customers to opt out of the Partitioned parameter via a setting to make sure we're not accidentaly breaking their possibly unusual flows.

from metabase.

Some other updates

• I checked and it's (as we expected) still not working on safari, as they don't support CHIPS
• I confirmed that setting Partitioned always so true could break some unusual workflows (ie: our "zendesk flow")
• it seems that the "https requirement" for samesite=none is not needed for localhost

from metabase.

Closing the issue as we decided to proceed with CHIPS

from metabase.