You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Editors of the Censorship Findings page (https://explorer.ooni.org/findings) have the opportunity to add various types of data (e.g. domains, ASNs, tags, test name, etc) as part of the data entry fields required for the creation of each report.
It would be great if we could add an additional data field for blocking method(s).
As part of the report writing process, I am documenting anyway the technical means by which blocks are implemented (e.g. DNS tampering, TLS interference, IP blocks, etc), providing a certain amount of detail to qualify the blocking method (e.g. NXDOMAIN error, TLS handshake timeout error, TLS handshake connection reset error, etc.).
I think it would be super useful (and important!) if this information were collected in a machine-readable way through the data entry fields of Censorship Findings page reports. That way, we could not only display the blocking methods as metadata on the reports, but we could also use this information to inform the improvement of our data analysis capabilities. Moreover, we could potentially visualize the blocking methods adopted by countries around the world (based on this data), and show how censorship changes over time! There are lots of interesting and important things that we can do with this data, and since I'm documenting it anyway as part of the reports, it would be nice if we could have a dedicated data entry for it and store it in the backend.
The text was updated successfully, but these errors were encountered:
We discussed that as an interim solution, we can take note of the blocking method(s) as part of the tags (there's an existing data field for that). That's probably a good idea to avoid overcomplicating the underlying data model.
The proposed format is blockingmethod-{method_string}. To make it easier to parse the method_string if we want to upgrade to another format, it should follow the snake_case convention and we should be sure to use method names which are consistent.
Example:
blockingmethod-tcp_reset ✅ GOOD
blockingmethod-tcp-reset 🔴 BAD (not snake_case)
blockingmethod-httpblockpage ✅ GOOD
blockingmethod-httpblockpage and blockingmethod-http_block_page 🔴 BAD (duplicate key with different formats)
Editors of the Censorship Findings page (https://explorer.ooni.org/findings) have the opportunity to add various types of data (e.g. domains, ASNs, tags, test name, etc) as part of the data entry fields required for the creation of each report.
It would be great if we could add an additional data field for blocking method(s).
As part of the report writing process, I am documenting anyway the technical means by which blocks are implemented (e.g. DNS tampering, TLS interference, IP blocks, etc), providing a certain amount of detail to qualify the blocking method (e.g. NXDOMAIN error, TLS handshake timeout error, TLS handshake connection reset error, etc.).
I think it would be super useful (and important!) if this information were collected in a machine-readable way through the data entry fields of Censorship Findings page reports. That way, we could not only display the blocking methods as metadata on the reports, but we could also use this information to inform the improvement of our data analysis capabilities. Moreover, we could potentially visualize the blocking methods adopted by countries around the world (based on this data), and show how censorship changes over time! There are lots of interesting and important things that we can do with this data, and since I'm documenting it anyway as part of the reports, it would be nice if we could have a dedicated data entry for it and store it in the backend.
The text was updated successfully, but these errors were encountered: