Re: Offline webapps and speech UI

On 11/03/2010 03:30 PM, Andy Mauro 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,
Yes, I was talking about the speech engines running locally on users device.


-Olli



  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.
>>
>
>

Received on Wednesday, 3 November 2010 15:30:49 UTC