This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] HTTP/HTTPS probe
- Previous message (by thread): [atlas] HTTP/HTTPS probe
- Next message (by thread): [atlas] HTTP/HTTPS probe
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Robert Kisteleki
robert at ripe.net
Fri Nov 22 12:32:05 CET 2013
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
- Previous message (by thread): [atlas] HTTP/HTTPS probe
- Next message (by thread): [atlas] HTTP/HTTPS probe
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]