Found this while digging around while reporting a similar bug in Chrome. When advanced tracking protection is turned off, we can detect whether or not a cross-origin URL is a redirect using the difference of performance.getEntriesByName(...)[0].fetchStart - performance.getEntriesByName(...)[0].startTime.

Reproduction steps:

1. Download the attached index.html file.
2. Run a python HTTP server by running python -m http.server in the same directory as the index.html file.
3. Open http://localhost:8000/index.html in Firefox
4. Open the javascript console
5. https://google.com should be correctly identified as a redirect, whereas, https://www.google.com should be identified as a URL without a redirect.

NI myself for taking a look

Not sure what you mean by "advanced tracking protection is turned off"... is that just a typo for "enhanced" (ETP is disabled for the site) or do you mean it happens in "Standard" ETP as opposed to "strict" (advanced?) ETP? Odds are the first, but it's good to be clear.

Please let us know the link to the Chromium issue. I'm sure we can't see it if you've filed it as a security bug, but it's handy to be able to tie the issues later and double-check.

(In reply to Daniel Veditz [:dveditz] from comment #2)

Not sure what you mean by "advanced tracking protection is turned off"... is that just a typo for "enhanced" (ETP is disabled for the site) or do you mean it happens in "Standard" ETP as opposed to "strict" (advanced?) ETP? Odds are the first, but it's good to be clear.

It was a typo for "Enhanced Tracking Protection" :)

That being said, I appear to have misinterpreted the following warning Request to access cookie or storage on “<URL>” was blocked because it came from a tracker and content blocking is enabled. as the PoC not working. The exploit detects redirects with ETP enabled also. ETP is probably blocking 'credential': 'include' in my index.html PoC which caused the misunderstanding.

Please let us know the link to the Chromium issue. I'm sure we can't see it if you've filed it as a security bug, but it's handy to be able to tie the issues later and double-check.

https://bugs.chromium.org/p/chromium/issues/detail?id=1290150 is the bug (it is filed a security bug, yeah)

Chrome apparently landed a fix recently
https://chromium.googlesource.com/chromium/src/+/e96b9f57d8d9e32bf9cb748524735d7903271755%5E%21/
That includes also some changes to a wpt, so perhaps we have even a test for this.

Given the recent Fetch spec updates, Step 8.1 in
https://fetch.spec.whatwg.org/#finalize-and-report-timing specifies
that start time(StartTime) and post-redirect start time(FetchStart) should
be start time when TAO check fails.

Make FetchStart uses StarTime when TAO check fails for PerformanceResourceTiming r=smaug
https://hg.mozilla.org/integration/autoland/rev/c02b29bea3fc334e7567776ea41a508eef74bdea
https://hg.mozilla.org/mozilla-central/rev/c02b29bea3fc

I tried to reproduce the issue on Firefox 98.0a1 (2022-01-24), and got this response:

• https://google.com/ is a redirect? index.html:10:25
• https://www.google.com/ is not a redirect

On the latest Beta, 100.0b8, with the steps from Comment 0, is displayed:

• https://google.com/ is not a redirect index.html:13:25
• https://www.google.com/ is not a redirect

From Comment 0, it doesn't look like the expected result. Is there anything that I'm missing, or is this the expected behavior?

(In reply to Mihai Boldan, QA [:mboldan] from comment #8)

I tried to reproduce the issue on Firefox 98.0a1 (2022-01-24), and got this response:

• https://google.com/ is a redirect? index.html:10:25
• https://www.google.com/ is not a redirect

On the latest Beta, 100.0b8, with the steps from Comment 0, is displayed:

• https://google.com/ is not a redirect index.html:13:25
• https://www.google.com/ is not a redirect

From Comment 0, it doesn't look like the expected result. Is there anything that I'm missing, or is this the expected behavior?

That is the expected behaviour (being unable to detect if a redirect has occured in the newer version)

Thanks Sohom Datta for the confirmation.
Based on the comments from above, I'm marking this issue as Verified Fixed.