Having spent some time deconstructing Google’s careful attempts to protect the content of their Google Print partners, it seems only fair that I also give my thoughts on how they can improve the restrictions without affecting the usability. One could argue that I shouldn’t help them with this – but then, I think people will vote with their feet when it comes to DRM-like features. And anyway, it’s an interesting technical challenge.
The best method would probably be an extension of what they are doing now. Have ten nested <div>s, each of which has a background-image set, and each of which has a near-identical URL – the only thing wrong being the signature which they already incorporate into their URLs. The “print” servlet should serve up a clear GIF when it receives a bad signature. So, given that there’s no programmatic way (short of reverse-engineering the signature algorithm) to choose between:
a user would have to resort to checking each one by hand to see which was the real image. (Or writing a specialised extension to sort through and pick out the one with the largest size.) That would defeat at least some of the methods we’ve come up with so far, or at least make things a lot slower.
But when it comes down to it, they’ll probably be content with the current clue barrier.
Update: Having now read some Slashdot comments, you could combine the above technique with image slicing (where the true image was at a different stack position in each slice) to multiply the number of possibilities. Manually searching 10 possibilities for a non-blank image would be OK. Searching 100 sets of 10 slices to find the valid strips would be a lot nastier.