Issue 508: Horizontal review updates to security considerations

[maryjom]

Per Issue #508 this is a draft PR to update the Security Considerations section. If you have edits to propose, please use the Google doc.

[netlify]

✅ Deploy Preview for wcag2ict ready!

Name	Link
🔨 Latest commit	3061345
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2ict/deploys/66e9a448723c420008d5ec00
😎 Deploy Preview	https://deploy-preview-510--wcag2ict.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[bruce-usab]

I offer an iteration (Option 3) on @iadawn suggestion in the Google doc. I drop "however" and start with "as with any additional features".

This Working Group Note does not introduce any new security considerations. As with any new additional features, implementing WCAG 2 success criteria in the context of non-web ICT could potentially be exploited to compromise software security features. It is best practice to choose implementations that reduce the potential for unauthorized access (e.g. ability to bypass logins and CAPTCHAs) or introduction of malicious software by cyberattacks.

I am also okay with Option 1 (no change) and Option 2 as proposed.

[daniel-montalvo]

Based on Bruce's suggestion, I would remove "new additional"and just use "other" instead.

While it sometimes happens that accessibility comes as an afterthought, additional implementation, that's not always the case. This "new additional" would not cover well the use cases where accessibility has indeed been included from the beginning of the project.

This Working Group Note does not introduce any new security considerations. As with any new additionalother features, implementing WCAG 2 success criteria in the context of non-web ICT could potentially be exploited to compromise software security features. It is best practice to choose implementations that reduce the potential for unauthorized access (e.g. ability to bypass logins and CAPTCHAs) or introduction of malicious software by cyberattacks.

[maryjom]

These two latest proposals got rid of "accessibility" in "accessibility features" - which was a main point in the issue. I'll work on updating the proposal in the Google doc so we can swiftly settle on the right language. See Option 4 there. I can update the PR with the language once we settle on the right way to say it.

[loicmn]

+1 to option 4 in the Google Doc.

[mapluke]

Also +1 to Option 4 in the Google doc.

[mitchellevan]

+1 to option 4, with edits. I made my edits directly in option 4 in the Google doc, with a suggestion to @maryjom to call this option 5.

[bruce-usab]

+1 to Option 5 in Google doc, @mitchellevan edits to option 4. Copy/paste:

This Working Group Note does not introduce any new security considerations. As with any other software features, when implementing non-web ICT features to meet WCAG 2 success criteria, accessibility features could potentially be exploited to compromise software security features. It is best practice to choose implementations that reduce the potential for unauthorized access (e.g., ability to bypass logins and CAPTCHAs) or introduction of malicious software through cyberattacks.

NOTE: The WCAG 2 Security Considerations section also lists specific success criteria with possible implications for security, which could also exist for non-web ICT.