Hi,
thanks Guillaume for exposing this misfeature that has crept into
Thunderbird.
I wasn't aware of this.

Yes, it seems in the current state Thunderbird generates a single
clientID for all IMAP accounts and even for all SMTP servers and sends
that same one to all servers that request it.

I don't know how a random string increases any security for the server.
Only if the string is something special defined by the server for the
particular user, that the user needs to submit back at each connection.
This is being discussed in bug 1532388 comment 156.

So I'd also say the clientID must be switched immediatelly to
per-account unique one as Jorg said and TB should have NO global default
value. And NO clientID must be submitted to any server unless the user
specificallly enables it and provides the value.

Of course best would be to just drop it out of Thunderbird, as I do not
understand why some 'feature' in draft proposal state of a
never-heard-of server needs to be supported by Thunderbird immediatelly
and compromise the privacy of unsuspecting users.
Yes, user having more accounts on the same server (or multiple servers
having the same server software with clientID requirements) is a
problem, the clientID of TB having the fixed string of "TB-UUID" is a
problem (it reveals the application, if that already isn't done in other
ways)

aceman

Dňa 6. 7. 2019 o 0:13 Jörg Knobloch napísal(a):

On 06/07/2019 01:22, ace wrote:

Since the patch are pure additions of code, it can be removed within 10
minutes, even from TB 68 beta 5 which we'll shipping next week.

Just note: https://bugzilla.mozilla.org/show_bug.cgi?id=1532388#c5

Jörg.

Hello Jörg, all,

Thank you for considering my email and for the quick answers.

I'm sorry, I can't tell you more about the privacy problem in details.
Since an other email client community didn't choose to integrate this
feature because of user privacy concerns, I felt as Ace, "I do not
understand why some 'feature' in draft proposal state of a
never-heard-of server needs to be supported by Thunderbird immediatelly
and compromise the privacy of unsuspecting users". So I wanted to get up
a warning flag to the Thunderbird team, just in case you didn't think
about this point. And so you can evaluate the situation to be sure that
this feature deserves integration in Thunderbird.

I trust you all to discuss the point and take the right decision, you
are so much skilled than me on these technologies ! I just can thank you
very much for that and keep continue donating !

Have a nice week-end !

BR,
Guillaume

Le 06/07/2019 à 08:00, Jörg Knobloch a écrit :

On 2019/07/06 15:00, Jörg Knobloch wrote:

Why don't we simply drop it then?

I don't believe this is necessary for majority imap/pop3 servers, correct?

Chiaki

PS: Im Japan, there is a scandal of a large convenience store chain
which has introduced a QRcode payment system, of a sort, using
smartphone since July 1st.
It was hacked from day 1 and already about a 900 users' accounts and a
half a million dollars were reported to be stolen. The company has
scrambled to limit the operation by stopping in charging/topping the
account from credit  card any more.

From the press conference a couple of days ago, we have learned that
the president of the company did not know about "two stage"
authentication, and the VIP of IT let the system be released when a
change of password, etc. will be notified to OTHER e-mail address,
different from the one originally registered by the user, etc. Dream of
crackers.
(Remember there is no two stage authentication!)
I can't believe what I read, but it is for real.

It is a mess and I have feeling that this company, the operator of 7-11
is not on top of security and less concerned with user security and privacy.

I hope TB stays away from any suspicion of such user privacy/security
problems if it can afford to.
The particular feature is not part of any IETF mail protocol document,
if I am not mistaken.
So my initial reaction much thinking is above.
Remove it immediately. Just a thought. I hope more will chime in to
discuss this issue.

I am in favor of removing this, or at least disabling it by default. A unique id is still something that can be used for tracking a single installation over different geographic locations, even if it is not personal information.

Philipp

On 07/07/2019 20:34, Philipp Kewisch wrote:

Perhaps we should at least wait for a word from the inventors of the
client ID.

This is an additional authentication method. The servers are already
contacted by the client and the client identifies itself to the server
with user ID and password. So the mail provider can already track the
location of their customers based on the requests coming in.

Client ID is just another security measure where only certain clients
are allowed to authenticate via username and password. Even if someone
steals username and password, they still can't authenticate since they
still need to have a valid client ID. It's a bit like Google's
app-specific passwords.

To use the phone's IMEI as client ID is not a good idea, that's mostly
why K9 rejected the patch.

The only privacy concern here is that if a user has two accounts with
the same provider operating from the same profile in TB, the provider
can identify this. Or as I wrote earlier, if two providers share that
information, they can identify the common customer.

I'm happy to pull it out from beta 5 and ESR if we come to a decision
this week. I'm not prepared to work on a patch that would a) allocate
different IDs to different accounts, or b) hide the whole thing behind
an option. The original patch authors would need to do that.

Jörg.

On 07/07/2019 20:51, Jörg Knobloch wrote:

[...]

Just pull it.

Unless and until this has an opt-in option (which crystal clear
explanation to the end user of its purpose and ramifications) and
per-account IDs it seems pretty obvious now that it has no legitimate
place in Thunderbird.

Why was there such a hurry to add it as a feature, anyway?

--
Mark Rousell