> What I find fascinating in this setting is that Google becomes such a powerful weapon due to a series of perfectly legitimate design decisions.
It does have a certain "perfect storm of good intentions" quality, but no, "prefetching" hundreds of gigabytes worth of images that the user is not looking at right now* and that will not be cached for the next time the user views it, that the user did not indicate will be changing frequently or have recently changed, and doing it every hour on the hour (according to timestamps in a screenshot), is not a "perfectly legitimate" design. Calling it that implies IMO that there is nothing Google should change about this (maybe the author does not mean that.)
Maybe I or the author are missing something here -- why did Google think it was necessary to fetch something that will not be immediately shown to the user nor will it be cached for later? I can understand the no-caching decision, but then why fetch at all if it's not needed now? Why is 1 hour supposedly short enough for some hypothetical user that wants their spreadsheet's embedded images to update automatically, but long enough to not cause damage (wasn't long enough in this case)? And I hinted at "on the hour" above because it seems like some sort of staggered refreshing would be better on the CPUs and networks involved, though it wouldn't make a difference to the author.
Even if for some reason they think fetching this aggressively and wastefully is good, it seems like it's in Google's own interest to have some kind of safety valve (bandwidth restriction, hard abort, something in between) after a few hundred megabytes on one spreadsheet's refresh cycle. If nothing else, that omission means it probably wasn't a "legitimate" design decision.
Wild theory: the author was accidentally causing the refresh somehow (or maybe purposely automated but forgotten.) Somehow it seems more likely than Google setting it up this way on purpose...
* I'm kind of assuming here, but the author doesn't mention anything like he was actively viewing the spreadsheet while the attack was happening. Even if he had it open (and with all the image-linked cells in view!) for hours on end, I stand by my other points that it's strange and not a perfect design for Google to auto-refresh in this fashion.
I'm gonna test it out on a much smaller scale, and slightly different setup. I just grabbed 3 images from a rarely used server hosted with DigitalOcean, with a custom domain, and put them in a new Google Sheet using the same =image(url) technique the author mentioned. The access logs show Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)" grabbed each of the images once immediately which makes sense. I'll check back in a few hours and see if there are any other requests.
Edit: I also grabbed 3 different images and put them in a separate sheet. I'm gonna leave one open on my desktop and not open the other and see if that changes the requests.
One Hour Later: I think that Google is probably grabbing images On-Demand now. There are 12 total requests on my 6 images. The first 6 are sporadic, which correspond to when I added the images to the sheets. Then the next 3 are in the same second, which come from opening the sheet on my desktop. And the last 3 also came in the same second, again from opening that sheet on my desktop. I kept one open and closed the other and neither have had the images requested since.
I'm pretty sure they fixed it. I don't remember whether that was already in the original discussion of this story or a little bit later, but I remember the comment that one can't use it anymore as an attack tool since the feedfetcher behaviour changed.
It does have a certain "perfect storm of good intentions" quality, but no, "prefetching" hundreds of gigabytes worth of images that the user is not looking at right now* and that will not be cached for the next time the user views it, that the user did not indicate will be changing frequently or have recently changed, and doing it every hour on the hour (according to timestamps in a screenshot), is not a "perfectly legitimate" design. Calling it that implies IMO that there is nothing Google should change about this (maybe the author does not mean that.)
Maybe I or the author are missing something here -- why did Google think it was necessary to fetch something that will not be immediately shown to the user nor will it be cached for later? I can understand the no-caching decision, but then why fetch at all if it's not needed now? Why is 1 hour supposedly short enough for some hypothetical user that wants their spreadsheet's embedded images to update automatically, but long enough to not cause damage (wasn't long enough in this case)? And I hinted at "on the hour" above because it seems like some sort of staggered refreshing would be better on the CPUs and networks involved, though it wouldn't make a difference to the author.
Even if for some reason they think fetching this aggressively and wastefully is good, it seems like it's in Google's own interest to have some kind of safety valve (bandwidth restriction, hard abort, something in between) after a few hundred megabytes on one spreadsheet's refresh cycle. If nothing else, that omission means it probably wasn't a "legitimate" design decision.
Wild theory: the author was accidentally causing the refresh somehow (or maybe purposely automated but forgotten.) Somehow it seems more likely than Google setting it up this way on purpose...
* I'm kind of assuming here, but the author doesn't mention anything like he was actively viewing the spreadsheet while the attack was happening. Even if he had it open (and with all the image-linked cells in view!) for hours on end, I stand by my other points that it's strange and not a perfect design for Google to auto-refresh in this fashion.