In response to anonym's suggestion
What about this:
> 1. DAVE downloads the ISO into a sandboxed file system (
> https://developer.mozilla.org/en-US/docs/Web/API/File_and_
> Directory_Entries_API) in the background
> 2. then it verifies ISO,
> 3. if verification succeeds, then it presents the ISO download (from the
> sandboxed file system) to the user, so they can decide where to place it
> via the Download dialog (which result in a local copy/move of a file, since
> the ISO already is downloaded).
> This would only slightly change the UX: only the timing of the Download
> dialog changes from the PoV of the user. It'd also give users less control
> of disk usage, since this sandboxed filesystem (where the download happens)
> probably is some temporary directory decided by the browser. I still think
> that it is acceptable. What do you think, sajolida?
> So, is that solution technically possible, Uzair?
Well, in theory the solution is possible. We can send an xhr request to
download the ISO and save it in the sandboxed file system. One thing to
note is that the xhr request is gonna keep data in memory until the request
completes so I'm not sure how browser will behave with such a large data in
memory. The fetch api supports streaming but it's only supported in chrome.
Also, there won't be any resume support (we can probably build our own
resume support but this would require changes in server(download mirrors)
as well) .
On Sun, Jun 4, 2017 at 5:08 PM, Uzair Farooq <uzairfarooq11@???>
wrote:
> > - 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.
>
> > - 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.
>
>
> On Wed, May 31, 2017 at 8:54 PM, sajolida <sajolida@???> wrote:
>
>> We are looking into porting DAVE (the Firefox extension behind
>> /install/download) to Web Extensions. This would be required for it to
>> keep working on Firefox in the future and would also make it easier to
>> port it to Chrome.
>>
>> We contacted a freelancer to do this job and he pointed out the fact
>> that Web Extensions or Chrome Extensions are not allowed to read back a
>> file once it's downloaded (we rely on this to compute its hash). And
>> that the only way to read back that file would be to let the user select
>> it through a file chooser widget.
>>
>> I think that this new limitation could lead us to rethink quite in depth
>> what this extension does and how it is integrated in the installation
>> instructions. Hopefully things would not become more complex overall.
>>
>> Moving the download out of the extension
>> ========================================
>>
>> For example, in the current implementation, the download is handled by
>> the extension partly because it then allows the extension to know which
>> file has to be verified. If the user has to select the file again
>> anyway, then the download part could be removed from the extension and
>> done by the user through the native interface of the browser.
>>
>> Another benefit from having the download handled by the extension is the
>> nice way to pause and resume the download, even across mirrors. This is
>> especially useful since it's a huge download. For example, on the Tor
>> Browser shipped in Tails 3.0~rc1 I couldn't find a way of doing this
>> from the native download interface of Firefox. I don't know the
>> situation with Firefox (and not Tor Browser) or with Chrome and I should
>> check.
>>
>> But if we could rely on the native browser interface to pause and resume
>> the download, then I wouldn't mind removing it from the extension.
>>
>> Anybody else knows how pausing and resuming work in Firefox and Chrome?
>>
>> Making sure that people verify their download
>> =============================================
>>
>> Another important aspect of the current extension is that it forces you
>> to do the verification because it's an automatic step after the
>> download. If the verification become an extra manual step, how could we
>> prevent people from missing it, skipping it, etc.?
>>
>> Downloading the ISO image is always the first step in an installation or
>> upgrade scenario, for example:
>>
>> https://tails.boum.org/install/win/usb/
>>
>> So we could either:
>>
>> - Find some mechanism to hide the following steps until the
>> verification is successful. Note that we would then have to adjust
>> step 3 in which we are telling people to visit the same page from
>> another device.
>>
>> - Split the download step in a separate page and only point to the full
>> instructions once the verification is successful.
>>
>> But none of this sounds very complicated.
>>
>> Reopening the instructions
>> ==========================
>>
>> The last interesting aspect of the current extension is that, even if
>> you close your browser and come back to the instructions some hours
>> later, the extension still displays the local path of the ISO image and
>> that it has been verified. We thought that displaying the path would be
>> helpful for people to be able to find it back later on when they need to
>> give it to Tails Installer. If the download was not finished or
>> interrupted, then the extension proposes you to resume it.
>>
>> I wonder if this would still be possible with Web Extensions...
>>
>> Not trying to do everything at once
>> ===================================
>>
>> So we could do many things... But still I wonder what would be the
>> minimum changes that would be acceptable to do as a start. So I wonder
>> whether:
>>
>> - Some aspects of the download as done by the current extension would
>> also be affected by Web Extensions, especially the pausing and resuming?
>>
>> - 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?
>>
>
>
