Ideas on future perspectives.
When the file system is mature enough, its root will be accessed directly by
instead of by
/root/. In order to achieve this, some key elements of the tree
will have to be self-hosted, like the Pencil and the Gateway. This means we
will have figured out a way to know when to send files directly and when to open
them through file tree plugins.
EDIT: This was done as of 2012-04-04.
The current Operational Transformation in use (apart from being buggy) uses up a lot of space on the server side (we have to store a copy of the file for each client editing it, which makes a lot of copies!), and the transformation operation used (patch) is quite expansive CPU-wise.
We intend to use finer Operation Transformations such as those devised in Xerox
PARC . We may add information as we go, since those algorithms have been more
heavily understood and optimized since then. We will document our effort in
relevant documentation files (probably along
EDIT: This was done as of 2012-04-18. Special thanks to [Tim Baumann] (https://github.com/operational-transformation/ot.js).
We wish to have the following functionalities:
- Run some programs (such as compilers) as an FFI.
- The program cannot see or go above the root directory.
- The program is limited in time and memory.
- (Future requirement:) The program cannot modify password-protected files without input from the user.
- Use chroot
zsh, for that matter) (Is that really useful? Can we run
bashfrom there? Through vi?)
- Use a custom
rcfile that resets all shell variables.
ulimitin that bash
- Can this be cross-platform? The above ideas are Unix-only.
We get a salt from the server. We send a PBKDF2ed SHA256 key from the passphase the user enters. On receiving the SHA, the server makes it go through another PBKDF2, and compares it to its own sha. If they match, it decodes the AES256-ciphered data with the SHA it got (not the one it computed). The resulting file is sent in clear to the client.
The reason why the client only sends the SHA256 is to prove that we do not store keys in the clear. It is a PR force with no real value, since we already are under https.
We absolutely need TLS (otherwise the whole security system crumbles down). We can get it free from StartCom, whose root certificate is in Firefox (and probably everywhere else, too).
Reasons that design cannot succeed.
That design isn't aware of the Read/Write access differences that we want, instead encrypting all the data, even if unnecessary. This results in a lot of encrypting / decrypting that doesn't need to be there.
Beyond taking a lot of CPU cycles, it also takes a lot of effort to engineer, mainly because all of the system needs to be implemented at once.
Besides, having the key both encrypted in a PBKDF2 and used in encrypting the data raises differential cryptanalysis concerns.
Finally, the use of PBKDF2 is slower on a CPU than on a GPU, allowing advanced code breaking techniques to brute-force the key fast: increasing the number of iterations makes normal use have an increase in execution time that is a lot smaller for code breaking use.
Metadata access and write access requires the following:
- Put OT support in the File System library.
- Provide deniable access to file system primitives.
Read access requires more engineering (and a little bit more design effort).
Users can restrict metadata modification by using a passphrase. That
passphrase's hash is stored with scrypt in the file's metadata, under the name
metakey. Without the key, users can view all metadata but the keys. With the
key, they can modify the metadata.
A request for editing the metadata will follow these steps:
- Get the key from the user.
- Send the key in the
metakeyfield of a server-side request to
/$meta-save, protected by HTTPS, with the modifications, or through the Authorization HTTP header field.
- Get the scrypt of that key, using the salt and iteration count indicated in
metakey. Authorize an unlimited number of tries, with a second wait between each try.
- If the hash we got is the same as the one that is in
metakey, the modifications get applied. Otherwise, they are denied.
Users can restrict write access by using a passphrase. The system knows that a
file has a write access restriction if the file's metadata has a non-empty
writekey field or the first parent folder that has a
readkey fields is
non-empty. That passphrase is stored with scrypt in the file's metadata, under
A request for read access always succeeds. That property makes encrypting the data greatly useless.
Any request that modifies the contents of the data, without including a
writekey field with the correct passphrase, will fail. The operational
transformation system will forbid modification.
Without a correct write key, the user is granted read-only access.
Users can restrict read access by using a passphrase. The system knows that a
file has a read access restriction if the file's metadata has a non-empty
readkey field or the first parent folder that has a
readkey field is
non-empty. That key overrides the write key; the
writekey field becomes
readkey works similarly to how the
writekey works, except that it won't
give read-only access if the supplied password doesn't match the stored scrypt
hash. Accessing those files either requires a
readkey or an
HTTP header, the latter of which is made easier by the fact that sending an
incorrect key causes serving this page through
Also, the files are all encrypted using the standard scrypt system. They are decrypted and stored in memory while editing.
Note that this means that users have to wait for the file to be decrypted before they can start editing it.
User-Space File System
Create a proper distributed file system, using a flexible protocol over a secure websocket connection. We should have two main frames: content and delta. Think of them as I-frames and P-frames in video encoding.
We should construct a user-space filesystem through FUSE. Make metadata work fast (load it all up in memory at startup?) and more flexible (use the SET file format instead?) so that we can actually annotate the metadata with comments. Of course, we would prettify it on every disk write.
Allow a user to fork a file. That FS-level operation forces the system to keep track of all changes made to that file. Once done, the user can join back to the origin file. The system should prevent conflicts from ever happening (which is theoretically possible).