Re: Working Group Decision on ISSUE-131 caret-location-api

On Thu, Apr 28, 2011 at 10:47 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> But this doesn't have to be an either-or question. One solution that
> would satisfy both would be to add another boolean argument to the
> function which would indicate if drawing should drive focus or not. So
> the resulting API would be something like this:
>
> context.drawFocusRing(element, x, y, [ canDrawCustom ], [ driveUserSelection ]);
> context.setCaretSelectionRect(element, x, y, w, h);
> . . .
> cx.beginPath();
> cx.moveTo(10, 10);
> cx.drawFocusRing(elem, 10, 20, false, false);
> . . .

Could we please avoid boolean arguments wherever possible?  They're
totally opaque if you haven't read the documentation, and even if you
have read the documentation, you have to remember which value is true
and which value is false.  Without having ever used canvas or any
other graphics API in my life, or even knowing for sure what a focus
ring is, I can guess from looking at that code that "elem" is an
element that's somehow related to the focus (maybe clicks in the
canvas should be transferred to the element or something?), and the
numbers are probably the x and y coordinates of a point (given the
moveTo(10, 10) immediately above), but the "false, false" could mean
absolutely anything.  I have no clue at all.

On Fri, Apr 29, 2011 at 10:06 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> - I don't buy this fingerprinting argument at all. Hard coding the blink rate does not reflect the user's settings. Frankly, it is a ridiculous waste of resources on behalf of the browser vendor to have to put in a constant for a blink rate when an author can define the constant themselves to be WCAG 2 compliant. Cookies do far more damage with respect to fingerprinting than this will, yet they still are used extensively and are not prohibited by browser manufacturers ( not everyone knows to turn on private browsing). Frankly, I see this as the browser manufacturers speaking out of both sides of their mouth.

Cookies are irrelevant to fingerprinting.  Fingerprinting is when you
can reliably identify users even *after* they've cleared their cookies
or turned on private browsers.  It's done by adding together many
different things that tend to be stable per user but vary between
users, like reported OS version, installed fonts and plugins, time
zone, etc.  Since almost no users will change their default OS blink
rate, anyone who *does* change their blink rate would almost surely be
uniquely identifiable in combination with a few other details if this
info were exposed by the browser -- even if they use private browsing
mode, clear cookies, etc.  It would even help track users across
different computers, if they configure all computers they use to the
same atypical blink rate.

For more information on fingerprinting, see this demo page by the EFF,
and accompanying paper:

http://panopticlick.eff.org/
http://panopticlick.eff.org/browser-uniqueness.pdf

Fingerprinting is cumbersome for authors to do, so it's not as
critical a problem as some things that are easier to pull off, but
it's a serious privacy problem in the case of authors who have the
resources to do it.  More features like this will make it ever harder
to fix.  Browsers need to remove these features, not add new ones.

(I haven't researched the broader issue of canvas accessibility at
all, so I have no comment on that.  It seems like a small enough loss
for canvas cursors to not respect user blink rate settings, but if
it's not, could you work out some API that lets authors honor them
without knowing them?  I.e., let the author say "I want this to blink
at the user's blink rate setting", without letting them know what it
is?)

Received on Friday, 29 April 2011 16:05:26 UTC