W3C home > Mailing lists > Public > public-html-a11y@w3.org > October 2010

[Bug 10994] accessKeyLabel can expose new information about the user and possibly also other origins

From: <bugzilla@jessica.w3.org>
Date: Tue, 12 Oct 2010 16:26:01 +0000
To: public-html-a11y@w3.org
Message-Id: <E1P5hft-0007xa-IK@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10994

--- Comment #6 from Simon Pieters <simonp@opera.com> 2010-10-12 16:26:01 UTC ---
(In reply to comment #4)
> That information is exposed anyway -- it's just a question of whether it can be
> harvested automatically or with some minimal user intervention.

Yes. It's a lot harder to make the user press a lot of keys compared to just
visiting a page (you'd probably need to test a large amount of accesskeys to
get useful data).

> If you want to
> see if the accesskey "a" is taken, just make an element with accesskey="a b"
> and get the user to hit Alt-A or whatnot and see if your element gets hit.  So
> it's not created only by accessKeyLabel.  Although some variant of that attack
> (the user-interaction-required one) might be doable now in at least some
> browsers, depending on how they assign accesskeys.
> 
> Also, I don't think authors will want to assign fallback accesskeys. 
> Accesskeys are meant as shortcuts for power users to memorize and be able to
> use reflexively, so they have to be consistent -- it's no good for them to
> change randomly depending on the presence of other accesskeys.

The feature isn't meant to change randomly on the presence of other accesskeys,
it's meant to change based on what device the user is using (full keyboard vs
mobile).

> No native app
> does this kind of accesskey switching, right?  If there's a conflict, one of
> them wins and the other just doesn't work.

That still lets you detect information about the cross-origin iframe if the
browser assigns an accesskey for that document and you later try to set the
same accesskey.

> So unless there's evidence suggesting that this switching behavior is actually
> desired by authors, I'd say drop that in preference to dropping accessKeyLabel,
> if there's a conflict.  I already gave evidence in comment 1 that the latter
> would be useful to authors.

I agree that it's useful, although I also think that being able to assign
fallback keys for mobiles (or letting the browser choose for itself) is useful.
I'm just highlighting the issues I can think of.

I'm not reopening at this point since I still haven't thought this through
completely. I'll probably revisit this when it comes to implementing it.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 12 October 2010 16:26:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:22 GMT