I suggest to start making HEAD requests to a limited set of destinations available to all users. Initially limit the list destinations under control of RIPE NCC, including anchors. I feel that this would not require an opt-in question to probe hosts, just information. As a next step we could then define a process for adding other destinations. This would prevent Atlas from becoming a general purpose tool for HTTP performance measurement and abuse. How's that to start with? Daniel On 22.11.2013, at 12:32 , Robert Kisteleki <robert@ripe.net> wrote:
On 2013.11.21. 20:41, Richard Barnes wrote:
I think HEAD would probably be OK. At least, I'm not aware of any exploits that would enable.
--Richard
A completely different dimension of this is something that's (almost) unique to Atlas: you can use vantage points that are in others' networks or homes. Seemingly the request (whether it's GET or HEAD) will come from there.
If one uses this to access illegal content (for whatever definition of illegal), then the host will be in trouble, and I don't think explanations about "it was not me, it was someone else" or "it was just a HEAD request, I didn't really see that picture" will make a difference in all cases. (We will likely be able to trace back the actual request to someone, but it may not help the host in question.)
Maybe I'm a pessimist here, but if I'm not, then it means we can only use some kind of opt-in method, and even that does not solve the root problem.
The alternative is to limit the potential destinations system-wide, which severely limits the usefulness of such measurements (or it boosts the Atlas Anchor deployment rate ;-)
Robert