Closed Bug 1835907 Opened 1 year ago Closed 1 year ago

Only propagate storage access during self-initiated, same-origin navigation

Categories

(Core :: Privacy: Anti-Tracking, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
118 Branch
Tracking Status
firefox118 --- fixed

People

(Reporter: bvandersloot, Assigned: bvandersloot)

References

(Blocks 1 open bug)

Details

Attachments

(6 files, 1 obsolete file)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

See the changes in https://github.com/privacycg/storage-access/pull/141.

Particularly the flag to the source snapshot params used during create navigation params by fetching, and the conditional copy of sourceDocument's relevant settings object's flag over to the new environment that will be created

Blocks: 1805861
Severity: -- → S3

Note: this means that we should not always initially set hasStorageAccess to true if the permission is set.

Because the Document's Channel's LoadInfo is no longer being set to reflect the storage-access permission, we need to test if the permission is set before we ask the user about it.

Currently I opted for an IPC (and one we already have) in Fission. We could cut this out with an extra bit on the document, but I don't think this is performance-critical since it only happens on prompt-able requestStorageAccess calls.

Depends on D184823

This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.

Depends on D184824

Now that iframes don't automatically get "storage access" when the permission is allowed, we need to call requestStorageAccess in the iframes that use that access. This test makes that change.

In xorigin tests, the test gets the storage access in the test's iframe then creates a new iframe to run the tests in. I just added calls to the storage access API in that second iframe.

Depends on D184826

Assignee: nobody → bvandersloot
Attachment #9346257 - Attachment description: WIP: Bug 1835907, part 1 - Add has storage access bit and triggering window id to the LoadInfo - WIP → Bug 1835907, part 1 - Add has storage access bit and triggering window id to the LoadInfo - r=smaug!
Status: NEW → ASSIGNED
Attachment #9346258 - Attachment description: WIP: Bug 1835907, part 2 - Add has storage access bit and triggering window id to the SessionHistoryEntries - WIP → Bug 1835907, part 2 - Add has storage access bit and triggering window id to the SessionHistoryEntries - r=smaug!
Attachment #9346259 - Attachment description: WIP: Bug 1835907, part 3 - Only propogate storage access bit on same-origin, self-initiated subframe navigations - WIP → Bug 1835907, part 3 - Only propogate storage access bit on same-origin, self-initiated subframe navigations - r=#anti-tracking!
Attachment #9346260 - Attachment description: WIP: Bug 1835907, part 4 - Test the storage access permission before prompting the user - WIP → Bug 1835907, part 4 - Test the storage access permission before prompting the user - r=#anti-tracking!
Attachment #9346261 - Attachment description: WIP: Bug 1835907, part 5 - Refactor the window's mStorageAccessPermissionGranted variable and its Getters to a more accurate name: mUsingStorageAccess - WIP → Bug 1835907, part 5 - Refactor the window's mStorageAccessPermissionGranted variable and its Getters to a more accurate name: mUsingStorageAccess - r=#anti-tracking!
Attachment #9346262 - Attachment description: WIP: Bug 1835907, part 6 - Update anti-tracking tests to work when storage access is not automatically given to iframes where the permission is already granted - WIP → Bug 1835907, part 6 - Update anti-tracking tests to work when storage access is not automatically given to iframes where the permission is already granted - r=#anti-tracking!
Attachment #9346263 - Attachment description: WIP: Bug 1835907, part 7 - Update DOM Cache API tests so xorigin mode keeps working - WIP → Bug 1835907, part 7 - Update DOM Cache API tests to remove most TCP-specific code, disable in xorigin - r=asuth!
Attachment #9346258 - Attachment is obsolete: true
Pushed by bvandersloot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/74f90708260a part 1 - Add has storage access bit and triggering window id to the LoadInfo - r=smaug,necko-reviewers,kershaw,pbz https://hg.mozilla.org/integration/autoland/rev/bb9f48eec5bf part 3 - Only propogate storage access bit on same-origin, self-initiated subframe navigations - r=anti-tracking-reviewers,pbz https://hg.mozilla.org/integration/autoland/rev/4790e44c234c part 4 - Test the storage access permission before prompting the user - r=anti-tracking-reviewers,pbz https://hg.mozilla.org/integration/autoland/rev/86e3f98ceb31 part 5 - Refactor the window's mStorageAccessPermissionGranted variable and its Getters to a more accurate name: mUsingStorageAccess - r=anti-tracking-reviewers,pbz https://hg.mozilla.org/integration/autoland/rev/989479621780 part 6 - Update anti-tracking tests to work when storage access is not automatically given to iframes where the permission is already granted - r=anti-tracking-reviewers,pbz https://hg.mozilla.org/integration/autoland/rev/91ef29afec50 part 7 - Update DOM Cache API tests to remove most TCP-specific code, disable in xorigin - r=asuth

Backed out for causing multiple failures.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=91ef29afec50af8628de6ae793ff088fb9d907e9&selectedTaskRun=FcLDZfPORdOd9kJvJlpEFA.0

Failure logs:

Backout link: https://hg.mozilla.org/integration/autoland/rev/7454614ef39046960ee75b81928128e9a77aa0e2

Flags: needinfo?(bvandersloot)

Found the issue: I was injecting a user interaction into the loadinfo by accident. This is resolved, so I'm going to push again once static analysis and a fresh try run finishes.

Flags: needinfo?(bvandersloot)
Pushed by bvandersloot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e6a83f1b7940 part 1 - Add has storage access bit and triggering window id to the LoadInfo - r=smaug,necko-reviewers,kershaw,pbz https://hg.mozilla.org/integration/autoland/rev/51e533c3d812 part 3 - Only propogate storage access bit on same-origin, self-initiated subframe navigations - r=anti-tracking-reviewers,pbz https://hg.mozilla.org/integration/autoland/rev/f543a9922f2e part 4 - Test the storage access permission before prompting the user - r=anti-tracking-reviewers,pbz https://hg.mozilla.org/integration/autoland/rev/bd2d6d649e2e part 5 - Refactor the window's mStorageAccessPermissionGranted variable and its Getters to a more accurate name: mUsingStorageAccess - r=anti-tracking-reviewers,pbz https://hg.mozilla.org/integration/autoland/rev/6f1909eb87de part 6 - Update anti-tracking tests to work when storage access is not automatically given to iframes where the permission is already granted - r=anti-tracking-reviewers,pbz https://hg.mozilla.org/integration/autoland/rev/6d987539c7b6 part 7 - Update DOM Cache API tests to remove most TCP-specific code, disable in xorigin - r=asuth
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: