GH-1621: Site-Specific Whitelisting for Unknown Trackers via Anti-Tracking #416
Conversation
… on further commits until Design is finished reviewing the feature (a console.log has been added in each place where logic may be added to match upcoming feature implementation requirements)
Eden12345
requested review from
IAmThePan,
jsignanini,
zarembsky and
ghostery/ghostery
as
code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
JIRA Ticket: https://cliqztix.atlassian.net/browse/GH-1621
Notes
Firstly, I'm only able to get anything to show up in this category on 9gag.com, so you'll probably want to use that for testing.
As I mentioned to @wlycdgr, there's still an issue with race conditions in the UI when whitelisting/un-whitelisting an unknown tracker when a page is still close to its initial load time. By the time the background gets the message that its being whitelisted, it's already running anti-tracking on it so it rewrites the state with the un-whitelisted data points that it scrubs, even though the whitelist on the backend has been updated (the message is sent in the end of the
_updateAntiTrackingWhitelist()function inreducers/blocking). Plus, even if it isn't overwritten you lose the UI state when you close the panel anyway, so we should be sending the source of truth from the backend rather forcing it.I've also sent @wlycdgr (via Slack) a list of the places where strings need to be replaced with calls to our translation library, so I won't crowd up these PR notes with any more of that.