Allow for serializing and deserializing a handle as a string

[slaymaker1907]

Why?

My specific use case is for self modifying HTML (single file TiddlyWiki). It would be nice to save these handles to the wiki itself (i.e. save the handle to a file to the file itself). IndexedDB introduces security problems when using file:// in addition to being much more inconvenient.

I think being able to store these in cookies/on the server also makes things easier to integrate into existing software.

Requirements

• Add a .toJSON() method to file and directory handles that returns a promise to a JSON object. This should be a promise in case the logic for serialization is expensive for a given implementation (maybe due to requiring an extra permission to serialize these handles, waiting for entropy, etc.).
• These handles should not be valid indefinitely. There should be a mechanism at the browser level like a revocation list and/or expiration dates for handles.
• Specify only that these handles are serializable to JSON. It might just be a single encrypted/random string or implementations might choose something more complex by allowing some introspection into the metadata of the handle for stuff like expiration times, domain associated with the handle, etc.
• Mandate that only information already available via JS to the requestor of the handle be stored in the handle to avoid information leaks. i.e., do not store the absolute path to the file in unencrypted form in the handle. However, domain is obviously ok since that is trivial to determine for the requestor of the handle.
• Require enforcement of domain for deserialized handles to avoid inadvertent privacy/permissions leaks. If a site were to store these handles on a DB, these handles should only be useable from the origin domain.

Implementation Ideas

• Generate a large, secure random number as an ID and store metadata about the handle in the browser. This has the advantage of allowing users to see what sites have which handles. Obviously only generate this ID if toJSON is called for a particular handle to avoid storage bloat.
• Serialize the raw handle including full path, origin, etc. and then encrypt this data and use a mechanism like JWT. Any encryption mechanism would want to take care to prevent leakage of privacy by preventing attackers from knowing that two handles were issued by the same browser. These handles could be time limited and in combination with a revocation list (probably tracked with an origin and time so that the list does not grow indefinitely and since tracking individual handles may be difficult).

Security

• As discussed above, this proposal does not suggest or recommend allowing general serialized handles to bypass the same origin policy already in place for file handles.
• Attacks going after weak encryption methods is not a huge risk since there is no guarantee that deserialized handles will work. If an encryption method was compromised, browsers could simply switch to a new algorithm and drop support for the compromised algorithm. There is no need or reason to support arbitrary encryption mechanisms.
• Privacy is probably the biggest issue, but I think these issues can be controlled and mitigated.

[pmario]

As a user, why should I want, that a file handle from my harddisk is stored on a server? Encrypted or not. If I store content locally, everything needs to be locally. No info goes to the server. nothing - never!

[slaymaker1907]

https://github.com/slaymaker1907/TW5-browser-nativesaver is why. It is specifically extremely useful for self modifying HTML on the local file system.

If you actually read my proposal, you would note that there are no additional privacy/security implications since any data exposed by these handles must either be invisible externally or already easily available to the site in question. I would expect these handles to get invalidated by browsers at the same time as IndexedDB and/or localStorage.

The only thing this should enable is avoiding the horrific IndexedDB APIs (look at my reference code and note how much is devoted to IDB nonsense) and giving slightly more flexibility.

[ftreesmilo]

I'm not really sure this makes sense... the server has no use to store that string... and could cause issues if the handle is saved and associated with a user account. If they use another device to access the server the handle would be useless on the new device.

in any case, if the wiki files are saved in a folder that you request access to, all these file references can be re-created by traversing that folder when they open your app the next time.

[mkruisselbrink]

I'm not sure I understand the benefits this has over the current system where you can store handles in IndexedDB? We'd probably have to invalidate all such created serializations at the same moments in time where currently IndexedDB is cleared, so websites could just as well maintain a mapping of random string to handles in IndexedDB themselves. I don't think there is much benefit in the browser providing this mapping.