Maintaining forks of oohttp and oocrypto is a significant burden on our release process, so we should try to simplify this if possible.
The problem oocrypto and oohttp are trying to solve are:
- Address the problem of OONI Probe clients getting blocked due to the golang ClientHello fingerprinting (see: https://ooni.org/post/making-ooni-probe-android-more-resilient/#changing-our-android-tls-fingerprint)
- To support GREASED Encrypted Client Hello
Problem 2. is going to be addressed by the fact we will be upgrading the only test that uses it to the latest version of go which supports it natively.
Regarding 1., this is ultimately a very narrow edge case, which affects a single country and a very particular set of architectures. We might even consider the fact that we can tell this from our measurements as a feature.
We should consider if the development overhead and effort to maintain these forks is worth our while.
To test this, we should make a release of the engine where all of these pieces are ripped out and measure the impact on measurement quality and see if we see a noticeable difference in increasing of blocking when we do. If we don’t notice anything significant in the data, we can probably just consider it as noise and not invest more time in getting it working accurately.
The ideal solution would be parrot the ClientHello of a real browser, using something like utls or utls-light, but as it currently is it’s only really a partial solution that is very costly to maintain so we should probably scrap it.
Action items:
Maintaining forks of oohttp and oocrypto is a significant burden on our release process, so we should try to simplify this if possible.
The problem oocrypto and oohttp are trying to solve are:
Problem 2. is going to be addressed by the fact we will be upgrading the only test that uses it to the latest version of go which supports it natively.
Regarding 1., this is ultimately a very narrow edge case, which affects a single country and a very particular set of architectures. We might even consider the fact that we can tell this from our measurements as a feature.
We should consider if the development overhead and effort to maintain these forks is worth our while.
To test this, we should make a release of the engine where all of these pieces are ripped out and measure the impact on measurement quality and see if we see a noticeable difference in increasing of blocking when we do. If we don’t notice anything significant in the data, we can probably just consider it as noise and not invest more time in getting it working accurately.
The ideal solution would be parrot the ClientHello of a real browser, using something like utls or utls-light, but as it currently is it’s only really a partial solution that is very costly to maintain so we should probably scrap it.
Action items: