[atlas] HTTP/HTTPS probe

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 at 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
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/ripe-atlas/attachments/20131122/9de72f0d/attachment.sig>