Extension not working when chrome://flags/#test-third-party-cookie-phaseout is enabled

[Laura Gutierrez]

Hi,

We have an extension (Gumbamail) which is executed within Gmail.

It has been working for years, but I am testing the extension enabling the flag #test-third-party-cookie-phaseout (as it will be enabled in future versions of Chrome) and it is not working anymore.

As the user is authenticated (the extension communicates with a backend server we own) two login cookies are created, which should be attached to every request made to our backend server.

The URL is added to the host_permissions in the manifest. Nevertheless, the cookies are ignored. I would like to understand if this is the expected behavior or not, and if there is a way to keep this configuration working before taking action.

The extension code is initiated through the InboxSDK library.

Any clarification regarding our scenario + how to manage third-party cookies would be appreciated and helpful.

Thank you

P.D. It is easy to test. Just enable "chrome://flags/#test-third-party-cookie-phaseout", install the Gumbamail extension, go to Gmail, and activate your Gumbamail account. You can see that menus are loaded but when you try to interact (click on "my campaigns", "my lists", "my templates", etc.) it won't be able to load the content (see attached screenshot). 

[Oliver Dunk]

Hi Laura,

Thanks for reaching out. I've been trying to keep an eye on the impact of third-party cookie deprecation on extensions so this is definitely interesting to me.

If I understand correctly, you're making a request from a content script on https://mail.google.com/ to /init, and this sets a session cookie which needs to be passed along with future requests.

Since this is a SameSite=None cookie, and the request is being made from https://mail.google.com/, this would be considered a third-party cookie. I don't think we have any special behaviour for content scripts right now so I can understand why setting that cookie would be blocked.

Is https://mail.google.com/ the only site you need to be signed in on? If so, I wonder if you could set the Partitioned attribute on the cookie. This will make it only accessible from the Google mail domain but prevent it from being blocked entirely.

Alternatively, you could move your networking logic into an iframe or the background page where host permissions do have more effect on the behaviour. You can read about that here: https://www.chromium.org/updates/same-site/test-debug/#testing-chrome-extensions

I'd definitely love to know more about how you get on - this may also be a case where we can add some special behaviour in the future, but I don't have anything specific to promise today.

Feel free to email me directly if you want to discuss this more and don't feel comfortable using the mailing list.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/5aa79165-5482-4179-847a-f95c8e69bc9dn%40chromium.org.

[Laura Gutierrez]

Hi Oliver,

I am sorry for the late update.

You pointed me in the right direction, so the answer was to create the session cookies as partitioned cookies.

A briefing of the main actions required:

• Add partitioned attribute: Configure a middleware in our backend server to add the "partitioned" attribute only for cookies created by the extension within Gmail.
• Adapt chrome.cookies.get(): In the "background", I have to read the session cookie. Using the "chrome.cookies" library requires an adjustment, as "partitioned" cookies are not read the same way. In the "chrome.cookies.get()" function, it is required to include the "partitionKey" filter, if not, the cookie is not detected (even if you search for the right "name" and "url").
• Invalidate old not partitioned cookies: Two cookies with the same name, but one partitioned and the other one not partitioned, are not treated as the same cookie by the browser. This means that for already existent users with the old session cookie active, when the new session cookie partitioned is created, this one is not overwriting the old one. Both coexist, which can be problematic. So, on extension initialization, I had to add a request to our backend server where the session cookies are created this way: not partitioned and with an expiration date in the past. This way, the old session cookies are invalidated and they don't interfere with the new partitioned session cookie created.
• Remove requests in the background context: In the "background" context, I had some requests to our backend server too. As the background context has a different domain, the session cookies are not valid here anymore. So, a refactor was required to move this requests to the "content scripts" context.

Bye!

[Oliver Dunk]

Hi Laura,

Really appreciate the update. Glad to hear you were able to get things working!

I'd be curious about the problems the non-partitioned cookies were causing (they should just be ignored), although it sounds like you sorted that so hopefully not a problem anymore.

It's unfortunate that you had to move requests from the background. Do these involve any sensitive data that you might not want to expose in the page? The reason I ask is that we consider the background slightly safer than content scripts since it runs in a separate process. This shouldn't be a concern if all of the requests are using data the page has anyway, but if the background knows things you wouldn't want the page to know, trying to find a way to keep those requests in the background is a good way to keep the process isolation which provides some additional safety at the system level.

There's some more on that here: https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure#content_scripts

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB