[Tag Review] - Model Acquisition #173
Description
From: w3ctag/design-reviews#1093 (comment)
The API often appears to be designed with the assumption that a model needs to be downloaded as a browser-wide component before first use, possibly depending on the expected input and output language. This leads to a rather unusual asynchronous instantiation via
LanguageModel.create().However, the user agent or the underlying platform may choose to utilize a model that is already present on the device, manage model downloads separately, or send the prompt to a cloud model for processing. In this case, the model acquisition architecture should be left as an implementation detail and not exposed to scripts.
Put differently, we feel that it shouldn’t be possible for a website to query the existence or monitor the download of a browser-wide component, as this might allow cross-site collaboration attacks (e.g., two sites could use the download progress to identify a user uniquely). Instead, the browser could prompt for downloading (“This site wants to download a 4 GB model onto your device. After download, you will have N gigabytes left. Allow?”) and report the download progress using its own UI.
The developer may not be in the position to make a determination when to download a model. For example, the user might be on a fast network with unlimited quota and a high-end device and with no concerns about download quotas. It is not for the site to make any determinations about the user's device, capabilities, or environment as otherwise it violates the principle of "one web" for everyone.
Please consider the gamut of possible users of this technology: from low-end devices, to users who are traveling, those on limited quotas, etc. and leave the user in control, while enabling the largest set of use cases.