search

jimmywarting / StreamSaver.js

StreamSaver writes stream to the filesystem directly asynchronous
https://jimmywarting.github.io/StreamSaver.js/example.html
MIT License
3.95k stars 413 forks source link

Warn that self hosting mitm is required #306

Closed jdarpinian closed 1 year ago

jdarpinian commented 1 year ago

Cross origin requests to the service worker are no longer working in Chrome. This means that self hosting mitm.html is now required. I don't know why it stopped working or if it could be fixed now, but it will definitely stop working when the third-party cookie deprecation finally hits because cross-origin iframes aren't allowed to register service workers at all when third party cookies are disabled.

Please add a large disclaimer to the README, and maybe some console.warn calls to alert people that this library will fail to work unless you self-host mitm.html.

jimmywarting commented 1 year ago

Hmm, i have known about the "third party cookies disabled state" for a while. i feel like there should be some way of opt-in to allow third party cookie somehow. possible with some kind of iframe sandboxing attributes

i initially develop streamsaver.js to be very hacky to have it working in the early days when https was not as common, i wanted it to work on sites that only operated in insecure modes (http) by opening a popup and then install a service worker and trigger a download. and i also wanted it to be as simple as just importing a lib without worry about having to set up a service worker on your own. that way it could also work inside of eg jsfiddle where it was not possible to install a service worker at all.

but the insecure mode is leaning towards a end so i would also like to remove all the http/popup hack. so there is also less reason for needing a 3rd party domain. and even more reason for setting up a own service worker. and skipping the hole mitm iframe, so it can talk directly to the service worker instead.

then again, StreamSaver.js, FileSaver.js, and other a-like is leaning towards a end. it's kind of being replaced with file system access and showSaveFilePicker where you are allowed to write data directly to the hard drive (with streams).

I have been thinking if it would be worth using file system access so that it dose not need any iframe or service worker at all. but then it will work completely different. you won't get any native browser UI such as download progress / cancelation functionality etc.

On another note. https://github.com/jimmywarting/native-file-system-adapter is kind of a polyfill for file system access too. and it have better backpressure support that uses a pull based operation instead. and it based upon streamsaver.js way of initiating a service worker and saving data the same way but without 3rd party domains and self hosting, the service worker is optional there. so it will fallback to using blob + objectURL otherwise.

so maybe just a disclaimer/warning is the best option while also letting ppl know that native-file-system-adapter is an better self-hosting option that dose not require a mitm iframe.