search

IRTF-PEARG / draft-safe-internet-measurement

draft-safe-internet-measurement
6 stars 1 forks source link

Question about the scope of the document and what measurements it applies to #33

Open hellais opened 2 months ago

hellais commented 2 months ago

In reading through the specification, it's unclear to me if this RFC is meant to cover all possible internet measurement scenarios or if it's limited only to a particular class of internet measurements.

For example it states in the beginning:

Proactively identify your measurement to others on the network.

Which is something that in many cases, including ours at OONI, is not feasible or desirable because it would invalidate our measurement altogether, since we would not look like legittimate end user traffic.

Share responsibly

This whole section assumes that the data is already not public by default, which is the case in certain measurement platforms like OONI or RIPE Atlas.

See also my comments to the Do not scan section.

If it's meant to be a document informing a particular class of internet measurement experiments I guess it would be helpful to clarify it at some point in the document.

mallory commented 1 month ago

Arturo, thanks for these comments. It's made me consider that we should include end-user measurement tools as in scope, but that we should approach this holistically. If you have suggestions for:

1) how end-user measurement tools are substantively different (do not scan, identification to the network, but what else?) 2) whether and how we need to make this distinction in the draft at a high level.

I do worry that I think this draft shouldn't definitively "split" certain kinds of internet measurement from others. Perhaps we can take a more incisive approach that recognizes kinds of measurements in which the first party (measurer) and the second party (target) are joined by an informed third party probe that is attached to a person, their agent or their device.

Your comments from #32 that can be resolved in this ticket are:

Moreover, for a tool that people run, I think it would not be fair for the creator of said tool to restrict it's usage by imposing a blocklist on the targets, so probably this do not scan list should only apply to platform initiated testing.

I also think it would be important to include in the considerations WRT what should not be scanned user safety. Over the years we have received requests from community members to not scan classes of targets from particular geographies and so the lists have been updated to exclude them from testing.