smaller XSRF attack still possible

[warner]

It occurred to me that, despite the show-all-files-by-URI change we made to protect the private-vdrive URI from referrer headers and active javascript attacks, that there is still one remaining: the URI of the HTML file itself.

Let's say that you write a secret HTML document and upload it to the grid, attached to some directory in your private vdrive so nobody else can see it. In this document you include an HREF to mysuperevilsite.org, because it's really cool. When you use your tahoe node's web server to read that document, it will serve it to you as /uri/RANDOMURI, and when you follow that HREF to the super evil site, I (as the operator ot mysuperevilsite.org) will see a Referrer header with /uri/RANDOMURI in it. Then I fire up my own tahoe node and get to read your secret document.

Alternatively, once you're viewing a page from the evil site, I can put javascript in that page which uses your tahoe node to read /uri/RANDOMURI and do something clever to get the data back to me.

I'm less concerned about this one than the previous attack (#98), but it would still be nice to find a way to fix it. I can't think of any clever solutions, though. Note that the javascript attack means that (like with all confused deputy attacks) somehow encrypting the URL wouldn't help (since ambient authority can still be exploited by the attacker).