Re: [w3ctag/design-reviews] On-device Web Speech API (Issue #1038)

domenic left a comment (w3ctag/design-reviews#1038)

> Restricting recognition location

I really appreciate the TAG's nuanced perspective on this. (This is an area we're keeping an eye on for other APIs as well: https://github.com/webmachinelearning/writing-assistance-apis/issues/38.)

One technology that comes to mind is privacy-preserving cloud implementations. I believe we've seen some of these deployed in the private advertising spaces, and you could imagine them being deployed for these sorts of technologies as well.

I don't know the full details of how such technologies would be used here. E.g., is the privacy technologically guaranteed through mechanisms like TPMs, homomorphic encryption, multiple parties in the chain each of which only sees some of the data, etc.? Or the privacy mostly contractual, where the cloud model provider has some strong guarantee that they never look at the data? Do web developers and users have different feelings about these two levels of privacy guarantee?

My immediate concern is to avoid designing APIs which are future-incompatible with such technology. For example, consider a future where we designed an API of the shape `{ onDeviceOnly: true }`, which when used means that the API only works on ~20% of devices (those with enough GPU memory). But then, one browser believes they have a strong-enough private cloud implementation, which would allow device coverage to go up to 100%. Are all sites that have chosen `{ onDeviceOnly: true }` forever locked out of that 100% device coverage? Or do we break the meaning of `{ onDeviceOnly: true }` to also allow private clouds? Neither alternative seems good.

I don't know what the best solution here is, but I think @jyasskin's suggestions of

> With those caveats, some of the TAG supports giving the site a way to encourage the browser to keep the speech local. Or, perhaps equivalently, for the site to tell the UA that it's going to keep the audio constrained to as few devices as possible, as a hint that the UA should do the same. This should not be a strong UA requirement, which means that it should not be called ondevice-only.

seem promising.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1038#issuecomment-2808118710
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1038/2808118710@github.com>