Re: Offline webapps and speech UI

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

Received on Wednesday, 3 November 2010 14:31:41 UTC