Re: Offline webapps and speech UI

I don't agree that allowing the browser to ignore the web app's
request for using a particular speech service is the same as not
allowing the developer to request it. Browsers should normally follow
the app's request, but may ignore it if needed (e.g. for offline mode
or paranoid privacy settings). The proposed requirement is to force
the browser to let the web app know when this happens, so that the web
app can for example choose to disable speech input entirely.

/Bjorn

On Wed, Nov 3, 2010 at 3:30 PM, Andy Mauro <Andy.Mauro@nuance.com> wrote:
> Using a threat of hacking as a means of making recognizer behavior lowest
> common denominator strikes me as disingenuous. The fact of the matter is
> that recognizers, while largely the same, have their own idiosyncracies that
> developers sometimes want or need to take advantage of and benefit from. I'd
> argue that it's probably going to be hard to hide the recognizer the user is
> using anyway because the requests going to/from the recognizers will likely
> be traceable. If we're talking about offline mode/embedded recognizer, then
> I have no strong opinion - hiding seems fine if we think it's more secure
> and the user won't care about it.
>
> We need to get some closure on this point - I can't imagine making the
> (network) recognizer user settable and developer settable are compatible,
> yet they are both on the list. Looks like the current proposal is to allow
> the user agent to refuse to use the recognizer specified by the webapp,
> which seems like just another way to say that it isn't developer settable.
>
> -Andy
>
>
>> From: Satish Sampath <satish@google.com>
>> Date: Wed, 3 Nov 2010 15:15:35 +0100
>> To: <Olli@pettay.fi>
>> Cc: <public-xg-htmlspeech@w3.org>
>> Subject: Re: Offline webapps and speech UI
>> Resent-From: <public-xg-htmlspeech@w3.org>
>> Resent-Date: Wed, 03 Nov 2010 14:16:07 +0000
>>
>>> Another possible requirement is that webapps should not know the exact
>>> speech engine installed locally. I mean the vendor and version etc.
>>> There are few reasons for this; webapps should just work everywhere,
>>> no browser/speech engine specific hacks.
>>
>> I agree with this point.
>>
>>> Another reason is that by exposing the exact vendor/version, that would
>>> help hackers to attack against that particular system.
>>> (I assume many speech engines are written in C/C++ or in other unsafe
>>> languages and may not be fuzz tested properly. Well, implementation
>>> done in a memory safe language may still have other security bugs.
>>> I basically want to make a new attack vector a tiny bit harder for hackers.)
>>
>> I think our proposal should not be concerned about bugs in speech
>> service implementations, because they are short term issues and may
>> get fixed soon after they are discovered.
>>
>>> Third reason would be to not add yet another way to fingerprint user.
>>
>> I agree with this view, and I think allowing speech services to return
>> custom fields/parameters in the recognition output can be a way for
>> the web page to identify which speech service is being used.
>>
>
>
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

Received on Wednesday, 3 November 2010 14:42:36 UTC