Christian and Matthew are assigned.

Christian: Marcos mentioned this has the same issue as PromptAPI, you can query if there is a model present on the device suitable for a certain level/language, this could be a fingerprint vector. I want to reccomend they look at Prompt API review.

Ehsan: Isn't this the same problem with all language based models? Maybe we can have a consistent answer.

Lola: Do you suggest we should have a document on language-based models?

Ehsan: That would be my suggestion. Come up with a document that describes all of that. Should be done at the WebML groups. Think this is coming up more often.

Marcos: It’s a more general problem of downloading system components which then you can query, because then they become global.

Lola: To make this even more general, should we have a position on downloading system components? Or is this restricted to this use case?

Marcos: No, could be related to everything. Codecs, etc. Should be a design principle.

Lola: Who would be willing to write that? We also have another plenary before the F2F.

Christian: Could offer to do that, would be my first design principle, and a topic where I’m interested in.

Ehsan: Same here. Would be good to have a more experienced TAG member on that as well.

Lola: Design principles is owned by Jeffrey, so we can talk to him about that.

Christian: We asked a question here. There is the fingerprint-ability concern. We also talked about when we review the prompt API, thinks that you can basicaly download AI models to the system as a global compenent, and in choosing languages and other options, it becomes fingerprintable.

That was our first reaction. Web speech API with local processing is already there, it exists. It can already download AI modules and the previous tagest with concerns to that. so now they are just adding the quality level, which is a minor change but adds to the fingerprintability.

We are now waiting for a response.

Hadley: maybe if we don't hear back next week, let's nudge?

Christian: sure

(Christian/added before the meeting: This is pending external feedback.)

Christian: this is related to the Global Browser Component topic we discussed in our f2f. Previous TAG said saistisfied or satisified with converns, but not for the baicl local web speech API. Now they want to extend that local API by giving you a quality property, the level of speech recognition quality. Marcos looked at the pull request. Hard to say anything other than satisfied by concerns because we already said that.

Marcos: perfect summary.

Christian: shall we close it with satisfied with concerns, where the concerns being fingerprinting?

Matthew and Marcos: yes

Christian: We feel this will be satisfied with concerns. We asked them to add fingerprintabiltiy information, but this was ignored. They said it's been covered already, but adding the quality dimension adds a lot of fingerprinting vector.

Marcos: We can see the problem again where we're closing issues but then have no mechanism to follow up - e.g. Christian said it would be nice to see certain things. Maybe we should file bugs relating to those concerns? Then they can't avoid the feedback we give them.

Lola: We've spoken about this in relation to other issues.

Matt: We have process for what you just described Marcos. We can see in one place when groups have closed issues, if they've addressed resolutions, etc. We have it and we could use it.

Christian: Should we try out that process here?

Matt: I'm working on guidance for how to do this, I'm happt to take that and make it applicable for TAG but docs are needed. Happy to take it on and work with chairs.

Lola: Let's write the closing comment for this, and then figure out with chairs, Matthew, and anyone else, how to track things.

Christian: Let me know on the proosed comment.

Christian: Last time we weren't sure what to do about the fingerprinting risks. It tends to make fingreprinting worse. The proponents ignored our request to add a S&P section. The alterntive was that we create an issue in their repo to track it there.

Marcos: S&P is a requirement for any W3C spec.

Matthew: Could show you how to track issues, if somebody is interested. Reach out to me if you want to learn how tracking works.

Ehsan: Curious to know if they have communicated the reason for not adding S&P section? The choice of on-device processign reflects an interest in privacy.

Christian: Their argument is that having a local model means their S&P considerations are already there.

Marcos: They mention mitigations; they've not landed.

Ref https://github.com/w3ctag/design-reviews/issues/1189#issuecomment-4000423542

There's a larger concern around Web Speech that contributions are Chrome-only, and lack of implementation commitments. Though I see some from Mozilla.

Yves: It would fail the TR '2+ implementations' test if that was a problem at transition time.

Marcos: This is confusing as it seems to be incubation work, but being done within a WG. Checks charter. Will file a bug.

... They're saying they think they solved it through un-merged PRs on the spec. We could push back and say it'd be helpful to give people a summary in the explainer, as it's confusing.

Christian: We could conclude the review here, and ask them to add a link in the explainer at that time.

Matthew: Question is, we would be happy if the PRs are merged. "Assuming the PRs are merged, and the link is added…"

(Consensus.)