- From: John Foliot <john.foliot@deque.com>
- Date: Tue, 20 Jun 2017 11:06:15 -0500
- To: Janina Sajka <janina@rednote.net>
- Cc: Gregg C Vanderheiden <greggvan@umd.edu>, Jason J White <jjwhite@ets.org>, "lisa.seeman" <lisa.seeman@zoho.com>, Alastair Campbell <acampbell@nomensa.com>, "public-cognitive-a11y-tf@w3.org" <public-cognitive-a11y-tf@w3.org>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxy=KeC+dXzCFjUCs1z8GnNfhHcV=ru+LAFeZ_jfXgnT_g@mail.gmail.com>
Hi Janina, I think we are in agreement, but discussing different perspectives. I'll attempt a visual metaphor here, as a means to illustrate my concern. As I read Lisa's comment, I visualize a single slider widget, with security on the left, and ease-of-use on the right (imagine a left-right panning slider), based upon this comment: "People will need to take the security alternative that give the right balance between security and easy of implementation for their scenario." - with a focus on the word *balance*. In actual fact, I believe the correct visual metaphor is that there are *two* sliders - one for security, the other for ease of use, with each horizontal slider ranging from "minimal" to "maximum". The goal as I understand it is to move the ease-of-use slider to a place that accommodates as many users as possible - however we cannot move the security slider in a direction that would make the application "easier" to use at the cost of security, which is how I am reading Lisa's comment today. There cannot be a trade-off here, the requirements (accessibility *AND* security) need to be kept separate. Lisa then wrote: > What I said was people will pick the alternative based on their scenario and security needs. Hi Lisa, I'm not sure who you mean by "people" - authors or end users? End users today have no choice but to use the method(s) provided by the authors, and I am hard-pressed to find a content author who today is choosing an authentication scheme that is harder than it needs to be, just for the sake of making it harder: in fact many banking sites I know of here in the US are now also offering software tokens and bio-metric alternatives already (fingerprint on cell devices) , despite the fact that those "solutions" still leave some users out in the cold. JF On Tue, Jun 20, 2017 at 10:14 AM, Janina Sajka <janina@rednote.net> wrote: > John: > > I have to disagree with you. > > When APA met with the Web Authentication Working Group during TPAC in > Lisbon, perhaps the key point the security folks wanted us to understand > is that every login attempt is evaluated against some scale of > confidence. They do not think in terms of 100% confident, or the > opposite. It's always some kind of inbetween level based on whatever > factors they use, how the data appears (e.g. what IP it comes from), > etc. > > Some sites will have stricter confidence requirements, others not so > much. > > > hth > > Janina > > > John Foliot writes: > > Lisa wrote: > > > > > People will need to take the security alternative that give the right > > balance between security and easy of implementation for their scenario. > > > > Hi Lisa, > > > > With respect, I think this may be part of the problem > > . > > > > When I read what you just wrote, it appears to indicate that you believe > > there is a trade-off possible here between accessibility and security - > > that there is a balance question here that needs to be addressed at > scale. > > > > There isn't such a balance, and I strongly suspect that at some level > there > > never will be, certainly not for high-security situations such as > banking > > and medical services (to name two critical / high-security situations). > The > > closer we get to "ease of implementation", the easier it becomes to spoof > > or automate (hack) the required authentication task, which then weakens > the > > security, not only for the individual user, but perhaps of an entire > system > > - which no high-security application will accept at any cost. > > > > I can appreciate that this isn't a great answer, but it remains part of > our > > larger problem. That is one of the reasons why I have previously asked > > about splitting this into 2 SC - one for low-security needs (for example > > commenting on a blog) versus high-security needs (doing my banking > online). > > We've previously drawn that distinction before, with SC # > > 3.3.4 Error Prevention (Legal, Financial, Data) > > - https://www.w3.org/TR/WCAG20/#minimize-error-reversible and thinking > > about the problem statement at two levels of security requirements may > help > > us achieve something here, if not all that you seem to be asking for now. > > > > > > > they have been reviewed by security experts > > > > This is interesting, have you shared that feedback with the larger group? > > > > (I apologize in advance if yes, and I missed it). > > If not, could you do so please? > > > > > > > > Meanwhile, Jason wrote: > > > > > It’s clear that... > > > > we need more secure, and less demanding, authentication mechanisms. > > > > Amen. This need transcends persons with disabilities however, even if or > > when the impact is more significant to specific user-groups. > > > > "Passwords" alone have proven too brittle and fragile for any number of > > reasons, including some of the issues this SC is attempting to address. > > Unfortunately, some of the brightest minds on the planet, at companies > > ranging from Google, Amazon, and IBM, to Microsoft, Apple, Facebook and > > more (and I didn't even mention high-security players like the banking > > industry, who trust me are all over this as well) have still not come up > > with an equitable solution that addresses all of these known problems. > > > > In the case of browsers, the best they have managed to offer us to date > > appears to be built-in password managers inside of the browser, which > also > > raises a question: if a password manager "remembers" a password, which > > presumably takes a lot of pressure off of the end user with short-term > > memory issues, then does that (the PW manager) meet the functional > > requirement(s)? How do we as evaluators then test for that? How do we > even > > take that into account when drafting the normative SC language? > > > > Research and experience confirms that this is a serious problem - and I > can > > appreciate that for the COGA TF this was likely one of the more critical > > concerns looking to be addressed. However, given the backdrop and current > > state of technology today, I cannot see this SC succeeding as written > > today, at least not without addressing the high-security scenario at a > > minimum. > > > > And for that I am saddened. > > > > JF > > > > > > On Mon, Jun 19, 2017 at 1:23 PM, Gregg C Vanderheiden <greggvan@umd.edu> > > wrote: > > > > > +1 to Jason’s concern about security of these. Have they been vetted > by a > > > security specialist? > > > > > > > > > Also — are these supposed to be easier than copying something ? > > > > > > All of these appear to be cognitively much more complicated than > copying > > > information from one place into the field. As such - is this > something > > > where the solution requires more cognitive skills than the problem? > > > > > > Has anyone demonstrated that someone who cannot copy information — can > do > > > any/all of these? That these are indeed simpler? > > > > > > If not - then is there any grounds for assuming that any of these will > > > reduce the cognitive demands on a person….. > > > > > > These all sound complicated to me…. > > > > > > *g* > > > > > > Gregg C Vanderheiden > > > greggvan@umd.edu > > > > > > > > > > > > > > > On Jun 19, 2017, at 1:48 PM, White, Jason J <jjwhite@ets.org> wrote: > > > > > > > > > > > > *From:* lisa.seeman [mailto:lisa.seeman@zoho.com <lisa.seeman@zoho.com > >] > > > *Sent:* Monday, June 19, 2017 1:30 PM > > > > > > We are allowing multiple alternatives, such as: > > > > > > - two step authentication that has a link to press as an > alternative > > > to entering a code > > > > > > *[Jason] What are the security implications, if any? The server > comprising > > > the destination of the link could be attacked (e.g., by trying > different > > > values for the data carried in the link in succession).* > > > > > > - two step authentication using devices that sends a tokens via > > > Bluetooth > > > > > > *[Jason] These are promising as an idea, but without standardization, > the > > > user may end up having to use several different devices with different > Web > > > sites – not a desirable outcome. I think these could only be required > in > > > WCAG when the standards are in place.* > > > > > > - Email resetting is an option for most places, including google > if > > > people have an alternative address > > > > > > *[Jason] This isn’t suitable for high security applications, since > anyone > > > who gains access to the e-mail account can compromise the security of > the > > > system.* > > > > > > - login in via something like facbook > > > > > > *[Jason] This involves trusting/relying on a third party to perform the > > > authentication. If I remember correctly, this is known to have serious > > > security shortcomings.* > > > > > > - conformance to the web authentification specification at > > > https://www.w3.org/TR/webauthn/ <https://www.w3.org/TR/webauthn/> > > > > > > *[Jason] This is the most promising of your alternatives. Will it be > > > practically available by the time WCAG 2.1 enters Candidate > Recommendation?* > > > > > > In short, I think most of the options are at least suspect from a > security > > > point of view. > > > > > > > > > ------------------------------ > > > > > > This e-mail and any files transmitted with it may contain privileged or > > > confidential information. It is solely for use by the individual for > whom > > > it is intended, even if addressed incorrectly. If you received this > e-mail > > > in error, please notify the sender; do not disclose, copy, distribute, > or > > > take any action in reliance on the contents of this information; and > delete > > > it from your system. Any other use of this e-mail is prohibited. > > > > > > Thank you for your compliance. > > > > > > > > > > > > > > > -- > > John Foliot > > Principal Accessibility Strategist > > Deque Systems Inc. > > john.foliot@deque.com > > > > Advancing the mission of digital accessibility and inclusion > > -- > > Janina Sajka, Phone: +1.443.300.2200 > sip:janina@asterisk.rednote.net > Email: janina@rednote.net > > Linux Foundation Fellow > Executive Chair, Accessibility Workgroup: http://a11y.org > > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) > Chair, Accessible Platform Architectures http://www.w3.org/wai/apa > > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Tuesday, 20 June 2017 16:06:50 UTC