[whatwg] Exposing spelling/grammar suggestions in contentEditable

[Charles Pritchard]

On 11/28/2010 11:30 PM, Benjamin Hawkes-Lewis wrote:
> On Mon, Nov 29, 2010 at 4:19 AM, Charles Pritchard<chuck at jumis.com>  wrote:
>>>> What breach is enabled by using a limited spell check?
>>> (What does “limited” mean?)
>>>
>>> If script can programmaticaly get at the spell check results, then it
>>> exposes whether particular words are in the user’s dictionary to that
>>> page.
>> Limited, meaning not particular to a user's dictionary.
> Breaches would include:
>
>     1. Detecting the user's language (including fine distinctions like
> British/US English).
>     2. Fingerprinting the user's system. Different systems likely use
> different dictionaries with different coverage. You could use
> dictionary profiles to guess at the user's system (potentially down to
> operating system and version).
This information is already exposed to varying degrees. Still, I do see 
your point.

> Also your proposed limitation might well require user agents on some
> platforms to implement their own dictionary service as opposed to
> using platform dictionary services.
>
> For example, say you were building a user agent for OS X. AFAICT you
> can't exclude the user's dictionary when querying the system
> spellchecking API:
>
> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSSpellChecker_Class/Reference/Reference.html#//apple_ref/doc/uid/20000378
Good point.  How "damaging" do you consider exposing a 
getSpellcheckRanges() option?
I'm not speaking to listing spellcheck suggestions, just to ranges.

As you've noted, doing so would expose the user's language, and could be 
used to detect and distinguish system dictionaries.
> If you don't need the user's dictionary or the same spellchecking UI,
> you could disable spellchecking with the "spellcheck" attribute and
> roll your own over XHR/web sockets.
>
> http://www.w3.org/TR/html5/editing.html#spelling-and-grammar-checking
Can also roll one with SQL and/or indexedDB. Still, it'd be nice to have 
some standard API methods and arguments.

Has this list considered moving towards standards in 'chrome' 
extensions? It seems that there is a lot of low-hanging fruit
that, while not exposed to untrusted scripts, could easily be 
standardized between vendors supporting the Widgets spec.


-Charles