Hacker News new | past | comments | ask | show | jobs | submit login

The lock metaphor does not work in this case

There was no lock, not even a sucky one, if you want to use a physical analogy then the one burpee posted above is good.




If he had to write a script to take the addresses and bruteforce the IDs, there was a lock. A weak one, but still a lock. If there were just a public page that lists all the emails and IDs, the case would be different. I can see no legitimate reason to download a massive list of names - if you wanted to show a vulnerability, one or two emails would be enough. If he stopped when he found a hundred emails or found an algorithm that can generate an ID and guess an email and published that - this would be very different. Even if he created a demo script that would find emails but would not record them (or record sha1 hashes of them - so it can be proven they were true ones but not possible to actually use it for any malicious purpose) - it would still be different.


URLs are not a lock. They are a mechanism for locating a resource. AT&T made no attempt to obscure the resource location, or to mathematically hide the location of a given resource like the rest of the sane world does. Publishing something on a predictable interface and then saying "oopsie, that's private, you're a felon for looking at it" is insane.


You again ignore the facts. He didn't just "look" at it. He wrote a script - a purposeful action - to generate specific sets of IDs based on his guesses about geographic distribution, etc. and used it to download more than 100K email addresses. You here sound like spammers saying "what you want from me, I just sent an email, now it's a crime?". That stopped working long ago. There's a difference between looking at one page and writing a tools that scans through millions of IDs (most of which would be rejected by the access controls) to bruteforce the protection and download 100K of emails. I don't believe anybody can be genuinely so obtuse as not to understand the difference between the two.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: