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

Note I've forked the discussion on "allow ..." Madness over to
public-webapps@w3.org with a proposal to centralize it up front.


On Thu, Jan 31, 2013 at 2:05 PM, Florian Bösch <pyalot@gmail.com> wrote:

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