Everyone here that is thinking of giving this company the benefit of the doubt needs to go read their (smeagle) responses to RKearney from the original thread. Here are some samples of the careless attitude behind this: ---- "if anyone's concerned about your AWS key, just destroy your IAM user and create a new one. that's what it was designed for." ---- In response to advice saying they should notify users by email:…
Never Give Your Information To 10 Minute Old Startups
161–170 of 185 posts
Re: Never Give Your Information To 10 Minute Old Startups
#162Earlier quoted context omitted.
The mistake betrays so much incompetence that there is really no way for me to trust anything they ever do again. The other mistakes they make might not be quite so easy to find.
I don't think hack-shaming accomplishes anything. Just yesterday we had someone publish a "securely delete your email" application. 'tptacek found problems in it immediately[1], but he didn't call the guy incompetent or an idiot or "never trust anything he does again." There was no attempt to shame. I see the more experienced people around here have a lot more sympathy for these guys. If you've done a lot, you've als…
Re: Never Give Your Information To 10 Minute Old Startups
#163Earlier quoted context omitted.
we're incredibly sorry about all of this. honestly, this was all accidental. it was a pet project we started to toy with Glacier and a week later i accidentally hit the Like button sending a ping to my friends on FB. bless my friends for being so influential i guess. shame on us for using Rails carelessly. if you have any experience with startups, you'll know that 99% of the things you launch go nowhere--this project…
Why did you share Ryan's email address in a previous comment and why have't you deleted it yet ?
Re: Never Give Your Information To 10 Minute Old Startups
#164That's why I'm not a user of App.net. They only accept credit card.
Re: Never Give Your Information To 10 Minute Old Startups
#165Re: Never Give Your Information To 10 Minute Old Startups
#166Re: Never Give Your Information To 10 Minute Old Startups
#167Earlier quoted context omitted.
"Never give your information to a business that made a mistake like this, ever." Fwiw back in 1996 or 97 the UPS website did the same thing. By altering the tracking number you could see somewhat complete information on someone else's shipment. Since the tracking numbers ran in sequence from the shippers log books giving one tracking number from a competitor you could see all their customers. (To get that all you had…
That hasn't changed. You can pop a tracking number into UPS and get shipment info.
Package weight
Shipping date
Who signed for it (last name)
Where package was left
Town delivered to
When delivered
And some other nominal info.
In the old days you saw exactly who the shipper was and detailed info on the recipient and recipients address. There was probably other info but what I've listed is what I remember. I remember thinking at the time that it would be valuable and contain exactly what a competitive company would need to gather a list of potential customers.
Re: Never Give Your Information To 10 Minute Old Startups
#168Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…
There is no such thing as irresponsible disclosure, therefore there can be no such thing as responsible disclosure.
Re: Never Give Your Information To 10 Minute Old Startups
#169Earlier quoted context omitted.
What does that have to do with anything ?
With the title of TFA.
Re: Never Give Your Information To 10 Minute Old Startups
#170Many folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of break…
For a vulnerability as obvious as this, it's a fair bet that bad guys will notice immediately. "Responsible disclosure" is great when you've discovered something tricky, but it's irresponsible when anyone else can notice as easily as you can.
Remember that the term "responsible" is about responsibility to the users, not to the developers. If publicizing a vulnerability would leak it to bad guys who don't have it, the responsible thing to do is not to leak it. If the bad guys already have it, the responsible thing to do is to tell the public. (After all, disclosure is about whether to tell the public, not whether to tell the developers.)