> On Oct 24, 2019, at 2:59 PM, Julien Vehent via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> On Thursday, October 24, 2019 at 5:31:59 PM UTC-4, Paul Walsh wrote:
>> There is zero data from any company to prove that browser UI for website 
>> identity can’t work.
> 
> https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf

I’ve read this. It’s 13 years old! And consisted of 27 users broken into 
groups. I’m surprised that’s being cited as meaningful research/data in 2019. 
Some participants here weren’t even out of high school back then. I’m jealous.

I don’t know if you read our findings already Julien [1] but we conducted the 
same research with 85,000 active users over a period of 12 months - Chrome, 
Brave, Firefox and Opera. I have documented the entire process along with the 
method used to determine whether or not the visual indicator had achieved 
product/market fit. Our research started in December 2017 and lasted more than 
a year. This same software is now being sold into businesses of different 
sizes. Since it was first released, we have had zero victims of a deceptive 
website. And according to our MSP partners, their support calls and emails are 
massively reduced because when relying on the visual indicator we designed, 
they are less likely to report “suspicious” emails or websites. 

It’s by no means perfect, but when a popular crypto DNS was compromised we 
changed the classification so it was immediately blocked. This is an edge case 
that requires more work.

For context, my engineers were the same people who built the official browser 
add-ons for digg, Delicious, Yahoo!, eBay, PayPal, Google and Microsoft. They 
contributed to Firefox bug fixing and my COO started the Firefox developer 
evangelist community. Our first API for child safety was supposed to be 
integrated with Firefox but weirdly one engineer thought it was censoring the 
web so Chris Hoffman, Mitch and others decided not to proceed.

So, we’re a tiny player, but there are fewer people with more experience in 
browser software, visual indicators and URL Classification. This doesn’t mean 
we’re more right - it just means that our assertions should be taken seriously 
and not disregarded as “vendor marketing”. 

We also built the first ever security integration for native email clients - 
here’s a video demo of link annotation for the Apple Mail client 
https://www.youtube.com/watch?v=elutAAsboyE - visual indicators can and do work 
when done well. 

It was very easy for us to educate users of the visual indicators and it was/is 
easy for them to rely on them. Similar to how I suspect you want users to rely 
on your new UI for tracking. We didn’t even have a website for this product 
until about 3 weeks ago and our on boarding sucks right now.

I would urge you to read about this and feel free to ask me any question you 
like in public or private. Please, when you read it though, assume that I love 
https, free dv certs, the lock and encryption - my article talks about the 
downside in regards to “how” these are being implemented.

Furthermore, my R&D into visual indicators started in 2004 - before EV was even 
considered by its creators. Every member of the W3C Semantic Web Education & 
Outreach Program (of which I was a member) voted our ‘proof of concept’ add-on 
as one of the most compelling implementations of the Semantic Web 
https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ 
<https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/> I’m highlighting this 
because the data/research we did back then isn’t relevant today - just like the 
research you refer to isn’t relevant today in my opinion. 

Timing and market conditions is everything. In my article I also draw 
conclusions about the relationship between phishing and the other components 
mentioned - using a massive number of data points from various cybersecurity 
companies that face these problems daily.

> 
> "In this paper, we presented a controlled between-subjects evaluation of the 
> extended validation user interface in Internet Explorer 7. Unfortunately, 
> participants who received no training in browser security features did not 
> notice the extended validation indicator and did not outperform the control 
> group.”

If this was true, no browser vendor would be able to release new features for 
anything. That said, browser settings is generally where UX goes to die a slow 
death. But some browser vendors do some things very well - Firefox tracking is 
good. Brave “shields" is probably the best implementation of anti-tracking I’ve 
seen because it’s the main utility. 

> 
> https://storage.googleapis.com/pub-tools-public-publication-data/pdf/400599205ab5a1c9efa03e2a7c127eb8200bf288.pdf
> 
> "We conclude that modern browser identity indicators are not effective.   To 
> design better identity indicators,  we  recommend  that  browsers  consider  
> focusing  on active negative indicators, explore using prominent UI as an 
> opportunity for user education, and incorporate user research into the design 
> phase."
> 
> And more at 
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md

[PW] More of the same I’m afraid. Both research and implementation of website 
identity has been executed poorly to say the least. This is pretty much all 
I’ve been working on since I co-instigated the creation of the W3C 
Recommendation for URL Classification that replaced PiCS in 2009. Our original 
motivation was to help people with disabilities find search results that 
contained links to sites that were accessible to them based on their user 
profiles. 

I digress. But that’s where my research started - my first company provided a 
trustmark to companies that complied with W3C WCAG. When we contributed to 
those specs we found that websites which complied with the categories, it 
didn’t really help real users who have different requirements. OK now I’m 
really digressing :-) 

[1] https://casecurity.org/2019/10/10/the-insecure-elephant-in-the-room/ 
<https://casecurity.org/2019/10/10/the-insecure-elephant-in-the-room/> 

- Paul

> 
> 
> - Julien
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to