How to signal progress for resuming a previous download

[domenic]

(Originally raised by @tomayac at https://issues.chromium.org/issues/441940325.)

Our current design in the spec requires that progress always start at 0, and proceed linearly to 100%. In particular, if the user agent has already downloaded 2 GiB of a 10 GiB model, the progress still starts at 0; it doesn't start at 20%, or jump quickly from 0 to 20%.

This has two nice properties:

• It gives users a clear signal of how far they've come, from starting the download to it being finished. Whereas, if we started at 20% or jumped there quickly, it could be confusing why the last 80% is so much slower than the first 20%.

• It avoids a rather weak fingerprinting attack where multiple sites download a model at the same time and correlate progress with each other to find a unique user. (This is weak because: it can only be done ~once per user, and there will be fuziness so that the downloadprogress events are not necessarily delivered at the exact same time to different sites.)

However, it was pointed out that there is a potential bad user experience here:

1. The user loads up a site and engages with an AI feature
2. The site starts the download, and the progress bar slowly creeps up from 0% to 50%.
3. The user accidentally clicks a link somewhere else.
4. Oh no, they didn't mean to do that! They go back to the original page and re-engage with the AI feature.
5. Now the progress bar "starts over" at 0%. It'll be moving 2x as fast as last time, since 100% represents 1/2 of the bytes, but the user might still feel like they lost progress.

We wanted to open this issue to get community feedback on how bad this kind of user experience might feel, and how it weighs against the above two positives of the current approach. Especially because we are finding that displaying download progress and status is a particularly tricky part of the initial adoption of these APIs.

(As with many things in the download progress space, one potentially better solution here is to have trusted browser UI display the download progress...)

[tomayac]

One thing that was discussed in the context of the bug was whether to report true download progress per-origin: if you start the model download on example.com and reload the page when 20% of the model is loaded, the progress bar would start at 20% again, but if you open another page example.org that also triggers a model download, it would start from 0%. This would mean there would be no confusion about seemingly lost progress, but another potential confusion on the same resource's download being at different progress percentages and moving with different speeds. (This assumes the user knows the model is shared, which may not be given.)