- From: Michael Cooper <cooper@w3.org>
- Date: Thu, 18 Dec 2014 11:20:20 -0500
- To: Brad Hill <hillbrad@gmail.com>, Mike West <mkwst@google.com>, Brad Hill <hillbrad@fb.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>, WAI Liaison <wai-liaison@w3.org>
- Message-ID: <5492FEC4.8040208@w3.org>
Hi Brad - a similar question was occurring to me as I was writing up the PF response. I'm going to have to go back to the group on it. There are accessibility APIs available, but whether they have features that correspond to security notifications, I don't know. Certainly we wouldn't want to introduce something untestable into the spec. So I'll ask the group to provide concrete guidance for how you would meet your CR exit requirements with this edit. Because of the timing with upcoming holidays, it may be into the beginning of January that we can get solid input from PFWG members. Will that be a problem for your timeline? Michael On 17/12/2014 4:46 PM, Brad Hill wrote: > Michael, > > I made them a "SHOULD" rather than "MUST" because I'm not clear if > such APIs always exist and how we can verify conformance to and > interoperability for such a requirement as part of our REC-track > process. So I thought... > "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." > But this is likely just my ignorance of the landscape. > > Are there examples of similar requirements in other specifications? > If we are going to make this a MUST, are there particular APIs we can > normatively reference and test frameworks we can use? > > thanks, > > Brad > > On Wed Dec 17 2014 at 12:38:33 PM Michael Cooper <cooper@w3.org > <mailto:cooper@w3.org>> wrote: > > Thank for your prompt response to the comments filed by the PFWG. > The group thinks the edits made largely address the comment. The > PFWG has one request for the changes implemented: the "SHOULD" > statement you added should be a "MUST". So the two instances of > "... SHOULD also be made available through accessibility APIs..." > we request be changed to "... MUST also be made available through > accessibility APIs...". > > The rationale is that these requirements are very important for > situations to which they apply. They only apply when the relevant > conditions stated in the rest of the paragraph are active. So they > are not across-the-board requirements - but are critical when > applicable. These relate to the requirements of User Agent > Accessibility Guidelines success criteria 4.1.1 > http://www.w3.org/TR/UAAG20/#sc_411 and 4.1.2 > http://www.w3.org/TR/UAAG20/#sc_412. (Those are provided for > reference, not as a request to add those to the specification.) > > > Michael > > > On 11/12/2014 6:53 AM, Mike West wrote: >> Brad's changes look reasonable to me. I've merged his patch, and >> will be happy to make further changes if deemed necessary. >> >> Thanks for reviewing the spec! >> >> -mike >> >> -- >> Mike West <mkwst@google.com <mailto:mkwst@google.com>>, @mikewest >> >> Google Germany GmbH, Dienerstrasse 12, 80331 München, >> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz >> der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine >> Elizabeth Flores >> (Sorry; I'm legally required to add this exciting detail to >> emails. Bleh.) >> >> On Wed, Dec 10, 2014 at 3:46 PM, Brad Hill <hillbrad@fb.com >> <mailto:hillbrad@fb.com>> wrote: >> >> Thank you, Michael. >> >> Please let me know if you believe the following changes are >> sufficient: >> >> https://github.com/w3c/webappsec/pull/110 >> >> -Brad Hill >> >> From: Michael Cooper <cooper@w3.org <mailto:cooper@w3.org>> >> Date: Wednesday, December 10, 2014 at 9:58 AM >> To: "public-webappsec@w3.org >> <mailto:public-webappsec@w3.org>" <public-webappsec@w3.org >> <mailto:public-webappsec@w3.org>>, WAI Liaison >> <wai-liaison@w3.org <mailto:wai-liaison@w3.org>> >> Subject: [MIX] PF comments on Mixed Content - accessible >> indication and user controls >> Resent-From: <public-webappsec@w3.org >> <mailto:public-webappsec@w3.org>> >> Resent-Date: Wednesday, December 10, 2014 at 9:58 AM >> >> The Protocols and Formats Working Group has reviewed the >> Mixed Content specification and has two comments: >> >> 1) Section 4.3 - UI Requirements >> http://www.w3.org/TR/2014/WD-mixed-content-20140722/#requirements-ux >> <https://urldefense.proofpoint.com/v1/url?u=http://www.w3.org/TR/2014/WD-mixed-content-20140722/%23requirements-ux&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=XPcXAKUl3phy%2FY%2Ft%2BlvgAEh9qYPjZHSeKjorGTIZU5s%3D%0A&s=5c5f053ec7c7d182281966f064f0648c8da272411726617ad0fe54fa6652ffbd> >> >> There is a requirement that the UI have a visual >> indication as to whether the connection is secure or not: >> >> >> If a request for optionally blockable passive >> resources which are mixed content is not treated as >> active content (per requirement #3 above), then the >> user agent MUST NOT provide the user with a visible >> indication that the top-level browsing context which >> loaded that resource is secure (for instance, via a >> green lock icon). The user agent SHOULD instead >> display a visible indication that mixed content is >> present. >> >> >> It is important to have a requirement that the indication >> is also available to assistive technology. Current >> implementations have an image icon that is not made >> available to accessibility APIs. >> >> 2) Section 4.4 - User Controls >> http://www.w3.org/TR/2014/WD-mixed-content-20140722/#requirements-user-controls >> <https://urldefense.proofpoint.com/v1/url?u=http://www.w3.org/TR/2014/WD-mixed-content-20140722/%23requirements-user-controls&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=XPcXAKUl3phy%2FY%2Ft%2BlvgAEh9qYPjZHSeKjorGTIZU5s%3D%0A&s=71fe814840bf2380b530e9334924d92417469034db7420a7920b26874757fded> >> >> There are some MAY statements about user agents offering >> controls to limit exposure to blockable passive content >> and active mixed content. Such controls need to be >> available to the assistive technology as well. >> >> For the PFWG, >> Michael Cooper >> >> >
Received on Thursday, 18 December 2014 16:20:31 UTC