Privacybadger: explain the export-/import-behavior (in the addon)

[DJCrashdummy]

i read the PR of the export-/import-feature #982 and the functionality is nice, but if you are using different instances side by side it comes to a little problem:

Import acts as a semi-union: if a given domain does not exist in the current map, it will be added; if a given domain does exist, it will be overwritten with the object from the supplied file.

shouldn't always the worst behavior/rating be carried over?

if a intelligent merging is too complicated or too much work, maybe as a workaround the export-feature can be tweaked a little bit with additional button(s) to just export misbehaving domains?

[ghostwords]

I think we thought the proposed logic was a decent compromise that probably did what you wanted without completely overwriting all data in the destination Badger.

action_map entries are indeed overwritten with incoming entries when the domain exists in both source and destination.

snitch_map entries go through the same logic we use when we record tracking. I think this was done to handle the case where importing and merging should put a domain over the blocking threshold.

Linking to the current logic:
https://github.com/EFForg/privacybadger/blob/badcfce403655c8bd308c0bc40ce22b5f862b0ef/src/js/storage.js#L434-L478

A note about snitch_map merging: We lose snitch_map entries for domains that have a non-NO_TRACKING/ALLOW status in action_map (because of short-circuiting here), meaning domains that Badger (or the user?) already decided to block lose the history of where they were seen tracking on. This doesn't matter usually, but can come up during (and complicate) debugging.

[ghostwords]

Would you be able to come up with specific examples (here are the action_map and snitch_map entries, I expect example.com to be blocked but instead ...) of when the current code doesn't do the right thing?

[DJCrashdummy]

thanks @ghostwords for explaining (and showing) the import-behavior in detail, i didn't dive deeper into Privacy Badger.

i was mainly concerned about the heuristic collected information, but as you explained, this information is thankfully merged.
...and if you overrode some actions manually it makes sense to carry over the imported settings.

so if i got you right, for someone who hasn't overrode the settings for any domain, it is completely samey which data he imports first and last, because of the already implemented "intelligent merging" the result will be the same?

[DJCrashdummy]

well... maybe loosing some words at the export-/import-tab about "how it works", especially: _what is exported_, _what is imported_, _what will be merged_ and _what will be overwritten_ would be helpful and very nice.

[ghostwords]

Importing from A to B vs. importing from B to A: the end result should be the same thanks to snitch_map merging. We should check that this is the case though.

[ghostwords]

@DJCrashdummy @bcyphers @andresbase How about adding the following text to the top of the Manage Data tab?

Importing combines the lists of sites where your Badger should be disabled, overwrites general settings, and teaches your Badger about the trackers in the import, reapplying any custom blocking preferences.

Screenshot:

[ghostwords]

Tracking domains data no longer gets overwritten as of #2082. We now go through the site domains where each tracker base domain was seen on (this is stored in the "snitch map"), and reapply this learning.

So if you were already blocking a domain that's present but not yet blocked in the import, you will keep blocking it.

If your Badger saw a domain perform tracking on two sites (meaning the domain is still allowed), and the incoming data has that same domain track on a different third site, your Badger will learn to block that domain on import.

[andresbase]

How about something like:

Importing combines

• The lists of sites where you disabled Privacy Badger
• Overwrites general settings
• Teaches your Badger about the trackers learned in the import, reapplying any custom blocking preferences.