[tahoe-dev] [tahoe-lafs] #615: Can JavaScript loaded from Tahoe access all your content which is loaded from Tahoe?

[tahoe-lafs]

#615: Can JavaScript loaded from Tahoe access all your content which is loaded
from Tahoe?
---------------------+------------------------------------------------------
 Reporter:  zooko    |           Owner:  nobody   
     Type:  defect   |          Status:  new      
 Priority:  major    |       Milestone:  undecided
Component:  unknown  |         Version:  1.3.0    
 Keywords:           |   Launchpad_bug:           
---------------------+------------------------------------------------------

Comment(by swillden):

 Replying to [ticket:615 zooko]:
 > In the long run it might be possible for us to arrange to do this, such
 as by embedding a unique string, possibly the verifycap or possibly an
 incrementing string, into the domain name, or by taking advantage of some
 not-yet-created mechanism to tell web browsers "No, no, these two things
 are of different origins even though they are loaded from the same host
 and port.".

 One option is to use loopback addresses other than 127.0.0.1.  The entire
 127/8 class A is technically reserved for loopback, and so any of the
 2^24-2 (127.0.0.0 and 127.255.255.255 aren't allowed) addresses in that
 range should be usable to connect to your Tahoe node.  The node could
 issue 304 redirects to automatically shift you from one "host" to another.

 Some possible problems with this:

 (1) I don't know if all IP implementations around actually honor the
 "unusual" loopback addresses.  Linux does.  Windows appears to (at least,
 'ping 127.42.94.19' works).

 (2) Javascript implementations may know that 127.x.x.x is all the same
 host and allow cross-address connections.

 (3) It's not clear to me how Tahoe should know when to issue redirects.

 Another option is to use cookies.  A cookie can also be made specific to a
 host/domain but also to a path.  As I understand it (haven't tested),
 Javascript loaded from path A should not have access to cookies set
 specific to path B.  If Tahoe were to set per-path cookies on first access
 to a path, then refuse later requests that don't include the right cookie,
 then Javascript from path B would not be able to successfully load URLs on
 path A, because it wouldn't have the cookie.

 There are numerous downsides to the cookie approach, and the only
 advantages I see are if it perhaps works around (1) or (2) and the fact
 that it allows arbitrarily-large authentication strings.

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