Firefox 91 ESR doesn't send cookies when fetching <object>s from same host if privacy.firstparty.isolate = true
Categories
(Core :: Privacy: Anti-Tracking, defect, P3)
Tracking
()
People
(Reporter: jorilx, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Steps to reproduce:
I'm seeing a strange issue on Firefox 91.5.0esr on Linux (shipped with Debian 9 and 10).
We have an internal web application that requires authentication and allows to browse our archived pdfs by embedding them via <object> tag. It works nicely on Firefox 60.9.0esr (on a very old Debian) and on Firefox 91.5.0esr under Windows, but not on Linux. When the browser calls the server to fetch the PDF to embed, it doesn't send any cookie, so the server sees che call as not authenticated and returns a redirect to the login page.
I've verified this with the "network" tab of the Developer Tools.
I've tried using an incognito window but the problem persists.
I've tried comparing the "about:config" pages on both browsers (FF91 Linux vs FF91 Windows) but I couldn't find anything relevant.
Many thanks for your time!
Actual results:
The browser shows an embedded "login page"
Expected results:
The browser should show an embedded PDF
Forgot to mention: it used to work on Linux even with 78.15.0esr
|
||
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 3•4 years ago
|
||
Can you try to use https://mozilla.github.io/mozregression/ to find which change has regressed the behavior? Thank you.
Didn't know about mozregression, thanks! I'm not sure I'm using it correctly though... I've installed mozregression-gui and configured a bisection like this:
Application: firefox
Bits: 64
Build type: shippable
Repository: [empty]
Last known good build: release 78
First known bad build: release 91
But every tested build was good... Here's the output:
Bisecting on mozilla-central [2020-06-01 - 2021-07-12]
Tested mozilla-central build: 2020-12-21 (verdict: g)
Tested mozilla-central build: 2021-04-02 (verdict: g)
Tested mozilla-central build: 2021-05-23 (verdict: g)
Tested mozilla-central build: 2021-06-17 (verdict: g)
Tested mozilla-central build: 2021-06-30 (verdict: g)
Tested mozilla-central build: 2021-07-06 (verdict: g)
Tested mozilla-central build: 2021-07-09 (verdict: g)
Tested mozilla-central build: 2021-07-11 (verdict: g)
Bisecting on mozilla-central [877be9f9 - 3880d0d2]
Tested mozilla-central build: 5dee15cf (verdict: g)
Tested mozilla-central build: 5f345b97 (verdict: g)
Bisecting on autoland [693f792b - 1a9ece0f]
Tested autoland build: 5e7d1891 (verdict: g)
Tested autoland build: c4765371 (verdict: g)
Tested autoland build: 90f9b53f (verdict: g)
Tested autoland build: 723d9c48 (verdict: g)
Tested autoland build: 81a42afe (verdict: g)
|
||
Comment 5•4 years ago
|
||
Then perhaps it's either some strange setting in your profile (https://www.businessinsider.com/how-to-reset-firefox?r=US&IR=T) or some extension/add on that you're using.
You're right, thanks! I've managed to isolate the problem to the
privacy.firstparty.isolate = true
setting that I have in my profile since January 2018 (I believe it was/is a workaround for Meltdown/Spectre)
Since our internal webapp used to work with this setting on the previous ESR, I'm not sure if this change of behaviour is expected...?
|
|
||
Comment 7•4 years ago
|
||
I think you'd need to repeat the mozregression with privacy.firstparty.isolate = true at each point you do the test.
The bisection ends in a "Unable to find enough data to bisect" message, but here's the (condensed) result:
Tested mozilla-central build: 2020-07-20 (verdict: g)
Tested mozilla-central build: 2020-07-21 (verdict: b)
|
|
||
Comment 9•4 years ago
|
||
Moving this to the right component. They will be able to help.
|
||
Comment 10•4 years ago
|
||
First Party Isolation will isolate your cookies by using the top-level domain as an additional key. It looks to me that the login cookie is isolated but the fetch request isn't. So, it ends up with no cookies in this case.
Description
•