Login with Stackdriver is still broken after bug 1505212
Categories
(Core :: Privacy: Anti-Tracking, defect, P1)
Tracking
()
People
(Reporter: ehsan.akhgari, Assigned: baku)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [privacy65][anti-tracking])
Attachments
(2 files, 3 obsolete files)
Assignee | ||
Comment 1•6 years ago
|
||
Reporter | ||
Comment 2•6 years ago
|
||
Updated•6 years ago
|
Assignee | ||
Comment 3•6 years ago
|
||
Reporter | ||
Comment 4•6 years ago
|
||
Updated•6 years ago
|
Assignee | ||
Comment 5•6 years ago
|
||
Assignee | ||
Comment 6•6 years ago
|
||
Assignee | ||
Comment 7•6 years ago
|
||
Assignee | ||
Comment 8•6 years ago
|
||
Reporter | ||
Comment 9•6 years ago
|
||
Comment 10•6 years ago
|
||
Updated•6 years ago
|
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
Comment 13•6 years ago
|
||
Assignee | ||
Comment 14•6 years ago
|
||
Assignee | ||
Comment 15•6 years ago
|
||
Assignee | ||
Comment 16•6 years ago
|
||
Assignee | ||
Comment 17•6 years ago
|
||
Comment 18•6 years ago
|
||
Hello,
We have tried to reproduce this issue and have the following findings:
-
This issue still occurs with the same repro steps on the latest Nightly build 66.0a1(2019-01-08) with the loop remaining stuck on https://tinyurl.com/y8dzegdf
-
This issue is not present on the latest Beta build (65.0b9).
We have modified on the latest nightly "network.cookie.cookieBehavior" from 4 to 0 and it had the desired behavior, thus, this may very well be the culprit for this.
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Reporter | ||
Comment 20•5 years ago
|
||
This still reproduces for me on trunk. Andrea, are you planning to clean up your patches for review?
Assignee | ||
Comment 21•5 years ago
|
||
Ehsan and I discussed this issue on IRC. We are going to have a meeting this week to find a better strategy/solution to fix this issue. We can give an update after the meeting.
Assignee | ||
Comment 22•5 years ago
|
||
The heuristic that we are going to implement is the following:
- When a first-party document A is created by a redirect from B
- and if the B's origin is included in a pref-based list,
- the B's origin will have storage-access permission granted, when loaded as 3rd party in A.
- the storage-access permission will have a short expiration time.
This is partially implemented. I hope to finish the implementation (tests included) for the next week.
Reporter | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 23•5 years ago
|
||
I've submitted a patch. This is a first starting point which is not optimal, but good enough to be reviewed.
This patch gives storage access to 3rd party trackers after a top-level tracker to non-tracker HTTP redirect. The storage access permission is granted only if the user has interacted with the tracker before the redirect.
Good news, this patch allows the user to complete the authentication on stackdriver. Bad news, it works only after the second try.
At the first try, my patch doesn't work because we have a sequence of redirects like this:
- google.com authentication form redirects to youtube.com (tracker to non-tracker)
- youtube.com redirects to google.co.uk (non-tracker to non-tracker)
- google.co.uk redirects to stackdriver.com (non-tracker to non-tracker)
But from the second try, the sequence is different:
- google.com to stackdriver.com (tracker to non-tracker)
Because of this, my patch is able to grant permission to google's 3rd-party resources when loaded on stackdriver.com.
Assignee | ||
Comment 24•5 years ago
|
||
Reporter | ||
Comment 25•5 years ago
|
||
Thanks Andrea! I unfortunately didn't get a chance to look at your patch today, will do that next week.
Comment 26•5 years ago
|
||
Comment 27•5 years ago
|
||
bugherder |
Comment 28•5 years ago
|
||
Backed out for causing crash in bug 1610485
https://hg.mozilla.org/mozilla-central/rev/40f9aaaead2a56f46733afaa4572deda7899e666
Assignee | ||
Comment 29•5 years ago
|
||
Comment 30•5 years ago
|
||
Comment 31•5 years ago
|
||
Backed out 2 changesets (Bug 1507055) for causing build bustages in AntiTrackingCommon.cpp CLOSED TREE
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=285809282&resultStatus=testfailed%2Cbusted%2Cexception&revision=be170480919d58df035e2b15ac72a37956bf328b
Failuire log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=285809282&repo=autoland&lineNumber=30606
Backout: https://hg.mozilla.org/integration/autoland/rev/4bad694ce45e736111015f0ea14da37b49627103
Assignee | ||
Updated•5 years ago
|
Comment 32•5 years ago
|
||
Comment 33•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6f83de2c474a
https://hg.mozilla.org/mozilla-central/rev/3ea18bc6dc4a
Updated•5 years ago
|
Comment 34•5 years ago
|
||
I've managed to reproduce this issue on Firefox 74.0a1 (2020-01-10) using Windows 10x64 by following the STR from comment 0.
This issue is verified fixed on Firefox 74.0b6 and Firefox 75.0a1 (2020-02-21) on the following OSes: Windows 10x64, Windows 7x64, macOS 10.15 and Ubuntu 18.04x64.
Comment 35•5 years ago
|
||
This heuristic has been documented here: https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy$compare?locale=en-US&to=1615168&from=1614896
Description
•