Detectability of assistive technology

[ShivanKaul]

I reviewed https://raw.githack.com/w3c/aria/2020-09_CR/index.html for privacy issues as requested by the ARIA WG. Currently the document does not have a Privacy Considerations section.

It seems that aria-hidden=true can be used in combination with focus or mousedown/up JS events to detect whether or not the user of a website is browsing using a screen reader. Here's a demo website: https://dylanb.github.io/screenreaderdetection. I believe a website developer could use role=none/presentation similarly.

I'm curious as to why there is no text around this in the document. Seems like it is a widely-recognized privacy harm [0, 1] and something that could be discussed along with possible mitigations [2] in a Privacy Considerations section.

[cookiecrook]

My results indicate this is not as straightforward as the demo indicates. It does catch a few real instances, but it's also wrong a lot of the time.

1. Keyboard Nav on Mac: "keyboard-only user on Apple device, screen reader might be present" (Screen reader was not active on my Mac.)
2. VO on iOS with default activation: noted as "Screen reader user on OS X"
3. VO on iOS with pass-through: noted as "mouse/touch user on Apple device"
4. VO on macOS with default activation: noted as "Screen reader user on OS X"
5. VO on macOS with click activation: noted as "mouse/touch user on Apple device"
6. Keyboard Nav on iOS noted as "Screen reader user on OS X" (VoiceOver was off)

I'm pretty sure I could get it to fail in a number of other circumstances and on other platforms, but I think this enough for now.

This approach is also not limited to ARIA. You can use a similar approach with plain old HTML+CSS and get similar faulty but sometimes correct results.

[jnurthen]

Indeed the demo site shown will show exactly the same issues if you remove the aria-hidden. The only difference is that a very savvy screen reader user might notice that buttons were doubled up.

This is not to say that there are not potential issues - however from this demo I'm not convinced that they come from ARIA and not from HTML and CSS. Indeed the mitigations discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=988896 have nothing to do with ARIA and show themselves with a standard HTML button.

[JAWS-test]

If I understand the test page correctly, the cause is the screen reader, because screen readers convert keyboard events into click events. I have tested Firefox with JAWS and NVDA and in both cases the screen reader is recognized correctly. In JAWS I can set that the conversion of events should not take place and then JAWS is also no longer recognized. In NVDA, the problem does not occur when I switch to forms mode, because then the events are not converted either.

In this respect it is a screen reader problem. In my opinion it has nothing to do with ARIA

[ShivanKaul]

@cookiecrook - point taken about the detector script not working for every combination, but from your notes it does seem like it mostly identifies the default case - I'd imagine that this would be most users?

@jnurthen - agreed that aria-disabled would simply prevent the user from even knowing that there was a strange second button when this detection attack was carried out. But having it makes the attack more passive, which I think is not great. Also, I haven't gotten too much time to look into it, but could a potential attack for the screen reader vs keyboard-user case also be having 3 elements on a page, the middle one aria-hidden, and if there is a focus event on the first and last but not the middle aria-hidden one then that is evidence of a screen reader being used?

In general, the ability for a server to turn off/modify ARIA use by the browser/screen reader such that the user's behaviour is measurably (by the page) modified is a problem, and while I haven't gotten time yet to fully explore all the different attacks possible, it does seem worthwhile to think and call out the potential for them in the ARIA spec.

[JAWS-test]

@ShivanKaul Everyone has written so far that it has nothing to do with ARIA. The test page takes advantage of a feature of screen readers. The example at http://dylanb.github.io/screenreaderdetection/ would also work in the same way without ARIA

[carmacleod]

In case it's helpful, 2 additional articles [3, 4] I had saved on why detection is a bad idea.

[samuelweiler]

@ShivanKaul Everyone has written so far that it has nothing to do with ARIA. The test page takes advantage of a feature of screen readers. The example at http://dylanb.github.io/screenreaderdetection/ would also work in the same way without ARIA

Should this not still be documented here?

[ShivanKaul]

The example at http://dylanb.github.io/screenreaderdetection/ would also work in the same way without ARIA

I was under the impression that the aria-hidden is what causes the simulated button to not show up for screen reader users. If yes, IMO this is a problem because screen reader users won't even come to know that there is a weird button here. In general, we would prefer attacks be active (detectable by the user), not passive. FWIW I don't think it's a serious enough issue to hold up publication.

[jyasskin]

In the PING call today, I suggested that it'd be good to have a Privacy Considerations section in ARIA 1.2 saying something like,

The fact that someone is using assistive technology is sensitive information that would ideally be hidden from webpages. Unfortunately, many aspects of the web platform reveal that information, and many web pages rely on it in order to provide an acceptable experience for people using assistive technology. Within the ARIA spec, aria-hidden, X, Y, and Z can be used to detect that assistive technology is in use.

Or whatever y'all think is accurate.

There's no need to figure out how to make screen readers and non-screen-readers indistinguishable in ARIA 1.2, as that's a much bigger project.

[cookiecrook]

Within the ARIA spec, aria-hidden, X, Y, and Z can be used to detect that assistive technology is in use.

I would definitely object to this phrasing... It's inaccurate and alarmist.

[cookiecrook]

By that phrasing, you might also need to say "In the HTML Spec, <button>, < a href>, and features x, y, and z can be used to detect assistive technology. In the CSS spec, the position and visibility properties can be used to detect assistive technology." I don't think that's accurate, but there are observable differences across all aspects of the web platform, and each point might be used to infer a higher or lower probability that "AT might be in use"... Listing the exact heuristics in the specs seems like it would only be useful as a checklist for malicious actors.

Perhaps we should have an ARIA/PING joint meeting to discuss.

[cookiecrook]

Not to beleaguer the point, but does mousemove list that it can be used to differentiate left-handed versus right-handed users? Should it? Without a clear path to resolve it, it seems the only benefit to listing it in the spec would be scare users and give more ideas to malicious fingerprinting engineers.