Open Bug 1618895 Opened 4 years ago Updated 1 year ago

Ensure LocalStorage databases aren't created for blocked sub-domains which are potentially reached via a redirect from their root domain (ex: blocking www.reddit.com and navigating to reddit.com)

Categories

(Core :: Storage: localStorage & sessionStorage, defect, P2)

Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr78 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox84 --- wontfix
firefox85 --- fix-optional
firefox86 --- fix-optional

People

(Reporter: cbaica, Unassigned)

Details

(Keywords: regression)

Attachments

(2 files)

Attached video bug cookies

Affected versions

  • Fx74.0b9
  • Fx75.0a1

Affected platforms

  • Windows 7

Steps to reproduce

  1. Launch Firefox.
  2. Go to about:preferences#privacy, scroll down to the 'Cookies and Site Data' and click 'manage permisions'.
  3. In the field write 'https://www.reddit.com', click the 'Block' button and save changes.
  4. In a new tab, navigate to the blocked website (reddit.com).
  5. After the website loads, switch back to the about:preferences#privacy page and refresh it.
  6. Scroll down to the 'Cookies and Site Data' section and click 'Manage Data'

Expected result

  • Cookies from reddit should not be displayed.

Actual result

  • Cookies from reddit.com are displayed.

Regression range

  • Will come back with a regression range ASAP.

Additional notes

  • Issue can't be reproduced on windows 10.
Summary: Firefox receives cookies for website that was set as blocked in the permission section → Firefox receives cookies for a website that was set as blocked in the permission section

I can't reproduce on OSX, but I guess you said that this only reproduces on Windows 7 anyway, which seems really weird to me. If this can be consistently reproduced getting a regression range would be nice.

Component: Permission Manager → Privacy: Anti-Tracking
Has Regression Range: --- → no
Has STR: --- → yes

As a side-note I've investigated the issue further on ubuntu and macOS 10.13. I've managed to reproduce the issue there as well.
I've ran the regression and here is the result:

Keywords: regression

Thanks. It's interesting that you can reproduce on OSX, but the regression range seems very unlikely.

Just to clarify, you're using a fresh profile, right? And without having been to reddit.com on that profile before?

Yes, I'm using a fresh profile every time, so there wouldn't be any 'residual' navigation data.
As for the regression range, I'm not sure wether it matters, but I got it on an ubuntu 18.04 machine.

Steven, could you set the priority flag for this bug?

Flags: needinfo?(senglehardt)

I can reproduce this on Nightly build 20200305212712 on Ubuntu 18.04.

However, I'm wondering if this is the expected functionality. The address entered in the video is https://www.reddit.com, and we see that no www.reddit.com cookies are set, only reddit.com. If instead enter https://reddit.com then no cookies are set, so I'm guessing we either use full hostname matching to the domain attribute of the cookie or eTLD+1.

Johann can you confirm that's the expected functionality?

Flags: needinfo?(senglehardt) → needinfo?(jhofmann)
Priority: -- → P2
Has Regression Range: no → yes

In the video storage is set, though. So maybe we have a place where storage code is not respecting the cookie permissions correctly? I don't think the site data manager is showing regular cache in the storage section, so it would have to be something like localStorage.

Component: Privacy: Anti-Tracking → Storage: localStorage & sessionStorage
Flags: needinfo?(jhofmann)

Something weird is definitely happening if I navigate to "reddit.com" like in the video. When I opened the network panel in devtools I was able to reproduce locally and the profile is showing that we are storing data in QuotaManager for the on-disk encoded origin of https+++www.reddit.com for both LSNG and the Cache API and there is a ServiceWorker registration for https://www.reddit.com/. The only thing in Cache API storage is the ServiceWorker's https://www.reddit.com/sw.js script.

My naive presumption would be that we're sending the non-existent permissions for "reddit.com" or for a pre-STS upgrade "http" origin down to the process, not "https://www.reddit.com". If the permission isn't making it into the process then it would make sense that StorageAllowedForWindow would return StorageAccess::eAllow when it shouldn't. This same check is used both for LocalStorage and for ServiceWorkers as called by ServiceWorkerContainer::Register.

I'm going to try and get a pernosco reproduction up now and without involving devtools.

Hi Andrew, any luck in getting the pernosco session?

Flags: needinfo?(bugmail)

I have managed to reproduce this issue on Mac OS 11 while running these steps:

  1. Open Firefox and go to about:preferences -> "Privacy & Security" section.
    Firefox is opened and "Privacy & Security" section is displayed
  2. Make sure that "Standard" option is set in the Enhanced Tracking Protection section.
    Standard is set by default
  3. Go to Cookies and Site Data -> click on "Manage Data..."
    You can see a list with many sites displayed
  4. In the "Cookies and Site Data" click on the "Manage Permissions..." button.
    The "Exceptions - Cookies and Site Data" dialog is opened.
  5. Add https://www.reddit.com/ in the field manually and hit the "Block" button.
    The website in question is added in the list with the "Block" status.
  6. Go to Reddit.
    The website will not be completely loaded as all cookies are automatically blocked.
  7. Go to Cookies and Site Data -> click on "Manage Data..."
    You can see a list of websites but https://www.reddit.com/ is NOT displayed on that list.

Reddit related cookies are shown in the list.

Considering previous comments, this appears not to be Windows 7 specific and somewhat intermittent.

OS: Windows 7 → All

I have managed to reproduce this issue on Ubuntu 20.04 using the steps from comment 0. The cookies are still shown in the list.

Hi Jan, can you try to reproduce this, please?

Flags: needinfo?(bugmail) → needinfo?(jkrause)

I tested on macOS with Firefox Nightly 99.0a1 (2022-02-22) (64-Bit) using the instructions in comment 0. Between every page load, I deleted the corresponding cookies. I also made sure to refresh about:preferences#privacy every time, because otherwise new cookies will not show up.

Doing multiple tests shows that it depends on how you navigate to the website. For example typing https vs http or using www vs not. This could be the reason why some could reproduce it, while others not or it may appear as intermittent. To give some more insights, I varied the URL in the blocklist. Also note that the cookie list in the "Manage Data..." dialog does not show the protocol of the host name.

The following overview outlines how the blocking URL affects whether cookies are saved or not depending on the URL that is used to visit the website. [-] means no cookies for reddit.com were saved, [x] means there are cookies for reddit.com after going to the URL that follows after [-]/[x].

If I see cookies, they are always from reddit.com and not from www.reddit.com. Even with an empty blocklist, it's always the host without www that is listed in the "Manage Data..." dialog.

Blocking https://www.reddit.com

Blocking http://www.reddit.com

Blocking https://reddit.com

Blocking http://reddit.com

Flags: needinfo?(jkrause)

(asuth to try and identify existing test coverage that could form the basis of an automated test, will set needinfo on :jkrause when posting it)

Flags: needinfo?(bugmail)

I think it was probably a bit ambiguous about what the scope of the bug was here, so I've re-titled it and I'll go into more detail here.

Bug scope: If navigating to "reddit.com" in the URL bar with cookies blocked for "https://www.reddit.com", and there is no QuotaManager storage for the origin on disk at PROFILE/storage/default/https+++www.reddit.com then after navigating to "reddit.com" in the URL bar, there should still be no storage for the origin on disk.

Extra context:

  • The about:preferences#privacy was changed since this bug was filed so that it only displays data on a granularity of eTLD+1. So if there is data for "www.reddit.com" it will be displayed as "reddit.com". If there's data for "reddit.com" it will also be displayed for "reddit.com". Same for "foo.reddit.com".
  • reddit.com is in our strict-transport-security preload list and that includes its subdomains. We will never attempt to talk to "http://reddit.com" or "http://www.reddit.com", only their https variants.
  • https://reddit.com/ servces a 301 redirect to https://www.reddit.com and there are no cookies.
  • https://www.reddit.com serves cookies with a domain of both reddit.com and .reddit.com. So it seems quite possibly reasonable that cookies might show up on "reddit.com" if we're only blocking "www.reddit.com". Arguably it's nonsensical for someone to block just a subdomain because of how cookies work, and maybe that's something that the "manage exceptions" UI should handle. But that's not this bug, that would be an anti-tracking bug/privacy bug.
  • A bunch of improvements / bug fixes have been made about permission transmission and just in general with the fission process model.

So I think we probably want to re-run these tests with a slightly altered procedure where we:

  • Only test blocking for "https://www.reddit.com" and "https://reddit.com" since it seems like the http block, as expected, does not block https!
  • Make sure there's no PROFILE/storage/default/https+++www.reddit.com before testing the navigation.
  • Our check becomes only checking if that directory showed up or not. We don't care about the preferences privacy UI and in fact we do expect that cookies will probably get set against "reddit.com" because of how cookies work and the specificity of the block.

Based on the existing results in comment 13 I would expect that we should probably pass this test.

Test Investigation Notes

The general takeaway would probably be that CookiePolicyHelper is probably a good basis for any tests operating in this area as it can let us check that we're really checking what we think we're checking by also making sure out check detects data when it's allowed, etc. But I don't know that we need to add an automated test for this at this time.

Flags: needinfo?(bugmail) → needinfo?(jkrause)
Summary: Firefox receives cookies for a website that was set as blocked in the permission section → Ensure LocalStorage databases aren't created for blocked sub-domains which are potentially reached via a redirect from their root domain (ex: blocking www.reddit.com and navigating to reddit.com)

Thanks!

Arguably it's nonsensical for someone to block just a subdomain because of how cookies work, and maybe that's something that the "manage exceptions" UI should handle. But that's not this bug, that would be an anti-tracking bug/privacy bug.

So we seem to confuse our users quite a bit here, up to the point to confuse ourselves, too. I think this is worth filing a bug (if it does not exist already). Jan-Rio, apart from re-testing following :asuth instructions, can you please check and file it in case?

Attached image search-bar.png

I did another test as suggested by Andrew in comment 15. I was using Firefox Nightly 100.0a1 (2022-03-09) (64-Bit) on macOS. Checking for files in PROFILE/storage/default/https+++www.reddit.com, but not examining or clearing cookies in between.

Blocking https://www.reddit.com, navigating to ...

There is one exception or intermittent when navigating to the non-www host, especially if you use a trailing slash or not. Sometimes, no files are created when using one of the last two URLs.

I think this is because the search bar handles the redirect itself and takes you directly to the https://www version of the website, skipping the server-sided redirection of the website. See attachment for clarification. I just pressed enter after typing the URL and did not click on any suggestion. I guess this also depends on whether or not you have already visited the website.

Blocking https://reddit.com

  • no files are created at all using the 4 URLs from above
Flags: needinfo?(jkrause)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.