Re: About speech request initiation and reco element etc

I don't expect our proposal to disallow starting speech input with a single
click because that can happen in the trusted/whitelisted sites scenario. But
I expect we'll have wording in the API proposal to discourage UAs from
sending audio to remote servers without explicit user consent in some form.

Cheers
Satish


On Tue, Jul 5, 2011 at 4:12 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

> On 07/05/2011 04:58 PM, Satish S wrote:
>
>>    As I said
>>
>>    "Note, I'm not against <reco>, if we can find a reasonable security
>>    model when it is used. "
>>
>>    So if Google is ok that user needs to give an explicit permission to
>>    the page before activating speech recognition, then this one
>>    problem is solved :)
>>
>>
>> Explicit permission comes in various forms. As we discussed earlier on
>> mobile devices it could be a dedicated key, on desktop browsers it could
>> be a button on the window chrome, in an enterprise environment it could
>> be a set of trusted intranet pages set by the domain policy and in
>> untrusted environments it could be a drop down or an info bar or a
>> dialog asking the user for an extra click. I think we all agree on these
>> models and that they get explicit permission in various forms. So I
>> think the problem is solved.
>>
>
> Ok. So let me still verify - Google does not require that the API
> allows speech recognition to be started without getting explicit
> permission from user? (So it is ok if the API disallows the UI Chrome
> has now - or at least the API will require UA to ask permission at some
> point?)
>
>
>
>
>
>> Is everyone else ok with a <reco> style markup element and its methods
>> being the JS API for speech input? A similar model could be used for TTS
>> as well so a <tts> element if visible on page could provide a UI similar
>> to the <audio> tag, allowing users to play/pause/seek in the audio stream.
>>
>>
>