"Third-party cookie will be blocked" message

[Likely Logic]

Hello,

I've noticed in the UI of my extension Control Space I'm getting lots of warnings about "Third-party cookie will be blocked".

They all seem to be related to favicons. My extension is a tab manager, so it shows the titles of the open tabs, along with the favicon.

There are two sets of warnings, "Reading cookie" (86) and "Setting Cookie" (4).

> Cookies with the SameSite=None; Secure and not Partitioned attributes that operate in cross-site contexts are third-party cookies. In future Chrome versions, reading third-party cookies will be blocked. This behavior protects user data from cross-site tracking.

I have a loose grasp on cookies and how they are sent with requests, but I don't really understand the ramifications of the upcoming change and whether it is going to affect the functionality of my extension.

Can someone fill me in?

Thank you

[Pavel Aronovich]

For icons, use the API:

https://developer.chrome.com/docs/extensions/how-to/ui/favicons

понедельник, 5 февраля 2024 г. в 16:57:06 UTC+3, Likely Logic:

[Likely Logic]

OK, makes sense, thanks.

I'm currently on MV2, I have to migrate before July, so will just have to live with the warnings for the time being huh?

[Pavel Aronovich]

Yes :)

понедельник, 5 февраля 2024 г. в 18:18:36 UTC+3, Likely Logic:

[Oliver Dunk]

How are you embedding the favicons?

My best guess is that there are cookies associated with the sites you are loading favicons for, and this is just a warning that those cookies won't be sent when accessing the favicon for users with third-party cookie blocking enabled. Image requests are generally different to a normal CORS request though so I'm not sure what is happening or able to reproduce.

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/208948f4-0e07-42fc-a6b1-3206c60366c0n%40chromium.org.

[Likely Logic]

Hi Oliver,

I'm grabbing the favicon property from the Tab and just using it as an CSS background-image property in the page.

I just need the images to display. Though it sounds like I need to migrate to the favicons permission when I upgrade to MV3 anyway?

[Oliver Dunk]

You should be ok without it actually!

The favicon permission is an alternative to a previous feature where you could request the "chrome://favicon" permission and access favicons from Chrome's local database. You can learn more about it here.

If you are loading from the web, and that is working for you, you should be fine to continue doing so.

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

[Likely Logic]

But that is great info, as I am doing that for bookmark items!

I've mucked about with the documented and undocumented favicon functions, trawled some of the source code too, so good to know there's now an official way to do it.

A couple of questions:

• Does it dispatch proper events if it doesn't have an icon?
• Is there any way to manually populate Chrome's local database with a new favicon (other than visiting the page) ?

I ask as my extension creates some bookmarks on load, and the icons show as missing if those pages have never been visited.

I'm been ideating all kinds of "hidden" ways to visit those pages so the user doesn't see my vain attempts to populate Chrome's database...

[Oliver Dunk]

Glad it was helpful! The documentation Pavel shared explains everything in more detail.

There aren't currently any events for a missing icon I'm afraid. I'm also not aware of a way to populate the database, although you might be able to figure something out by playing around. Perhaps if these are fixed links you could include the icons in your extension bundle?

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

[Jackie Han]

The warnings of "Third-party cookie" don't affect the use of `tab.favIconUrl` for images, because you don't rely on cookies.

Does it dispatch proper events if it doesn't have an icon?

This is a real problem for developers. At present, chrome favicon api always returns 200 http status code even if there is no cached favicon (in this case it returns a default favicon).

I recommend adding a new search parameter for new behavior. For example, 

/_favicon/?pageUrl=URL&size=SIZE&failIfNoCache=yes 

If adding this parameter, return 404 instead of 200 status.

I can create a new issue for this feature request if needed.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/e2d2dc3d-ac35-4e01-b612-491ac21da97en%40chromium.org.

[Oliver Dunk]

Please feel free to open a feature request!

It would be nice to see if we can return something that still allows the image to load, since some developers may like having the fallback but just want to be aware it is there.

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

[Likely Logic]

> Does it dispatch proper events if it doesn't have an icon?

I've actually thought a solution to this problem.

The generic icon seems to consistently converts to a data URL, so you can serialise any result from Chrome's internal API and compare to a known missing data URL.

I've tested it and it seems to work:

https://gist.github.com/davestewart/6e6ba20b85abecdf26f340dd00e3040e

[Jackie Han]

> Please feel free to open a feature request!

I created a feature request at https://issues.chromium.org/issues/324117289

> It would be nice to see if we can return something that still allows the image to load, since some developers may like having the fallback but just want to be aware it is there.

HTML/JS/CSS already supports handling fallback. For example, 

`imgElement.addEventListener('error', handleFallback);`

The current problem is that the favicon api always succeeds with 200 status code. Because the favicon api is not a real api, it is just a URL for image. So my feature request is adding a new search parameter for new behavior.

> workaround: https://gist.github.com/davestewart/6e6ba20b85abecdf26f340dd00e3040e

It should work, but it's not ideal. It adds complexity and a lot of computation. Bookmarks manager or tabs manager extensions may require creating hundreds of favicons.

[Likely Logic]

I agree that standards-compliant support would be excellent.

As would a fallback option to single-letter icons as I think there was in one of the previous implementations.

I've updated the Gist; I've expanded its capabilities to return HTMLImageElements as well as reuse the Canvas element, so should be about as efficient as it can get now.

I'll add a bookmark test later today when I have time.

[nem...@readcube.com]

How will this change affect regular api requests that extension makes?

For example, user currently has tab opened with domain.com

Extension is in background making request to another-domain.com and is including cookies with that request, and those cookies are also from another-domain.com domain. Is this going to be still possible in the future, or those cookies are not going to be sent with this change in the future? 

[Oliver Dunk]

In most cases, requests from an extension context to another-domain.com should work the same. A request from an extension service worker or a chrome-extension:// page open as the top-level frame in a tab will work the same, including bypassing CORS and including SameSite=Strict cookies if you have host permissions.

The biggest changes happen if (for example) you embed an extension page in a third-party site. Currently requests to another-domain.com from a chrome-extension:// subframe won't include most SameSite=Strict and SameSite=None cookies (the exception is those marked as Partitioned). This actually feels like a bug to me and I've been looking into if we can fix that, but nothing has been decided yet.

If you have any specific questions, let me know. Otherwise my advice would be to test for now (#test-third-party-cookie-phaseout on chrome://flags) and check everything is working, since there's a lot of nuance and it's hard (at least I've found it so!) to reason about what will break hypothetically.

Hope that helps!

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

[Likely Logic]

OK, I've spent some time on the icon 404 issue to try and really understand the problem / pitfalls:

I've create a Git repo here:

• github.com/davestewart/chrome-uncached-favicons

I've modified the approach to listen to existing DOM images / icons and the helper function lets you know if it's missing or not.

Performance is relatively slow vs an image error event (as it has to serialise and compare the image) but won't be noticeable in pretty much most meaningful contexts where you would load at max 10s or 100s, not 1000s of icons at once. 

The harder part of the problem, is what to do about missing icons? It seems the only way for Chrome to have an icon in its cache is to have loaded the page in a tab.

Note: I have a LOT of missing icons above as I recently transferred machines.

Anyway, lots more detail and initial attempts to get to the bottom of these issues in the repo.

New ideas welcome here or as issues on the repo 🙏