W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

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

From: Wez <wez@google.com>
Date: Thu, 31 Jan 2013 10:01:34 -0800
Message-ID: <CALekkJcpGfNQA-vyvRdbqH_KOCCHFF9DwxTxj7Pvzyx13VMu3w@mail.gmail.com>
To: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, www-dom@w3.org, Florian Bösch <pyalot@gmail.com>
On 31 Jan 2013 04:50, "Hallvord Reiar Michaelsen Steen" <hallvord@opera.com>
> >> Well yes, implicitly you did. If a random website can figure out where
> >> are on your keyboard (i.e. what layout you are using) it is an extra
> >> point for fingerprinting / tracking users.
> > I strongly disagree with that we should sacrifice accessability and
> > i18n on the altar of fingerprinting concerns.
> Let's try to solve the problem rather than stating disagreement. We have
- here and many, many other places - conflicting goals between enabling
features and protecting users from some potential abuse. We're discussing
this in order to balance both concerns without "sacrificing" anything - as
long as we find a way forward.
> > The HTTP header "accept-language" defined by HTTP 1.1 section 1.4.4
> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html already provides
the users
> > locale. A users locale has a strong correlation to a users keyboard
> 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
(bought laptop while living in London ages ago). Plus surfing with Opera.
There's probably only one of me ;-).

In this case the code translation API will behave as if nn-NO were in
effect - the fact that you have that but an en-GB keyboard only becomes
relevant if you press a key not normally present on nn-NO, which should be
a relatively easy corner-case to address.

> > If the intent is to avoid adding identifyable bits by preventing locale
> > that train is gone with accept-language.
> The problem with fingerprinting is that the more bits of information we
add, the easier it gets.
> 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
> --
> Hallvord R. M. Steen
> Core tester, Opera Software
Received on Thursday, 31 January 2013 19:38:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC