(Moving this discussion to anti-censorship-team@. See below for context.)
On Wed, Apr 29, 2020 at 11:35:48PM +0000, soncyq47 wrote:
---MY EMAIL HAS 3 PARTS SO PLEASE READ IT ALL---
I believe it's feasible (albeit not trivial) for an adversary to modify these fingerprints, e.g., by making Firefox believe that it runs under a different screen resolution, has a variety of apps installed, etc.
/1./ It's obviously possible to spoof a few things. The point I was making is that there are like 20 or 50, if not more aspects of the fingerprint, and we can measure it all, so it's practically impossible to spoof them all. We could just then group similar fingerprints together.
I think I'm missing something here. Doesn't it suffice for an adversary to tamper with a single feature to create a new browser fingerprint, and thus obtain different bridges? I suppose it would depend on how the server derives its fingerprints.
It's not a bad idea but I'm not convinced that the implementation effort would be worth the outcome.
Another issue is that for this to work, we would have to store the fingerprint of requesting users and we would rather not store unique, user-specific identifiers.
This problem might be slightly mitigated with federation. But I totally agree with the privacy issue you're saying.
/2./ I have a theory for why paid VPNs get blocked less, maybe the operators of the GFW can't get access to an American credit card, so the VPN doesn't have to worry about IP distribution, just the encryption algorithm.
I don't have any thoughts on this.
/3./ What about SMS distribution. I know there are tricks to get lots of numbers, but what I've seen is usually limited to one country, so we could just separate area codes into different distribution buckets.
Again, not necessarily a bad idea but expensive to build. Our resources are very limited and we need to be rather confident that something works out before investing a substantial amount of development time.
Please reply about what you think of my 3 points. Cheers
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, April 29, 2020 4:16 PM, Philipp WInter phw@nymity.ch wrote:
On Tue, Apr 28, 2020 at 09:52:29PM +0000, soncyq47 wrote:
Sorry I don't understand Selenium very well, but in terms of automating, each fingerprint only gets one bridge, so if you keep automatically asking you just keep getting the same address over and over.
I believe it's feasible (albeit not trivial) for an adversary to modify these fingerprints, e.g., by making Firefox believe that it runs under a different screen resolution, has a variety of apps installed, etc.
Another issue is that for this to work, we would have to store the fingerprint of requesting users and we would rather not store unique, user-specific identifiers.
Cheers, Philipp
On 5/1/20 7:04 AM, Philipp WInter wrote:
(Moving this discussion to anti-censorship-team@. See below for context.)
On Wed, Apr 29, 2020 at 11:35:48PM +0000, soncyq47 wrote:
---MY EMAIL HAS 3 PARTS SO PLEASE READ IT ALL--- [...]
/2./ I have a theory for why paid VPNs get blocked less, maybe the operators of the GFW can't get access to an American credit card, so the VPN doesn't have to worry about IP distribution, just the encryption algorithm. [...]
I know lots of people in China using Linode and Google Cloud which also a credit card. They only support the credit card like VISA or MasterCard instead of China UnionPay card. So it isn't too hard if someone wants to get the card, especially is GFW who be described as "unlimited fund" by GFW technology review blog.
They don't block the IP just because a few people use it. Yes, the credit card it did block a lot of people:(
/3./ What about SMS distribution. I know there are tricks to get lots of numbers, but what I've seen is usually limited to one country, so we could just separate area codes into different distribution buckets.
SMS is not a good idea to me. Chinese +86 phone numbers must be real name verification to using (due to against like telephone crimes). Using these number received the SMS will break the anonymity.
anti-censorship-team@lists.torproject.org