Live data from Hacker News

Never Give Your Information To 10 Minute Old Startups

blog.ryankearney.com

161–170 of 185 posts

Re: Never Give Your Information To 10 Minute Old Startups

#161

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:…

@smeagol. First of all you fucked up. So stop acting so high and mighty and apologize to rkearney and everyone else who even thought about signing up for your product. Secondly, if this was just meant for you and your friends, don't go public with it and post it on HN. I highly recommend another hobby in a different field because clearly this one doesn't agree with you. Lastly, please stop calling yourself a nerd.

Re: Never Give Your Information To 10 Minute Old Startups

#162

Earlier 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…

The thread in question involved a few broad oversights in a tool, not an immediate disclosure due to a trivial oversight. There's a difference between not generating random numbers correctly and immediately disclosing every AWS key you've been given.

Re: Never Give Your Information To 10 Minute Old Startups

#163
post #34

Earlier 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 ?

Knee-jerk reaction?

Re: Never Give Your Information To 10 Minute Old Startups

#165
post #98
post #91

Earlier quoted context omitted.

Could you elaborate? I fail to see the connection.

Not sure what the parent is referring to, but back in the day you'd have porn preview galleries with no index, but with an easily enumerable id in the URL. Ah, youth...

You are correct.

Re: Never Give Your Information To 10 Minute Old Startups

#167
post #149
post #62

Earlier 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.

Currently given a tracking number you can only get the following 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

#168
post #27

Many 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…

Responsible disclosure is a myth.

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

#169
post #166

Earlier quoted context omitted.

What does that have to do with anything ?

With the title of TFA.

Fortunately, you don't give App.net your credit card information directly. It's handled by Stripe, and they're past being "10 minutes old". (Even though this isn't easily verifiable in the checkout flow to a non-developer.)

Re: Never Give Your Information To 10 Minute Old Startups

#170
post #27

Many 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…

The purpose of "responsible disclosure" is to prevent subtle vulnerabilities from being known by more people.

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.)

Post reply on HN