This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Industry:DOJ Nondiscrimination on the Basis of Disability"
From OWASP
(Created page with '__NOTOC__ Return to Global Industry Committee {| style="width:100%" border="0" align="center" ! colspan="4" align="center" style="background:#4058A0; color:white"|<font co…') |
(Responsibilities updated / Links added / Comments added) |
||
| Line 17: | Line 17: | ||
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles''' | | style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles''' | ||
| style="width:25%; background:#cccccc" align="center"|'''Primary'''<br>[mailto:alexander.fry(at)owasp.org '''Alexander Fry'''] | | style="width:25%; background:#cccccc" align="center"|'''Primary'''<br>[mailto:alexander.fry(at)owasp.org '''Alexander Fry'''] | ||
| − | | style="width:25%; background:#cccccc" align="center"|'''Secondary'''<br>[mailto:(at)owasp.org ''' | + | | style="width:25%; background:#cccccc" align="center"|'''Secondary'''<br>[mailto:lorna.alamri(at)owasp.org '''Lorna Alamri'''] |
| style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>Please use the [http://lists.owasp.org/mailman/listinfo/global_industry_committee Industry Committee list] | | style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>Please use the [http://lists.owasp.org/mailman/listinfo/global_industry_committee Industry Committee list] | ||
|} | |} | ||
| Line 43: | Line 43: | ||
| style="width:25%; background:#7B8ABD" align="center"| '''Resources''' | | style="width:25%; background:#7B8ABD" align="center"| '''Resources''' | ||
| colspan="3" style="width:75%; background:#cccccc" align="left"|[http://www.regulations.gov/search/Regs/home.html#documentDetail?R=0900006480b20b1a Document detail] | | colspan="3" style="width:75%; background:#cccccc" align="left"|[http://www.regulations.gov/search/Regs/home.html#documentDetail?R=0900006480b20b1a Document detail] | ||
| + | |||
| + | [https://docs.google.com/a/owasp.org/fileview?id=0B5wp7wNKKjxnYzg3MDI3MTctYzgzYy00MWQzLThmM2UtZjkwOWYzNWU3MzQz&hl=en Annotated version] | ||
| + | |||
| + | [https://spreadsheets.google.com/ccc?key=0AnrIOS37w1dAdDRPSXpWQzF3cXBpY3h4ZVhfTFlSQmc&hl=en&invite=CJPD_e4H Project plan] | ||
| + | |||
| + | [http://www.regulations.gov/search/Regs/home.html#docketDetail?R=DOJ-CRT-2010-0005 Other comments submitted] | ||
Response submission to Federal eRulemaking Web site: www.regulations.gov by 24th January 2011 | Response submission to Federal eRulemaking Web site: www.regulations.gov by 24th January 2011 | ||
| Line 67: | Line 73: | ||
=== Draft Text version 1 === | === Draft Text version 1 === | ||
| − | |||
| − | + | === CW's notes === | |
| + | |||
| + | [CW} I think the following questions posed by the DoJ are the most relevant for response by OWASP. My comments on each of those are included below | ||
| + | |||
| + | 1.) Should the Department adopt the WCAG 2.0s "Level AA Success Criteria" as it's standard for Web site accessibility for entities covered by Titles II and III of the ADA? Is there any reason why the Department should consider adopting another success criteria level of the WCAG 2.0? | ||
| + | |||
| + | :From a website security point of view, WCAG 2.0s "Level AA Success Criteria" is not inconsistent with having a secure website. Conformance levels A, AA and AAA all require additional considerations for security due to the use of: | ||
| + | :* input, storage and output of additional text | ||
| + | :* alternative forms of CATCHA | ||
| + | :* input, storage and output of additional files | ||
| + | :* third party services | ||
| + | :* additional client-side scripting | ||
| + | :* flexible session timeouts | ||
| + | :* enforcing code validity | ||
| + | :These can all be achieved using secure development practices, but the additional requirements increase complexity. There is one aspect in the more stringent "Level AAA Success Criteria" which would be difficult to achieve in a secure manner: | ||
| + | :* re-authentication recovery | ||
| + | :Reference: "Can an accessible web application be secure? Assessment issues for security testers, developers and auditors", Colin Watson, OWASP AppSec Europe 2009, http://www.owasp.org/images/2/22/AppSecEU09_owasp_appsec_eu09_colin_watson_2.ppt | ||
| + | |||
| + | 6.) What Resources and services are available to public accommodations and public entities to make their Web sites accessible? What is the ability of covered entities to make their Web sites accessible with in-house staff? What technical assistance should the Department make available to public entities and public accommodations to assist them with complying with this rule? | ||
| + | |||
| + | :The W3C WAI pages on WCAG 2.0 provide ample information. In particular the "Techniques and Failures for Web Content Accessibility Guidelines 2.0" provide excellent guidance and duplication of this effeort elsewhere would appear to be un-necessary. In terms of ensuring the security is maintained, we recommed OWASP's own guidance documents, standards and tools such as the Top Ten, Development Guide, Code Review Guide, Testing Guide, Application Securitity Versification Standard and the Software assurance Maturity Model. These are already referenced by organisations such as DISA, NIST, NSA and the FFIEC. | ||
| + | :Reference: OWASP Citations http://www.owasp.org/index.php/Industry:Citations'' | ||
| + | |||
| + | 7.) Are there distinct or specialized features used on Web sites that render compliance with accessibility requirements difficult or impossible? | ||
| + | |||
| + | :At Conformance Level AA, no. | ||
| − | + | 8.) Given that most websites today provide significant amounts of services and information in a dynamic, evolving setting that would be difficult, if not impossible, to replicate through alternative, accessible means, to what extent can accessible alternatives still be provided? Might viable accessible alternatives still exist for simple, non-dynamic Web sites? | |
| − | ' | + | :It is important that alternative means provide the same level of protection to the users, their data and the business systems, so that for example weaker authentication requirements in an alternative telephone service make it easier to steal a person's identity than through an online website service, or the telephone service can be used to assist exploitation of the website (e.g. enumerate usernames). |
| + | |||
| + | 19.) The Department is interested in gathering other information or data relating to the Department’s objective to provide requirements for Web accessibility under titles II and III of the ADA. Are there additional issues or information not addressed by the Department’s questions that are important for the Department to Consider? | ||
| − | + | :In the OWASP response to Question 1, we stated that an accessible website can be secure. It is also worth mentioning that an insecure website possibly may not be accessible because it would be possible to create web pages (responses) which are do not met the conformance requirements. A simple example would be injecting code which includes inaccessible content from a third party website, or which breaks the code validity because an extra H1 tag has been inserted. | |
| − | |||
Return to [[Global Industry Committee]] | Return to [[Global Industry Committee]] | ||
Revision as of 10:35, 18 October 2010
Return to Global Industry Committee
| ACTIVITY IDENTIFICATION | |||
|---|---|---|---|
| Activity Name | DOJ Nondiscrimination on the Basis of Disability | ||
| Short Description | Provide response to "Accessibility of Web Information and Services of State and Local Government Entities and Public Accommodations" | ||
| Related Projects | None | ||
| Email Contacts & Roles | Primary Alexander Fry |
Secondary Lorna Alamri |
Mailing list Please use the Industry Committee list |
| ACTIVITY SPECIFICS | |||
|---|---|---|---|
| Objectives |
| ||
| Deadlines |
| ||
| Status |
| ||
| Resources | Document detail
Response submission to Federal eRulemaking Web site: www.regulations.gov by 24th January 2011 | ||
Submission Response
Latest first
Final version
tbc
Draft Text version 2
tbc
Draft Text version 1
CW's notes
[CW} I think the following questions posed by the DoJ are the most relevant for response by OWASP. My comments on each of those are included below
1.) Should the Department adopt the WCAG 2.0s "Level AA Success Criteria" as it's standard for Web site accessibility for entities covered by Titles II and III of the ADA? Is there any reason why the Department should consider adopting another success criteria level of the WCAG 2.0?
- From a website security point of view, WCAG 2.0s "Level AA Success Criteria" is not inconsistent with having a secure website. Conformance levels A, AA and AAA all require additional considerations for security due to the use of:
- input, storage and output of additional text
- alternative forms of CATCHA
- input, storage and output of additional files
- third party services
- additional client-side scripting
- flexible session timeouts
- enforcing code validity
- These can all be achieved using secure development practices, but the additional requirements increase complexity. There is one aspect in the more stringent "Level AAA Success Criteria" which would be difficult to achieve in a secure manner:
- re-authentication recovery
- Reference: "Can an accessible web application be secure? Assessment issues for security testers, developers and auditors", Colin Watson, OWASP AppSec Europe 2009, http://www.owasp.org/images/2/22/AppSecEU09_owasp_appsec_eu09_colin_watson_2.ppt
6.) What Resources and services are available to public accommodations and public entities to make their Web sites accessible? What is the ability of covered entities to make their Web sites accessible with in-house staff? What technical assistance should the Department make available to public entities and public accommodations to assist them with complying with this rule?
- The W3C WAI pages on WCAG 2.0 provide ample information. In particular the "Techniques and Failures for Web Content Accessibility Guidelines 2.0" provide excellent guidance and duplication of this effeort elsewhere would appear to be un-necessary. In terms of ensuring the security is maintained, we recommed OWASP's own guidance documents, standards and tools such as the Top Ten, Development Guide, Code Review Guide, Testing Guide, Application Securitity Versification Standard and the Software assurance Maturity Model. These are already referenced by organisations such as DISA, NIST, NSA and the FFIEC.
- Reference: OWASP Citations http://www.owasp.org/index.php/Industry:Citations
7.) Are there distinct or specialized features used on Web sites that render compliance with accessibility requirements difficult or impossible?
- At Conformance Level AA, no.
8.) Given that most websites today provide significant amounts of services and information in a dynamic, evolving setting that would be difficult, if not impossible, to replicate through alternative, accessible means, to what extent can accessible alternatives still be provided? Might viable accessible alternatives still exist for simple, non-dynamic Web sites?
- It is important that alternative means provide the same level of protection to the users, their data and the business systems, so that for example weaker authentication requirements in an alternative telephone service make it easier to steal a person's identity than through an online website service, or the telephone service can be used to assist exploitation of the website (e.g. enumerate usernames).
19.) The Department is interested in gathering other information or data relating to the Department’s objective to provide requirements for Web accessibility under titles II and III of the ADA. Are there additional issues or information not addressed by the Department’s questions that are important for the Department to Consider?
- In the OWASP response to Question 1, we stated that an accessible website can be secure. It is also worth mentioning that an insecure website possibly may not be accessible because it would be possible to create web pages (responses) which are do not met the conformance requirements. A simple example would be injecting code which includes inaccessible content from a third party website, or which breaks the code validity because an extra H1 tag has been inserted.
Return to Global Industry Committee
