RE: About speech request initiation and reco element etc

I'm fine with the markup element and its method being the JS API for speech input.  I agree with Olli that doing so doesn't completely "solve" all security concerns, but I agree with you that the existence of click jacking or other security concerns does not sink the approach.  It just means browsers (and the environments they are run in) need to be cautious and aware.  But I think the various mitigation strategies are largely up to the UA.

From: public-xg-htmlspeech-request@w3.org [mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Satish S
Sent: Tuesday, July 05, 2011 6:58 AM
To: Olli@pettay.fi
Cc: public-xg-htmlspeech@w3.org; Bjorn Bringert
Subject: Re: About speech request initiation and reco element etc

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.

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.