Thunderbird 78, Enigmail and OpenPGP secure email
Kai Engert
https://blog.mozilla.org/thunderbird/2019/10/thunderbird-enigmail-and-openpgp/
Two popular technologies exist that add support for end-to-end
encryption and digital signatures to email. Thunderbird has been
offering built-in support for S/MIME for many years, and will continue
to do so.
The Enigmail Add-on has made it possible to use Thunderbird with
external GnuPG software for OpenPGP messaging.
Because Thunderbird 78 will no longer support classic Add-ons, the
current Thunderbird 68.x branch (maintained until Fall 2020) will be the
last that can be used with Enigmail.
As a replacement, the Thunderbird team intends to develop integrated
OpenPGP messaging for the next major version of Thunderbird, which will
be released in summer 2020 (likely version 78).
We are happy that Patrick Brunschwig, who has been developing and
maintaining the Enigmail Add-on for many years, has offered to assist
the Thunderbird development team.
Many details need to be considered for this initiative.
Please have a look at the following article which describes the approach
we'd like to take:
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
If you have feedback, please post it to this list.
This feature was originally requested in
https://bugzilla.mozilla.org/show_bug.cgi?id=22687
Kai
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Ludovic Hirlimann
> Please have a look at the following article which describes the approach
> we'd like to take:
> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
>
> If you have feedback, please post it to this list.
Are you considering leveraging Pronto mail's PGP library (like bugzilla
did a year or so ago) ?
(it doesn't support all encryption protocols, has issues with big keys
(like mine was over 800kb with signatures).
Are we following
https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
gpg/pgp in thunderbird will follow the new standard and make the wot
more usable ?
Regarding S/Mime the issue I had with it was renewing certs and these
days Find a cert issuer - there's probably oportunities for TB to
partner with someone and get some €€€ throught a S/mime partnersip (eg
referal from tb - someone pays for a cert and Tb get's revenue from it).
Final note I'm very happy to get this email today - because the main
reason I use TB is that I can easily use pgp with it. Thanks Patrick
(and Hi ). Thanks kaie.
Ludo
--
https://www.hirlimann.net/Ludovic/carnet/
Patrick Cloke
Awesome news! I think this is an important feature to bring to our users.
Will there be a migration path from users who are using Enigmail to
Thunderbird native PGP? I understand that not all options, etc. will
want to be supported, but having to not setup PGP again would be nice.
Looking forward to seeing this in Thunderbird!
--Patrick
Kai Engert
> Are you considering leveraging Pronto mail's PGP library (like bugzilla
> did a year or so ago) ?
Are you referring to https://github.com/ProtonMail/openpgpjs ?
That library is a potential candidate for a library that supports
OpenPGP message, its LGPL license could allow us to bundle it with
Thunderbird.
However, looking at the output of "npm-remote-ls openpgp", it has a
large set of dependencies.
In my understanding, if we decided to use OpenPGP.js we'd have to bundle
it together will all its dependencies. To keep those attack vectors
under control, we'd probably have to watch all those dependencies for
security issues, and publish an updated Thunderbird version for every
security incident related to any of those dependent libraries.
Also, bundling might not be acceptable for some downstream distributors,
like Debian, which distributes individual node packages. We'd have to
ensure our bundled OpenPGP.js works with the system module versions
available on downstream consumer system.
Because of the above, it seems preferable to use a C/C++ or Rust library
for OpenPGP message processing.
> Are we following
> https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
> gpg/pgp in thunderbird will follow the new standard and make the wot
> more usable ?
This article makes very critical statements about PGP in general, such
as not using PGP for encrypting email at all, which is obviously
contrary to our intention.
When you mention a new standard, can you please point out to which part
of the article you're reffering?
It's not yet clear if, or how, or how soon, we might support the Web Of
Trust.
> Regarding S/Mime the issue I had with it was renewing certs and these
> days Find a cert issuer - there's probably oportunities for TB to
> partner with someone and get some €€€ throught a S/mime partnersip (eg
> referal from tb - someone pays for a cert and Tb get's revenue from it).
It might be best to have a separate thread for discussing challenges
with S/MIME.
As a quick reply, I share the impression that the availability of
publicly trusted certificates for personal use with email security seems
to have decreased, especially when considering certificates available
for no cost. And Firefox has recently removed support for the HTML
keygen tag, which will make it more complicated to obtain such
certificates, as it will likely require the use of external command line
tools to create a key pair with the private key only being stored on the
user's own computer.
The use of S/MIME might be more appropriate for corporate or
organizational environments, while OpenPGP might be better suited for
communication between private users, because it doesn't require to
involve a third party CA to get started.
Kai
Kai Engert
> Will there be a migration path from users who are using Enigmail to
> Thunderbird native PGP? I understand that not all options, etc. will
> want to be supported, but having to not setup PGP again would be nice.
Kai
Patrick Cloke
> On 08.10.19 13:50, Patrick Cloke wrote:
>> Will there be a migration path from users who are using Enigmail to
>> Thunderbird native PGP? I understand that not all options, etc. will
>> want to be supported, but having to not setup PGP again would be nice.
> Yes, at least for the keys the user already owns.
>
> Kai
--Patrick
Ludovic Hirlimann
Are we following https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure gpg/pgp in thunderbird will follow the new standard and make the wot more usable ?This article makes very critical statements about PGP in general, such as not using PGP for encrypting email at all, which is obviously contrary to our intention. When you mention a new standard, can you please point out to which part of the article you're reffering?
And that's me forgetting that it was in an other article :
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
Ludo
Ludovic Hirlimann
> organizational environments, while OpenPGP might be better suited for
> communication between private users, because it doesn't require to
> involve a third party CA to get started.
any S/mime message, or even an org managing a CA for that purpose the
last one I know of died in 2009.
I'm raising the issue , but I'm not proposing any soution, but is s/mime
support worth keeping ?
Ludo
Wiktor Kwapisiewicz
> As a replacement, the Thunderbird team intends to develop integrated
> OpenPGP messaging for the next major version of Thunderbird, which will
> be released in summer 2020 (likely version 78).
That's great to hear! Given the number of people that use Thunderbird
daily providing built-in OpenPGP can tremendously lower the effort
needed to encrypt e-mails.
> Please have a look at the following article which describes the approach
> we'd like to take:
> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
The wiki page is very well written. If you don't mind I've got a few
minor comments:
> We intend to identify and use another existing library that provides support for creating and processing OpenPGP messages, and we will try to reuse parts of Enigmail that aren’t specific to GnuPG.
As far as I know there are two: OpenPGP.js, that is re-used by the
Autocrypt extension [1] and Sequoia [2], that is native and AFAIK
provides a way to talk to GnuPG agent (for keys stored on smartcards).
[1]: https://addons.thunderbird.net/en-US/thunderbird/addon/autocrypt/
> It’s a controversial question whether email software should automatically use opportunistic encryption, or whether the user should be required to actively opt in, prior to using end-to-end email encryption.
The old OpenPGP e-mail header specified "preference" field [3].
[3]:
https://datatracker.ietf.org/doc/html/draft-josefsson-openpgp-mailnews-header-07#section-3.3
> Furthermore, starting to use OpenPGP comes with some responsibility for the future. Once a user distributes their own key to others, they’ve opened Pandora’s box. Others might discover the keys later and send encrypted email at any time in the future.
This can be (somehow) mitigated by using "Let's Encrypt approach". If we
assume a keyserver would be used then setting a short expiry on the user
key and then extending it every couple of months automatically (with no
user input) would provide a "dead man's switch" that'd render the key
unusable if the user stops using Thunderbird.
> For the initial version of Thunderbird with OpenPGP support, Thunderbird 78, we’ll not yet enable OpenPGP encryption for emails automatically. Instead, we’ll require that users opt in, prior to using it. However, it should be easy to opt in, and we might implement a smart user interface, that allows the user to discover the the availability of the OpenPGP messaging features, and offer interactive assistance that makes it easy to get started.
This could also be coupled with something like that "OpenPGP" header,
for example replying to a contact that indicated that they prefer
encrypted e-mail could trigger a bar similar to "forgotten attachment"
asking the user to generate OpenPGP keys.
Thanks for the work in this area!
Kind regards,
Wiktor
--
https://metacode.biz/@wiktor
Kai Engert
> but is s/mime support worth keeping ?
sufficient reason to remove it.
Even if not using S/MIME actively, Thunderbird users can passively
benefit from S/MIME support, by being able to verify the digital
signature in emails. I frequently receive digitally signed S/MIME email
sent to me by banks, companies, insurances or the post office.
Also, I assume there are many corporate Thunderbird users who are still
happy that we support S/MIME.
Kai
Kai Engert
>>
>> When you mention a new standard, can you please point out to which part
>> of the article you're reffering?
>
> And that's me forgetting that it was in an other article :
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020#Key_sharing
Kai Engert
On 08.10.19 13:44, Wiktor Kwapisiewicz wrote:
>> We intend to identify and use another existing library that provides
>> support for creating and processing OpenPGP messages, and we will try
>> to reuse parts of Enigmail that aren’t specific to GnuPG.
>
> As far as I know there are two: OpenPGP.js, that is re-used by the
> Autocrypt extension [1] and Sequoia [2], that is native and AFAIK
> provides a way to talk to GnuPG agent (for keys stored on smartcards).
Thunderbird is distributed under the MPL 2.0 license.
The Sequoia PGP library code uses the GPL v3 license.
IANAL, but in my understanding it means that Thunderbird cannot bundle
the Sequoia library, and therefore it cannot be used.
Another potential option is the RNP [4] library, which depends on the
Botan [5] crypto library.
[4] https://www.rnpgp.com/software/rnp/
[5] https://botan.randombit.net/
Kai
neandr
https://blog.mozilla.org/thunderbird/2019/10/thunderbird-enigmail-and-openpgp/
Two popular technologies exist that add support for end-to-end
encryption and digital signatures to email. Thunderbird has been
to do so.
The Enigmail Add-on has made it possible to use Thunderbird with
external GnuPG software for OpenPGP messaging.
Because Thunderbird 78 will no longer support classic Add-ons, the
current Thunderbird 68.x branch (maintained until Fall 2020) will be the
last that can be used with Enigmail.
OpenPGP messaging for the next major version of Thunderbird, which will
be released in summer 2020 (likely version 78).
maintaining the Enigmail Add-on for many years, has offered to assist
the Thunderbird development team.
Many details need to be considered for this initiative.
we'd like to take:
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
This feature was originally requested in
https://bugzilla.mozilla.org/show_bug.cgi?id=22687
Tanstaafl
earlier in this thread...
My question is, is this the result of working with and integrating P=P,
which was discussed last year (and possibly early this year)?
Or is this entirely different?
If different, I would like to hear what happened,m because we were all
promised news on this work but nothing ever materialized, that I saw,
but maybe I missed it.
Thanks,
Charles
On Tue Oct 08 2019 04:29:32 GMT-0400 (Eastern Standard Time), Ludovic
Hirlimann <lud...@mozilla.com> wrote:
> On 10/8/19 9:20 AM, Kai Engert wrote:
>> Please have a look at the following article which describes the approach
>> we'd like to take:
>> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
>>
>> If you have feedback, please post it to this list.
>
>
> Are you considering leveraging Pronto mail's PGP library (like bugzilla
> did a year or so ago) ?
>
> (it doesn't support all encryption protocols, has issues with big keys
> (like mine was over 800kb with signatures).
>
>
> Are we following
> https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
> gpg/pgp in thunderbird will follow the new standard and make the wot
> more usable ?
>
>
> Regarding S/Mime the issue I had with it was renewing certs and these
> days Find a cert issuer - there's probably oportunities for TB to
> partner with someone and get some €€€ throught a S/mime partnersip (eg
> referal from tb - someone pays for a cert and Tb get's revenue from it).
>
>
> Final note I'm very happy to get this email today - because the main
> reason I use TB is that I can easily use pgp with it. Thanks Patrick
> (and Hi ). Thanks kaie.
>
>
> Ludo
>
_______________________________________________
Phillip Hallam-Baker
Magnus Melin
There has been no real developments on the Thunderbird - pEp
front. The status of those discussions is still at the same stage
they were some years ago: we're still awaiting an initial alpha
prototype that can be evaluated, and after that further
discussions would be had. (Re the prototype, we've been told, pEp
in Enigmail is not it.)
The pEp mode of Enigmail will not be included in the Thunderbird
OpenPGP integration. AFAIK pEp has abandoned using Enigmail as the
delivery mechanism for their technology and are working some kind
of alternative pEp integration for Thunderbird.
-Magnus
Magnus Melin
See my other tb-planning post from a few minutes ago for current status
of Thunderbird and pEp.
-Magnus
Ludovic Hirlimann
TLDR; If any of you here will be at the Singapore IETF, we need to talk.
I know mozillamessaging never did. and this raises another question : Is Thunderbird represented in any internet standard orgs ?
Ludo
Kai Engert
interesting ideas, but we might not be able to spend much with new
research ideas at this time. The Thunderbird release timing is rather
fixed, we'll need to ship a polished and production quality Beta release
by May next year. I'm afraid the limited development resources that we
have available in the security feature area might be fully consumed by
the migration from Enigmail to internal OpenPGP support.
On 08.10.19 20:28, Phillip Hallam-Baker wrote:
> What if Thunderbird was also an end-to-end secure chat client and it
> wasn't limited to a single service provider?
also close to shipping OTR, but we aren't yet ready to announce it.
Hopefully in a few weeks we'll do a call for testing.
Kai Engert
intensive. Paying for flight, hotel, the expensive IETF meeting fee, and
probably not being able to get other work done for about a week, three
times a year, seems like a significant investment to me. If one
implements technology, but doesn't actively define new standards, how
can such participation be justified?
Ben Bucksch
This is fantastic! Thanks for getting PGP included, and for getting Patrick Brunschwig on board. He’s a great guy and very competent developer. I would like to thank Patrick for his awesome work over all the years!
Security-wise, I am also happy to read the following: “To promote secure communication, Thunderbird 78 will encourage the user to perform ownership confirmation of keys used by correspondents, [and] notify the user if the correspondent’s keys change unexpectedly”
These 2 things are crucial for secure communication. If the key is not validated, somebody could be sitting in the middle. Even more important is the key change notification. Without that, somebody could get into the middle, read all messages, and the user would not notice.
This is missing in most “secure messaging” applications with so-called “crypto”, and without this key change notification, there is no trusted communication possible. Thank you that you took attention to such details.
Ben Bucksch
Thank you for your wise position on this. I'm glad to see that we have
crypto competence on board, with you and Patrick Brunschwig.
I completely agree with what you wrote there. It is the right choice,
given the current circumstances.
Here is a potential problem:
> For users who prefer to avoid unencrypted email completely, we might
> offer an advanced configuration, that could require all outgoing email
> to be encrypted, either using any available key, or by requiring the
> use of confirmed keys, only.
I am concerned by such an option. If some advanced or security-conscious
Thunderbird users would enable this, find keys for me, and I would not
be able to read my own mail.
You mention exactly my reason later:
> Once a user distributes their own key to others, they’ve opened
> Pandora’s box. Others might discover the keys later and send encrypted
> email at any time in the future. If the key has been lost, either
> because the computer broke and no backups of they are available, or
> because the user forgot the passphrase that was used to protect the
> key, the incoming encrypted email cannot be read. Also, if the key has
> been lost, the archive of encrypted email that’s still available on
> your mail server can no longer be read either.
I am in that position. I have multiple keys on key servers, because I
sign software. However, I read mail on multiple email clients. Mostly
Thunderbird, but also on Android (where TB doesn't exist). I do not wish
to put the valuable PGP keys that I use to sign software on my cell
phone just to read mail.
There's even a worse situation: An attacker might create a PGP key for
the victim (a normal unsuspecting user that never used Thunderbird nor
GPG), put it on a key server, and Thunderbird users would fetch the key,
encrypt mail to the victim, and the victim would not be able to read her
own mail anymore. So, such opportunistic encryption creates new attack
scenarios, comparable to a DoS (Denial of service) attack, but it would
be in the design and permanent. At least for such senders that enable
such a Thunderbird feature. That's why such a feature is problematic.
Ben Bucksch
organizations, esp. governments, are actively using it, in Thunderbird.
Wiktor Kwapisiewicz
On 09.10.2019 17:13, Kai Engert wrote:
> FYI, it already is. We support XMPP/Jabber and some others, and we're
> also close to shipping OTR, but we aren't yet ready to announce it.
> Hopefully in a few weeks we'll do a call for testing.
multiprotocol support?)
As far as I know OTR has been largely replaced by OMEMO in XMPP/Jabber.
Source:
https://wiki.xmpp.org/web/XMPP_E2E_Security#OTR_.28Off-the-record_Messaging.29
(see also comments about OMEMO on that page).
John Bieling
DNSSEC which I think solves the trust issue. There is/was even an addon
https://addons.thunderbird.net/addon/great-dane-smime/
I use S/MIME and I would be sad if it got removed from Thunderbird.
Why do we always have that discussion to remove stuff from thunderbird?
S/MIME is a standard, isn't it?
John
> On 08.10.19 14:02, Ludovic Hirlimann wrote:
>> is s/mime support worth keeping ?
>
Patrick Cloke
> Hi Kai,
>
> On 09.10.2019 17:13, Kai Engert wrote:
>> FYI, it already is. We support XMPP/Jabber and some others, and we're
>> also close to shipping OTR, but we aren't yet ready to announce it.
>> Hopefully in a few weeks we'll do a call for testing.
>
> Is there a rationale somewhere why OTR was selected? (for example
> multiprotocol support?)
>
> As far as I know OTR has been largely replaced by OMEMO in XMPP/Jabber.
>
> Source:
> https://wiki.xmpp.org/web/XMPP_E2E_Security#OTR_.28Off-the-record_Messaging.29
>
>
> (see also comments about OMEMO on that page).
>
OTR is cross protocol, which fits nicely into what Thunderbird supports.
It is unfortunately hard to get a clear picture of what is worth
implementing for XMPP (i.e. how many users exist that support different
end-to-end encryption technologies). The major downside, in my
understanding, is that OTR does not support multi-user chats. I'm sure
there are some others, but OTR seemed like a good place to start.
There's a bug [1] about implementing OMEMO for anyone who is interested!
--Patrick
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1237416
ba
No details about pEp. Do I miss a statement TB isn't going with pEp anymore?AFAIK pEp is installed with Egnimail, so if Egnimail stops working with >68 which role will pEp play in the future for TB?
Phillip Hallam-Baker
Will
> On 08.10.19 20:28, Phillip Hallam-Baker wrote:
>> What if Thunderbird was also an end-to-end secure chat client and it
>> wasn't limited to a single service provider?
> FYI, it already is. We support XMPP/Jabber and some others, and we're
> also close to shipping OTR, but we aren't yet ready to announce it.
> Hopefully in a few weeks we'll do a call for testing.
the other issues related to add ons, we'd like to know why TB is
spending presumably a lot of resources on chat client encryption?
TB is an email client right?
Why don't you concentrate on getting that bit right first?
There are mountains of unfixed bugs, APIs that are a mess, add ons that
we can't get to work and could do with help, and you are messing around
with chats and OTR?
Exactly what is the direction of travel for TB? Replace email with chat?
You are so late to that party.................
We don't need it - we already have a good chat system, with OTR if we
want it, and a pile of other functionality. Quite simply there are
already much better systems out there.
Chat in TB is just a waste of CPU and coding cycles IMHO. Beyond a
cursory look we have never used it. I'd rather see it dumped completely.
Obviously this has all been discussed behind closed doors? Why isn't the
community consulted about this sort of thing, or is it paying clients only?
<shakeshead>
Phillip Hallam-Baker
Magnus Melin
> we'd like to know why TB is
> spending presumably a lot of resources on chat client encryption?
Thunderbird is committed to ensuring free and private communications.
Not only for chat but email too, which the OpenPGP announcement would
have you know. I think in the larger view of things, ensuring
distributed end-to-end encryption systems for communication are easily
obtainable is very important for freedom of speech and other fundamental
rights.
-Magnus
Óvári
Please integrate Jami into Thunderbird.
Jami works on all platforms that Thunderbird works on. Jami also works on other platforms where Thunderbird doesn't like iPhone and Android.
Jami would also enable a SIP client to be available from within Thunderbird so Address Book contacts could be called.
What do you think?
Thank you
Óvári
Will
The focus of any open source project is invariably what people are prepared to work on.
With any OS project we are involved in (several), if we can't code, we help in support, or documentation, and if nothing else pay.
We are talking about core TB code here. The very base that everyone needs. The bit I guess most TB devs should probably be most focussed on because like - that is the core product??
It isn't our fault if the developers we have asked to help us have told us they don't want to because the code is missing features they require or it is so spaghetti like they don't want to waste their time and ours, or they can't see the point as it will all have to be rewritten again in 5 minutes.
Hey ho, Seems there are plenty of others who feel the same way.
I'll leave them to continue the fight as we will undoubtedly get banned for being out of order or somesuch.
Patrick Cloke
Wiktor,
On 10/11/19 7:23 AM, Wiktor Kwapisiewicz wrote:
On 09.10.2019 21:58, Patrick Cloke wrote:
It is unfortunately hard to get a clear picture of what is worth
implementing for XMPP
XSF publishes Compliance Suites every year that group features that they consider "worth implementing". See for example:I hadn't seen this exact compliance test site before. Thanks! I think it is only half the picture though. If a server implements an XEP, but no clients do, then it is not necessarily worth implementing. (There's also the aspect of trying to understand what clients are popular, I haven't looked into this for XMPP in a very long time though.)
https://xmpp.org/extensions/xep-0412.html
There are also tests run by companies that invest in XMPP heavily:
https://compliance.conversations.im/tests/
(i.e. how many users exist that support different end-to-end encryption technologies).
That's not the impression I got from XSF mailing lists. There are three groups of E2E technologies within XMPP: legacy (OTR and old OpenPGP), recommended (OMEMO and new OMEMO) and there is also MLS that some XSF council members believe will replace OMEMO long-term but the spec is not ready.I should probably join the XSF mailing list... the thing missing from that site is some understanding of how popular each of those clients are. (What percentage of the user population supports it, not what percentage of clients do.) Anyway, I'm not against supporting OMEMO, but supporting OTR was a good baseline since it helps all the protocols implemented in Thunderbird, and a bunch of the work had already been done a few years ago. Kai and Alex finished integrating it.
Currently OMEMO is widely implemented, see: https://omemo.top/
OTR, as the wiki page indicates, is used in either legacy clients where multiprotocol support is necessary. (There is also OTRv4 in development supported by one client that showcases it: https://coy.im ).I've seen the OTRv4 stuff, a bit, but haven't been plugged into whether clients really plan to implement it or not. My understanding is that it is very incompatible with OTRv3, which is unfortunate from a technical standpoint.
The major downside, in my understanding, is that OTR does not support multi-user chats. I'm sure
there are some others, but OTR seemed like a good place to start.
There's a bug [1] about implementing OMEMO for anyone who is interested!
Thanks for the reference!
No problem. I think it'd be good to have multiple options here. Hopefully the other users you're talking to have at least one that overlaps! I'm unsure how hard it would be to incorporate OMEMO, but I'd be willing to help guide someone who is interested.
Last thing I'll say is that if there are specific XMPP features
that are missing from Thunderbird please
start by filing a bug (probably a bug per XEP / feature).
Unfortunately most of my use of XMPP is via GTalk [1] which has a
pretty terrible feature set.
--Patrick
[1] Yes, it still works.
Tanstaafl
> On 10-10-2019 13:04, Will wrote:
>> we'd like to know why TB is
>> spending presumably a lot of resources on chat client encryption?
>
> Thunderbird is committed to ensuring free and private communications.
> Not only for chat but email too, which the OpenPGP announcement would
> have you know. I think in the larger view of things, ensuring
> distributed end-to-end encryption systems for communication are easily
> obtainable is very important for freedom of speech and other fundamental
> rights.
client, not a Chat client, and that should take a -very high- priority.
Once the email code is rewritten and all major/known bugs squashed, then
and only then should PAID resources (volunteers are of course always
welcome to work on whatever they want) be focused on chat and other
extraneous features.
If PAID resources are being used for Chat and other non-email type work,
then I question the validity of such decisions.
Will
> On 10-10-2019 13:04, Will wrote:
>> we'd like to know why TB is
>> spending presumably a lot of resources on chat client encryption?
>
> Thunderbird is committed to ensuring free and private communications.
> Not only for chat but email too, which the OpenPGP announcement would
> have you know. I think in the larger view of things, ensuring
> distributed end-to-end encryption systems for communication are easily
> obtainable is very important for freedom of speech and other
> fundamental rights.
>
time, and fully support the reasons for it.
We're not sure what relevance OpenPGP has to chat systems - that is just
conflating things. We understand the moves with OpenPGP for email.
However, there is a suggestion you are adding OTR to Thunderbird which
suggests you are trying to make it more a chat client and we just can't
see the logic behind that, especially when there are so many issues in
the basic email and calendar client itself.
Trying to compete in an already crowded *chat* market where you are up
against some seriously big players seems odd. We don't need TB for that
- there are much better solutions out there that fulfil your aspirations.
Why not just have hooks to use other systems, be that Signal or
whatever? Let the add on devs decide what they want to plug in.
TB are probably concerned that ultimately (in the long term) chat is
going to make email, and therefore TB, redundant. That really needs an
open conversation in itself.
Wiktor Kwapisiewicz
On 09.10.2019 21:58, Patrick Cloke wrote:
> implementing for XMPP
consider "worth implementing". See for example:
https://xmpp.org/extensions/xep-0412.html
There are also tests run by companies that invest in XMPP heavily:
https://compliance.conversations.im/tests/
> end-to-end encryption technologies).
groups of E2E technologies within XMPP: legacy (OTR and old OpenPGP),
recommended (OMEMO and new OMEMO) and there is also MLS that some XSF
council members believe will replace OMEMO long-term but the spec is not
ready.
Currently OMEMO is widely implemented, see: https://omemo.top/
multiprotocol support is necessary. (There is also OTRv4 in development
supported by one client that showcases it: https://coy.im ).
> understanding, is that OTR does not support multi-user chats. I'm sure
> there are some others, but OTR seemed like a good place to start.
>
> There's a bug [1] about implementing OMEMO for anyone who is interested!
Magnus Melin
> However, there is a suggestion you are adding OTR to Thunderbird which
> suggests you are trying to make it more a chat client and we just can't
> see the logic behind that,
Thunderbird already has chat, and many other features not directly
"mail" too. Adding OTR support is just picking a fairly low hanging
fruit that Thunderbird can use to differentiate itself to others with.
We've also learnt that for organizational usage, the chat component is
important.
> TB are probably concerned that ultimately (in the long term) chat is
> going to make email, and therefore TB, redundant.
I don't see any concern there. Mail and chat are used for totally
different things.
-Magnus
Ryan Sipes
Hey Tanstaafl,
The percentage of time and resources spent on chat probably
matches up with the userbase that we have for chat. We have many
large enterprises and a few governments using XMPP right now with
Thunderbird.
If they represent 1% of our userbase, that probably tracks with the time spent on this feature - if even, I'd say the time spent is actually a fraction of a fraction of a percent of donations. And those enterprises and governments, as far as I can tell, are a good source of donations.
Also, the entire Thunderbird team uses chat in order to stay in touch and collaborate. Improving chat means helping the core team communicate more effectively, and if we can secure our chat with each other that's even better.
This comes across as "I don't use that feature, therefore it is a
waste." - which I think is a flawed way to think about what to
work on. I've had a couple of enterprises reach out to share
they've made reasonably sizable, often recurring donations, and
share what they use. Are their donations not worth anything?
Wiktor Kwapisiewicz
On 11.10.2019 14:12, Patrick Cloke wrote:
> I hadn't seen this exact compliance test site before. Thanks! I think it
> is only half the picture though. If a server implements an XEP, but no
> clients do, then it is not necessarily worth implementing. (There's also
> the aspect of trying to understand what clients are popular, I haven't
> looked into this for XMPP in a very long time though.)
still in use so it's not really possible to cover all cases. On the
other hand there is a high convergence of XEPs supported if one
considers modern clients (such as https://conversations.im/ or
https://dino.im/ ).
> I should probably join the XSF mailing list... the thing missing from
> that site is some understanding of how popular each of those clients
> are. (What percentage of the user population supports it, not what
> percentage of clients do.)
a federated protocol such as XMPP.
> Anyway, I'm not against supporting OMEMO, but
> supporting OTR was a good baseline since it helps all the protocols
> implemented in Thunderbird, and a bunch of the work had already been
> done a few years ago. Kai and Alex finished integrating it.
protocols that's a big plus. I just wanted to mention OMEMO as observing
a small circle of federated protocols is my hobby :)
> Last thing I'll say is that if there are specific XMPP features that are
> missing from Thunderbird please start by filing a bug
> is via GTalk [1] which has a pretty terrible feature set.
was popular but the protocols and feature sets varied so drastically
that it seems like two different protocols.
If you have time and would like to see XMPP I'd suggest installing
https://conversations.im and trying it out. It does have end-to-end
encryption enabled by default and looks and feels like any kind of
modern chat application.
Wiktor Kwapisiewicz
I noticed the following change on the Wiki:
> Will OpenPGP cards be supported for private key storage ?
>
> Probably not, because we don't use the GnuPG software that's usually required to access OpenPGP smartcards.
I think it's worth mentioning that there is a way to access smartcards
through GnuPG's JSON interface (native messaging). That's what
Mailvelope uses and it's just a browser extension.
Some details are available here:
https://github.com/mailvelope/mailvelope/wiki/Mailvelope-GnuPG-integration
Of course I wouldn't consider this a top priority (Mailvelope added
support for that just recently) but certainly interesting for some
people that prefer not to store their private keys in software.
Tanstaafl
Actually, your explanation completely resolves any concern I may have
had - and I certainly didn't mean to come across as saying "I don't use
foremost, an EMail client, not a Chat client. I don't think anyone would
disagree with that.
But if these details had been included in the OP, I wouldn't have said a
thing, because I have no problem at all with what you described.
Anyway, thanks for taking the time to respond and clear that up, and
again, thanks for your and everyone's hard work keeping TB the best
EMail client available.
Charles
On 10/14/2019, 5:29:10 AM, Ryan Sipes <ry...@thunderbird.net> wrote:
> Hey Tanstaafl,
>
> The percentage of time and resources spent on chat probably matches up
> with the userbase that we have for chat. We have many large enterprises
> and a few governments using XMPP right now with Thunderbird.
>
> If they represent 1% of our userbase, that probably tracks with the time
> spent on this feature - if even, I'd say the time spent is actually a
> fraction of a fraction of a percent of donations. And those enterprises
> and governments, as far as I can tell, are a good source of donations.
>
> Also, the entire Thunderbird team uses chat in order to stay in touch
> and collaborate. Improving chat means helping the core team communicate
> more effectively, and if we can secure our chat with each other that's
> even better.
>
> This comes across as "I don't use that feature, therefore it is a
> waste." - which I think is a flawed way to think about what to work on.
> I've had a couple of enterprises reach out to share they've made
> reasonably sizable, often recurring donations, and share what they use.
> Are their donations not worth anything?
>
> Ryan Sipes
> Community and Business Development Manager
Will
>
> This comes across as "I don't use that feature, therefore it is a
> waste." - which I think is a flawed way to think about what to work
> on. I've had a couple of enterprises reach out to share they've made
> reasonably sizable, often recurring donations, and share what they
> use. Are their donations not worth anything?
>
We're more like
"We don't use that feature because there are much better, more secure
products out there that are kicking email into touch, and if the time
spent on messing around with chat had been spent on email and trying to
make PGP easier then maybe we wouldn't be faced with the extinction of
email because chat is just so much easier"
If you really want to do chat just build yourself a working API that
integrates Signal, Whatsapp (yuck) Facebook messenger & all that other
stuff. Why bother with OTR when you can integrate their stuff which
already has end to end encryption?
Email is stuck in its ways. We hate the word 'disruption' but email is
going the same way as fax. Can't change it. Engineer around it.
Millennials and Generation Z barely look at email beyond using an
account to setup their phones. They are the future.
A few advantages of chat off the top of the head.
Instant comms
Read receipts, and you don't even need Exchange
Any type of attachment (admin permitting) and easy handling
End to end security via SSL, and many have end to end encryption built
in too
Easy voice messaging
Bots.....
Most are accessible via web clients so are platform independent, and
just as easily accessible via mobile with either a browser or app.
Integrated messaging into things like CRMs - just message your clients
direct from your CRM to their whatsapp or FB messenger (yuck) or
whatever etc AND vice versa
Integrated into web sites - customers can contact you direct off you
site and send attachments etc. Saves a lot of issues with emails.
Federates systems where different systems can talk to one another
Like it or not, that is the direction of travel. YMMV.
Where TB sits in the middle of that we really don't know. But the recent
misery that TB upgrades has caused us has just made us look a whole lot
harder at how we get rid of email entirely.
We expect we can continue with TB at the current version for a couple of
years by which time we think chat will be almost ubiquitous and email
will barely be required.
Onwards and upwards.
Magnus Melin
> If you really want to do chat just build yourself a working API that
> integrates Signal, Whatsapp (yuck) Facebook messenger & all that other
> stuff. Why bother with OTR when you can integrate their stuff which
> already has end to end encryption?
None of those are open systems. AND, regarding end to end encryption,
for the ones that even claim to support it we can only take their word
that there aren't back doors. In reality, with a centralized system
you're not safe against a powerful attacker.
Thunderbird wants to enable *distributed*, open, end-to-end encrypted
communications. There are not too many common solutions for that.
> Email is stuck in its ways. We hate the word 'disruption' but email is
> going the same way as fax. Can't change it. Engineer around it.
>
> Millennials and Generation Z barely look at email beyond using an
> account to setup their phones. They are the future.
Email usage is just going up:
https://99firms.com/blog/how-many-email-users-are-there/
Regardless of that, for any business use case, I'm sure your contacts
will be pleased to have you message them work conversations (other than
casual) through social networks. [irony, if you didn't catch that already]
-Magnus
Patrick Cloke
On 10/14/19 5:07 AM, Wiktor Kwapisiewicz wrote:
> Hi Patrick,
>
> On 11.10.2019 14:12, Patrick Cloke wrote:
>> I hadn't seen this exact compliance test site before. Thanks! I think
>> it is only half the picture though. If a server implements an XEP,
>> but no clients do, then it is not necessarily worth implementing.
>> (There's also the aspect of trying to understand what clients are
>> popular, I haven't looked into this for XMPP in a very long time
>> though.)
> Agreed. Additionally XMPP has a lot of unmaintained clients that are
> still in use so it's not really possible to cover all cases. On the
> other hand there is a high convergence of XEPs supported if one
> considers modern clients (such as https://conversations.im/ or
> https://dino.im/ ).
>> that site is some understanding of how popular each of those clients
>> are. (What percentage of the user population supports it, not what
>> percentage of clients do.)
> I'm not sure if it's possible to get "percentage of user population"
> in a federated protocol such as XMPP.
before and done a little research on this for IRC. Anyway, your point is
valid. My counterargument really comes down to: with limited resources
you need to be selective in what is implemented.
>> good baseline since it helps all the protocols implemented in
>> Thunderbird, and a bunch of the work had already been done a few
>> years ago. Kai and Alex finished integrating it.
> Sure, there is no harm doing that I guess and if it works with all
> protocols that's a big plus. I just wanted to mention OMEMO as
> observing a small circle of federated protocols is my hobby :)
you might have.
--Patrick
Mihovil Stanić
15.10.2019 u 14:11, Magnus Melin je napisao/la:
> On 14-10-2019 23:02, Will wrote:
>> If you really want to do chat just build yourself a working API that
>> integrates Signal, Whatsapp (yuck) Facebook messenger & all that other
>> stuff. Why bother with OTR when you can integrate their stuff which
>> already has end to end encryption?
>
> None of those are open systems. AND, regarding end to end encryption,
> for the ones that even claim to support it we can only take their word
> that there aren't back doors. In reality, with a centralized system
> you're not safe against a powerful attacker.
>
> Thunderbird wants to enable *distributed*, open, end-to-end encrypted
> communications. There are not too many common solutions for that.
>
Actually, Signal is open. And if it's true, Whatsapp is build based on
Signal technology, but since no one can verify it...
Wiktor Kwapisiewicz
On 16.10.2019 07:45, Mihovil Stanić wrote:
>>
>> Thunderbird wants to enable *distributed*, open, end-to-end encrypted
>> communications. There are not too many common solutions for that.
>>
> Actually, Signal is open. And if it's true, Whatsapp is build based on
> Signal technology, but since no one can verify it...
Signal is open-source but is not distributed. Additionally Moxie is
against other clients connecting to their servers (see [0]). For me
Signal is not really an "open communications" platform but I guess this
is subjective.
[0]:
https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165
For the record parts of Signal (libsignal) are re-used in other systems
such as XMPP's OMEMO.
Kind regards,
Wiktor
--
https://metacode.biz/@wiktor
Will
>
>> Email is stuck in its ways. We hate the word 'disruption' but email is
>> going the same way as fax. Can't change it. Engineer around it.
>>
>> Millennials and Generation Z barely look at email beyond using an
>> account to setup their phones. They are the future.
>
> Email usage is just going up:
> https://99firms.com/blog/how-many-email-users-are-there/
>
Ahh, lies, damn lies, and statistics?
We said they use an email address to "register" their devices, and then
don't use it again... 'users' and 'usage' are two different things.
Equally, where are the comparative stats between email usage and chat/IM
usage??? You might have seen a meteoric rise in IM over the last 10
years. Email has not had that. Well, apart from the amount of junk sent.
There are any number of reports online showing you the rise in IM. That
is at the expense of email.
From our own systems something like 70% of all mail that hits our server
is junk - and some days it is much higher than that. People are sick of it.
Junk on most IM platforms currently is minimal, and non existent on
internal systems.
But you know all this and that is why you have tried to integrate chat
into TB, contradicting yourself and your stats quoted above.
It really is a shame that there has not been a wider and more open
discussion about it.
> Regardless of that, for any business use case, I'm sure your contacts
> will be pleased to have you message them work conversations (other
> than casual) through social networks. [irony, if you didn't catch that
> already]
>
Actually you are making assumptions here, and you know the adage about
that don't you?
This is client driven. They are the people that pay the bills. If they
want, then we have to provide. Whether we like it, or not (personally I
hate it and avoid it in private, but... clients)
More and more of the big companies like M$ etc try to block it unless it
originates from another equally big provider. So you are forced more and
more to use email systems (M$, Gmail et al) that are not under your
control and where mail can be read my the providers (or at least meta
data) for advertising purposes. And you are worrying about IM?
Yup. Where we can we push them to use better more secure systems, and we
are pretty careful about what we do, and how we do it. GDPR and all that.
But, they are the clients and we have bills to pay. You cut your cloth
accordingly.
==============
"Oh, that was easy," says Man, and for an encore goes on to prove that
black is white and gets himself killed on the next zebra crossing.”
:-)