exclude duckduckgo maps from fingerprinting protection

[diracdeltas]

since it is a known false positive: https://twitter.com/bsstoner/status/1085624406796365830

my theory is that DDG-default users tend to turn on first party fingerprinting protection, which makes this bug appear more frequently than other FP false positives

[diracdeltas]

statement from DDG attesting that they do not do fingerprinting: https://twitter.com/bsstoner/status/1085623657999806464

[agentofuser]

Cross-posting from twitter:

Sorry to be picky, but shouldn't what could be not untruthfully described as adding a "backdoor" for DDG require more than any one person's word? I mean this is a hardcoded whitelist going out to millions of users for an unaudited entity w/ a vague ToS/PP & some branding.

[diracdeltas]

a couple of reasons that we are choosing to whitelist DDG (no other sites are currently whitelisted from fp protection btw):

• Background: FP protection works by blocking access to DOM APIs that are occasionally used for fingerprinting. Unfortunately a lot of the methods like the ones associated with canvas and webgl are used legitimately and thus show up as false positives. Probably the vast majority of sites that the average user sees using these APIs are using them legitimately.
• DDG is a Brave partner and we have contacts there: https://spreadprivacy.com/duckduckgo-brave-private-tabs/
• DDG's VP of search promised on Twitter that they don't do fingerprinting: https://twitter.com/bsstoner/status/1085623657999806464

If we detect any evidence of them doing fingerprinting we will of course remove them from the whitelist

[agentofuser]

Thank you for the thoughtful response.

no other sites are currently whitelisted from fp protection

Great. That was going to be my next question.

---

I understand there is a partnership and mutual trust between the two companies, and I personally have no reason to distrust either of them more than any other company. (On the contrary, I'm a most of the time a big supporter.)

As it relates to this point though, I'm trying to argue an impersonal user advocate/adversarial position and, from that perspective, "trust us, we trust them" seems insufficient. (And makes my promoting of Brave harder!)

Questions that come to mind:

a) What would this endorsement list behave like with regards to user settings?

1. If the user deliberately sets the global Shields settings to "Block all fingerprinting", would fingerprinting protection be disabled anyway on an endorsed domain? (Guessing "Yes", just to make sure.)
2. Would the fingerprinting/device recognition dropdown on per-domain Shields settings show that the protection is disabled on an endorsed domain?
3. Would the user be able to override the security/privacy exception on endorsed domains by reactivating fingerprinting protection via the per-domain Shields settings?
4. Would any extra trust indicator be visible that didn't require clicking the Shields icon? (Analogous to the TLS padlock; maybe a different color or decoration on the Shields lion icon.)
5. Would there be a way for the user to see the full endorsement list and disable individual entries or all entries at once?

b) Are there general criteria that could be required from candidates for endorsement?

I don't mean proof of no fingerprinting, as that would be hard to do once, let alone keep updated, in the general case.

But at least measures that would make it easier for independent parties to convince themselves that the exceptional (and, as it stands, potentially invisible and un-overridable by the user) privilege granted to endorsed domains are warranted.

Examples of varying strictness based on my limited knowledge:

1. All JS must be at least "source-available" (e.g. via source maps), not just minified/obfuscated, including dynamically-loaded code
2. All JS must be separately published to Brave, who then publishes an endorsed signed hash to be checked by the user agent before it puts into effect the fingerprinting protection exception

I understand these are stringent requirements. (There might be less onerous and equally trust-enhancing ones that I'm not aware of which would of course be suitable substitutes.)

From Brendan's response though, it seems like I expressed myself poorly so that my position—that some auditability be required—appeared to extend to the whole Web:

You can doubt DDG but auditability & verifiably (which we work on for our own code) cannot be required of all web content.

That is not what I meant. Those requirements would only be asked of applicants for inclusion into the list of Brave-endorsed domains with security/privacy exceptions.

That is assuming that the existence of such exceptions is even a good idea in the first place, which leads to the last issue.

c) Is this needed at all?

1. Isn't there any way DDG (or other non-compliant websites) can fix this on their end?
2. Are there ways for websites to detect breakage and deliberately ask the user to turn off defenses (and let the user weigh the trade-offs themselves)?
3. Would there be a way to anonymously (e.g. with anonize) collect user reports of breakage and then reach out to the biggest offenders to help them improve their compatibility with Brave? The report collection and outreach would be analogous to what already happens for payments to unregistered content creators.

[tildelowengrimm]

This issue only comes up when someone has specifically enabled fingerprinting protection. Adding a baked-in allow-list substantially increases the complexity needs of the and subverts the decision of the person who made the choice to block potential-fingerprinting methods from first parties. They can just as easily turn it off.

The root problem here was that on viewing the fingerprinting list, it's not clear that this could well be a false-positive. IMO that's the root problem here and we shouldn't add an allow-list.