Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove oohttp and oocrypto from codebase #2827

Open
3 tasks
hellais opened this issue Dec 7, 2024 · 1 comment
Open
3 tasks

Remove oohttp and oocrypto from codebase #2827

hellais opened this issue Dec 7, 2024 · 1 comment

Comments

@hellais
Copy link
Member

hellais commented Dec 7, 2024

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:

  1. 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)
  2. 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:

  • Validate and document all the places in the code where we are using oohttp and ootls to make sure we aren’t missing anything
  • Make a release where oohttp and ootls are replace with the standard library and measure the impact
  • Assess the impact and evaluate if more work and effort is needed to invest into this
@hellais
Copy link
Member Author

hellais commented Jan 23, 2025

I believe we are aiming to have this land into not the next, but the following release. Here is a WIP branch that implements this: ooni/probe-cli#1674

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Backlog
Development

No branches or pull requests

3 participants