When farbling canvas, farble across all channels

[Thorin-Oakenpants]

Updated Issue (@pes10k edit)
Currently the canvas farbling only effects one channel. That channel is determined by the per-eTLD+1, per-session farbling seed, so the channel isn't guessable, but it is probably detectable given a determined attacker.

It might make reversing the canvas farbling slightly more difficult if the farbling was done across all channels, which would make it a bit more difficult for an attacker.

Original Issue
There is a flaw in canvas randomizing. It's not a security issue. Do you want to discuss it here, or via email, or in a private repo. I'm not talking about the per-origin, per-execution to protect the random seed. It should be a simple fix

[srirambv]

cc: @pes10k

[pes10k]

Howdy @Thorin-Oakenpants , nice to run into you again :)

If you're in anyway not 100% sure that its not a security issue, feel free to email me at [email protected] and we can discuss more there. Otherwise, feel free to add your findings / concerns here and we can sort things out here.

Thanks!

[Thorin-Oakenpants]

@pes10k email sent: feel free to close this (or not)

[pes10k]

Just to keep things transparent, the concern is about how reversable canvas fingerprinting protections are (answer, not very hard to reverse!). Specifically, whether

1. it'd be better to not just farble a single channel (determined by the seed), and instead to farble all channels
2. whether it'd be better to not use the current per-session, per-etld approach, but instead do something shorter, like frame length seeds, to prevent tracking 1p tracking w/in the same-session

I'm going to update this issue accordingly:

1. This would be nice to do one, but its pretty low priority
2. I dont think we'll change this for reasons discussed over email (mainly, it makes it easier for the site to get the seed, and undo all farbling protections, not just for canvas)

Thanks again to @Thorin-Oakenpants for reporting!

[Thorin-Oakenpants]

Just to be clear: item 2 is out of scope, and was asked as an off-topic generic overall design question: @pes10k 's information in the email helps explain some of those decisions - thanks! I still think there can be changes there, but not in this ticket

[pes10k]

Sorry, apologies @Thorin-Oakenpants , didn't mean to put words in your mouth or misstate your comments. Thank you for clarifying!

[Thorin-Oakenpants]

^^ no worries: I see OP has been edited: "but it is probably detectable given a determined attacker" <- just to make that crystal clear - it is 100% detectable (with the right script), not probably

[Thorin-Oakenpants]

randomizing can also be completely bypassed (completely meaning zero channels are randomized) in iframes and currently offscreen worker doesn't seem to be covered: @pes10k email me if you want details, or you may already be aware of these

[pes10k]

@Thorin-Oakenpants hmm, the iframes example is very surprising, we have tests, but we may have missed something! Same with workers! So, if there are further edge cases we need to cover, that would be very welcome!

You can see our manual test cases here too, fwiw (there are of course automated tests we have in CI too), though you'll need to be in nightly to see everything we expect to be covered. There are somethings tested in these tests that are not yet implemented, but most of it is.

https://dev-pages.brave.software/farbling.html

TL;DR; Yes, more details / sunlight you can offer, the more thats appreciated!

[pes10k]

Closing this out because we now also determine which channel to farble depending on on the seed, which will prevent the attacker from knowing which channels are unmodified and which are farbled. Thanks for the issue @Thorin-Oakenpants !

[pes10k]

@Thorin-Oakenpants pointed out some techniques sites could use to determine which channel is being farbled in the current implementation (thanks!). After discussing, I'm convinced we should do as the issue suggested, and farble across all channels. I'll follow up with a possible PR. Thanks!

[pes10k]

for QA, there are new, per channel tests on https://dev-pages.brave.software/farbling.html

[stephendonner]

Verified FIXED on the beta channel using

Brave	1.22.51 Chromium: 89.0.4389.72 (Official Build) beta (x86_64)
Revision	3f345f156bfd157bd1bea06310e55f3fb2490359-refs/branch-heads/4389@{#1393}
OS	macOS Version 11.2.2 (Build 20D80)

Verified that the values per channel (∟ red channel, etc.) do all of the following:

1. differ per origin, so https://dev-pages.brave.software/farbling.html and https://dev-pages.bravesoftware.com/farbling.html have different values when shields are up (this is the “there site” link at the top of the page, for reference)

Shields up, dev-pages.brave.software/farbling.html vs. dev-pages.bravesoftware.com/farbling.html:

Shields down, dev-pages.brave.software/farbling.html vs. dev-pages.bravesoftware.com/farbling.html:

2. differ per browser session (so if you quit the browser and come back, you should get different values, on both origins)

Shields up, restart, dev-pages.brave.software/farbling.html vs. dev-pages.bravesoftware.com/farbling.html:

3. differ from the shields down version (which should be the same cross origin, cross session)

Shields down, restart, dev-pages.brave.software/farbling.html vs. dev-pages.bravesoftware.com/farbling.html:

In addition to the screenshots, I've captured the values, below; SU = Shields up, SD = Shields down

	Shields up - brave.software	Shields up - bravesoftware.com	Shields down - brave.software	Shields down - bravesoftware.com	SU, restart, brave.software	SU, restart, bravesoftware.com	SD, restart, brave.software	SD, restart, bravesoftware.com
red	72009bc3	d971e672	68ede59d	68ed59d	5e30861d	4daf9c46	68ed59d	68ed59d
green	44a7bda2	e633f8ab	f8d9ea89	f8d7ea89	bbc842c7	fb0f2ad7	f8d7ea89	f8d7ea89
blue	391c891f	691556c2	a68c1dac	a68c1dac	9735d809	4b8da15b	a68c1dac	a68c1dac

[srirambv]

Verification passed on OnePlus 6T with Android 10 running 1.22.51 x64 build

• Verified steps from When farbling canvas, farble across all channels #12069 (comment)

Case 1: Shields Up, same value

Case 2: Shields Up, different value on restart

Case 3: Shields Down, same value

Case 4: Shields Down, same value on restart

---

Verification passed on Samsung Tab A with Android 10 running 1.22.51 x64 build

• Verified steps from When farbling canvas, farble across all channels #12069 (comment)

Case 1: Shields Up, same value

Case 2: Shields Up, different value on restart

Case 3: Shields Down, same value

Case 4: Shields Down, same value on restart