"To minimize the chance of users unwittingly allowing web pages to record speech without their knowledge, implementations must abort an active speech input session if the web page lost input focus to another window or to another tab within the same user agent."
Given this the actual Chrome implementation is wrong.
Hmm. Thinking about how I use google hangouts, this "standardized" behavior would actually make hangouts virtually useless. For example, I would be unable to share my screen in any meaningful fashion, or hold a conversation while multitasking (I program as part of a distributed team, so I do both frequently).
I'm not entirely sure this spec creates a useful environment for webapp developers; in fact this limitation would encourage non-standardized implementations so they could actually be used by normal people.
We're talking about the Speech API here, which isn't something an app like Hangouts would use. WebRTC, which is more suitable, does not have that restriction codified into its spec.
I agree with you, though the speech to text API is different than just microphone access. Something like video conferencing may not fall under the same rules.
One interesting thing is that web specs don't usually go into that much detail about UI, or at least that used to be the case. It was generally considered outside of the spec's purview, and it boxes in future browser interfaces that could be something very different than tabs and windows.
If you needed something, I would think something like there must be a visible notice to the user that their sound is being recorded, and if that notice becomes obscured, cease recording. But I'm not entirely sure it should be enforced on the spec level; instead it could have a non-normative security section and leave it up to the browsers to implement it well.
Indeed. Perhaps a reasonable compromise would be to have the permission apply to only the tab for which the user allowed it, and only as long as the tab remains pointed to that same domain. No inheriting permissions across child windows and no retaining the permission for that domain when future tabs are opened. Seems like it would reasonably fit the expectations of the user and I can't think it would put up unreasonable road blocks for developers.
But it looks like all four points of the security model (including #4 that you've quoted) were retained. Luckily, Chrome is more aggressive on popups than ever, so there's less likelihood, but it's not yet bulletproof.
I agree it looks like Chrome's implementation is not matching this spec. I'll look into if we can tighten this up.
In it, a Chrome representative said: "The security of our users is a top priority, and this feature was designed with security and privacy in mind. We've re-investigated and still believe there is no immediate threat, since a user must first enable speech recognition for each site that requests it. The feature is in compliance with the current W3C standard, and we continue to work on improvements."
Check the informationweek article for more, specifically around the errata to remove that sentence from the spec.
As a side note: is it a good thing that a window obtained through a Window.open() inherits the parent window's permissions?
Right now in Chrome permissions are enabled or disabled globally with exceptions based on hostname patterns. Adding a new option like "Allow popup window to inherit permissions" will solve the issue.
A well-hidden popup window can track your position all day using the geolocation API?
"To minimize the chance of users unwittingly allowing web pages to record speech without their knowledge, implementations must abort an active speech input session if the web page lost input focus to another window or to another tab within the same user agent."
Given this the actual Chrome implementation is wrong.