- Override ContentSettingsManagerDelegate instead of
ContentSettingsManagerImpl.
- Removed top_origin_url param from
TrackingProtectionService::ShouldStoreState since it wasn't used and
also isn't available in ContentSettingsManagerDelegate.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/06dea0268dc9a7b01790ef36e83d9a49e1e32ae6
commit 06dea0268dc9a7b01790ef36e83d9a49e1e32ae6
Author: Clark DuVall <cduvall@chromium.org>
Date: Tue Apr 21 17:07:31 2020 +0000
Move ContentSettingsManagerImpl to //components/content_settings
Now that TabSpecificContentSettings is componentized, it makes sense to
share the logic in ContentSettingsManagerImpl.
Bug: 1070825
Chromium change:
https://chromium.googlesource.com/chromium/src/+/2f8d810ec34e1b8a23b5003759d7f71b4ba00588
commit 2f8d810ec34e1b8a23b5003759d7f71b4ba00588
Author: Darin Fisher <darin@chromium.org>
Date: Wed Oct 23 18:51:46 2019 +0000
Convert content settings IPC over to Mojo
This renamed ContentSettingsRenderer to ContentSettingsAgent and the corresponding
class ContentSettingsObserver to ContentSettingsAgentImpl. This class represents
the agent of the content settings system that runs in the renderer process. It is
responsible for answering some of the blink::WebContentSettingsClient methods
directly and for others it needs to delegate to the browser process. It does so
through a new interface named ContentSettingsManager. This provides async and sync
methods to check for permission to access different storage types.
A big change here is that instead of answering these questions about storage
access on the IO thread, now the code is answering those on the UI thread. The
old code was constrained by the NPAPI plug-in system that forced synchronous IPCs
from the renderer process to be handled not on the UI thread. Now we no longer
have that constraint, and it is far simpler to just handle the IPCs directly on
the UI thread. There is potential for some added delay to storage access if the
browser's UI thread happens to be busy, but this should be a minor issue compared
to the overall cost of accessing the storage systems.
1. Parse the FirstPartyTracker list provided by the `tracking-protection` extension.
2. On any request to Store data (Cookies, localStorage, sessionStorage, WebSQL, indexedDB)
1. Check if the Shield Settings and tracker blocking is allowed for the site that initiated the redirects
2. Check if the site is in the Storage trackers list.
3. Deny if the URL is found in the tracker list.
This feature is currently gated behind a BUILD flag and a runtime flag. The flags are disabled by default
auditors: @bridiver, @iefremov
mkarolin