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

Add data field for blocking method to Censorship Findings page #902

Open
agrabeli opened this issue Jan 10, 2024 · 2 comments
Open

Add data field for blocking method to Censorship Findings page #902

agrabeli opened this issue Jan 10, 2024 · 2 comments

Comments

@agrabeli
Copy link
Member

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.

@agrabeli
Copy link
Member Author

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.

@hellais
Copy link
Member

hellais commented Jan 15, 2024

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)

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

No branches or pull requests

4 participants