|
|
|
|
|
by ethbr1
2 days ago
|
|
Is it really that complicated? Why not just create per-domain browser-controlled folders (cert-linked?) that are abstracted into a simple read/write API via the browser (with subfolders allowed under that domain's root), disallow cross-domain access... and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)? So essentially local storage with better integration with the actual filesystem, that's browser-controlled. Allowing websites to have arbitrary (even user-approved) access directly to the real filesystem seems like a bad idea, when most use cases could be handled by a browser-mediated filesystem-like abstract view. |
|
This part already exists, that's the "Origin-private file system".
> ...and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)?
That's pretty much what the directory picker is - or would have been. Apparently it doesn't satisfy the security worries of some.