Re: Re: Re: Keyboard events for accessible RIAs and Games

On Thu, Jan 31, 2013 at 1:49 PM, Hallvord Reiar Michaelsen Steen <
hallvord@opera.com> wrote:

> Anyway, we are (again) up against the old problem that browsers aren't
> very good at letting users say "I trust this site". IMHO browsers should
> have a "Trusted sites" list as a prominent part of their UI. IE's security
> zones was an attempt at solving this, but the implementation IMO wasn't
> really usable. For all I know the FirefoxOS "every site can be an app"
> approach is a way to get there, if the app-bookmarked-sites get extra
> privileges?
>
The current "I trust that site to do this" solution practised by chrome and
mozilla for features such as pointerlock, fullscreen, WebRTC, etc. is to
have a dialog "Allow yadda yadda?"

So for instance I have an application that would make use of pointerlock,
fullscreen, keyboard symbol translation and localstorage, what happens is
that:

- Allow local storage?
- Allow pointerlock?
- Allow fullscreen?
- Allow localized shortcuts?

Probably all stacked on top of each other. It's, how shall I most
delicately put this, user unfriendly? not funny?

Besides the obvious usability concern of stacking N "Allow yadda yadda?"
dialogs (either spatially or temporally), there's an additional
complication this throws up for a site, in that it has to deal with the
possibility that it was not allowed, i.e.

requestFullscreen -> onFullscreenChange error/fail
requestPointerlock -> onPointerLockChange error/fail
requestLocalStorage -> onLocalStorageAllow error/fail
requestLocalizedShortcuts -> onShortcutsAllow error/fail

This makes APIs both more complex to use, and it makes it more difficult to
render a page. It's an inconvenience rather than a problem, still, it's
what it is.

This is definitely true, however for fingerprinting the devil really is in
> the details. So I'm that guy requesting nn-NO with an en-GB keyboard

The problem is not with any extra keys that are functional or
internationally the same (backspace, enter, function keys, numpad numeric,
mathematical numpad symbols and so on). The main problem resides with
language specific symbols for keys, which mostly is just the alphabet and
the places where extra characters are different. There is plenty of
wiggling room where you can normalize the key-codes already (switch them to
the locales symbol) as to not give away the specific. For instance for
german keyboards switch KeyZ and KeyY before it becomes necessary to reveal
the layout trough them. You can foil fingerprinting further by filling keys
the user does not have on his keyboard with random keycodes. The remaining
translations of keys to a users key layout should be almost identical to a
users locale except of course for contrieved special cases.

Regardless, I've voiced my opinion, pointed out the solution, and reasoned
the problems and pointed out migitation strategies. I cannot do more than
club you over the head with it which i consider done now. But by all means
go ahead and implement something which forces any application using
shortcuts to be a pain in the arse for its respective users, I'll gladly
introduce a dialog in such an app pointing out how the w3c choose to foil
attempts to make things not user friendly.