> It can be useful to show X-Face or Gravatar from certain mails, such as
> those coming from a (trusted) forum (hint to Louis: it may be useful to
> be able to configure the images to show for specific senders)
Will be implementing something like this later on, probably for workplace
platforms. All my emails from GitHub discussions for example have the GitHub
logo right now, making individual users not that visually distinguishable.
GitHub sends a user header from which I could fetch the associated users'
avatar.
I didn't know about the X-Face header! Is that something still in use?
What kind of configurability would you be looking for? Aside from overriding
through contacts of course.
Groetjes,
Louis
Op donderdag 11 januari 2024 om 22:31, schreef Ángel via mailop
<mailop@mailop.org>:
> On 2024-01-11 at 17:43 +0100, Jaroslaw Rafa wrote:
> > And it's clearly visible from the Laurent's mail that if MUAs will display
> > the unverified BIMI logos (and what would prohibit them from that?) the
> > "authentication" factor can be even weaker than with no avatars at all -
> > because user who is convinced that the logo being displayed means that the
> > message is genuine, may not even look at the actual sender field.
> >
> > Also, if a hypothetical MUA displays BIMI logos, but also displays avatars
> > obtained by other means (one of the users in the thread mentioned a MUA he
> > develops that uses eg. favicons, or Gravatar service for that purpose), how
> > the user is supposed to distinguish which avatars are verified BIMI logos,
> > and which ones come from a totally different source?
>
> Every MUA must be able to show whatever it wants. And each one will
> have its own some design goals. Hopefully sane and consistent, albeit
> they might end up being chaotic at times.
>
> I see how some people may like seeing images along the profiles. I also
> see the benefit of (configurable) multiple sources for that.
>
> For example, Microsoft Outlook shows the profile images from Active
> Directory. This can be useful for instance for sorting out which guy
> was each one in a meeting, and makes much more sense to prioritize that
> over a BIMI logo of your own company, which would be relatively
> pointless to shown on pretty much every email.
>
> But if I have set a photo for that Contact (e.g. a Clown face for my
> boss), it should be showing *that* (albeit I might face some pushback
> from my boss or HR if they figure out).
>
> It can be useful to show X-Face or Gravatar from certain mails, such as
> those coming from a (trusted) forum (hint to Louis: it may be useful to
> be able to configure the images to show for specific senders),
>
> But, as Laurent mentioned, this is going to be prone for impersonation,
> with a goal of leading uers to phishing, BEC fraud, etc.
>
> A really important point here is that the BIMI logos themselves *must
> be validated* by the MUA. I have been looking at the draft [1], and
> while there are references to a "BIMI Evidence Document", which is
> supposed to validate whether I am allowed to use a trademarked logo (at
> an undefined jurisdiction, I was unable to find its specification, it
> simply says that "These are defined in a separate document".
>
> Perhaps Seth can bring some light on this. I think that is an integral
> part of the BIMI security properties, that it MUST contain both a hash
> of the allowed logo (or logos), the jurisdiction(s) where it was
> validated (see below) and the linked sender domains (plus whatever
> properties that are needed for validate that through PKI).
>
> And the receiver steps miss that they MUST compare the logo with the
> Evidence Document, and reject it if it mismatches.
>
> Otherwise, I could register a trademark IOCBYHZ with a random logo, and
> switch the contents of the url to a PayPal one. People are already
> registering ludicrous names as trademarks to enter the Amazon Brands
> program [2]. Registering a trademark and logo, plus acquiring a
> certificate, for a targeted attack to a company has an higher bar. But
> a successful CEO fraud could easily make it worth. Not to mention if
> the goal were to compromise the company, exfiltrate its trade secrets
> or launch a supply-chain attack.
>
> Having the certificate specify on which jurisdiction is the trademark
> registered would at least palliate “a bit” the known issue of colliding
> names/trademarks on separate jurisdictions[3][4] by allowing the
> clients to ignore (by policy) those in shady offshore jurisdictions
> and, ideally, showing only those pertinent to the user... if the MUA is
> somewhat able to figure out what "pertinent" means.
>
> Would that mean that companies may need to register an international
> trademark or apply for the same one in different jurisdiction for BIMI
> to show to their different users around the globe? (along the
> associated registration and certificate costs). I'm afraid that may end
> up being the case.
>
> Maybe some MUA will overlap a flag onto the trademark, or allow
> choosing which countries / trademarks it will honor.
>
> Although I doubt the users that the feature intends to protect would
> notice the small differences due, anyway.
>
> It's a complex issue with no easy solution. I feel we are back at the
> all EV Certificates scenario, with all the same unsolved problems. We
> just replaced names with logos.
>
> 1-
> https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification
> [https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification]
> 2-
> https://nymag.com/intelligencer/2023/01/why-does-it-feel-like-amazon-is-making-itself-worse.html
> [https://nymag.com/intelligencer/2023/01/why-does-it-feel-like-amazon-is-making-itself-worse.html]
> 3-
> https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/
> [https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/]
> 4- https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/
> [https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/]
>
> _______________________________________________
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
