Do not expose exact download progress

[domenic]

Probably we should not expose the exact model size during the download progress, as doing so basically lets you know the model ID. This is a slight fingerprinting and compatibility concern. We could instead expose the nearest percent or tenth of a percent.

Are there any concerns about this?

[domenic]

Some offline discussed suggested we should do this censoring, but we should be sure that the values are granular enough that developers still see progress every 50 ms in the typical case. That is, if we just used the integers 1-100, it's possible that for large models it'd take longer than 50 ms to move from 1 to 2.

Some rough numbers for order-of-magnitude:

• Chrome's model is ~2 GiB download size. Let's say ~5 GiB as a conservative bound on size.
• Browsing https://worldpopulationreview.com/country-rankings/internet-speeds-by-country something like 20 Mbps seems like a low ballpark: only a few countries have their medians below it.
• 5 GiB = 5 * 2^30 bytes = 5 * 2^30 * 8 bits, divide by 20 Mbps = 2 * 10^7 bits/second = ~2147 seconds = ~2,147,484 ms = ~42,950 50-millisecond intervals.
• Round up to nearest power of 10: 100,000 50-millisecond intervals
• So we should give the progress to 1 part in 100,000, e.g. a percentage plus 3 decimal digits, or 6 decimal digits between 0 and 1.

We have a few ways to accomplish this:

1. Use ProgressEvent as-is with numbers between 1 and 100,000.
2. Update ProgressEvent from unsigned long long to double, and use numbers between 1 and 100 with 3 decimal digits.
3. Update ProgressEvent from unsigned long long to double, and use numbers between 0 and 1 with 6 decimal digits.

I feel pretty strongly that we should update ProgressEvent: it's quite backward-compatible, with the only behavior change being for synthetic events. (Before, (new ProgressEvent("progress", { loaded: 1.5 })).loaded === 1. After, you get back the 1.5.)

I'm unsure on the choice between (2) and (3). @tomayac points out that HTML's <progress> defaults to the 0-1 range, so maybe (3) is the best choice.

[tomayac]

I'm unsure on the choice between (2) and (3). @tomayac points out that HTML's <progress> defaults to the 0-1 range, so maybe (3) is the best choice.

Developers are lazy (I am), so any normalization to the <progress> range that they don't have to make is a welcome API convenience. Similar to the Prompt API conveniently giving you tokensLeft, even if you could calculate it.

[domenic]

@annevk as XHR owner, any initial reactions to extending ProgressEvent from unsigned long long to double?

[annevk]

Probably okay?

[domenic]

#30 implements this. Note that my above calculations use base 10, but I realized that JavaScript (and C++) numbers are base 2. So the last step is changed from 1 part in 100,000 to 1 part in 65,536. The spec has the full updated calculation (using MathML!).

[fergald]

As a user, I want to know if the proposed download is 1.5G or 1.5M. Maybe that should be in the agent's UI, especially since there's no guarantee that the page will present any information about the download at all.

[domenic]

Yeah, that definitely seems like a user agent UI thing. Maybe it's a bit of user agent UI we should recommend in the spec, though.

[fergald]

Yeah, I think recommending it in the spec is a good idea.