Hacker News Reader

Comment by OzzyB | Hacker News Reader

+1 For Amazon for kindly reimbursing the overage charge.

-1 For Google for creating what is the biggest threat to content providers by enabling easy-to-use DDOS attacks across the entire interwebs.

</hyperbole>

Seriously, is this what we have to look forward to when Google Spreadsheets, and God knows what else, become ever-more popular?

Think about all the additional onerus costs that would be incurred by content providers as more and more Google Spreadsheet users hotlink images, mp3s, videos...

This has to be a bad design decision by Google, there's no need to redownload assets by-the-hour, on-the-hour, regardless of whether the user's spreadsheet is open or not.

Is it time to go back to the days of putting your web assets behind $HTTP_REFERER?

View on HN

It's not a DDOS becuase it's not distributed and there was no denial of service. And it doesn't work "across the entire interwebs" because the Google bots are rate-limited against most websites. There are some whitelisted sites, like S3, that are not rate-limited. S3 did not go down in this "attack". In fact the app didn't even go down. So the decision not to rate-limit against S3 was sound, since there was no DDOS.

Are you saying Google isn't distributed?

In any case, it may not be a denial-of-service, but if you can find someone with an S3 bucket with large files you could maliciously cause them to rack up a huge bandwidth bill using this mechanism. I guess you could say it's a DDOM (Distributed Denial of Money).

lol I'll take DDOS any day over DDOM!!

Ironically, it might be DoS in the sense that it drives app maintenance costs so high that the owner could decide to, naturally, deny the service (shut down).

Otherwise, maybe it's the new type of flood attack, cost-of-service (CoS), applicable against those who use ‘invincible’ cloud infrastructure such as Amazon's.

Is that a term? "Cost of service attack" ? If not, let's coin it :)

Cost-of-service-attack: Consuming bandwidth or other resources in cloud based solutions to drive up the cost of running the service.

Very easy when the cost is so tightly coupled with the resource use...

OK, so now we have DoS and CoS!

I dunno though, it's all technically bandwidth flood in the end. The consequences (or goals) of flood may include immediate or eventual denial of service, high cost of service, various security attacks, or probably all at once—further classification surely is complicated.

Meanwhile, both terms DoS and CoS are a bit vague, too. Say, turning off a server or forcing providers to alter their DNS records more or less qualifies as denial of service attack (which, by Wikipedia's definition, is “an attempt to make a computer or network resource unavailable to its intended users”).

I wold argue that "DoS" is not vague, just a broad term.

Aanyway.. You're right, it boils down to bandwidth flood (or maybe CPU..) in the end.

Maybe CoS is not really a technical term, just made more relevant by the technological changes. OP would have been charged much less had he not been using "the cloud".

Lets say I have small'ish competitor hosting their app on EC2. Using classical DoS techniques, how much can I ramp up their bill before they notice? Or can actually stop it? What if I run it on a smaller scale, "just" doubling their bandwidth bill.. Will they notice? Maybe they'll believe it's extra users ;)

Maybe Amazon should add smart log mining ?

If it requires a lot of effort to productize, Amazon could potentially offer it as a service $0.5/hr to ensure you are not making major goof ups.

I believe this kind of attack is already referred to as EDoS (Economic Denial of Service/Sustainability) - basically killing of a service through bankruptcy.

This is why most cloud services have a customisable limit on how many virtual servers can be booted automatically, a solution is yet to be found for protecting S3.

Thanks..

"[snip]..one might envision that instead of worrying about a lack of resources, the elasticity of the cloud could actually provide a surplus of compute, network and storage utility that could be just as bad as a deficit"

http://rationalsecurity.typepad.com/blog/2009/01/a-couple-of...

Like the author notes, I don't think the problem was with Google. It was no fault of theirs. The reason: It's a fine line between maintaining privacy policies and managing such events. If google were storing/caching these links, there would have been an outcry from those worried about user privacy and stuff.

About the by-the-hour downloads, well there again is a trade-off between providing data quickly and doing a lazy evaluation.

I think, as the author notes, it was just an unfortunate event that was a consequence of good design decisions gone bad circumstantially and wreaking havoc for the author.

It was certainly nice of Amazon to have made that refund. The resources (read bandwidth) were used after all.

I don't understand the privacy concern - a publicly accessible URL doesn't offer any privacy. It's the same as a transparent proxy.

I think it is primarily a legal concern. Legally, caching public content is not always an acceptable (or at least clear-cut) practice. I concur in thinking that's a little silly, but enough people disagree for it to be an issue that Google has to take into account.

There have been similar complaints about attempts to aggregate the contents of Hacker News posts, for example.

A password works by there is a piece of text that only you know, and thus, when you give that password to a server, that server knows who you are.

can't you also view a url as a password? (If only I know the url, then only I can download the file).

I am able to give out a url to someone else, so they can access the file, likewise, I can give out my file server's username and password, and whoever has it can also access my files.

You have a point, but the difference is that url's are not usually considered secret and are therefore not treated the same way a password would be. For example in the browser..

Google is already storing urls to those files.

Google are presumably storing/caching these photos for an hour before expiring and redownloading them.

I don't see why Google don't redownload them using If-Modified-Since, and reusing the original downloaded photos in the case that the origin server says they've not changed.

> If google were storing/caching these links, there would have been an outcry from those worried about user privacy and stuff.

Where would we be without Google taking such a noble and strongly principled stance on user privacy, applied equally and consistently, striving to avoid legal responsibility, even when it costs unrelated parties thousands of dollars.

Come on, really? This is clearly an edge case they simply didn't see and will probably solve once the right people know about it. The sky may be falling, but it's not because of Google Spreadsheets...

> -1 For Google for creating what is the biggest threat to content providers by enabling easy-to-use DDOS attacks across the entire interwebs.

Wanna help make the web better? Stop using Google and use a competitor like DuckDuckGo.com. Google has too much power, too much control.

Reply on news.ycombinator.com