- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 29 Nov 2010 09:53:23 -0800
On 11/29/2010 1:49 AM, timeless wrote:
> On Mon, Nov 29, 2010 at 5:57 AM, Charles Pritchard<chuck at jumis.com> wrote:
>> A method for triggering a system/ua spell check via execCommand
>> would be a small step forward. Is that something already available?
>> Afaik, it was canned from the early MS model.
> Bringing up system dialogs is scary/surprising and could be annoying[1].
>
> I'm waiting for the day when a security vulnerability is reported for
> a system spellchecker. -- And don't laugh, the open source spell
> checkers we've used have some really crummy code w/ a rather poor
> track record when it comes to buffers and inputs. Thankfully so far
> most attacks against them have been by dictionary vendors instead of
> users, but...
>
> [1] we still get bugs from people complaining about while(1)alert("boo");
I'm not laughing: using the 'Help' menu in old Windows (what was that,
98?) to into explorer.exe was one of my favorite security holes. I don't
think it's unreasonable to expect that spell checkers would be
distributed within the browser. But I don't want to add on additional
burdens to UA designers either. I don't think it's reasonable to play
for system spell checkers to be exploited; if it's being tossed to the
OS, then it really is an OS responsibility. If there is an exploit via a
buffer overflow on a string/unicode pattern, it's quite possible that an
existing spell checker would fail within the existing scheme.
Regarding while(1) alert("boo") -- I really like how the "Ignore further
notifications from this page" option evolved to solve that issue. Spell
checkers have something similar that people are used to: "Ignore all".
With the system dialog: Isn't the point here, to maintain consistency
with the OS? Using an OS-level spell check dialog would do that.
It's not my favorite solution, but I'd like to find some way to inch
forward (giving up on taking full steps).
Received on Monday, 29 November 2010 09:53:23 UTC