-
Notifications
You must be signed in to change notification settings - Fork 142
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
webconnectivity: long term evolution (aka v0.5.x aka LTE) #2237
Comments
In a pure step-by-step model, we don't need to trace HTTP round trips like we did before. We _may_ want in the future to also have some form of HTTP tracing (see #868 for a prototype) but doing that is currently not in scope for moving forward the step-by-step design. For this reason, I only added a public convenience function for formatting an OONI spec compatible request. I also added new fields, which should be documented inside the ooni/spec repository (see ooni/probe#2238). Required by ooni/probe#2237
Initial release (v0.5.0)We merged ooni/probe-cli#882, which contains an initial implementation. I will spend a couple of days running some extra tests and then I'll bless an alpha release, so power users can help us moving forward. |
Support for late DNS replies (v0.5.1)See ooni/probe-cli#883, which supports recording late DNS replies. |
This pull request documents more precise stdlib resolver naming that will benefit [email protected]. See ooni/probe#2238, ooni/probe#2237, ooni/probe-cli#885. While there, fix the template for new PRs.
See what we documented at ooni/spec#257 Reference issue: ooni/probe#2238 See also the related ooni/spec PR: ooni/spec#257 See also ooni/probe#2237 While there, bump [email protected] version because this change has an impact onto the generated data format. The drop in coverage is unavoidable because we've written some tests for `measurex` to ensure we deal with DNS resolvers and transport names correctly depending on the splitting policy we use. (However, `measurex` is only used for the `tor` experiment and, per the step-by-step design document, new experiments should use `measurexlite` instead, so this is hopefully fine(TM).) While there, fix a broken integration test that does not run in `-short` mode.
Use better resolver engine names (v0.5.2)See ooni/probe-cli#885, which implements ooni/spec#257. |
While working on ooni/probe#2237, I noticed there's no enforced timeout for measurement tasks. So, this diff introduces the following timeouts: 1. use a 4 seconds timeout for the DNS lookup; 2. use a 10 seconds timeout for TCP; 3. use a 15 seconds timeout for HTTP. They are a bit stricter than what we have on the probe because the TH should supposedly have better bandwidth and connectivity.
This diff introduces the following `oohelperd` enhancements: 1. measure both IP addresses resolved by the TH and IP addresses resolved by the probe; 2. when the URL scheme is http and there's no explicit port, measure both 80 and 443 (which will pay off big once we introduce support for optionally performing TLS handshakes); 3. include information about the probe and TH IP addresses into the results: who resolved each IP address, whether an address is a bogon, the ASN associated to an address. This diff is part of ooni/probe#2237
This diff improves oohelperd to measure :443 endpoints with TLS. Part of ooni/probe#2237.
The above PRs extended |
Use TLS info from the TH (v0.5.3) |
Sync data format with v0.4 and urlgetter (v0.5.5)We're bumping the version number to reflect recent improvements in the data format implemented in these pull requests: ooni/probe-cli#942, ooni/probe-cli#943, ooni/probe-cli#944 |
DoH failure should not set failure flags (v0.5.6) |
It's confusing to see ``` measuring additional addrs from TH: [] ``` when actually nothing is going to be measured. So, instead, let us log about the additional addrs discovered by the TH instead, which is less confusing. Part of ooni/probe#2237
It's confusing to see ``` measuring additional addrs from TH: [] ``` when actually nothing is going to be measured. So, instead, let us log about the additional addrs discovered by the TH instead, which is less confusing. Part of ooni/probe#2237
It's confusing to see ``` measuring additional addrs from TH: [] ``` when actually nothing is going to be measured. So, instead, let us log about the additional addrs discovered by the TH instead, which is less confusing. Part of ooni/probe#2237
We're bumping the experiment's version number because we changed the name of the field used to contain late/duplicate DNS responses. We have also changed the algorithm to determine #dnsDiff, however, the change should only impact how we log this information. Overall, here the idea is to provide users with a reasonably clear explanation of how the probe maps observations to blocking and accessible. Part of ooni/probe#2237
We're bumping the experiment's version number because we changed the name of the field used to contain late/duplicate DNS responses. We have also changed the algorithm to determine `#dnsDiff`. However, the change should only impact how we log this information. Overall, here the idea is to provide users with a reasonably clear explanation of how the probe maps observations to blocking and accessible using expected/unexpected as the conceptual framework. Part of ooni/probe#2237
) We're bumping the experiment's version number because we changed the name of the field used to contain late/duplicate DNS responses. We have also changed the algorithm to determine `#dnsDiff`. However, the change should only impact how we log this information. Overall, here the idea is to provide users with a reasonably clear explanation of how the probe maps observations to blocking and accessible using expected/unexpected as the conceptual framework. Part of ooni/probe#2237
With #2396 (which is part of the 3.17.x release train), we added support for A/B testing of the webconnectivity version to use depending on feature flags provided by the check-in API. With this functionality, we can start testing this new version of webconnectivity more widely. |
The idea here is to rewrite
webconnectivity
to use step-by-step and to incorporate somewebsteps
features without deviating from the original data format. Here's what we can reasonably implement:webconnectivity
and just use a single connection for determining redirectsThe general idea is to write this prototype using boilerplate (see ooni/probe-cli#853), and make it available to
miniooni
users optionally under a disabled-by-default feature flag to collect feedback from users (see #2009). After an initialminiooni
only deployment and refinement, we aim to selectively enable this new implementation just for somedesktop
,cli
,android
, andios
users via the check-in API, so to collect more data and further improve the implementation.The overall aim is to start collecting
websteps
like data without breakingwebconnectivity
. This strategy should give us better data as well as better information regarding a full rollout ofwebsteps
.Users will be able to run this experiment like this
miniooni [email protected]
, which will select the new version as opposed to selecting thev0.4.1
version that is being run by default.The text was updated successfully, but these errors were encountered: