I don't denigrate the recent work done. Not at all. This "exploit" is long known to those in the know.
My key objection is that there needs to be a way to validate that the brick and mortar bank you've done business with for years _is_ the same group as currenrtly has web domain xyz. Something significant is lost if that capability disappears. Some would argue that any diminished capability there qualifies the treatment to be removed. Some would argue that we should fix the holes in the scheme, even if those fixes are draconian and exclude startups. Can we accept that there is value in being sure that website XYZ actually is the bank down the road? On Mon, Dec 11, 2017 at 2:32 PM, James Burton <[email protected]> wrote: > EV is on borrowed time and deprecating EV is the most logical viable > solution right now and brings us one step forward in vanishing the old > broken web security frameworks of the past. Now that both me and Ian > have demonstrated the fundamental issues with EV and the way its displayed > in the UI, it's only time until the REAL phishing starts with EV. > > James > > On Mon, Dec 11, 2017 at 8:29 PM, Matthew Hardeman via dev-security-policy > <[email protected]> wrote: > >> The question that I have is whether the community might consider it >> in-scope to discuss enhancements (even fixes) to EV to arrive at assurance >> commensurate to its handling. >> >> Matt Hardeman >> >> On Mon, Dec 11, 2017 at 2:09 PM, Ryan Sleevi via dev-security-policy < >> [email protected]> wrote: >> >> > On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek < >> [email protected] >> > > >> > wrote: >> > >> > > >> > > >> > > Certainly, as you noted, one option is to improve EV beyond simply >> being >> > > an assertion of legal existence. >> > > >> > >> > Does this mean we're in agreement that EV doesn't provide value to >> justify >> > the UI then? ;-) >> > >> > I say it loaded and facetiously, but I think we'd need to be honest and >> > open that if we're saying something needs to be 'more' than EV, in >> order to >> > be useful and meaningful to users - which is what justifies the UI >> surface, >> > versus being useful to others, as Matt highlighted - then either EV >> meets >> > the bar of UI utility or it doesn't. And if it doesn't, then orthogonal >> to >> > and separate from efforts to add "Validation ++" (whether they be QWACS >> in >> > eIDAS terms or something else), then there's no value in the UI surface >> > today, and whether there's any value in UI surface in that Validation++ >> > should be evaluated on the merits of Validation++'s proposals, and not >> by >> > invoking EV or grandfathering it in. >> > _______________________________________________ >> > dev-security-policy mailing list >> > [email protected] >> > https://lists.mozilla.org/listinfo/dev-security-policy >> > >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
