Uzair Farooq:
>> - Some aspects of the download as done by the current extension would
>> also be affected by Web Extensions, especially the pausing and resuming?
>
> Chrome have support for resume/pause.
>
> If we handle download ourself, we can
> also pause/resume programmatically. One thing to note though, Chrome
> does not allow resume after browser is closed.
Meta: I'm putting Uzair Farooq in explicit copy now. He's the freelancer
interested in porting DAVE to WebExtensions. Welcome Uzair!
Regarding resuming, let's differentiate three scenarios:
- *Pause* -- the user intentionally pauses the download:
- Chrome: works and easy to find
- Firefox: works but harder to find (right-click)
- Tor Browser: works but harder to find (right-click)
- *Interruption* -- the download is interrupted by a network failure:
- Chrome: doesn't work
- Firefox: doesn't work without DAVE, should work with DAVE
- Tor Browser: doesn't work even with DAVE because of:
https://labs.riseup.net/code/issues/10686
- *Restart* -- the browser is restarted
- Chrome: doesn't work
- Firefox: doesn't work without DAVE, works with DAVE
- Tor Browser: doesn't work even with DAVE because Tor Browser is
amnesic.
>> - It would be less coding work to decide to remove the download part
> from the extension instead of porting it to Web Extensions and Chrome?
>
> Yeah, without the download it'd be less work.
Ok, that's important as well.
So, merging here the other technical details that anonym and Uzair
exchanged off-list we have to choose between the following two options.
Uzair, please correct me if I get some technicalities wrong!
Option A. Keep the download inside DAVE relying on the File and
Directory Entries API [1] which gives access to a virtual, sandboxed
file system:
1. DAVE downloads the ISO into the sandboxed file system.
2. It verifies the ISO.
3. After the verification succeeds, it asks the user where to save
the ISO in the real file system.
[1]:
https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API
- Pros:
- Less UX work and redesign of the web interface. Still, users would
be asked where to save their download *after* the download finishes
so some details might change. I haven't thought of this much...
- Better resume experience *only* when downloads are interrupted by a
*network failure* on Firefox and Chrome (not Tor Browser):
- The resume experience is not better than option B when the
*browser is restarted* because with this API we're in a virtual
file system only in memory so I understand that it's lost when
the browser restarts.
- When people want to *pause and resume manually* we're not
offering more possibility that the vanilla download. Still, we
might be able to provide a slightly better UX for Firefox where
this feature is harder to find.
- Cons:
- We're downloading in memory so users need ~1GB of RAM to download.
- We're downloading in memory and don't really know how browsers
behave with ~1GB in memory.
- The UX of downloading might be weird if everything happens in a
sandbox while users expect stuff to happen on their real file
system.
Option B: We move the download outside of DAVE and rely on the vanilla
download mechanism of the browser.
- Pros:
- Less code at the end in DAVE.
- Less coding work overall when doing the port.
- Probably less code at the end in the web interface.
- We're sure that would work fine.
- Cons:
- More UX work and more coding work on the web interface:
- Redesign the steps of DAVE, removing the download.
- Redesign the workflow of the installation scenarios to force
people to verify. See [2].
- Worse resume experience when downloads are interrupted by a network
failure on Firefox and Chrome (not Tor Browser).
[2]:
https://mailman.boum.org/pipermail/tails-ux/2017-May/003385.html
We basically, we have:
- A cool idea (option A) that might or might not work well, would be
more work for Uzair and less work for me and would be nicer in case
of network interruptions.
- A safe bet (option B) that will work, will be more work for me and
less for Uzair and that will degrade a bit the UX on network
interruptions.
I would say we should do option B. But I would like:
- More UX comments on option B.
- More technical review of the implications of option A.
- anonym and Uzair to check carefully what I'm saying here :)
