Re: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned
On 2/6/2024 10:43 AM, John Levine wrote: In this case, Dave's right. Wow. Can't help yourself, can you? "In this case." As ad hominems go, that was almost creative. But alas, it was offset by being so thoroughly gratuitous. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned
The "Report as Spam” button is always there. They have normalized the practice for users to expect legitimate mail in spam boxes, thus causing more eyeballs around the junk. That is all spammers want. https://www.wsj.com/articles/google-and-yahoo-are-cracking-down-on-inbox-spam-dont-expect-less-email-marketing-dd124c19 Google and Yahoo Are Cracking Down on Inbox Spam. Don’t Expect Less Email Marketing. wsj.com All the best, Hector Santos > On Feb 6, 2024, at 1:43 PM, John Levine wrote: > > It appears that Jim Fenton said: >> On 5 Feb 2024, at 14:02, Dave Crocker wrote: >> >>> On 2/5/2024 1:56 PM, Jim Fenton wrote: And you will also provide citations to refereed research about what you just asserted as well, yes? >>> >>> >>> Ahh, you want me to prove the negative. That's not exactly how these things >>> go. >> >> You said that the URL lock symbol failed. Asking for research to back that >> up is not asking for you to >> prove the negative. I suspect there is research out there that backs up that >> statement, and I’m just >> asking for the same amount of rigor that you are asking for. > > In this case, Dave's right. Here's a conference paper from Google saying > that only 11% of users > understood what the lock meant. > > https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/ > > The annual Usenix SOUPS conferences are full of papers about failed security > UI. Here's this year's. > Don't miss the one saying that Gmail's message origin indicator doesn't work, > > https://www.usenix.org/conference/soups2023/technical-sessions > > R's, > John > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned
It appears that Jim Fenton said: >On 5 Feb 2024, at 14:02, Dave Crocker wrote: > >> On 2/5/2024 1:56 PM, Jim Fenton wrote: >>> And you will also provide citations to refereed research about what you >>> just asserted as well, yes? >> >> >> Ahh, you want me to prove the negative. That's not exactly how these things >> go. > >You said that the URL lock symbol failed. Asking for research to back that up >is not asking for you to >prove the negative. I suspect there is research out there that backs up that >statement, and I’m just >asking for the same amount of rigor that you are asking for. In this case, Dave's right. Here's a conference paper from Google saying that only 11% of users understood what the lock meant. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/ The annual Usenix SOUPS conferences are full of papers about failed security UI. Here's this year's. Don't miss the one saying that Gmail's message origin indicator doesn't work, https://www.usenix.org/conference/soups2023/technical-sessions R's, John ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
