7 ms·

+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 DDO

by OzzyB 14y ago

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

hm8 14y ago
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.
- mooism2 14y ago
  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.
- ricardobeat 14y ago
  I don't understand the privacy concern - a publicly accessible URL doesn't offer any privacy. It's the same as a transparent proxy.
  - yew 14y ago
    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.
  - andrewreds 14y ago
    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.
    - gizzlon 14y ago
      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..
    - piaskal 14y ago
      Google is already storing urls to those files.
- tripzilch 14y ago
  > 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.
sp332 14y ago
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.
- eridius 14y ago
  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).
  - genu1 14y ago
    lol I'll take DDOS any day over DDOM!!
- goblin89 14y ago
  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.
  - gizzlon 14y ago
    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...
    - goblin89 14y ago
      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”).
rapind 14y ago
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...
whackberry 14y ago
> -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.

by OzzyB 14y ago

hm8 14y ago

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.

mooism2 14y ago
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.
ricardobeat 14y ago
I don't understand the privacy concern - a publicly accessible URL doesn't offer any privacy. It's the same as a transparent proxy.
- yew 14y ago
  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.
- andrewreds 14y ago
  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.
  - gizzlon 14y ago
    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..
  - piaskal 14y ago
    Google is already storing urls to those files.
tripzilch 14y ago
> 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.

sp332 14y ago

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.

eridius 14y ago
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).
- genu1 14y ago
  lol I'll take DDOS any day over DDOM!!
goblin89 14y ago
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.
- gizzlon 14y ago
  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...
  - goblin89 14y ago
    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”).

rapind 14y ago

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

whackberry 14y ago

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