1–10 of 14 posts
https://news.ycombinator.com/item?id=8818170
So, why not?
They don't need to do deep introspection on the VM's, a sample every now and then could easily tell whether your instances are churning through SHA hashes.
If I'm wrong for some technical reason - what is it?
Since this is a major risk, I'm curious why it's impossible for Amazon to protect you against it.
If they start an infrastructure for deep introspection of the VMes, especially for something which isn't prohibited by their agreement (at least, I don't think it's prohibited) then what is their liability for not looking for other signatures?
There are other virtual currencies. Some don't use SHA, I assume. Even if all Bitcoin attempts could be identified and killed within a second, I assume that people would switch to other systems.
keeping your credentials safe instead of relying on amazon sounds a lot easier to me
your argument is like saying a daily withdrawal limit (like $500) you can lift at any time isn't sane, because "keep your card and PIN safe" sounds a lot easier. Well, yes, but the point is your card/pin can (and does) get stolen, and so do Amazon credentials.
I just don't understand why they don't add that extra layer.
(Well, I can understand. If 98% of the clients with stolen access are huge companies that have no idea whether their charge should be $170 or $85,000 per month and are happy to pay either, then the policy might make sense to Amazon. But that doesn't seem likely, as they go out of their way to try to reach you and notify you that this might be happening. . .)
2) They can detect that the computer is running near 100%, but I guess there are a lot of legit users that use near the 100%.
3) I'm not sure of the privacy conditions, but most people would not like that Amazon peeps into their VM. Perhaps you are simulating a new secret drug medicine, or you are enhancing a porn video, or you are encrypting/decrypting your users post/photos, or you are deep mining health information to send medical spam/advertising/advice. These don't use a massive sha calculation, but it may be difficult to notice the difference automatically.
4) The more similar real word application I can think now is doing a massive git rebase (rebase all the Linux kernel from start, or all github repositories). IIRC git uses sha-1 and bitcoin uses sha-256, so this is not an exact application.
5) They would have to test the use of instance to mine scrypt based coins, like Litecoin. And other mining schemes ...
1) Your comment has an answer. 2) They can detect that the computer is running near 100%, but I guess there are a lot of legit users that use near the 100%. 3) I'm not sure of the privacy conditions, but most people would not like that Amazon peeps into their VM. Perhaps you are simulating a new secret drug medicine, or you are enhancing a porn video, or you are encrypting/decrypting your users post/photos, or you ar…
Your answer (3) makes sense, but wouldn't these people opt in to lift this limit? I can think of few such applications that someone would elect to run on Amazon without knowing it in advance.
do people really do (4) on amazon's hardware? (instead of their own).
In (5) are you saying that this, combined with (2) is not really possible for them technically? Why not?
It just seems trivial to me. If there are false positives you could lift the restriction out-of-band (not with your normal credentials, like the 'atm card/pin' combination.)
I know I would prefer to keep that protection in place, just as I keep my ATM daily limit in place.
They may not want to be subject to secondary liability. The most famous example is likely Playboy Enterprises, Inc. v. Russ Hardenburgh, et al., where screening for materials which infringed on copyright meant that Rusty-N-Edie's had secondary liability for the presence of infringing materials on their board. If they start an infrastructure for deep introspection of the VMes, especially for something which isn't proh…
I thought though that they did do some pretty deep stuff, like silently update for heartbleed - http://distinctplace.com/2014/04/16/openssl-heartbleed-ec2-a...
did I misread?
They may not want to be subject to secondary liability. The most famous example is likely Playboy Enterprises, Inc. v. Russ Hardenburgh, et al., where screening for materials which infringed on copyright meant that Rusty-N-Edie's had secondary liability for the presence of infringing materials on their board. If they start an infrastructure for deep introspection of the VMes, especially for something which isn't proh…
interesting idea. so running a VM is fine, but if you protect your users by sometimes checking for certain usage patterns (that they said they didn't want), you become liable for a lot more? I thought though that they did do some pretty deep stuff, like silently update for heartbleed - http://distinctplace.com/2014/04/16/openssl-heartbleed-ec2-a... did I misread?
If you check for certain usage patterns, but there's a 10% chance of failure, then will 10% of that customer base sue you for not doing the job you said you will do? Remember, you've started with the premise that there is a clear signal. Certainly it's possible to tweak any SHA calculation enough to confuse detection algorithms.
What advantage is there for Amazon to put the infrastructure in place, as compared to the current (seemingly generous) practice of revoking fees for abused accounts?
1) Your comment has an answer. 2) They can detect that the computer is running near 100%, but I guess there are a lot of legit users that use near the 100%. 3) I'm not sure of the privacy conditions, but most people would not like that Amazon peeps into their VM. Perhaps you are simulating a new secret drug medicine, or you are enhancing a porn video, or you are encrypting/decrypting your users post/photos, or you ar…
Isn't the statement "Amazon doesn't have access to the data on the instance" totally wrong? How can you 'not have access' to the data on a VM you're personally running? Your answer (3) makes sense, but wouldn't these people opt in to lift this limit? I can think of few such applications that someone would elect to run on Amazon without knowing it in advance. do people really do (4) on amazon's hardware? (instead of t…
> For Amazon EC2, AWS employees do not look at customer data, do not have access to customer EC2 instances, and cannot log into the guest operating system. AWS internal security controls limit data access.
Yes, since they have physical access to the machines, it's possible to get access. However, it's not designed with that in mind. Adding that capability would make it harder to be HIPPA compliant, which is something they want to do. Also, there's AWS GovCloud http://aws.amazon.com/govcloud-us/ for government computing which has its own level of confidentiality. It's more expensive to have 3 different infrastructures than one.
There are many whitepapers about running #3 on EC2. I think your lack of knowledge isn't a useful guide.
As for (4), my own data system does about 40 million SHA2s during a database update.
Earlier quoted context omitted.
interesting idea. so running a VM is fine, but if you protect your users by sometimes checking for certain usage patterns (that they said they didn't want), you become liable for a lot more? I thought though that they did do some pretty deep stuff, like silently update for heartbleed - http://distinctplace.com/2014/04/16/openssl-heartbleed-ec2-a... did I misread?
Well, yes, you can become liable for failure to do what you said you would do. That's what secondary liability means. If you check for certain usage patterns, but there's a 10% chance of failure, then will 10% of that customer base sue you for not doing the job you said you will do? Remember, you've started with the premise that there is a clear signal. Certainly it's possible to tweak any SHA calculation enough to c…
regarding your first point... they don't have to promise they will check for bitcoin mining by having a fraud prevention check in place. the fact that I cheerfully allow my bank to hold some transactions that look questionable to them while they verify with me, doesn't mean I will extend liability to them if they fail to hold a transaction or find it questionable. it's more a matter that they might refund me if I did not actually make a transaction (as with Amazon) so they want to cover themselves in some instances from this happening in the first place. more power to them.