Subject: [Bimi] (non)desire for bimi

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Feb 2019 10:57:54 +0000

(Sorry for not replying in-thread but I just subscribed
to the list, and this perhaps also deserves a separate
thread.)

>>> * Internet users want it - clear demand
>>
>> That claim keeps being made but I've never seen any serious
>> documentation for it.
>
> Marketing people want it -- that may not be documented but I have
> sufficient anecdotes to hand to believe it be the main driver here.

I'd be interested in some kind of verifiable backup
for that "clear demand" claim - I'm unaware that
such exists, other than perhaps as Richard says for
marketing purposes, and ISTM those purposes are amply
met already via mail bodies.

Meanwhile...

I use the Internet. I do not want logos added to mail
headers that increase the attack surface of my MUAs,
(and MS/MTAs), that likely enable additional tracking
of mail users, including me, and where mobile device
and web MUAs are unlikely to offer me an option to
turn all that off, even if some desktop MUAs might
(eventually), at the risk of making messages harder
to comprehend.

I also just do not want to see your logos, thanks.
Imposing those on me would decrease the utility of
mail. And regardless of what PKI were built I would
not treat bimi'd messages any better, more likely
I'd consider them badly.

As someone who sends email (not as a bulk sender)
from various domains that I operate, I do not want
to pay €€€ to someone for an additional cert, nor
for an "approved" logo, in order to increase the
chances that my mail gets delivered. Things in that
respect are bad enough, and this proposal seems to
me likely to only worsen the situation for those
who operate small domains, presumably to the benefit
of those who operate large mail infrastructures
and CAs who issue certs for money.

I also do not want to have to check if someone else
has abused a logo I may use in some CT log. I do
not want to have to process additional headers in my
MTAs nor retrieve and store your logos in some new
image store. I do not want to have to deal with any
of the new problems that'll arise when any of that
breaks.

So: No thanks, from me. Personally, as a mail user
I only see downsides to this whole idea.

Thanks,
S.

---

From: Terry Zink <[email-masked]>
Date: Thu, 14 Feb 2019 17:08:00 +0000

Thanks for your comments, Stephen. Here are my thoughts.

> for that "clear demand" claim

To me, it seems intuitively obvious. For example, in the Office 365 web interface, I see logos from several different companies in the list view and the sender photo when I open the message - Amazon, Lyft, Facebook, LinkedIn, Netflix, BackCountry, Quora, etc (this is displayed via Microsoft's Brand Cards program). My old Yahoo Mail interface has something similar. For a while, Gmail showed a company logo pulled from its Google+ page.

How does this not show demand? Isn't this an example of web mail providers wanting to enhance the user experience, and companies happily obliging, and me as a user being pleased?

I am not representative of the entire space, but I really *like* those sender photos.

> (eventually), at the risk of making messages harder

I'm not sure I understand this comment. The logos are not added to mail headers, but instead headers point to a location where the logo can be picked up and then shown to the end user. What's the difference between the sender/brand providing an authoritative source (DNS record that points to a CDN) vs Office 365/Yahoo pulling from their own internal database?

> I also just do not want to see your logos, thanks.

Again, I am not sure I understand this comment.

Logos are everywhere. Most large companies have Facebook and Twitter pages, and they all have logos. You see logos painted on the sides of walls, on stores, on TV, in newspapers, on web pages, as favicons, etc.

Are you saying these are all fine but in the sender photo it isn't? What's the fundamental difference between seeing a company's logo in the sender photo vs seeing it in the body of an email? Is it just a matter of turning of HTML and preventing those from loading?

> chances that my mail gets delivered.

Nobody is going to make you buy a cert, nobody is going to make you buy a logo, and so forth. It's up to you.

BIMI is an add-on; it augments the default experience, the lack of it doesn't downgrade the default experience.

> of the new problems that'll arise when any of that

Again, I'm unclear about the context of this statement. Nobody is going to make you as a sender, brand, or receiver send with BIMI. Nobody is going to make you retrieve logos from a store, nobody is going to make you verify any log, nobody is going to make you process additional headers.

Instead, it's about enhancing the email experience for those motivated to do so. And, BIMI provides a way to do this.

--Terry

________________________________
From: bimi <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Thursday, February 14, 2019 2:57 AM
To: [email-masked]
Subject: [Bimi] (non)desire for bimi

Meanwhile...

Thanks,
S.

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2019 12:52:42 -0500

In article <[email-masked]> you write:
>How does this not show demand? Isn't this an example of web mail providers wanting to enhance the user
>experience, and companies happily obliging, and me as a user being pleased?

I think you're extrapolating from a point.  To extrapolate from
another point, I find all those blinky things extremely annoying and
specifically choose mail software that does not show them.

>I'm not sure I understand this comment. The logos are not added to mail headers, but instead headers
>point to a location where the logo can be picked up and then shown to the end user. What's the
>difference between the sender/brand providing an authoritative source (DNS record that points to a CDN)
>vs Office 365/Yahoo pulling from their own internal database?

It makes it in effect another web bug.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 14 Feb 2019 10:06:27 -0800

> specifically choose mail software that does not show them.

Indeed.

      1. An axiom in usability research is to not treat developers or 
researchers as subjects (unless they really are the target audience.) 
In terms of cognitive detail and usage style, such folk differ 
substantially from the general user population.

      2. Any general claim about users in general needs to have some 
sort of statistical basis that gives credence to that generalization.

Simply put, you or I or John do not matter in this calculus.  We are the 
essence of a biased sample...

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Terry Zink <[email-masked]>
Date: Thu, 14 Feb 2019 18:23:21 +0000

Thanks John, and Dave.

> essence of a biased sample...

I agree, which is why I said earlier that I am not representative of the entire space.

> specifically choose mail software that does not show them.

Yes, there are some people that don't like this type of UX. And with BIMI, you'll still be able to use the same software that doesn't show images, HTML, sender photos, etc. There's no change there.

> It makes it in effect another web bug.

Hmm...

That heavily depends upon implementation. A web bug, as I understand it, helps to track user behavior - did the user open up my mail? While I concede that BIMI could be used this way, it's not a particularly effective way to do it. It would require setting up a lot of DNS records, and then being able to stand up infrastructure that can handle all those requests.

Most large receives wouldn't serve up a BIMI logo from the actual location pointed to by headers/DNS records each time they needed it. Instead, they'd periodically poll the logos/certs they need, upload them into a local database, and then pull from there. So, as a sender/brand, you might send out 100,000 messages to a single receiver and intend to use BIMI to see how many people interacted with the message. But in reality, you might see only 1 request - the one where that receiver saw it needed your logo and then downloaded it after verifying it. And then 30 days later, you saw them download it again.

So, while a web bug is a possible concern, a large receiver (and I would think even a medium sized one) would have to make use of more efficient architectural implementations to make the web bug concerns a minor one on the list of things to worry about.

--Terry

________________________________
From: bimi <[email-masked]> on behalf of Dave Crocker <[email-masked]>
Sent: Thursday, February 14, 2019 10:06 AM
To: John Levine; [email-masked]
Cc: Terry Zink
Subject: Re: [Bimi] (non)desire for bimi

Indeed.

--
bimi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bimi

---

From: Dave Crocker <[email-masked]>
Date: Thu, 14 Feb 2019 10:35:22 -0800

> I agree, which is why I said earlier that I am not representative of the 

Except that you only cited yourself and then said "How does this not 
show demand?"  You started with "To me, it seems intuitively obvious."

If there is anything in usability design that would qualify as speech of 
the devil, that sentence probably qualifies.

Usability design often needs to make choice that goes exactly against 
what is "intuitive" to one person or another.  By way of example, there 
is a common view that giving end users more information is always a good 
thing, but this flies in the face of well-understood cognitive limits.

> Yes, there are some people that don't like this type of UX. And with 
> BIMI, you'll still be able to use the same software that doesn't show 
> images, HTML, sender photos, etc. There's no change there.

This is another fundamental usability design error:  thinking that 
adding something is fine because users can turn it off.  This burdens 
users, and often creates a barrier because they don't know how to fix it 
or even that they can.

> That heavily depends upon implementation. A web bug, as I understand it, 
> helps to track user behavior - did the user open up my mail? While I 
> concede that BIMI could be used this way, it's not a particularly 
> effective way to do it.

So you are countering a security concern by saying that we should not 
worry about it because there are other vectors you consider better?

This suggests that additional attack vectors aren't to be worried 
aboout, as long as easier ones are available?

> Most large receives wouldn't serve up a BIMI logo from the actual 
> location pointed to by headers/DNS records each time they needed it. 

I don't understand how this point is relevant to the underlying concern.

How is a statement predicated on "most" a useful security concern 
counter?  It almost sounds as if systems not part of that 'most' don't 
matter...

d/

---

From: Richard Clayton <[email-masked]>
Date: Thu, 14 Feb 2019 18:50:36 +0000

In message <[email-masked]
1.prod.outlook.com>, Terry Zink <tzink=[email-masked]>
writes

>    That heavily depends upon implementation. A web bug, as I 
>    understand it, helps to track user behavior - did the user open up 
>    my mail? While I concede that BIMI could be used this way, it's not 
>    a particularly effective way to do it. It would require setting up 
>    a lot of DNS records, and then being able to stand up 
>    infrastructure that can handle all those requests.

... and surely marketing people would never do that ?+

>    location pointed to by headers/DNS records each time they needed 
>    it. Instead, they'd periodically poll the logos/certs they need, 
>    upload them into a local database, and then pull from there.

Please explain how they would "poll the certs they need" ?

I understand that they might cache certificates that they had already
fetched once, but that's not the same thing at all.

How do they know what certificates they need a priori ? is it just for
the brand owners who have sent them cheques to pay for the display of
their logo ??

>    So, as 
>    a sender/brand, you might send out 100,000 messages to a single 
>    receiver and intend to use BIMI to see how many people interacted 
>    with the message. But in reality, you might see only 1 request - 
>    the one where that receiver saw it needed your logo and then 
>    downloaded it after verifying it. And then 30 days later, you saw 
>    them download it again.

the way you would get tracking (and of course mess up the caching
behaviour by the mail receiver) would be to use a different (sub)domain
for every email...

... so if you wish to forbid this (or make it expensive) you need
language about wildcard certificates.  Where do I find that in the spec?

>    So, while a web bug is a possible concern, a large receiver (and I 
>    would think even a medium sized one) would have to make use of more 
>    efficient architectural implementations to make the web bug 
>    concerns a minor one on the list of things to worry about.

the reverse -- without protocol restrictions the large receiver would be
worried that their caching architecture was subject to attack

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Feb 2019 18:44:42 +0000

Hi Terry,

(I agree with both John and Dave's points upthread so will try
not repeat those, but I'm happy to elaborate if it's useful.)

On 14/02/2019 17:08, Terry Zink wrote:
>> I'd be interested in some kind of verifiable backup for that "clear
>> demand" claim
> 
> To me, it seems intuitively obvious. For example, in the Office 365
> web interface, I see logos from several different companies in the
> list view and the sender photo when I open the message - Amazon,
> Lyft, Facebook, LinkedIn, Netflix, BackCountry, Quora, etc (this is
> displayed via Microsoft's Brand Cards program). My old Yahoo Mail
> interface has something similar. For a while, Gmail showed a company
> logo pulled from its Google+ page.
> 
> How does this not show demand? Isn't this an example of web mail
> providers wanting to enhance the user experience, and companies
> happily obliging, and me as a user being pleased?
>

Right. And nor am I representative in my dislike of such.

> 
>> I use the Internet. I do not want logos added to mail headers that
>> increase the attack surface of my MUAs, (and MS/MTAs), that likely
>> enable additional tracking of mail users, including me, and where
>> mobile device and web MUAs are unlikely to offer me an option to 
>> turn all that off, even if some desktop MUAs might (eventually), at
>> the risk of making messages harder to comprehend.
> 
> I'm not sure I understand this comment. 

I'm not sure which bit of my para above you mean. If it's the last
point - I often get mail now where substantive parts of the mail
are only present in HTML and I don't render that in my latop MUA,
which forces me to occasionally delve into the raw message to
find out what some correspondent means. The desire for dancing
kittens in HTML body parts does sometimes make emails less
comprehensible. I reckon incorporating images as per bimi would
have a similar effect.

> The logos are not added to
> mail headers, but instead headers point to a location where the logo
> can be picked up and then shown to the end user. What's the
> difference between the sender/brand providing an authoritative source
> (DNS record that points to a CDN) vs Office 365/Yahoo pulling from
> their own internal database?

Aside from John and Dave's points another difference is that I
don't need to care about the latter, (as I don't use 'em)
whereas where bimi a standard that got deployed then my MUA may
add such (from my POV) broken-ness.

> Again, I am not sure I understand this comment.

John answered that I think.

> Logos are everywhere. Most large companies have Facebook and Twitter
> pages, and they all have logos. You see logos painted on the sides of
> walls, on stores, on TV, in newspapers, on web pages, as favicons,
> etc.
> 
> Are you saying these are all fine but in the sender photo it isn't?
> What's the fundamental difference between seeing a company's logo in
> the sender photo vs seeing it in the body of an email? Is it just a
> matter of turning of HTML and preventing those from loading?

I don't see sender photos and do not render HTML, except on
mobile device MUAs where I do not get that choice, which is,
for me, negative. Were bimi standardised it is entirely
unclear to me how various MUAs might handle it. But I very
much doubt that mobile device MUAs would provide that level
of user-control for bimi as they do not for bodies. And all
of us here are likely far more capable of configuring things
than most users.

>> As someone who sends email (not as a bulk sender) from various
>> domains that I operate, I do not want to pay €€€ to someone for an
>> additional cert, nor for an "approved" logo, in order to increase
>> the chances that my mail gets delivered.
> 
> Nobody is going to make you buy a cert, nobody is going to make you
> buy a logo, and so forth. It's up to you.
> 
> BIMI is an add-on; it augments the default experience, the lack of it
> doesn't downgrade the default experience.

Perhaps. Nonetheless there is at least one large mail service
that sends all mail from some domains I operate (that have never
sent spam and that have had stable IP addresses for years, DKIM
etc all good) to /dev/null and who won't respond to any form of
poking to try get that fixed despite a number of attempts. And
that provider is used (as MX) by people with whom I do need to
correspond, so I'm forced to use a different mail a/c to mail
those folks.

Yes I do indeed fear that bimi could and would be (ab)used by
some services to do more such dis-service. ISTM that damages
the mail environment rather than enhances it.

>> I also do not want to have to check if someone else has abused a
>> logo I may use in some CT log. I do not want to have to process
>> additional headers in my MTAs nor retrieve and store your logos in
>> some new image store. I do not want to have to deal with any of the
>> new problems that'll arise when any of that breaks.
> 
> Again, I'm unclear about the context of this statement. Nobody is
> going to make you as a sender, brand, or receiver send with BIMI.

I'm afraid that continues to be a concern of mine. (As an aside,
I am not a "brand" and have no ambition to become one:-)

> Nobody is going to make you retrieve logos from a store, nobody is
> going to make you verify any log, nobody is going to make you process
> additional headers.

In fact, my reading of bimi is that it does attempt to force a
receiving MTA/MS to actively download the image(s) and replace
the URL with one pointing at the MS (or nearby) - not doing so
would expose users of the MUAs using that MS to tracking once
those MUAs de-reference bimi URLs from the sender.

> Instead, it's about enhancing the email experience for those
> motivated to do so. And, BIMI provides a way to do this.

I realise that's your/the proponents position. Mine is that
bimi is only a negative.

Cheers,
S.

> 
> --Terry
> 
> ________________________________ From: bimi <[email-masked]>
> on behalf of Stephen Farrell <[email-masked]> Sent:
> Thursday, February 14, 2019 2:57 AM To: [email-masked] Subject: [Bimi]
> (non)desire for bimi
> 
> 
> (Sorry for not replying in-thread but I just subscribed to the list,
> and this perhaps also deserves a separate thread.)
> 
> I'd be interested in some kind of verifiable backup for that "clear
> demand" claim - I'm unaware that such exists, other than perhaps as
> Richard says for marketing purposes, and ISTM those purposes are
> amply met already via mail bodies.
> 
> Meanwhile...
> 
> I use the Internet. I do not want logos added to mail headers that
> increase the attack surface of my MUAs, (and MS/MTAs), that likely
> enable additional tracking of mail users, including me, and where
> mobile device and web MUAs are unlikely to offer me an option to turn
> all that off, even if some desktop MUAs might (eventually), at the
> risk of making messages harder to comprehend.
> 
> I also just do not want to see your logos, thanks. Imposing those on
> me would decrease the utility of mail. And regardless of what PKI
> were built I would not treat bimi'd messages any better, more likely 
> I'd consider them badly.
> 
> As someone who sends email (not as a bulk sender) from various
> domains that I operate, I do not want to pay €€€ to someone for an
> additional cert, nor for an "approved" logo, in order to increase
> the chances that my mail gets delivered. Things in that respect are
> bad enough, and this proposal seems to me likely to only worsen the
> situation for those who operate small domains, presumably to the
> benefit of those who operate large mail infrastructures and CAs who
> issue certs for money.
> 
> I also do not want to have to check if someone else has abused a logo
> I may use in some CT log. I do not want to have to process additional
> headers in my MTAs nor retrieve and store your logos in some new 
> image store. I do not want to have to deal with any of the new
> problems that'll arise when any of that breaks.
> 
> So: No thanks, from me. Personally, as a mail user I only see
> downsides to this whole idea.
> 
> Thanks, S.
> 
>

---

From: Thede Loder <[email-masked]>
Date: Thu, 14 Feb 2019 14:16:19 -0500

> On Feb 14, 2019, at 13:35, Dave Crocker <[email-masked]> wrote:
> 
> This is another fundamental usability design error:  thinking that adding something is fine because users can turn it off.  This burdens users, and often creates a barrier because they don't know how to fix it or even that they can.

I think Terry may have been saying that there are MUAs already in use which do not display images by default, or cannot at all.  For example, pine, elm, mailx.   There's not going to be any burden to end users of these, as there's nothing to swtich off.  

To Dave's point, if MUA maintainers adopt BIMI in MUAs for which logo display makes sense (from their perspective) and they turn logo display on by default, for people who find logos annoying there will be a burden to turn them off, if such an option is provided.  

Thede

-- 
Thede Loder
Managing Director, Skye Logicworks LLC
E: [email-masked]
L: https://www.linkedin.com/in/thede
M: 415-420-8615

---

From: Thede Loder <[email-masked]>
Date: Thu, 14 Feb 2019 14:26:05 -0500

> It makes it in effect another web bug.

The topic of BIMI potentially enabling another form of tracking or "web bug" has come up in discussions.  

Speaking for myself, my general sense is that no one substantively involved sees creating yet another tracking capability as a benefit, and that we should avoid doing so if possible. 

This is not the same as saying we've provably designed a system that denies tracking.  That would be better.  

Overall, I think we need to address this issue head on, with a careful analysis.  

Thede

---

From: Terry Zink <[email-masked]>
Date: Thu, 14 Feb 2019 23:36:34 +0000

Hi, Stephen,

I won't respond to all of your points, only a handful in the interest of keeping these responses manageable.

> The desire for dancing kittens in HTML body parts does sometimes
> make emails less comprehensible. I reckon incorporating images as
> per bimi would have a similar effect.

Do you think it's kind of a stretch to equate dancing kittens and general late-90's annoyance in HTML with a sender photo? Even in my mail client right now, there's a sender photo - it's a letter "B" for bimi @ ietf.org. If my email client decided to show the logo for the IETF instead, you'd find that as distracting as loud HTML?

> But I very much doubt that mobile device MUAs would provide that level

It sounds to me like you're saying you want to turn off BIMI logos in an email client. All you need is a checkbox in the MUA?

> I am not a "brand" and have no ambition to become one:-)

I'm trying to understand your position here, but I still don't get it.

BIMI is an add-on service; literally every domain in the world could publish a BIMI logo, and you might not, and you'd be none the wiser if you stuck to your plain text emails and MUAs. Are you saying that email receivers would eventually then force you to set up a BIMI record because the lack of it would cause your email/domain to suffer deliverability problems? That they would eventually strong-arm you into publishing BIMI records?

> those MUAs de-reference bimi URLs from the sender.

Where does it say that in the BIMI spec?

I helped write and edit some of the first documents for BIMI. For the brand, you upload an image somewhere, and create a DNS record that points to it. You then have it signed so that it can be verified by an email receiver. As a mail receiver, you use a bunch of DNS checks along with standard email auth checks to figure out where and if to pull the image.

As an email receiver, you could choose to pull it from where the brand publishes it (and therefore deal with the unreliability of everyone else's architecture), or you could pull it locally and replicate it on your own infrastructure. Indeed, that's already done today. If I'm an email receiver and I'm showing images based upon my best guess of what a brand's logo is, and a brand instead tells me what the authoritative source is, then I go pick it up from there instead of scraping it from the web.

If BIMI requires the things you say it does, I'd like to understand where.

-- Terry

________________________________
From: Stephen Farrell <[email-masked]>
Sent: Thursday, February 14, 2019 10:44 AM
To: Terry Zink; [email-masked]
Subject: Re: [Bimi] (non)desire for bimi

Hi Terry,

Cheers,
S.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 14 Feb 2019 17:00:01 -0800

On 2/14/2019 3:36 PM, Terry Zink wrote:
> It sounds to me like you're saying you want to turn off BIMI logos in an 
> email client. All you need is a checkbox in the MUA?

Terry, in the context of usability design, language like "all you need 
is a checkbox" hasn't been credible for at least 35 years.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Feb 2019 16:16:56 +0000

Hi Terry,

Just on this point for now...

> Where does it say that in the BIMI spec?

I'd have to go check the drafts again, but that's how it
was described to me at [1] and that matches my recollection
of the drafts.

Cheers,
S.

[1] https://mailarchive.ietf.org/arch/msg/spasm/cf-jmY5tOx-zIdklMyfLGdp9YqY

---

From: Terry Zink <[email-masked]>
Date: Fri, 15 Feb 2019 17:09:12 +0000

Hi, Dave,

> is a checkbox" hasn't been credible for at least 35 years.

LOL!

Yes, I know. I phrased it that way on purpose - to oversimplify the discussion as if to say "All that's required is a simple way to disable it?"

________________________________
From: Dave Crocker <[email-masked]>
Sent: Thursday, February 14, 2019 5:00 PM
To: Terry Zink; [email-masked]
Subject: Re: [Bimi] (non)desire for bimi

d/

---

From: "A. Schulze" <[email-masked]>
Date: Sat, 16 Feb 2019 15:03:40 +0100

> I also just do not want to see your logos, thanks.

Hello,

I agree with Stephen.

We all, but specially MUA developer/maintainer, fail to teach the user
what the technical meaning of RFC5322.From is.
It is simply text choosed by message originator, no difference to RFC5322.subject

Users expect this to be something other. That's the problem.

So we created these horrible zoo named SPF, DKIM, DMARC and ARC.
And what's the result?

RFC5322.From contain something I use to name "Display Name"
All the authentication tech ignore this part.
But what do MUAs present as "FROM" ?
Most of the time exactly this last piece of unauthenticated data.

All, what BIMI could do, is to teach
"Hey User, this message from $BRAND is only valid if you also see $BRAND's logo"

So BIMI sounds to me like an authentication method for the display name.
I would say, we failed...

Andreas

---

From: Marcel Becker <[email-masked]>
Date: Sat, 16 Feb 2019 08:07:29 -0800

>> I also just do not want to see your logos, thanks.

Personal preferences of visual message presentation and mua visual
design (while interesting) should not be really relevant to this
discussion imo.

> "Hey User, this message from $BRAND is only valid if you also see $BRAND's logo"

And that would be bad thing?

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Feb 2019 08:11:51 -0800

> And that would be bad thing?

Except, of course, that it will not have that effect on users, because 
there is extensive experience demonstrating that users mostly do not 
learn or use such signals.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Feb 2019 16:17:00 +0000

Hiya,

On 16/02/2019 16:07, Marcel Becker wrote:
> Personal preferences of visual message presentation 

To an extent, yes. The fact that you or I have some preference
here isn't very relevant, being effectively anecdotal. The reasons
for those preferences (and reasons have been described) are
however entirely relevant.

> and mua visual

I disagree here though - the proponents of bimi are arguing or
assuming that presentation of a logo will have some positive
effect. ISTM that means that calls for providing some convincing
arguments about MUA visual design (which admittedly is not a
common thing in an IETF context). I've yet to see such argument
offered.

Cheers,
S.

---

From: Marcel Becker <[email-masked]>
Date: Sat, 16 Feb 2019 08:24:54 -0800

On Feb 16, 2019, at 08:11, Dave Crocker <[email-masked]> wrote:
> Except, of course, that it will not have that effect on users, because there is extensive experience demonstrating that users mostly do not learn or use such signals.

While I usually tend to agree with that statement it is — in that
absolut form — not necessarily true. We know that, given time, users
are quite capable of learning and using such signals. When
specifically designed for that task.

But above I was merely reacting to a statement portraying that
potential outcome as failure. IF it had that effect, I wouldn’t call
it failure. But that’s besides the point of this conversation now as
well so I will shut up.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Feb 2019 09:03:19 -0800

> specifically designed for that task.

In real life, for this kind of task, no, they aren't.

On the average, they don't have an adequate threat model, they do not 
understand the security mechanisms, and they do not allocate the 
necessary time and effort to making the real-time decision.

If you have evidence of average users making security-related decisions 
in real-time -- in the midst of boring, daily tasks -- please provide it.

d/

---

From: Thede Loder <[email-masked]>
Date: Sun, 17 Feb 2019 20:55:09 -0500

> On Feb 16, 2019, at 12:03, Dave Crocker <[email-masked]> wrote:
> On the average, they don't have an adequate threat model, they do not understand the security mechanisms, and they do not allocate the necessary time and effort to making the real-time decision.
> 
> If you have evidence of average users making security-related decisions in real-time -- in the midst of boring, daily tasks -- please provide it.

If end users treat messages with or without logos exactly the same, through what means will end users be made worse off or less safe when BIMI-sourced logos are widely used?  

Thede

> d/

—
Thede Loder
M: +1-415-420-8615

---

From: Dave Crocker <[email-masked]>
Date: Sun, 17 Feb 2019 18:50:08 -0800

> If end users treat messages with or without logos exactly the same, through what means will end users be made worse off or less safe when BIMI-sourced logos are widely used?

Thede,

This line of logic implies that the only valid argument against doing a 
standard is demonstrable proof that it will do harm.

Besides that basic flaw in the implied foundation of your question, 
others have noted a variety of concerns both larger strategic 
opportunity cost and narrow, increased security exposures, and, of 
course, plausible misuse.

There is also the concern for the cost of doing a standard; they are 
extremely expensive.

d/

---

From: Thede Loder <[email-masked]>
Date: Mon, 18 Feb 2019 10:59:17 -0500

> On Feb 17, 2019, at 21:50, Dave Crocker <[email-masked]> wrote:
> 
> This line of logic implies that the only valid argument against doing a standard is demonstrable proof that it will do harm.

Which line of logic (or form of logic) lets you derive that implication?   

Even if we assume that the premise is true (end users treat messages exactly the same), and if we agree that this implies end users will not be made worse off through their own choices as a consequence, it says nothing of other mechanisms through which users might be made worse off (or better off).  (If A implies B, it does not hold that not A implies not B.  The contrapositive does hold).  

Under the logic rules that I am familiar with, your proposed implication is not what is implied (nor am I implying it).  

I asked the question to help move the discussion forward.  Maybe we can agree on some things.  

If people believe that end users treat messages with and without logos exactly the same, then we could potentially move on from considering the positive or negative implications of end user-mediated choices.  End user choices can neither be a cause of improvement nor a cause of worsening.  

On the other hand, and given that end user security and safety is really really important, it might not be the wisest thing to assume away end-user mediated choices as a potential factor of change in outcomes.  

If we let in the possibility that changes in choices could exist and may make users worse off, we have to let in the possibility that end-user choices may be a means through which we can make users better off.  One cannot have it both ways.  

My personal opinion is that we need to leave open the possibility, because to do otherwise violates the engineering practice of ‘fail-safe’.  

(That said, none of BIMI’s proponents are arguing that end users' choices resulting from the display of logos will be a primary or substantive cause of improvement in outcomes.  No one is saying that this mechanism should even be considered for reasons other than for its potential to reduce safety.  If you see language in the documentation asserting otherwise, please bring it to the group’s attention )   

The other reason I asked the question above was to motivate disclosure of additional objections to BIMI.  “BIMI won’t do what its designers think it will do” does not seem like a reasonable justification for disqualify it, even if it were true.  Let’s begin to consider the other issues.  

> Besides that basic flaw in the implied foundation of your question, others have noted a variety of concerns both larger strategic opportunity cost and narrow, increased security exposures, and, of course, plausible misuse.
> 
> There is also the concern for the cost of doing a standard; they are extremely expensive.

What I hear from the above as additional concerns are: 

A) larger strategic opportunity costs
B) narrow, increased security exposures 
C) plausable misuse
D) extremely expense of doing a standard 

Can you elaborate on A?  Help us understand these costs.  

Can you provide examples for B and C so that we can begin a discussion of mitigation strategies?    

Regarding D, let’s begin a larger discussion of costs.  Given your experience, where do you see the costs in doing a standard?  

Thede

—
Thede Loder

---

From: Thede Loder <[email-masked]>
Date: Mon, 18 Feb 2019 11:31:04 -0500

> On Feb 14, 2019, at 13:44, Stephen Farrell <[email-masked]> wrote:

Hi Stephen, 

Knowing your personal dislike of HTML-based email, and also that ~1 billion  
people read HTML email messages each day, many of whom like seeing 
graphics, tables, and other mark up, would you have proposed back when 
it was being considered for standardiation that it should never be developed 
or standardized?  

> the mail environment rather than enhances it.

Your fear is justifiable.  

One can imagine future anti-spam or anti-fraud systems.  They could  
include message scoring functions that assign messages 
from domains lacking authentication setup (or which do not have a valid 
VM Cert) lower scores.  And one can also imagine that this scoring 
strategy will have a larger negative impact on deliverability if too few 
other post-delivery derived reputation signals are available for a given 
sender.  In other words, low volume and newly registered domains.  

While potentially raising the costs differentially to prohibative levels 
for some of the “bad guys”, cost is also raised for those who were not 
causing harm under the original system design; the ‘good actors’ have 
increased costs to continue to to get what they had before.  

An analogy here from the offline world: “Because criminals abused 
ID-less open flying previously the norm for air travel, a system was 
implemented in which everyone must now present IDs at airports; 
if fliers do not have IDs they have to bear the costs of going out and 
getting them, whether or not they were a good actor or a bad actor.  “  

I think the relevant question is: 

If BIMI adoption contributes to a shift in the norms and certain costs 
associated with effectively using applicable existing media, on the 
balance, have we made these media better for the actors we care 
about?  

> those MUAs de-reference bimi URLs from the sender.

Tracking is a concern and my personal take is that I’d like to see it 
become either impractical or completely transparent (or both)?.   
Can someone from the Authindicators Working Group comment on
Stephen’s interpretation?   Stephen, can you point us to a section?  

> I realise that's your/the proponents position. Mine is that

This is certainly a valid position, and thank you for stating it.  This is 
in part what having a dialogue is about.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Feb 2019 08:36:41 -0800

On 2/18/2019 7:59 AM, Thede Loder wrote:
> Even if we assume that the premise is true (end users treat messages exactly the same), and if we agree that this implies end users will not be made worse off through their own choices as a consequence, it says nothing of other mechanisms through which users might be made worse off (or better off). 

Yes, limiting the scope of discussion to the topic at hand is certainly 
constraining.

So, how is your point relevant to an evaluation of /this/ proposal?

> I asked the question to help move the discussion forward.  Maybe we can agree on some things.

Thede, there has already been a number of very substantial concerns 
raised.  You seem to be focusing on trying to raise new ones rather than 
dealing with the ones already raised.  Your summary list, below, is more 
helpful.

> If people believe that end users treat messages with and without logos exactly the same, then we could potentially move on from considering the positive or negative implications of end user-mediated choices. 

We could do that if Bimi documentation and its advocates didn't keep 
suggesting improvements in recipient handling of email.

> End user choices can neither be a cause of improvement nor a cause of worsening.

That implies that a user's choosing to believe a phishing message 
doesn't make things worse.

> On the other hand, and given that end user security and safety is really really important, it might not be the wisest thing to assume away end-user mediated choices as a potential factor of change…

That seems to suggest ignoring the long and solid track record that 
expecting end-user mediated choices will happen has been wrong. Please 
explain why that's being ignored.

> If we let in the possibility that changes in choices could exist and may make users worse off, we have to let in the possibility that end-user choices may be a means through which we can make users…

You're introducing a view that hasn't been put forward.

What's been put forward is that justifying a security mechanism based on 
an expectation of recipient decision-making during message processing is 
known to be inappropriate.

> My personal opinion is that we need to leave open the possibility, because to do otherwise violates the engineering practice of ‘fail-safe’.

Please explain.

> (That said, none of BIMI’s proponents are arguing that end users' choices resulting from the display of logos will be a primary or substantive cause of improvement in outcomes. 

They have.  And some of the documentations can be taken to imply that it 
will.

> No one is saying that this mechanism should even be considered for reasons other than for its potential to reduce safety. 

The mechanism will /reduce/ safety???

> Can you elaborate on A?  Help us understand these costs.

An effort like this both sets expectations and consumes resources.  The 
former won't be met and will disappoint the market which will incline it 
to have lower receptiveness to the next proposal.  People working on 
this won't be working on other strategic effort.  Both of these are 
significant downsides.

> Can you provide examples for B and C so that we can begin a discussion of mitigation strategies?

I believe Stephen offered B.

As fort C, cf DMARC.

> Regarding D, let’s begin a larger discussion of costs.  Given your experience, where do you see the costs in doing a standard?

Consider the aggregate effort to produce a standard and consider the 
cost of the people who do that work.  30 years ago, I estimated at least 
US$1M for the simplest IETF standard.  It hasn't gotten cheaper.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Feb 2019 08:44:49 -0800

Thede,

This seems to be in the "what about" realm of responding to criticism by 
raising a purportedly related hypothetical.  That response mode 
typically seeks to dilute the original criticism.  In effect in this 
case, it seems to suggest that no one should ever worry about new 
security attack surfaces.

At the least, it certainly does not respond to the concern about the 
attack surface that was cited.

> One can imagine future anti-spam or anti-fraud systems. 

Sorry.  I am not understanding how the hypothetical that followed is 
relevant.  Please explain.

> balance, have we made these media better for the actors we care

What norms?  What costs?  How will it do either?

d/

---

From: Richard Clayton <[email-masked]>
Date: Mon, 18 Feb 2019 17:19:55 +0000

In message <[email-masked]>,
Thede Loder <thede=[email-masked]> writes

>(That said, none of BIMI’s proponents are arguing that end users' choices 
>resulting from the display of logos will be a primary or substantive cause of 
>improvement in outcomes.  No one is saying that this mechanism should even be 
>considered for reasons other than for its potential to reduce safety.

     increase ?

>  If you 
>see language in the documentation asserting otherwise, please bring it to the 
>group’s attention )   

from the front page of the brand indicators website:

     "What If You Could Put Your Brand On Every Email and Users Could
     Trust It’s You?"

     "will use brand logos as indicators to help people avoid fraudulent
     email"

     "When users see your logo, they’ll trust the email"

     "Stop Phishing"

this reads to me that an improvement in outcomes is a key aim of BIMI
since there is very little other substantive messaging there:

Except of course it also says

     "giving marketers a huge new opportunity to put their brands in
     front of consumers for free"

     "we believe brand indicators will increase response rates,
     magnifying the power and reach of our marketing efforts."

But I look forward to the "forest" document which sets out the high
level of what is intended to be achieved, so that it is possible to
assess the technical suggestions against that...

... and yes, if the main driver here is marketing then say so and the
effort can be properly tuned, by those who are prepared to work on the
standard effort, to get that right.

But Aims first, Tech Details second: No point talking about certificate
pinning if there will only ever be one CA for example.

>The other reason I asked the question above was to motivate disclosure of 
>additional objections to BIMI.

it's hard to object to generic aims if they aren't documented and appear
to dilettantes like me to change with the year

>Regarding D, let’s begin a larger discussion of costs.  Given your experience, 
>where do you see the costs in doing a standard?  

Hiring me to read your last email, check your website text and proofread
the brief response that I have penned here would likely cost you $100 at
my chargeout rate.

The opportunity cost of doing this email rather than working on better
schemes for mitigating list bombing (say for a concrete example) is
substantially more than $100 given the cost to the community (and
particular victims) of that abuse.

Multiply my small contribution by all the experts who need to keep up
with email lists, consider the consequences of minor changes, brainstorm
major improvements etc. and you will soon be talking substantial sums. 

The IETF does not pay for the expertise they garner (and I think would
probably be rather worse off if they did) but "opportunity cost" is the
key issue here -- in my view.

- -- 
richard                                                   Richard Clayton

---

From: Thede Loder <[email-masked]>
Date: Mon, 18 Feb 2019 13:03:26 -0500

> On Feb 15, 2019, at 11:16, Stephen Farrell <[email-masked]> wrote:
> 
> Hi Terry,
> 
> [1] https://mailarchive.ietf.org/arch/msg/spasm/cf-jmY5tOx-zIdklMyfLGdp9YqY <https://mailarchive.ietf.org/arch/msg/spasm/cf-jmY5tOx-zIdklMyfLGdp9YqY>

Stephen, thanks for this reference.  While its technically possible that a receiver
might fetch a certificate at message-receipt time, receivers not wishing to 
enable sender tracking have another straightforward option: they can maintain 
access to the Certificate Transpareny logs, and therefore have a copy of 
every issued certificate (and their embedded list of FQDNs) and so retrieve
relevant contents without any outbound communication to the net.  In practice, 
receivers might implement daily DNS checks, during which they lookup and 
confirm the current BIMI record for the set of domains known to be publishing 
them, or to discover new ones that have begun doing so. 

Thede

---

From: Thede Loder <[email-masked]>
Date: Mon, 18 Feb 2019 13:37:10 -0500

Stephen, 

> common thing in an IETF context). I've yet to see such argument

Can you tell me if you agree or disagree with the following statement? 

"To say that facilitating the regular practice of displaying logos (as 
sender identity) can bring about positive effects is not the same 
as saying the positive effects are due to, for example, improved 
end user-mediated choices. “ 

If you and others agree, maybe a way to move ahead is to next establish 
an agreement on possibility: 

“Is it possible that ways might exist for end users to be made safer 
without the users having to be reponsible for directly making safer 
choices for themselves? “  

If we agree such a thing might be possible (and it sounds like perhaps
you do, but are waiting for a proposal to evaluate), then we can move to 
a discussion of evaluating proposed ways.  

Thede

—
Thede Loder

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Feb 2019 21:46:56 +0000

Hiya,

Answering 3 mails at once..

On 18/02/2019 16:31, Thede Loder wrote:
> Hi Stephen,
> 
> Knowing your personal dislike of HTML-based email, and also that ~1
> billion people read HTML email messages each day, many of whom like
> seeing graphics, tables, and other mark up, would you have proposed
> back when it was being considered for standardiation that it should
> never be developed or standardized?

I don't recall details of when HTML body parts were standardised.
I do consider that blindly running random code from the Internet
as a default is one of the worst errors that web and mail user
agent developers have made in the last two decades. We are still
discovering some of the non-obvious consequences (Spectre etc.)

I am happy to be tech savvy to know that I can, and how to, turn
that down to something acceptable, which I find entirely usable.
I'm sad that's not the default. I do maintain that the world would
be a little better were user agents much more conservative in how
they handle active content like HTML.

>> Yes I do indeed fear that bimi could and would be (ab)used by some
>> services to do more such dis-service. ISTM that damages the mail
>> environment rather than enhances it.
> 

I'm sad to hear that.

> If BIMI adoption contributes to a shift in the norms and certain
> costs associated with effectively using applicable existing media, on
> the balance, have we made these media better for the actors we care 
> about?

That's an unanswerable (and hence badly formed) question. A "shift in
norms" can be overall negative or not so "on the balance" can't be
answered, at least not as an answer to that question.

>  become either impractical or completely transparent (or both)?. Can
> someone from the Authindicators Working Group comment on Stephen’s
> interpretation?   Stephen, can you point us to a section?

Don't have time 'right now to re-read the various drafts sorry.
Logically though, adding a URL that gets de-referenced has to
be a new tracker, and hence is IMO bad. Supposed ways of avoiding
the MUA doing the de-referencing seem almost fictional as they
require all MDAs to have intercepted and replaced that URL to
avoid their MUAs doing so. I don't believe you can eliminate
that form of tracking unless you send the image inline. (Which'd
have other downsides is a very different design.)

I can't see how that tracking aspect could be a surprise to
anyone.

On 18/02/2019 18:03, Thede Loder wrote:>
> access to the Certificate Transpareny logs, and therefore have a copy
> of every issued certificate (and their embedded list of FQDNs) and
> so
retrieve
> receivers might implement daily DNS checks, during which they lookup
> and confirm the current BIMI record for the set of domains known to
> be
publishing
> them, or to discover new ones that have begun doing so.

I have to say that seems pretty far-fetched (to put it kindly). But
if there's a more fleshed-out design I'd be interested in a pointer.
To poke at just one aspect, I've no idea what CT data structure you
are assuming is in a mail. If it's not e.g. an SCT or signed tree-head
then that seems to be nothing to do with CT and more that you seem
to be imagining a new image repository where images just happen to
be wrapped in X.509 cruft. Lastly, if the supposed CT-log/image-DB
is accessed by the MUA then that's the same tracking as before. If
you envisage the MDA doing that daily then that seems quite brittle
and unlikely (as before).

On 18/02/2019 18:37, Thede Loder wrote:
> "To say that facilitating the regular practice of displaying logos
> (as sender identity) can bring about positive effects is not the
> same as saying the positive effects are due to, for example,
> improved end user-mediated choices. “

I think that's a loaded question, sorry and I don't plan to take
the bait:-)

I continue to maintain that MUA UI design is relevant to this
discussion (which is unusual in an IETF context) and that I'm unaware
of evidence as to the claimed effects (good or bad) of displaying
graphics as proposed here. If no evidence is offered that such
graphics overall do good, then my conclusion is that this effort is
not worthwhile. (But that it is worthwhile opposing, as I do see
dangers, as well as costs, in what is proposed - sorry again;-)

If you or someone has some evidence that displaying these logos
has some overall positive effect, then sending a pointer to that
evidence would seem the obvious answer.

Cheers,
S.