Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Unfortunately, this is not possible. The most important reason being that it would be an <a href="http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html#security" rel="noreferrer"><strong>invasion of privacy/security hazard</strong></a>. A user must <strong><em>willingly</em></strong> choose to be recorded (in this case, by mouseclick). If the event can be emulated and the user is unaware that they are being recorded, there could be serious legal repercussions. Hope this helps!</p> <hr> <p><strong><em>UPDATE:</em></strong></p> <p>This is from a <a href="http://www.w3.org/2005/Incubator/htmlspeech/2010/10/google-api-draft.html#security" rel="noreferrer">document</a> about <code>Speech Input</code>:</p> <blockquote> <p>To minimize the chance of users unwittingly let web pages 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.</p> </blockquote> <p>Here are concerns from that same <a href="http://www.w3.org/2005/Incubator/htmlspeech/2010/10/google-api-draft.html#security" rel="noreferrer">document</a> :</p> <blockquote> <p>1) Spoken password inputs can be problematic from a security perspective, but it is up to the user to decide if they want to speak their password.</p> <p>2) Speech input could potentially be used to eavesdrop on users. Malicious webpages could use tricks such as hiding the input element or otherwise making the user believe that it has stopped recording speech while continuing to do so. They could also potentially style the input element to appear as something else and trick the user into clicking them. An example of styling the file input element can be seen at <a href="http://www.quirksmode.org/dom/inputfile.html" rel="noreferrer">http://www.quirksmode.org/dom/inputfile.html</a>. The above recommendations are intended to reduce this risk of such attacks.</p> </blockquote> <p>Also, according to <a href="http://updates.html5rocks.com/2013/01/Voice-Driven-Web-Apps-Introduction-to-the-Web-Speech-API" rel="noreferrer">this article from html5rocks.com</a>:</p> <blockquote> <p>the first time speech recognition is used, Chrome needs to ask the user for permission to use the microphone, in which case onstart only fires when and if the user allows permission. </p> </blockquote> <p>With this in mind, it would be <strong><em>very difficult</em></strong>, if not nearly impossible, to implement <code>onload</code> events without the user's consent, since Google has taken measures to protect against <code>malicious webpages</code>. Google has also prevented users from <a href="https://code.google.com/p/html5rocks/issues/detail?id=594" rel="noreferrer">simulating click events</a>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload