[whatwg] Exposing spelling/grammar suggestions in

On 11/29/2010 1:53 PM, Ashley Sheridan wrote:
> On Mon, 2010-11-29 at 10:40 -0800, Charles Pritchard wrote:
>> >  Date: Sun, 28 Nov 2010 15:54:04 +0100
>> >  From: Christoph P?per<christoph.paeper at crissov.de  <mailto:christoph.paeper at crissov.de>>
>> >  To: whatwg group<whatwg at lists.whatwg.org  <mailto:whatwg at lists.whatwg.org>>
>> >  Subject: Re: [whatwg] Exposing spelling/grammar suggestions in
>> >  	contentEditable
>> >  Message-ID:<62959690-0E26-4BBC-AB4F-F9726F24CAF9 at crissov.de  <mailto:62959690-0E26-4BBC-AB4F-F9726F24CAF9 at crissov.de>>
>> >  Content-Type: text/plain; charset=us-ascii
>> >
>> >  Charles Pritchard:
>> >>  >   A method for a contentEditable section, along the lines of getSpellcheckRanges() would allow for content editors, to stylize and provide further UI controls around spell checking.
>> >  Methinks this belongs into CSS:<http://lists.w3.org/Archives/Public/www-style/2010Oct/0849.html
>>
>> Should the issue re-arise in the CSS groups: it seems that most of the
>> vendors are against exposing system dictionary identified misspelled words.
>>
>> ::spelling would need to have the same level of security as a:visited --
>> only foreground, background color would accept alteration. Anything
>> else would expose the data being highlighted.
>>
>
>
> Erm, how would that help? It's currently very easy right now to 
> exploit the a:visited thing to grab an entire history list, which I 
> presume is what you're on about?

Yes, that's what I'm getting on about. If spelling ranges are not 
allowed, this would be a possible hole / limitation of CSS styling.

I do think it's reasonable to allow for a getSpellingRanges function.

I don't find Benjamin's objections to be sufficient to block, given the 
existing scripting context:
1)  "Detecting the user's language (including fine distinctions like 
British/US English)."
and
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)."

Those are the two objections I heard to exposing spelling ranges inside 
of contenteditable.

Both personal items are typically exposed in varying ways to the host 
and scripting environment. It may make sense to require a language code, 
to use the getSpellingRanges, if the item is important.

Complete anonymity, from fingerprinting profiling is really more the 
realm of UA modes. Google Chrome has an incognito mode, for instance. 
While I'm browsing incognito, it would not make sense for the spell 
check to access words from a non-incognito context.

There were many other objections to exposing suggested spelling, and I 
think that's a very separate issue now than exposing the misspelled ranges.

There are enough reasonable accessibility use cases to more strongly 
consider exposing something like getSpellingRanges( preferredLanguage )

Browser vendors may consider limiting such lookups, and that receiving 
more than a thousand lookups means that a script has gone awry. Doing so 
would limit any reasonable chance of a brute force attack discovering 
anything. A brute force attack with getSpellingRanges would use a 
dictionary to fill a contenteditable area and test to see if the word is 
in the system dictionary. The success of such an attack would be 
reasonably limited were spelling lookups limited by the UA.

Vendors:
Can I get a maybe?

-Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101129/fc2e53cc/attachment-0001.htm>

Received on Monday, 29 November 2010 14:08:09 UTC