> > [PW] Phil knows more about the intent so I’ll defer to his response at the > end of this thread. I would like to add that computer screens bigger than > mobile devices aren’t going away. So focusing only on mobile isn’t a good > idea. > > Thanks for the constructive conversation James, finally :) But I don’t > necessarily agree with your assertion about there being a lack of room to > support identity. It all comes down to priority as you know. We could have > said that Firefox mobile didn’t have enough room for tracking > icons/settings before it was implemented - but because Mozilla feels this > is important, they made the room. They made assertions about the lack of > real estate for identity prior to implementing visual indicators for > tracking. > > Mozilla once asserted that it wouldn’t implement any filtering > tools/preferences for any reason because it was considered “censorship”. > They have clearly changed their position - thankfully, with the filters for > trackers/ads. > > Mozilla dropped its mobile browser strategy completely for a long period > of time, but the team is now focused on mobile again. So things do change > with time and realization of market conditions and mistakes. Everyone makes > mistakes. > > >> It's right that we are removing the extended validation style visual >> security indicator from browsers because of a) the above statement b) >> > > One could argue that there’s less room inside an app WebView - where > there's so much inconsistency it hurts my head. Here’s an example of a > design implementation that *might* work to help demonstrate my point about > there being enough room - it’s not ideal but I only spent 5 minutes on it. > [1] >
I took a look at your concept of an extended validation type visual security indicator and the conclusion is that it doesn't provide any assurance to the users that the website is vetted or trustworthy. This concept is similar to the padlock visual security indicator and that too doesn't provide any assurance to the users that the website is vetted or trustworthy. The padlock visual security indicator only provides the user a visual indication that the connection is encrypted. Read Emily Stark's Twitter response regarding Chrome and the removal of the padlock visual security indicator: https://twitter.com/estark37/status/1183769863841386496?s=20 > normal users don't understand extended validation style visual security >> indicators c) >> > > Because they were never educated properly - UX sucked more than anything. > But you don’t just remove something without iterating to achieve > product/market fit. That’s what happened with identity. > Users shouldn't have to go through education lessons to recognise different positive visual security indicators. Its a stupid idea. Next stupid idea will be expecting users to go through a compulsory exam to learn about the different positive visual security indicators. If failed, they can't purchase goods online. If passed, they get a license issued to allow them to purchase goods online. Browsers iterating positive visual security indicators to achieve product/market fit is another stupid idea. It's good for CAs profit margins. It's bad for users as it will totally confuse them. Even if we did go down this stupid path, how many times would browsers need to change the visual security indicators to suit the CAs product? > the inconsistencies of extended validation style visual security indicator >> between browsers d) users can't tell who is real or not based on extended >> validation style visual security indicators as company names sometimes >> don't match the actual site name. >> > > I agree. This is why they should have been improved instead of removed. > Mozilla will likely iterated the UI/UX around tracking to improve adoption. > Above. Stupid idea. > > Ian, like every other commentator I’ve read on this subject, say things > that I agree with. But their conclusions and proposals are completely > flawed in my opinion. As I’ve said before, you don’t just remove something > that doesn’t see major adoption - you iterate/test. You’d only remove UI if > you know for sure that it can’t be improved - there’s no data to suggest > that any research was done around this. Mozilla have only supplied links to > research that’s flawed and so old it’s useless. I’m blown away by their > referencing research from more than 10 years ago. Some amazing people on > this list weren’t even working with web tech back then. > Extended validation isn't a new concept and it has been proven it has failed. > > > >> [1] https://www.typewritten.net/writer/ev-phishing >> [2] https://stripe.ian.sh >> > > > > [PW] [1] https://imgur.com/Va4heuo > > - Paul > > > > > The original proposal that led to EV was actually to validate the company > logos and present them as logotype. > There was a ballot proposed here to bar any attempt to even experiment > with logotype. This was withdrawn after I pointed out to Mozilla staff that > there was an obvious anti-Trust concern in using the threat of withdrawing > roots from a browser with 5% market share to suppress deployment of any > feature. > > Now for the record, that is what a threat looks like: we will destroy your > company if you do not comply with our demands. Asking to contact the > Mozilla or Google lawyers because they really need to know what one of > their employees is doing is not. > > Again, the brief here is to provide security signals that allow the user > to protect themselves. > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
