[tahoe-dev] [tahoe-lafs] #127: v (was: Cap URLs leaked via HTTP Referer header)

[tahoe-lafs]

#127: v
-------------------------------+--------------------------------------------
 Reporter:  warner             |           Owner:           
     Type:  defect             |          Status:  new      
 Priority:  major              |       Milestone:  undecided
Component:  code-frontend-web  |         Version:  0.7.0    
 Keywords:  security           |   Launchpad_bug:           
-------------------------------+--------------------------------------------

Comment(by zooko):

 I don't really understand those options very well or how they would be
 implemented in Tahoe-LAFS.  I should mention another option: moving the
 cap from the URL itself into the URL fragment, as Tyler Close's web-key
 does: http://waterken.sourceforge.net/web-key .

 This would certainly prevent caps from leaking into the Referer header,
 although they might still leak due to tools like "Yahoo Toolbar" and the
 like.  (Tools which send all the URLs that you view to some remote server
 for you.)

 Also, as Brian wrote in comment:8, it isn't clear how Tahoe-LAFS could use
 caps-in-fragments for purposes other than displaying the result in on a
 web page.  Perhaps there could be a two-layer design where the WAPI has
 caps in URLs (which is consistent with the REST paradigm), but a new WUI
 (which would be written in JavaScript, Cajita or Jacaranda) would somehow
 translate between caps-in-fragments and caps-in-URLs so that the URL that
 actually appeared in the URL widget would always be caps-in-fragment.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/127#comment:18>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid