search

w3c / uievents-key

UI Events KeyboardEvents key Values
https://w3c.github.io/uievents-key/
Other
15 stars 16 forks source link

Tasks for wide review #57

Open LJWatson opened 2 years ago

LJWatson commented 2 years ago

To prepare for horizontal review (as part of wide review) the following tasks need to be completed by the Editors:

Accessibility

Complete the FAST checklist. Document the responses in Markdown so I can include them when I open the request for review with the APA WG.

Create an "Accessibility" section in the specification that states this self-review has been completed, and documenting any accessibility considerations that were identified (if any).

I18n

Complete the short i18n checklist. Document the responses in Markdown so I can include them when I open the request for review with the I18n WG.

Privacy

Complete the self-review for privacy and security. Document the responses in Markdown so I can include them when I open the request for review with the Privacy IG and Security respectively.

Also take into account Mitigating browser fingerprinting in web specifications and RFC6973.

Create a "Privacy" section in the specification that states this self-review has been completed, and documenting any privacy considerations that were identified (if any).

Security

Referring to the self-review checklist completed for privacy, create an "Accessibility" section in the specification that states this self-review has been completed, and documenting any accessibility considerations that were identified (if any).

garykac commented 2 years ago

Accessibility

This specification simply defines a set of values that are valid for use in the KeyboardEvent's key attribute. Thus, it does not introduce any features that have accessibility concerns.

The FAST checklist has been completed and nothing is applicable to this specification.

A note related to the FAST checklist item: "If technology provides internationalization support". This specification inherently defines {{KeyboardEvent/key}} values that support international hardware, e.g., keyboards for different languages or layouts. It also defines many special keys which are given human-readable names (like "Shift", "Control", "Home" or "ArrowLeft").

These special key values are defined as human-readable strings so that code to detect special keys can be easier to understand. While these values are not intended to be exposed directly to users, there is nothing preventing that. Apps that choose to expose these values would need to determine whether or not it is appropriate to translate these strings for presentation (e.g.: presenting "Backspace" as "Suppr. arrière" for French users).

garykac commented 2 years ago

I18n

The short I18n checklist has been completed and none of the items apply.

garykac commented 2 years ago

Privacy / Security self-review

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? This spec defines a set of valid values for the key attribute of the various key events. This is necessary so that users can type text.

2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses? Yes

2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them? N/A

2.4 How do the features in your specification deal with sensitive information? N/A

2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions? No

2.6 Do the features in your specification expose information about the underlying platform to origins? The various key values could be used to infer that a user is using a keyboard with a particular locale (or IME) enabled.

2.7 Does this specification allow an origin to send data to the underlying platform? No

2.8 Do features in this specification enable access to device sensors? No

2.9 Do features in this specification enable new script execution/loading mechanisms? No

2.10 Do features in this specification allow an origin to access other devices? No

2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI? No

2.12 What temporary identifiers do the features in this specification create or expose to the web? None

2.13 How does this specification distinguish between behavior in first-party and third-party contexts? No difference

2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode? No difference from normal behavior

2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections? It sure does!

2.16 Do features in your specification enable origins to downgrade default security protections? Nope

2.17 How does your feature handle non-"fully active" documents? This attribute is only associated with key events, and they are not sent if the document is not fully active.

2.18 What should this questionnaire have asked?

3.1 Passive Network Attackers N/A. These are values for a static attribute on an event.

3.2. Active Network Attackers N/A

3.3. Same-Origin Policy Violations N/A

3.4 Third-Party Tracking N/A

3.5 Legitimate Misuse A site could capture all keypresses and build a map of the values generated by the keyboard. If the user types enough values (and doesn't change keyboard), then the site could try to match those values against a database of known keyboard layouts to guess the user's current keyboard layout.

garykac commented 2 years ago

The appropriate sections of the specification have all been updated with this information.

LJWatson commented 1 year ago

Thanks @garykac. Requests for horizontal review have been made...

LJWatson commented 1 year ago

The A11y review appears to be complete. They had one question about braille and other alternate input devices, but I've responded to explain that to the best of my knowledge these devices utilise standard key codes and values and so they're implicitly covered already. I've asked APA to confirm there are no issues arising on the Github issue.

The I18n review is still pending and I've sent a gentle nudge for news.

The PING review is complete with no issues arising.

There has been no response from the Sec review. I've sent a gentle nudge with a CC to PLH.

The TAG review is complete with no issues arising.

Sugest we leave it another week or so in case the I18n review completes, then I think it's OK to begin the transition process unless @marcoscaceres or @siusin think otherwise?

marcoscaceres commented 1 year ago

Moving forward with the transition sounds good.