I originally posted this here in crbug under the
project-fugu tag. I figured I’d cross post it here so more than just the Chrome people see it. This is my first post in this forum, so apologies if I’ve done anything wrong (I won’t be offended if my post gets deleted! haha).
This one is definitely a bit of a pipe dream, but hear me out for a second here - I think this could become especially useful when combined with the upcoming fugu file system stuff.
Imagine the following situation: You’ve got a file that you need to process, and there are a bunch of web apps out there that can do it for you, but it’s a sensitive file and you don’t trust that they’re not going to upload your file to your server and snoop on your data. For example, you might want to:
- Crop/resize/rotate your passport scan: squoosh.app
- Read a 5GB server log file: readfileonline.com
- Read your DNA data: fastq.bio
These sites (and many others like them) do all their number crunching on the client, and they assure users that all the potentially-sensitive data stays on the client. But how does the user know that they’re not lying?
As a web developer I’d love to have the ability to give my users certainty that I can’t even “see” their data at all. If this were possible, it would give web apps an advantage over native apps because (of course) the native apps could be malicious too - people just tend to trust them more for whatever reason. Adding a feature like this would extend the “trustlessness” of the web platform, which is one of its best features.
So what might such a feature actually look like? I have no idea. But here are some thoughts:
- I can write a CORS-protected image to a canvas and then draw a rectangle over the top, and then the user can right-click on the canvas to save the resulting image. The canvas has been tainted as soon as I’ve drawn the image, but the user can still download it once I’ve finished processing it. That’s the very beginnings of the sort of feature I’m talking about here, but it’s obviously no where near enough even for 99% of the image-processing web app use cases.
- This may actually just fall into the scope of the Permissions API. Websites would have the ability to revoke their own “basic” permissions, like the ability to access the internet. Undoing these revocations would cause all site data to be cleared. Some careful thought would be needed here though - for example, the “access to the internet” permission would most likely need to include within it the ability to embed iframes, otherwise users could be tricked into dragging-and-dropping their file into a frame with a different origin (one that still has the “access to the internet” permission). I imagine there are some pretty fundamental architectural considerations here.
- Even a very course-grained permissions revocation that occurs outside of the Permissions API might be able to solve this. It just “simulates” a lack of internet access for that specific origin, forever (and to undo the revocation all data needs to be cleared, as before).
- Perhaps an “opaque files” feature similar to CORs stuff could solve it. The data can be accessed, but the processed data can’t go anywhere except back to the user after the processing (like the canvas example above).