You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the PING and ARIA WGs' discussion of ARIA Issue #1371 yesterday and in the issue comments, members of the ARIA working group objected to singling out the ARIA feature as a specific risk area without addressing that it's a larger problem of the Web Platform. The feature "exploited" by the proof-of-concept relies on JavaScript event object inspection, not limited to the specific use with ARIA.
Multiple other features of HTML, CSS, and other W3C specs could potentially be abused as an imperfect but heuristically meaningful method for detection of assistive technology. This goes against Web Platform Design Principle 2.7: Don’t reveal that assistive technologies are being used, so members of the PING suggested these risk areas be called out in every spec.
Note: Another action was for PING to research how to address some specific problems confidentially, so that a large list of potential AT Detection methods did not become a recipe for malicious actors.
Someone on yesterday's call mentioned that ReSpec had a classname to mark a feature as a potential fingerprinting risk, and suggested a similar method could be used to mark various features of HTML, DOM, CSS, and ARIA, as risk areas for AT Detection. I took an action to file this issue against ReSpec to request that feature. I'm not sure what other authoring tools are used by the other spec editors, but it's likely needed it more tools than just ReSpec.
Someone on yesterday's call mentioned that ReSpec had a classname to mark a feature as a potential fingerprinting risk,
This was actually something in HTML, but BikeShed now supports it (ReSpec does not support it): speced/bikeshed#964
Someone on yesterday's call mentioned that ReSpec had a classname to mark a feature as a potential fingerprinting risk, and suggested a similar method could be used to mark various features of HTML, DOM, CSS, and ARIA, as risk areas for AT Detection.
If someone came up with the watermark, then it might be worth adding. Alternatively, the fingerprint watermark could be reused.
During the PING and ARIA WGs' discussion of ARIA Issue #1371 yesterday and in the issue comments, members of the ARIA working group objected to singling out the ARIA feature as a specific risk area without addressing that it's a larger problem of the Web Platform. The feature "exploited" by the proof-of-concept relies on JavaScript event object inspection, not limited to the specific use with ARIA.
Multiple other features of HTML, CSS, and other W3C specs could potentially be abused as an imperfect but heuristically meaningful method for detection of assistive technology. This goes against Web Platform Design Principle 2.7: Don’t reveal that assistive technologies are being used, so members of the PING suggested these risk areas be called out in every spec.
Note: Another action was for PING to research how to address some specific problems confidentially, so that a large list of potential AT Detection methods did not become a recipe for malicious actors.
Someone on yesterday's call mentioned that ReSpec had a classname to mark a feature as a potential fingerprinting risk, and suggested a similar method could be used to mark various features of HTML, DOM, CSS, and ARIA, as risk areas for AT Detection. I took an action to file this issue against ReSpec to request that feature. I'm not sure what other authoring tools are used by the other spec editors, but it's likely needed it more tools than just ReSpec.
Some additional info is available in ARIA Issue #1371. See other action items in my comment from Feb 12, 2021.
The text was updated successfully, but these errors were encountered: