> [...] directly in the browser. The video does not leave your local machine.
It would be cool if there were a special browser badge for a website that ensured uploaded content couldn't be transmitted to the server.
Something in the spirit of `Content-Security-Policy: connect-src 'none';` (not sure if that covers all edge cases though, I'm not super familiar with CSP)
That would be very simplistic. It means that all resources you need must be inlined in the initial download. This makes it hard to balance reasonable update time and log caching, especially if you have a slowly-updating ffmpeg.wasm and a more frequently updated UI.
Maybe it could add the CSP at some point after everything is loaded and then the badge appears? Of course you still want updates, how do you ensure that updates can occur without sneaking out information? Wiping all site data before downloading the new version would work but having local persistent data would be useful. Maybe all local data would be unavailable from the start of the new version fetch to until the no-network policy is applied?
This is a pretty wild concept, not that I disagree with it.
But when you think about it, we're asking a tool originally designed to browse documents on the web, to now execute what is essentially a (safe) binary application, and not to let it connect to the internet, while inside a document in a web browser.
I can't see how the future of the desktop is not going to be radically shaped by WASM, in whatever form that takes.
Agree 100%, next few years of webapps are going to be revolutionary. WebAssembly gaming in particular is going to disrupt Steam on PC, and the App Stores on mobile. Our startup is working on this btw
I made a simple static site that processes user images and videos with WASM and it would be great for users to be certain that their data will not leave the browser. It seems possible to define some list of resources I plan on loading, and anything else should not be allowed.
Not sure that can exist separate from just being a completely "offline mode" switch. The most naïve example being doing a bunch of GETs to www.datasucker.com/Base64EncodedDataHere.
And WebSockets and WebRTC and form submissions and so on. It'd be a whole policy for many things like gp suggests not just blocking one function.
Of course that being said the policy would basically have to be "disable network" at a trigger point not just uploads as you can just as easily leak large amounts of data via triggering GETs by making img placeholders come into view or other equally tricky things that can't be distinguished from "app is just still loading".
Even just basic hyperlinking would have to be heavily restricted.
For example...
1. Cross origin hyperlinks would have to be completely disabled
2. Same-origin URLs would need all url information (query params, path, etc) to remain completely client-side. The only thing transmitted to the server would be the base domain.
Post restriction there is no such thing as allowing network requests (same origin or cross origin) without opening a side channel which can work around said restriction (e.g. timing). However pre restricted mode there is no reason to restrict anything be it same origin or cross origin.
Pre-restriction would have to disallow running javascript in that case. Otherwise an app could save data to localstorage, refresh the page programmatically (or wait for the user), and then transmit.
Or rather have the browser treat the no-network session period with private window logic where the session is deleted if the no-network browsing session ends or dies (e.g. incognito puts a virtual session data container in RAM). That would even allow the app data (prior to triggering the mode) to stay cached without risking side channels with future resource loads.
The whole premise was to return to the pre-web 2.0 days but have the option for a user to enable modern web app capabilities. Which your idea would be a step towards.
It may make some things this can do possible but ffmpeg has support for so many codecs and so many operations and is incredibly extensible that I doubt anything short of making ffmpeg available in the browser will give you that much power.
I don't know if there's a pre-existing site that will do it, but you could do this with FFmpeg and therefore FFmpeg.wasm. A brief search [1] indicates that it would likely be about the combination of the right filters. Ostensibly, you could put those filter options into the FFmpeg.wasm demo app [2] (scroll down) and get your video out.
Excellent work, thanks for sharing. I did notice an issue where transcoding will fail if the filename chosen contains a space, the transcoding will fail with 'file not found'.
WebP [1] is based upon VP8 encoding. VP8 is one of the codecs for which WebM is frequently a container. Ultimately, it's similar but achieves different objectives.
It would be cool if there were a special browser badge for a website that ensured uploaded content couldn't be transmitted to the server.
Something in the spirit of `Content-Security-Policy: connect-src 'none';` (not sure if that covers all edge cases though, I'm not super familiar with CSP)