8 ms·

To be fair, the guy who owns that site did mention that it wasn't meant to be picked up by HN and was still in the early stages of development.

by alyx 14y ago

philwelch 14y ago
If it's accessible on the public internet and asks for something as secure as API keys, that is when you should worry about security, not when it's "meant to be picked up by HN".
- alyx 14y ago
  Fair, but in any case, the ultimate responsibility still lies with the user's judgment. Maybe if there was a service promised but not rendered, could you place full blame on the developer(s).
  - adgar2 14y ago
    Exactly. When you go to provide your information to a website, you need to consider "what are all the possible outcomes of this?" We can't use the reputation of the providers of a service as a proxy and thus have zero information about what to expect. Since you almost never have the source code for the website you're giving your information to, using your logic, just never give your data out. Right?
  - shardling 14y ago
    What exactly does "ultimate responsibility" even mean here?
  - philwelch 14y ago
    It's not a matter of assigning blame, it's a matter of not delivering a shitty service to your customers.
kooshball 14y ago
I have mixed feeling about this. On one hand we all want to move quickly, get users, add new features, etc etc. On the other, security issues like this are just so vital that nothing else really matter if your data is not secure. It's especially true for a BACKUP SERVICE that promises ridiculous stuff like "99.999999999%" uptime on the frontpage.
- smeagol 14y ago
  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 was no different. we honestly thought our site was of absolutely no consequence. we're truly thankful so many people found it useful, but trust me we're sorry there was a hole. however, just to be clear: - about 20 accounts were exposed, including me and my buddy - i emailed all of them, and wiped out the credentials - they quickly responded (i saw the updates come in) thankfully, AWS is designed for such situations. with a few clicks, people deactivated their credentials (both IAM and main account) and regenerated new credentials. the fact that all the early signups were techies who know their way around AWS really saved us. one more thing: the correct quote is: "Glacier is built for durability of 99.999999999%" also: i agree with ryan--don't trust 10-minute old startups :-)
  - adriand 14y ago
    Classy response. Now here's your chance to take lemons and make lemonade. Clearly your pet project is something that people find really interesting and useful. So it went public before you intended and had some security flaws: oh well, that's in the past now. Write your mea culpa about how much you learned from this experience, hit the front page of HN again, sign up a bunch of users, and go get some venture capital. Good luck!
    - AVTizzle 14y ago
notatoad 14y ago
still... developing an application and then bolting on some security over top of it later seems like a recipe for disaster. And pushing it to a public server before any security has been implemented is a very stupid thing to do.
- danielweber 14y ago
  It may have been a prototype they quickly wrote, and planned to do a heartier implementation later. And when they suddenly got onto HN's front page, a whole bunch of excitement happened and they completely forgot that this was just a prototype. "Pushing it to a public server" is really minor. Mozilla had this issue, too, when they had a new filename technically available on a server and someone jumped the gun and told the whole world that the new version was ready. Well, it wasn't. A bunch of kids whined that it was all Mozilla's fault for having a file available on their public server, but while it's arguable that a service that is reachable by URL has no expectation of privacy, it's a hell of a lot harder to argue that having a service reachable by URL implies a warranty that it is safe to use. Friends in the 90's would run telnet and web servers with "Username:" "Password:" "Credit Card Number:" prompts. It was funny to watch that some people would type in apparently real data, although we never verified.

To be fair, the guy who owns that site did mention that it wasn't meant to be picked up by HN and was still in the early stages of development.

by alyx 14y ago

To be fair, the guy who owns that site did mention that it wasn't meant to be picked up by HN and was still in the early stages of development.

philwelch 14y ago

If it's accessible on the public internet and asks for something as secure as API keys, that is when you should worry about security, not when it's "meant to be picked up by HN".

alyx 14y ago
Fair, but in any case, the ultimate responsibility still lies with the user's judgment. Maybe if there was a service promised but not rendered, could you place full blame on the developer(s).
- adgar2 14y ago
  Exactly. When you go to provide your information to a website, you need to consider "what are all the possible outcomes of this?" We can't use the reputation of the providers of a service as a proxy and thus have zero information about what to expect. Since you almost never have the source code for the website you're giving your information to, using your logic, just never give your data out. Right?
- shardling 14y ago
  What exactly does "ultimate responsibility" even mean here?
- philwelch 14y ago
  It's not a matter of assigning blame, it's a matter of not delivering a shitty service to your customers.

kooshball 14y ago

I have mixed feeling about this. On one hand we all want to move quickly, get users, add new features, etc etc. On the other, security issues like this are just so vital that nothing else really matter if your data is not secure. It's especially true for a BACKUP SERVICE that promises ridiculous stuff like "99.999999999%" uptime on the frontpage.

smeagol 14y ago
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 was no different. we honestly thought our site was of absolutely no consequence. we're truly thankful so many people found it useful, but trust me we're sorry there was a hole. however, just to be clear: - about 20 accounts were exposed, including me and my buddy - i emailed all of them, and wiped out the credentials - they quickly responded (i saw the updates come in) thankfully, AWS is designed for such situations. with a few clicks, people deactivated their credentials (both IAM and main account) and regenerated new credentials. the fact that all the early signups were techies who know their way around AWS really saved us. one more thing: the correct quote is: "Glacier is built for durability of 99.999999999%" also: i agree with ryan--don't trust 10-minute old startups :-)
- adriand 14y ago
  Classy response. Now here's your chance to take lemons and make lemonade. Clearly your pet project is something that people find really interesting and useful. So it went public before you intended and had some security flaws: oh well, that's in the past now. Write your mea culpa about how much you learned from this experience, hit the front page of HN again, sign up a bunch of users, and go get some venture capital. Good luck!
  - AVTizzle 14y ago

notatoad 14y ago

still... developing an application and then bolting on some security over top of it later seems like a recipe for disaster. And pushing it to a public server before any security has been implemented is a very stupid thing to do.

danielweber 14y ago
It may have been a prototype they quickly wrote, and planned to do a heartier implementation later. And when they suddenly got onto HN's front page, a whole bunch of excitement happened and they completely forgot that this was just a prototype. "Pushing it to a public server" is really minor. Mozilla had this issue, too, when they had a new filename technically available on a server and someone jumped the gun and told the whole world that the new version was ready. Well, it wasn't. A bunch of kids whined that it was all Mozilla's fault for having a file available on their public server, but while it's arguable that a service that is reachable by URL has no expectation of privacy, it's a hell of a lot harder to argue that having a service reachable by URL implies a warranty that it is safe to use. Friends in the 90's would run telnet and web servers with "Username:" "Password:" "Credit Card Number:" prompts. It was funny to watch that some people would type in apparently real data, although we never verified.