It's way too easy to give away write directory caps

[jsgf]

The WUI makes it too easy to accidentally give away the write directory caps for a directory. The most obvious thing to do - cut'n'paste the URL - is the worst thing to do. If you want to give a RO directory cap to someone else, you need to make a fairly explicit extra step to do so.

I don't know how to address this, but here are some thoughts:

1. Add an obvious "share this directory" button which pops up a pre-selected cuttable RO URL, in order to try and make the right thing the most simple and obvious.

2. Use cookies to maintain some per-session state, and use that state to mangle the cap in the URL, to prevent it from being accepted by any other web gateway/WUI session. Unfortunately without some strong crypto in the browser this will not prevent the URL from being accidentally shared unless the user notices it has been mangled before sending it.

3. Erm, something else?

[jsgf]

Adding some kind of distinctive graphic or colour cue to the WUI to indicate whether you're looking at the RW or RO cap might help too...

[jsgf]

Perhaps the best thing would be to add a nice obvious "share" button whose default action is to create an immutable snapshot of the directory and offer that URL for cut'n'paste. An immutable snapshot is the safest thing for people to share, since the current state is all the recipient will ever see, and there's no risk of accidentally leaking future changes without realizing it. More risky share options should be available of course, but they should take an extra step to achieve.

[jack.lloyd]

Alternatively, only show the RO/immutable cap by default, requiring the user to do something special to see the RW cap at all. Unclear how badly this will break standard user use flow.

Using colors to signal OK/DANGER seems like a definite win. Even better(?), use Javascript (or standard HTML/CSS, if it's possible) to overlay "Read-write capability; giving this to someone will allow them to edit your file/directory" and "Read capability; giving this to someone will let them read your file/directory" on mouse-over (in addition to colors, that is).

[jsgf]

Replying to jack.lloyd:

Alternatively, only show the RO/immutable cap by default, requiring the user to do something special to see the RW cap at all. Unclear how badly this will break standard user use flow.

That's not a bad idea, but I'm not sure how it would work. Given that you can't derive a write cap from a read cap (one hopes!), the UI would somehow need to carry along all the write caps under the covers so it can provide them if necessary.

[toby.murray]

What about when navigating to a RW directory cap, the WUI sets a cookie containing the RW directory cap, then navigates the user to a generic URI on the web node whose job it is to read the value of this cookie and then display its contents as usual. This would allow one to view RW directories but would prevent the RW cap appearing in the addresss bar.

One could then add 'share RW' and 'share RO' buttons to the WUI which would then display the relevant URI for the user to copy-paste. The 'share RO' button could be made more prominent, perhaps, than the RO button, so that 'sharing RO' is easier to perform than 'sharing RW'.

[davidsarah]

Replying to toby.murray:

What about when navigating to a RW directory cap, the WUI sets a cookie containing the RW directory cap, then navigates the user to a generic URI on the web node whose job it is to read the value of this cookie and then display its contents as usual. This would allow one to view RW directories but would prevent the RW cap appearing in the addresss bar.

Cookies are problematic because they get sent to all pages within that origin (which is all WUI pages for that gateway). A JavaScript-based UI, OTOH, could fix both this bug and #615 at the same time, if it avoided cookies and used XMLHttpRequest to get the directory contents. (It might be desirable to use the technique suggested in ticket:615#comment:8 to completely fix #615 and #821.)

One could then add 'share RW' and 'share RO' buttons to the WUI which would then display the relevant URI for the user to copy-paste. The 'share RO' button could be made more prominent, perhaps, than the RO button, so that 'sharing RO' is easier to perform than 'sharing RW'.

I don't see any reason not to put a RO-shareable URI in the address bar. That's easy to do in a JavaScript UI, for example by putting the cap in a fragment so that it doesn't cause a page reload (​http://maps.yahoo.com uses this approach). Putting the cap in a fragment also fixes #127 and #907, without any loss of usability.

[davidsarah]

Replying to davidsarah:

I don't see any reason not to put a RO-shareable URI in the address bar. That's easy to do in a JavaScript UI, for example by putting the cap in a fragment so that it doesn't cause a page reload (​http://maps.yahoo.com uses this approach). Putting the cap in a fragment also fixes #127 and #907, without any loss of usability.

I also meant to point out that RW URIs are still shareable in this approach: if the fragment contains a RW URI, the script would immediately change it to a RO URI in the address bar, but remember the original URI for use in XMLHttpRequests.

(This part of the script should be included directly in the document <head> so that it loads quickly even when not cached.)

I've just been looking at the implementation of Toby's ​Tahoe Explorer. It seems very well-written and quite suitable to be included in Tahoe proper, so that we could adapt it to be a more secure replacement for the existing WUI.

However, it depends on Cajita which is under the ​Apache License, Version 2.0, which is ​not GPLv2-compatible. It is GPLv3-compatible in the direction we need, but either Tahoe would need to change to GPLv3 (or include an exception to allow linking with the Cajita runtime), or Caja/Cajita? would need to change to be GPLv2/Apache dual-licensed. How irritating :-(

[davidsarah]

Replying to davidsarah:

However, [Tahoe Explorer] depends on Cajita which is under the ​Apache License, Version 2.0, which is ​not GPLv2-compatible.

Submitted as a Caja issue ​here. (Even if we change our license to work around this, I still think the Caja license is overly restrictive for the Cajita runtime.)

[davidsarah]

On closer examination, Tahoe Explorer depends on Cajita only to the extent of using cajita.forOwnKeys and safeJSON. I have a version working without Cajita. I'll open a ticket to add it to Tahoe.

[davidsarah]

Replying to davidsarah:

I'll open a ticket to add [Tahoe Explorer].

See #1000 (yay, I bags that ticket number! :-)

[zooko]

Replying to davidsarah:

I've just been looking at the implementation of Toby's ​Tahoe Explorer. It seems very well-written and quite suitable to be included in Tahoe proper, so that we could adapt it to be a more secure replacement for the existing WUI.

However, it depends on Cajita which is under the ​Apache License, Version 2.0, which is ​not GPLv2-compatible. It is GPLv3-compatible in the direction we need, but either Tahoe would need to change to GPLv3 (or include an exception to allow linking with the Cajita runtime), or Caja/Cajita would need to change to be GPLv2/Apache dual-licensed. How irritating :-(

Nowadays we have the special exception to allow linking with Apache-licensed components:

• COPYING.TGPPL.html
• COPYING.GPL​

[zooko]

A user accidentally pasted a cap to private data to IRC just now. It wasn't a directory, and they hadn't intended to give away read-access at all, but they accidentally gave away read+write access. The fact that the file happened to be mutable (which it arguably shouldn't have been since the content wasn't intended to change) was the only saving grace -- the user was able to overwrite the file in order to remove the original data from public access.

The contents that were originally in the file were apparently BitCoins which are inherently valuable, so the user was glad to be able to hide them.

[gdt]

One could also argue that people needing to use the WUI rather than mounting tahoe into the host is a significant part of the problem. Generally in cryptographic systems one tries to keep users from handling keying material. On Unix-like systems a FUSE implementation (or the existing sftp support) would work, but I don't know if FUSE works on windows.