"Prompting the user is a security failure"

I came across a short paper this morning discussing prompting users
(originally written in the context of audio/video access in the Web, hence
relevant): http://rtc-web.alvestrand.com/papers/barth-security-prompt.pdf.
It's useful context for our discussions around how and when speech
recognition should be started (c.f. R29). As we move beyond requirements and
start thinking about concrete approaches, I believe it would be instructive
to consider three distinct scenarios:

   1. Normal web browsing
   2. Installable web applications
   3. Custom application environments

Examples of 1 are very familiar - browsing the unconstrained, open Web with
Safari/Firefox/IE/Chrome/Opera etc. Examples of 2 are web runtimes, widget
frameworks, Safari's installable extensions, Chrome's installable webapps,
etc. Examples of 3 are more abstract, perhaps an example is a hand-free car
system with an HTML rendering engine and a button on the steering wheel to
start recognition.

I would offer that case 1 is the where the volume of usage will be
(particularly on mobile and tablet browsers where speech provides an
appealing alternative to typing) and most closely aligned with our charter
to extend regular HTML 5. Of course, any solution we propose could work for
all 3 scenarios by considering constraints appropriate to the environment.
For example, a solution to 1 is to have a "user gesture" such as a mouse
click trigger recognition on an <input> element along with a clear UI
indicator that recognition is underway. It would be dangerous to allow
scripting the click() method on that <input> element (file <input> disables
it) to automatically start recognition. However, it may be more appropriate
to permit click() for scenario 2 where a pre-authorization stage in the
install flow seeks a batched set of user permissions.

Dave