Passing in an nsIPrincipal gives us more control over the origin. We can ensure that it's valid and contains no origin attributes
Also, it allows us validate the principal type.
Previously some consumers would pass in a full origin with OA suffix. This patch changes it so we only use OriginNoSuffix.
Differential Revision: https://phabricator.services.mozilla.com/D139011
- Add observation of user interaction (for purpose of handing out storageAccessAPI permission) during grants of requestStorageAccess
- This will not observe user interaction when a page requests the permission when they already have it, by design
- This should also not observe user interaction when the grant is due to a heuristic.
- Add tests that verify adding user interaction on grant and autogrant. Plus one more test to verify that we do not add user interaction on deny
Differential Revision: https://phabricator.services.mozilla.com/D132025
- Adding browser tests to verify correct behavior in integration
- New test that fails on previous version: toolkit/components/antitracking/test/browser/browser_storageAccessScopeSameSiteWrite.js
- Add the ability to store permission by site, use 3rdPartyStorage for this
- No change is made to permission reads. These already proceed recursively, which eventually reach the site.
- When fetching all permissions for a principal, also look for site-scoped permissions on its site's principal
Differential Revision: https://phabricator.services.mozilla.com/D130675
- Adding browser tests to verify correct behavior in integration
- New test that fails on previous version: toolkit/components/antitracking/test/browser/browser_storageAccessScopeSameSiteWrite.js
- Add the ability to store permission by site, use 3rdPartyStorage for this
- No change is made to permission reads. These already proceed recursively, which eventually reach the site.
- When fetching all permissions for a principal, also look for site-scoped permissions on its site's principal
Differential Revision: https://phabricator.services.mozilla.com/D130675
To support calling ContentBlocking::AllowAccessFor() for the privilege
request storage access API, we need to make small adjustment regarding
the algorithm which is used to decided if we can run in the current
process. Also, we need to exempt the privilege API from the user interaction.
Differential Revision: https://phabricator.services.mozilla.com/D123807
This patch implements a async version of the ShouldAllowAccess check.
The method will check if a principal is allowed to access storage under
a given browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D123806
Priviously, the ContentBlocking::ShouldAllowAccessFor() checkes don't
check if the storage permission was came from the allowList or not. This
patch changes that and it will check if the channel/window is
allowlisted at the same moment as checking the ContentBlockingAllowList.
It returns early if the channel/window is in the allowList.
Differential Revision: https://phabricator.services.mozilla.com/D126278
We need to report when permission is added in order to wait it
explicitly. These will be put be hind a pref
'privacy.antitracking.testing' and should be only used for testing.
Differential Revision: https://phabricator.services.mozilla.com/D94979
This 'STORAGE_ACCESS_GRANTED_COUNT' telemetry probe would record the
count of gratned storage access. And it would also record the reason
why the storage access has been granted.
Differential Revision: https://phabricator.services.mozilla.com/D92555
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
We should check the nested iframe in the
ContentBlocking::ShouldAllowAccessFor(channel) as well. This patch
implements this.
Differential Revision: https://phabricator.services.mozilla.com/D77075
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
Before this patch, we only call StorageAccessGranted on windows that
triggers the storage heuristics. So even if we sync storage permission to the
other frames, their data will not be refreshed. For example, if a document
has a worker, we don't propagate the permission to the worker.
In this patch, we call ::StorageAccessGranted as long as we update
the window's storage permission.
Differential Revision: https://phabricator.services.mozilla.com/D74321
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
CookieBehavior should be the same for all the frames in the same tab,
we don't have to get its value for every browsing context in the same
browsing context tree.
Differential Revision: https://phabricator.services.mozilla.com/D73709
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
Before this patch, we only call StorageAccessGranted on windows that
triggers the storage heuristics. So even if we sync storage permission to the
other frames, their data will not be refreshed. For example, if a document
has a worker, we don't propagate the permission to the worker.
In this patch, we call ::StorageAccessGranted as long as we update
the window's storage permission.
Differential Revision: https://phabricator.services.mozilla.com/D74321
