Restrict SpeechRecognition and friends to secure contexts

[foolip]

Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=30176.

---

Preview | Diff

---

Preview | Diff

[padenot]

I think we want to merge this, despite being of a certain vintage?

@evanbliu, @youennf what's your respective opinion on this. Mozilla would rather only do this on SecureContext.

[padenot]

@evanbliu, @youennf, any comment on this?

[youennf]

LGTM, this is worth a try.
PR seems to need a refresh.

[padenot]

Done.

[youennf]

SpeechRecognition uses microphone so that makes sense to restrict.

For SpeechSynthesis, I am less sure, do we have some numbers there?
Maybe we could split the issue.

[padenot]

SpeechRecognition uses microphone so that makes sense to restrict.

Not in the current state of the spec, no, it doesn't have to. It can take its input from a MediaStream.

[youennf]

Not in the current state of the spec

This is a new API so the web compat risk is very low.
The initial intent of the PR was based on Chrome's change to disable SpeechRecognition, which is not functional in insecure websites.
On the other hand, SpeechSynthesis is functional in insecure websites so the web compat story is less clear.

[padenot]

This is a new API so the web compat risk is very low.

It is not, it has been shipped for about 11 years in Chrome, says MDN.

@evanbliu, what's Chrome opinion on this matter?

[youennf]

It is not, it has been shipped for about 11 years in Chrome, says MDN.

SpeechRecognition with microphone is not new, but SpeechRecoginition with any MediaStreamTrack is new AFAIK and is probably not a web compat issue.

[evanbliu]

Oops, sorry I missed this. Restricting SpeechRecognition to secure contexts sounds fine to me! But it seems like this isn't necessary for SpeechSynthesis.

[evanbliu]

@padenot & @youennf - What are your thoughts on gating the Web Speech API (or at least the on-device parts of it) behind a Permission Policy? Without this limitation, if a legitimate site using this API embeds a third-party iframe (e.g. an ad), that ad could read the same fingerprinting bits through availableOnDevice().

[youennf]

What are your thoughts on gating the Web Speech API (or at least the on-device parts of it) behind a Permission Policy?

This might deserve its own bug.
In general, if availableOnDevice() is opening new fingerprinting, the spec should say so and we should evaluate how to mitigate this/remove this. In general, I do not see Permission Policy as the right tool against fingerprinting.

I would instead tend to reduce what is being exposed to the bare minimum, do we have a bug tracker for that, or should I file one?
For instance, how about a boolean stating that website wants speech recognition to be done on device.

Getting back to SecureContext, @padenot, what are your thoughts?

[padenot]

Mozilla's SecureContext policy is still https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/.

SpeechRecognition should be SecureContext for obvious reasons. Synthesis should be SecureContet if we can make it so web-compat wise.

[youennf]

Can we then only tackle SpeechRecognition in this PR and open a separate issue to further study SpeechSynthesis?
I'd like to update WebKit when the spec is updated for SpeechRecognition.

[youennf]

Also, it would be nice to have a WPT legacy test to check that the constructs no longer appear in non secure contexts.

[padenot]

Can we then only tackle SpeechRecognition in this PR and open a separate issue to further study SpeechSynthesis? I'd like to update WebKit when the spec is updated for SpeechRecognition.

Done. We can write a idlharness test after merging.

[youennf]

Unofficial LGTM (it seems I cannot approve PRs here).

[padenot]

I've formally asked @evanbliu for a review, assuming Google is fine w/ the change.