4 ms·

I’m trying to understand the problem here. If the website you’re on has some javascript that’s executing side channel attacks to uniquely identify you, why coul

by nojs 5y ago

I’m trying to understand the problem here. If the website you’re on has some javascript that’s executing side channel attacks to uniquely identify you, why couldn’t they just use other fingerprinting techniques?

mlyle 5y ago
Perhaps you have the other fingerprinting techniques locked down. Brave has a whole lot of anti-fingerprinting measures. So instead, this approach has different adversaries sharing the fractional information they've gathered about this user and collaborate to build a stronger profile to positively identify the user.
sfink 5y ago
I believe this is assuming that fingerprinting mitigations are good enough to prevent unique identification. If you can uniquely identify a user, you don't need any cross-context coordination. The problem as I understand it is when you have two separate contexts, neither of which can unique identify you by themselves, and they want to test whether you are in fact the same user and furthermore send information between each other. The two contexts are usually either (1) two different websites, or (2) two different browsing contexts (two profiles or one is a private browsing / incognito session) on one site. The two contexts have a server-side communication channel to coordinate the attack. The two together may still not be able to uniquely identify you, but that's not the attack -- they just want to learn if you're the same user. I haven't read the paper, but I imagine it to work like this: say you have a global maximum of 100 WebSocket connections allowed alive at once. Context 1 opens up WebSockets until opening a new one fails. Then it tells the other context "hey, watch this." Using a shared clock, it closes one of the sockets for 1 second, reopens one for 1 second, etc., producing a string of 1s and 0s. The other context reads this string by attempting to open a socket of its own for a millisecond before closing it. (This is all hypothetical, there are probably flaws all over this.) If the probe succeeds, that's a 0, else it's a 1. You pass across a randomly-generated UUID or something. If you're using separate profiles, the advertiser (attacker) can now permanently remember that those profiles are actually the same person. You have a happy tracker, sad user. To defeat it, you need to partition the maximum limit, which means you either allow massive overcommitting, or you artificially restrict everything to a small value. It looks like they're arguing for overcommitting, using the argument that this will cause the attack to degrade the user's experience enough that they'll stop using the site, which means it'll stop being used. (To mitigate it, it seems like you could slow down the cross-context resource accounting, to make the bit rate too slow to be useful? But it probably doesn't take many bits.)
- heavenlyblue 5y ago
  I don’t think it’s common for any website that is not a spam landing page to have more than 1 websocket connection active at the same time. Let’s just say that most of the websites that require resources from a bunch of domain names are already a good heuristic for ad-infested pages.

by nojs 5y ago

mlyle 5y ago

Perhaps you have the other fingerprinting techniques locked down. Brave has a whole lot of anti-fingerprinting measures. So instead, this approach has different adversaries sharing the fractional information they've gathered about this user and collaborate to build a stronger profile to positively identify the user.

sfink 5y ago

I believe this is assuming that fingerprinting mitigations are good enough to prevent unique identification. If you can uniquely identify a user, you don't need any cross-context coordination. The problem as I understand it is when you have two separate contexts, neither of which can unique identify you by themselves, and they want to test whether you are in fact the same user and furthermore send information between each other. The two contexts are usually either (1) two different websites, or (2) two different browsing contexts (two profiles or one is a private browsing / incognito session) on one site. The two contexts have a server-side communication channel to coordinate the attack. The two together may still not be able to uniquely identify you, but that's not the attack -- they just want to learn if you're the same user. I haven't read the paper, but I imagine it to work like this: say you have a global maximum of 100 WebSocket connections allowed alive at once. Context 1 opens up WebSockets until opening a new one fails. Then it tells the other context "hey, watch this." Using a shared clock, it closes one of the sockets for 1 second, reopens one for 1 second, etc., producing a string of 1s and 0s. The other context reads this string by attempting to open a socket of its own for a millisecond before closing it. (This is all hypothetical, there are probably flaws all over this.) If the probe succeeds, that's a 0, else it's a 1. You pass across a randomly-generated UUID or something. If you're using separate profiles, the advertiser (attacker) can now permanently remember that those profiles are actually the same person. You have a happy tracker, sad user. To defeat it, you need to partition the maximum limit, which means you either allow massive overcommitting, or you artificially restrict everything to a small value. It looks like they're arguing for overcommitting, using the argument that this will cause the attack to degrade the user's experience enough that they'll stop using the site, which means it'll stop being used. (To mitigate it, it seems like you could slow down the cross-context resource accounting, to make the bit rate too slow to be useful? But it probably doesn't take many bits.)

heavenlyblue 5y ago
I don’t think it’s common for any website that is not a spam landing page to have more than 1 websocket connection active at the same time. Let’s just say that most of the websites that require resources from a bunch of domain names are already a good heuristic for ad-infested pages.