Re: [MIX] PF comments on Mixed Content - accessible indication and user controls

Based on the minutes, it sounds like the tests being proposed are manual.
That certainly makes sense, and would be possible to do across browsers and
platforms.

It's not clear, however, that there's any automated mechanism that could
test compliance cross-browser.

Regardless, I've poked at this text in
https://github.com/w3c/webappsec/commit/c32992a2665eef20f4b4ac97fdaf00473137b461
to change the requirement to MUST. I hope that addresses your concerns.

-mike

--
Mike West <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, Jan 14, 2015 at 9:15 PM, Michael Cooper <cooper@w3.org> wrote:

>  Hi Brad - PF discussed this comment last week and this week. Members of
> the group think it is possible to test the user agent exposure to
> accessibility API of notifications of mixed content. We recognize that you
> may need some guidance, and one of our members has an action to provide
> information about this for one user agent, which will hopefully lead to
> being able to describe it for other user agents as well.
>
> PF discussion: http://www.w3.org/2015/01/07-pf-public-minutes.html#item08
> Cynthia's action https://www.w3.org/WAI/PF/Group/track/actions/1550
>
> Let us know if you are getting done with your comment processing this
> issue remains open.
>
> Michael
>
>
> On 18/12/2014 11:59 AM, Brad Hill wrote:
>
> That should be fine, thank you Michael.
>
> On Thu Dec 18 2014 at 8:20:25 AM Michael Cooper <cooper@w3.org> wrote:
>
>>  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> 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>, @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> 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>
>>>> Date: Wednesday, December 10, 2014 at 9:58 AM
>>>> To: "public-webappsec@w3.org" <public-webappsec@w3.org>, WAI Liaison <
>>>> wai-liaison@w3.org>
>>>> Subject: [MIX] PF comments on Mixed Content - accessible indication
>>>> and user controls
>>>> Resent-From: <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
>>>>
>>>>
>>>
>>>
>>
>