I think this is is exactly how developing things in the open should
work. You spec something, and submit patches to make the feature gain
acceptance and advantages. Then of course, if it doesn't gain traction
over time, keeping the support may be questionable.

Anyway, the privacy concerns were discussed very closely in the bug, and
we indeed made sure there is a possibility to make the random generated
id per-account, though there is no UI for that yet. Keep in mind, this
is not some random website you're sending a random unique id to, it's
your chosen provider(s). If you worry about your provider knowing which
application you're accessing them with, then you should probably
consider changing to someone else.

 -Magnus

On 06-07-2019 02:22, ace wrote:

Dňa 7. 7. 2019 o 23:15 Magnus Melin napísal(a):

Yes, but experimental features with potential privacy implications must
not be automatically silently enabled for all users. It can be gradually
enabled for users by opt-in.

That's the problem, there is no UI and it is enabled by default so it is
sending something to the server without the user knowing.

The difference is, the user has chosen what username and what password
he sends to the server. Yes, the server has the user's messages, but
those may be encrypted.
But the server has no business knowing stuff about the user's client
application or the connecting device, e.g. whether it is always the same
one.

This feature allows the server to silently query additional information
about the user, that the user hasn't consented to (in the current
implementation).

So we do not need to rip it all out, we can support the optional
feature, but it must stay disabled until the user specifically allows
it. As an experimental feature it probably does not deserve space yet in
the Account manager settings, but the user can set it in prefs. Until
the user sets a value (and random string probably isn't useful), nothing
will be sent to that particular server.

I can make the patch in this direction.

Hi Guillarme,

Thanks for the input, these questions might help make it clearer for
others with similar questions.

First of all, it is important to recognize that CLIENTID is not
something that will be shared with unknown parties, only with the party
who you have a 'trusted' relationship, eg your email provider. (And of
course, they have your email address, and probably other things like
your credit card.  Similar to the way you transmit your EHLO, IP
Address, but remember this will only be sent over encrypted channels,
and ONLY to a trusted provider you specifically choose, eg where your
email account is hosted.)

As such is not something that should be looked at as a privacy concern.

If your concern is the implementation, and the possibility of the same
CLIENTID being passed on to two different 'trusted email provider', this
was a choice decided on by many contributors to the discussion, I think
mainly to simplify it so that the same CLIENTID would be used by (for
instance) your IMAP service and the SMTP service at the same provider.

Technically, you 'can' make sure a different CLIENTID is used at
different email providers manually, eg manually editing preferences.  In
the future, I would hazard a guess that if Thunderbird makes a stronger
distinction of a group of service(s) belonging to a service provider,
that more flexibility to allow distinct CLIENTID per email account would
be possible and/or encouraged.

In the mean time, the feedback from the Thunderbird contributors was to
standardize on a 'default' CLIENTID per profile, during initialization.

Does that clear up your concerns and questions?

-- Michael --

(Rest assured, this isn't anything that is used to 'phone home' or 'spy'
on you, just an extra level of security and confidence factor between
you and your email provider)

On 2019-07-05 3:13 p.m., Jörg Knobloch wrote:

--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

Dňa 7. 7. 2019 o 23:33 Michael Peddemors napísal(a):

Sorry, but any implementation must not just rely on promises of the
providers. In open source software, we can and have to make sure that we
do not need to trust any other party, we make sure that it is
technically not possible to infer anything from the data, even if the
provider does not hold its promises.

No, this must be the default, not only for those who manually edit the
preferences. The clientID must be distinct and only if you want you
should be able to send the same one to different providers.

Sorry, but this didn't clear anything. There is also a total secrecy of
what that that clientID should contain. It seems it is totally up to the
provider on what that ID should contain. As such, it looks like it
should be the provider clearly explaining on its webpage to its users
what this EXPERIMENTAL feature is about, what it does, how it is used on
the server (similarly to privacy policy and GDPR clauses), what string
they such pass in the clientID (surely a random strings brings no
increased security), etc. If you say it is a confidence factor between
you and the email provider, then it logically makes no sense to share
that same confidential information from the user to multiple other
providers. Thus the current implementation in Thunderbird makes no sense.
Without the above explanations from all providers, that request it,
making TB silently send some unique ID to all providers serves only to
spy, track and fingerprint users.

aceman

On 07/07/2019 22:33, Michael Peddemors wrote:

This is a remarkably naive statement.

If the data is shared with an email provider then, in reality, it can in
practical terms be shared with anyone else by that provider. Of course,
providers should not do such a thing but it is nevertheless false to
state, as you do, that it is "something that will be shared with unknown
parties". You have no control over what arbitrary service providers
might or might not do, so you should not make claims on their behalf.

It is only, at best, truthful to say that it "should not" be shared with
unknown parties, but it could in reality be shared regardless of laws or
contractual assurances. This risk must be taken into account.

Yes, this risk applies to existing usernames, passwords, and email data,
but that does not excuse adding arbitrary new features without thorough
thought, and it is clear that this has not adequately occurred.

Quite so, but this is very far from being a positive argument for adding
new client ID features, especially when they there is presently no UI to
control them, view them, set them, or delete them.

No sensible person excuses adding a new privacy risk because there are
current privacy risks.

Again, a remarkably naive and, in fact, foolish statement. It is foolish
because it is fundamentally incorrect. Of course a new personally
identifiable piece of metadata, an extension to an existing standard, is
a privacy concern.

It beggars belief that anyone working in this space would believe otherwise.

Which ones, and where was this discussion taking place? It seems to me
that a wider discussion with additional contributors is now taking a
different and, I would say, more realistic view.

That should surely be a choice under user control, if the user wishes.

No, it concerns me further. Your naivety and your strikingly careless
dismissal of this as a privacy issue are both worrying.

Who are you and what is your motivation to so hurriedly promote this
mis-feature (as it currently stands)? What exactly are you going to get
out of this being in Thunderbird in such a way that users cannot
explicitly opt into it and then control it? Are you the designer of this
scheme?

But you can surely understand that anyone could make such a claim. It
doesn't tell us anything, it is not reassuring, and it is not a useful
statement.

Whoever concluded that a significant and explicitly privacy-affecting
feature like this should added without there being explicit opt-in and a
UI for user control is seemingly thinking about it from within a bubble,
a bubble of naivety and short-sightedness.

To be clear: I am not against this sort of client ID as a new feature.
However, to implement it without (a) explicit user opt-in, (b) user
explanation within the UI, and (c) a UI to control all aspects of the
client ID on a per-account basis (including adding, editing and deleting
any client ID), is a quite remarkable mistake.

Additionally, the shockingly naive nature of some of your statements
above (specifically "CLIENTID is not something that will be shared with
unknown parties" and "not something that should be looked at as a
privacy concern") is worrying if you are one of the designers of the
scheme. You should know better.

So, by all means, let's see this feature in Thunderbird WHEN IT IS
FINISHED, i.e. when it has (a) explicit user opt-in, (b) user
explanation within the UI, and (c) a UI to control all aspects of the
client ID on a per-account basis.

--
Mark Rousell

On 07/07/2019 23:33, ace wrote:

Well said, aceman.

--
Mark Rousell

On 2019-07-07 3:33 p.m., ace wrote:

It was pointed out off list, that I could have described the above a
little better.. eg..

It isn't any more of a privacy concern, than sending the EHLO, your IP,
your OS fingerprint, your email address, and your password, when
interacting with your service provider is probably a more correct
description.

A great altruistic thought, however that isn't how email works now.

And/or frankly any service you sign-up for.  As pointed out, you can
infer from the EHLO/IP/OS etc.. many things.

At the risk of digressing even farther from the the original thread, if
the provider shared any of your personal information that would be a
breach ethically.

Sounds like this might have a better forum elsewhere, eg, education on
how/what CLIENTID is, but quickly to your points..

Not sure when you say there is total secrecy, it is pretty openly
described in the RFC Drafts.. (it is more for the user than it is for
the provider, eg I only want my personal email client to be able to log
into my account with my user name and password).

With changes to the internet, older methods such as 'only this
server/ip' as described by EHLO and IP address are no longer usable to
describe any form of access control.  CLIENTID gives the power to the
user to declare, only my Thunderbird should be able to access my
account. (if that is the only client the user uses)

Terms like 'spy, track, and fingerprint' users, are something where 3rd
parties or parties whom you do not have a relationship with, get access
to the data, and not the intended party.  This would already be covered
by any ISP's relationship or privacy policies, in the same way they
promise not to give out your password. Remember, this isn't sent to ANY
provider, except the ones you have an email account with.

This is simply an improvement to 30 year old email protocols, and to the
question earlier posed on this thread, why now?

Never in the history of the internet, have more resources, more botnets,
and more bad actors been engaged in attempting to hack email accounts.

With millions of hacked IoT devices, dedicated to taking advantage of
legacy methods to access email, implementing methods to help Thunderbird
users protect themselves, by enhancing the way they 'handshake' during
email connection/authentication with a trusted resource has never been
more important.

--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

Dňa 8. 7. 2019 o 1:29 Michael Peddemors napísal(a):

Just because there are already some ways to broadly identify a user does
not mean it excuses adding new ways to pinpoint a user even more precisely.
The whole point of the feature as outlined in the spec is to "represent
the IMAP client with a higher degree of certainty".
Also the spec itself in chapter "8. Security Considerations" says "it is
clear there is additional information divulged to the server. This may
have privacy considerations".
So claiming this does not increase privacy concerns (by submitting even
more identifying data than there already is) is simply lying from you.

With 'secrecy' I meant that it is totally up to the server what he uses
the clientID for and what it contains. So this must be communicated to
the user before he starts sending it to the server.

Good, we are getting somewhere. So the user should be able to choose if
he wants to opt-in to this "access control". Why is this the complete
opposite of what was implemented in Thunderbird? The feature is
force-enabled on all users with bad implementation (shared clientID)
with a hidden and unclear way of opting out (setting the clientID
preference on a particular server to an empty string MAY or MAY NOT work
with the current code).

You know, the data may still leak, be hacked, be stolen, be published
without the provider doing anything wrong intentionally. The best
preventive defence is always for the other party to have the least data
possible.

Sure, then let's give the users the methods and options.
Silently forcing a spying token on them just makes the server another
potential 'bad actor'.

aceman

On 08.07.19 07:36, ace wrote:

No, and "interaction" is really the difference. Just to give you a clear
picture of what scenario this CLIENTID is going to support me as an
email provider: basically we're looking at a future where setting up a
new profile will be interrupted by design, and you'll need to first
lower your pants "cross-device" and "omni-channel" before you can login.
Because I, "[COMPANY NAME] takes the security of your personal data very
seriously".

Instead of letting you login straight away, you'll see an email or
message popping up on an already configured device (if you're lucky to
have one), which reads something along the lines: "We have blocked an
unusual login attempt from an unknown device located at
<random-location-guess-of-your-IP-from-third-party-service>. Please
click big green button if this was not you. We offer best-in-class
secure webmail, please click virtually anywhere around here to buy. Oh,
not looking for this? There is a small grey link for 'other options'
down here?". The grey link being clicked, will land you on a web form
(still browsing on the auxiliary device), which will obviously ask you
for the Email password - btw, something which you shouldn't know by
hearth nor have ready to copy-paste on that device.

If you're mad of typing passwords all the time, and [COMPANY NAME] is a
more fancy provider which is advertising multi-factor login, you'll
instead receive an SMS code with a link, or magically see an $xCloud
code popping up while browsing that link (and if you're locked out of
all this, you probably had to register an alternative email for
"security reasons" before).

And after all this, if [COMPANY NAME] is really smart about their
business, they'll convince you to hit a link one more time, which you'll
very likely going to handle on the new device. If you don't believe me,
here is an idea: give your new device a generated name which is ugly by
design, so that you can't withstand going to rename it; or mention the
city next to yours as detected location, or pick the wrong model on
purpose - things you really can't leave that way.

And, while the user navigated through all this, related tracking cookies
across the browsers of both devices were installed. And this is it:
cross-device tracking is THE big business. And Identity Management is
THE door-opener for allowing this, and it becomes an ideal market-entry
barrier, as People really want fewer logins. But thanks to all this,
every email provider will learn about the person behind an email
address, and details about the hardware of both of their devices, more
than any browser alone is ever going to disclose.

I, [COMPANY NAME] could even maximize the outcome by making the process
fail "a bit" in between, like "uh, oh, login failed, Safari not so much
supported, maybe try other browser? or retry by clicking here". Bingo,
related tracking cookies installed across three instead of two browsers
for some, and the retry magically works for the rest of them.

I hope you now can imagine how this stable unique ID per client and
user is allowing an interaction which was not possible to initiate
before, and how it allows way more privacy breach than just a
non-interactive login per pseudonym (email + password).

Best

Claudio Luck

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

Problem is that we, the mail client users,  have no authority to make
that happen at all.
And I am sure that marketing types are always on a lookout for any piece
of information to make the obscure profile of users a bit clearer.

Now I know that there ARE IETF RFC drafts.
But I am a bit put off by the "Well, these are not our concerns. The
ball is in other people's court." tone of the security discussion.

Quote
9.  Security Considerations

   As this extension provides an additional means of communicating
   information from a client to a server it is clear there is additional
   information divulged to the server.  This may have privacy
   considerations depending on the client identity type or its contents.
   For example, it may reveal a MAC address of the device used to
   communicate with a server that would not previously have been
   revealed.  It is the responsibility of the client to decide whether
   the benefits outweigh the potential security impacts.

   As well, while this service extension requires that the identity
   information only be transmitted over an encrypted channel to reduce
   the risk of eavesdropping, it does not specify any policies or
   practices required in the establishment of such a channel, and so it
   is the responsibility of the client and the server to determine that
   the communication medium meets their requirements.

End quote

(From https://tools.ietf.org/html/draft-storey-smtp-client-id-05
SMTP Service Extension for Client Identity)

I agree with aceman and others that

• TB's client id ought to be "account"-specific.
  (In my mind, an account is exactly the account which TB offers. Namely
  the e-mail address and the server from which e-mails for that addresses
  are accessed.)

• Until that time the client ID info is "account"-specific and hidden
  unless OPT-IN agreement is given by the user, this feature should be
  unsupported.

Problem is that the current TB does not let the user exercise the
responsibility to make the educated decision on "whether the benefits
outweigh the potential security impacts".
The OPT-IN feature would achieve this. But this means that the opt-in
needs to be specified per account, whatever the consensus on the
definition of "account" is.

TIA

Chiaki