Open arky opened 1 year ago
I started working on a patch for this. The underlying conceptual problem is that Web Connectivity does not flag TLS failures as "tls" but rather uses "http-failure" also for TLS. So, the fix is to introduce the "tls" blocking value for Web Connectivity, process it into the pipeline, and handle it correctly inside OONI Explorer. I already wrote the first two paches (see above PRs) and asked for some clarifications regarding how to properly do this for Explorer.
@bassosimone Thank you!
Moving forward with this issue without changing the pipeline to automatically flag "tls"
in case of TLS failure is tricky because v0.4 measurements would report "http-failure"
and v0.5 measurements would report "tls"
. In turn, this flapping between two values would confuse people. In trainings, we typically suggest that results that oscillate between two values are to be investigated further.
Writing a more complex patch for the existing fast path pipeline seems therefore the correct way to comprehensively fix the issue and avoid flapping. However, we are also racing with ooni/data
here, and ooni/data
may land before I write and test a patch for the fast path pipeline to do this. (While would be intrinsically difficult, given that the fast path pipeline has not been designed to do this, so I would need to write specific code and perform lots of testing.)
For this reason, I am removing this issue from my sprint, since it's not possible for me to complete within the end of this two week sprint (in 2.5 days), and I am moving it back to the backlog.
Describe the bug
HTTP connectivity issues causes false positive
https://explorer.ooni.org/m/20230419090111.600304_KH_webconnectivity_5796fe766a5e6460
To Reproduce
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
System information (if applicable):
Additional context
Add any other context about the problem here.