Re: Action 22: Voice Browser Use Case...

For tracker's benefit, that's ACTION-22.

On 2006-11-30 07:46:23 -0800, Brad Porter wrote:
> From: Brad Porter <brad@tellme.com>
> To: "W3C Security (Public)" <public-wsc-wg@w3.org>
> Date: Thu, 30 Nov 2006 07:46:23 -0800
> Subject: Action 22: Voice Browser Use Case...
> List-Id: <public-wsc-wg.w3.org>
> X-Spam-Level: 
> X-Archived-At: http://www.w3.org/mid/456EFCCF.1060505@tellme.com
> 
> Action 22:  Produce Voice Browser use case... is assigned to me. 
> 
> I wasn't involved in the discussion at the time this action was 
> generated, so apologies that I didn't know I had an action and I'm going 
> in a little blind on the context for the request.  That said, let me lay 
> out some of the differences I see in the voice web experience from a 
> Desktop browser as they pertain to security.
> 
> *Special Considerations for Web Security in a Voice Browser Context
> *
> /Differences/
> 
>    * Interaction with a voice browser is often entirely transparent to
>      the end user.  He or she has no idea whether the interaction is
>      with a voice browser or any other automated phone application.
> 
>    * Voice browsers typically have no standard chrome whatsoever.  The
>      entire user experience is defined by the application markup. 
>      There is some standard context information provided to the
>      application markup (callerid, dialed number) which can be found in
>      5.1.4 of the VoiceXML 2.0 specification [1].
> 
>    * Voice browsers have no URL bar.  All content must be navigated to
>      via hyperlinking.  Bookmarking would be an application-specific
>      feature and is not built into the browser metaphor. 
> 
>    * A highly interconnected voice web is technically feasible, but
>      does not truly exist today.  Applications live in their own space
>      and do not contain links outside of their domain.
> 
>    * For latency reasons, Voice browser deployments often make use of
>      greater presentation markup caching and more separation of dynamic
>      data and presentation data.
> 
>    * Trust is typically established via the phone number the caller
>      dialed.  That said, there is no real reason you can trust the
>      phone number.  Trust would be established by the credibility of
>      the source of the phone number (corporate website, phonebook,
>      toll-free directory assistance.)  Outbound calls are inherently
>      less trustworthy. 
> 
>    * The search engines in this space are 411 services.  411 data is
>      typically maintained by telcos thorugh their whitepages and
>      yellowpages which usually involves a direct relationship with the
>      business or individual.  It is more difficult to publish yourself
>      as a spoof address.
> 
>    * The phone network tends to have more centralized control with
>      substantially greater regulatory control and legal precedent.  For
>      instance, the national do-not-call list generally works where
>      attempts to control email spam haven't.
> 
>    * The costs of answering a spoofed 800# or placing malicious
>      outbound calls are substantially higher than the cost of
>      publishing a spoof website or generating an email.
> 
> /Similarities/
> 
>    * Voice browsers run in a different trust zone than the web services
>      and databases.  Billions of calls a year are handled by voice
>      browsers operated by one company on behalf of another company. 
>      These browsers interpret many different companies' voice
>      applications.  As a result a single voice browser may be able to
>      access content and services that the application running on that
>      voice browser is not allowed to access.  As a consequence, all the
>      same sandboxing requirements apply.
> 
>    * Protecting user data and preventing cross-session data leaks is
>      equally critical.
> 
>    * Voice browsers make heavy use of Ecmascript. 
> 
>    * User authentication is still the responsibility of the web site
>      and not the browser.  Cookies are employed.  Authentication
>      techniques differ due to the inability to effectively recognize
>      random  a strings of letters, digits, caps, and punctuation that
>      is typically found in a typed password.  Biometric
>      identification/authentication  (voice prints) are more easily
>      integrated into the user experience, though they are not widely
>      deployed.
> 
> 
> --Brad
> 
> [1] VoiceXML 2.0 Standard Session Variables 
> http://www.w3.org/TR/voicexml20/#dml5.1.4

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Monday, 4 December 2006 08:58:06 UTC