librewolf/issues
25
145

Bug - Youtube cookies not being blocked despite 100% blocks in place #2539

Closed
opened 2025年06月11日 16:33:53 +02:00 by fkmozilla · 4 comments

I have every variation of youtubes domain set to BLOCK in my cookie settings, show in attachment 1, also block under tools/page-info/permissons as show in attachment 2.

Yet cookies are still being accepted from youtube, shown in attachment 3.

I've deleted cookies.sqlite and cookies.sqlite-wal and it hasn't helped.

Other blocks placed on other websites do work, just not ones placed on youtube.

I previously had this problem a few years back when using firefox - I was unable to block google cookies, now with LW I'm unable to block YT cookies (owned by google).

Is this a bug or is there something baked into firefox by dirtzilla to stop people from blocking google/yt cookies?

I have every variation of youtubes domain set to BLOCK in my cookie settings, show in attachment 1, also block under tools/page-info/permissons as show in attachment 2. Yet cookies are still being accepted from youtube, shown in attachment 3. I've deleted cookies.sqlite and cookies.sqlite-wal and it hasn't helped. Other blocks placed on other websites do work, just not ones placed on youtube. I previously had this problem a few years back when using firefox - I was unable to block google cookies, now with LW I'm unable to block YT cookies (owned by google). Is this a bug or is there something baked into firefox by dirtzilla to stop people from blocking google/yt cookies?
fkmozilla changed title from (削除) Bug - Youtube cookies not being blocked (削除ここまで) to Bug - Youtube cookies not being blocked despite 100% blocks in place 2025年06月11日 16:35:32 +02:00

Hm, we definitely don't want this. I'll put this on my tab to investigate.

Hm, we definitely don't want this. I'll put this on my tab to investigate.

@maltejur wrote in #2539 (comment):

Hm, we definitely don't want this. I'll put this on my tab to investigate.

Cool thanks. To be sure I just checked it out in 2 other profiles - 1 I already have setup and a freshly created one.

I put all the blocks in place, cleared cookies, then navigated through youtube and yet again - still yt cookies are unblockable in both profiles.

It's definitelty 100% impossible to block cookies from youtube, despite what blocks you put in place. I havent checked with google.* domains but the last time I checked (which was a few years ago) - they were unblockable as well..

The fact that this issue is present across multiple profiles including freshly created ones and the fact that blocking other websites cookies works as expected makes me wonder if this is some underhanded BS from dirtzilla - I don't know what else it could be.

@maltejur wrote in https://codeberg.org/librewolf/issues/issues/2539#issuecomment-5086224: > Hm, we definitely don't want this. I'll put this on my tab to investigate. Cool thanks. To be sure I just checked it out in 2 other profiles - 1 I already have setup and a freshly created one. I put all the blocks in place, cleared cookies, then navigated through youtube and yet again - still yt cookies are unblockable in both profiles. It's definitelty 100% impossible to block cookies from youtube, despite what blocks you put in place. I havent checked with google.* domains but the last time I checked (which was a few years ago) - they were unblockable as well.. The fact that this issue is present across multiple profiles including freshly created ones and the fact that blocking other websites cookies works as expected makes me wonder if this is some underhanded BS from dirtzilla - I don't know what else it could be.

Thanks again for this report. I managed to reproduce it, and I also think I found the root cause.

What happens here is that accounts.google.com sets cookies on youtube.com. If you also block accounts.google.com, no cookies should be set anymore.

But still, that this happens is strange, as LibreWolf should block this kind of third-party cookies by default. But as of Bug 1951443, which landed in Firefox 138, it seems ETP strict does not seem to block third-party cookies anymore. We didn't notice this until now. This means we should set network.cookie.cookieBehavior.optInPartitioning ourselves, now that it isn't set by ETP strict anymore.

Thanks again for this report. I managed to reproduce it, and I also think I found the root cause. What happens here is that `accounts.google.com` sets cookies on `youtube.com`. If you also block `accounts.google.com`, no cookies should be set anymore. But still, that this happens is strange, as LibreWolf should block this kind of third-party cookies by default. But as of [Bug 1951443](https://bugzilla.mozilla.org/show_bug.cgi?id=1951443), which landed in Firefox 138, it seems ETP strict does not seem to block third-party cookies anymore. We didn't notice this until now. This means we should set `network.cookie.cookieBehavior.optInPartitioning` ourselves, now that it isn't set by ETP strict anymore.
maltejur added this to the 140.0-1 milestone 2025年06月13日 12:36:01 +02:00

@maltejur wrote in #2539 (comment):

Thanks again for this report. I managed to reproduce it, and I also think I found the root cause.

What happens here is that accounts.google.com sets cookies on youtube.com. If you also block accounts.google.com, no cookies should be set anymore.

But still, that this happens is strange, as LibreWolf should block this kind of third-party cookies by default. But as of Bug 1951443, which landed in Firefox 138, it seems ETP strict does not seem to block third-party cookies anymore. We didn't notice this until now. This means we should set network.cookie.cookieBehavior.optInPartitioning ourselves, now that it isn't set by ETP strict anymore.

Thanks for investigating, your suggestion worked, now I can't sign in to google so it's not an ideal fix but at least the problems solved, cheers.

@maltejur wrote in https://codeberg.org/librewolf/issues/issues/2539#issuecomment-5114796: > Thanks again for this report. I managed to reproduce it, and I also think I found the root cause. > > What happens here is that `accounts.google.com` sets cookies on `youtube.com`. If you also block `accounts.google.com`, no cookies should be set anymore. > > But still, that this happens is strange, as LibreWolf should block this kind of third-party cookies by default. But as of [Bug 1951443](https://bugzilla.mozilla.org/show_bug.cgi?id=1951443), which landed in Firefox 138, it seems ETP strict does not seem to block third-party cookies anymore. We didn't notice this until now. This means we should set `network.cookie.cookieBehavior.optInPartitioning` ourselves, now that it isn't set by ETP strict anymore. Thanks for investigating, your suggestion worked, now I can't sign in to google so it's not an ideal fix but at least the problems solved, cheers.
sarge referenced this issue from a commit 2026年01月18日 05:36:27 +01:00
sarge referenced this issue from a commit 2026年01月18日 06:31:33 +01:00
Sign in to join this conversation.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
Branding
Issues that relate to our logo or the branding of our browser and website.
Broken Upstream
Issue is also present in Firefox
Build
Alpine
Issues specific to the Alpine Linux build of LibreWolf.
Build
AppImage
Issues specific to the AppImage release of LibreWolf.
Build
AUR
Issues specific to the AUR build of LibreWolf.
Build
Debian
Issues specific to our official release for Debian based distros.
Build
DebianOBS
Issues specific to the non-official OBS build of LibreWolf.
Build
Fedora
Issues specific to our official release for Fedora.
Build
FedoraCOPR
Issues specific to the non-official COPR build of LibreWolf.
Build
Flatpak
Issues specific to the Flatpak release of LibreWolf.
Build
Gentoo
Issues specific to the Gentoo build of LibreWolf.
Component: Infrastructure
Issues related to infrastructure provided by LibreWolf
Component
Builds
Issues related to how we build LibreWolf
Component
Patches
Issue with one of the patches in our source code.
Component
Settings
Issues related to the settings of LibreWolf.
Component
UI
A purely cosmetic issue in our browser.
Component
Website
Issues with our website.
Docs
Change required
A needed change in our documentation.
Docs
FYI
Issues that document a change, or how stuff gets patched, built or configured.
Flag
Caution
Change that might be tricky or that needs to be carefully evaluated. Best suited for core members.
Flag
Good first issue
Suited for a first contribution as it is a straightfoward task!
FreeBSD
Issues related to the FreeBSD release of LibreWolf.
Linux
Issues realted to one or all our Linux releases.
macOS
Issues realated to the MacOS release of LibreWolf.
Needed
Help
We are stuck :-(
Needed
Info
Closing in ten days if no details are provided.
Needed
Testing
We are almost there!
Prio
High
Issues with a high priority
Prio
Low
Prio
Normal
Prio/Urgent
Issues needing immediate attention
Repositories
An issue with our repositories.
Research
Collecting informations to document something or to evaluate a change.
Source
Issues related to the source code of LibreWolf.
Status
Blocked
An issue blocked by another one.
Status
Duplicate
Look for existing issues.
Status
Icebox
Change that is not happening soon or issue that cannot be tested.
Status
Known issue
An issue that we are aware of but that we cannot fix at the moment.
Status
Not Planned
The requested feature is currently not planned
Status
Upstream
Either we upstreamed the issue or a fix is coming directly from Mozilla!
Status
Won't fix
Does not require a fix.
Type
?
What?
Type
Bug
Ouch...
Type
Discussion
Let's have a talk...
Type
Feature
A feature request.
Type
Question
Not a issue but just a user question
Type
Task
This needs to be done
Windows
Issues related to the Windows release of Librewolf.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
librewolf/issues#2539
Reference in a new issue
librewolf/issues
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?