APG integration plot

229 views
Skip to first unread message

Oliver

unread,
May 20, 2010, 10:54:02 AM5/20/10
to K-9 Mail
This is intended as a draft of what I currently envision, pasted from
an email to Jesse, as this is a better forum. Please don't hold back
with better ideas, concerns, complaints, or flattery.

As stated in the issue #13 already, I think a secondary app that
concentrates on key management and encryption/decryption is sensible,
it follows what all other implementations do... an email program using
GPG or PGP. And k9mail should continue to concentrate on being an
email client.

I still think we can achieve good integration and a simple,
userfriendly interface:

1. Encrypt checkbox and sign checkbox somewhere in the compose
activity, which when enabled makes k9mail fire an Intent when "Send"
is clicked, APG picks that up and offers selection of keys, but it can
already use data provided by k9mail, such as some default preferences
and the key for the receiver email, if known, as well as a signature
key bound to the account. Right afterwards APG returns the encrypted
data to k9mail, which continues sending.

2. Opening an email allows k9mail-side determination of the type of
email, if it is PGP/MIME or inline PGP MESSAGE/SIGNATURE, then it can
offer a button or two (maybe in a secondary bar above "Reply", etc.)
to deal with the message. Clicking "Decrypt" again fires up an APG
Intent to handle the message, APG asks for the pass phrase (if not
already cached), returns the message to k9mail. So in the best case
scenario the pass phrase'd be cached, the user'd just see the decrypt
progress bar, and he's back in k9mail with the message replaced by
cleartext, worst case scenario he has to enter a pass phrase and click
"OK".
The same could be done for attachments, APG would ask where to save
them.

3. k9mail has loads of useful information APG doesn't have, such as
header and attachment type information, as well as sender and receiver
email addresses, which can be used for key pre-selection. In addition
to that it could have a section in preferences, which could use APG to
select preferred signature keys for different accounts. It also could
set a preference for PGP/MIME or inline MESSAGE/SIGNATURE, as well as
algorithm defaults handed over to APG.

4. While I'd naturally be happy to see APG being the main app to
handle all this, I'd make it an explicit design point to not make
k9mail dependent on it, or only work with APG. So all Intents and
what's going
on in k9mail should still work if some other app comes along and
offers to be able to handle those tasks. That being said... I'll try
to make sure there's never a better alternative. ;)

Since I don't know the k9mail code very well yet, my main concerns and
uncertainties are in how much this goes against existing GUI design
notions of k9mail, and whether that flow of Intents would somehow be a
technical issue or not.

It'd also be great to get more ideas for features we could integrate,
but also how to hide those functionalities if they aren't needed at
all

Raincoat,
Oliver

--
You received this message because you are subscribed to the Google Groups "K-9 Mail" group.
To post to this group, send email to k-9-...@googlegroups.com.
To unsubscribe from this group, send email to k-9-mail+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/k-9-mail?hl=en.

Oliver

unread,
May 20, 2010, 11:20:20 AM5/20/10
to K-9 Mail
Bit silly to talk about it without saying what it is, info about APG
can be found here:
http://apg.thialfihar.org/ and http://android-privacy-guard.googlecode.com/

cketti

unread,
May 20, 2010, 12:44:32 PM5/20/10
to k-9-...@googlegroups.com
Welcome Thialfihar!

I can't wait to have better OpenPGP integration. Your plan looks pretty
much like what I had envisioned and hoped someone would implement :)

I saw you live in Berlin. I will be there next week. So drop me a line
if you want to grab a drink and talk about K-9 Mail and APG.

Cheers,
Christian

Thialfihar

unread,
May 21, 2010, 12:03:59 PM5/21/10
to K-9 Mail
> I can't wait to have better OpenPGP integration. Your plan looks pretty
> much like what I had envisioned and hoped someone would implement :)

Sweet. I hope I can start trying things out in a branch next week.
I'll keep posting problems I run into and such

> I saw you live in Berlin. I will be there next week. So drop me a line
> if you want to grab a drink and talk about K-9 Mail and APG.

Leave the house? You must be mad! ;) But thanks for the offer.

Porridge,

Nathan of Tor / GuardianProject

unread,
May 25, 2010, 11:50:11 PM5/25/10
to K-9 Mail
(Hey I found the thread!)


On May 20, 10:54 am, Oliver <thialfi...@gmail.com> wrote:
> As stated in the issue #13 already, I think a secondary app that
> concentrates on key management and encryption/decryption is sensible,

Yes... especially since I know of other apps that want to use AGP
features beyond email. Have you published the intents you offer in AGP
and docs on how to use them?

> 1. Encrypt checkbox and sign checkbox somewhere in the compose
> activity, which when enabled makes k9mail fire an Intent when "Send"

Yes, as seamless as possible is good, with some options such as
"always encrypt if key is available" and "always sign messages" etc.

I also would want to have decryption of messages be as transparent as
possible, and not a two or three step procedure. That could get
annoying on a mobile device, so an "automatically decrypt" option
would be best, along with a preference on how long to cache passwords.

> 2. Opening an email allows k9mail-side determination of the type of
> email, if it is PGP/MIME or inline PGP MESSAGE/SIGNATURE, then it can
> offer a button or two (maybe in a secondary bar above "Reply", etc.)

Any thoughts on handling PGP/MIME attachments or .ASC encoded files,
messages or keys?

For whatever reason on the desktop, I send my encrypted messages using
MIME attachments, not plain text encoded ciphertext in the body, so I
don't think attachments should always be considered "files".

> on in k9mail should still work if some other app comes along and
> offers to be able to handle those tasks. That being said... I'll try
> to make sure there's never a better alternative. ;)

I think documenting an open API intent for encryption is a very
honorable approach, and would encourage you to do this. That said, I
hope there is never a better alternative either b/c you've done such
great work so far!

+nathan

Thialfihar

unread,
May 31, 2010, 6:10:55 PM5/31/10
to K-9 Mail
Heyup.

Sorry about the late response. Got some work done, tho. :)

> > As stated in the issue #13 already, I think a secondary app that
> > concentrates on key management and encryption/decryption is sensible,
>
> Yes... especially since I know of other apps that want to use AGP
> features beyond email. Have you published the intents you offer in AGP
> and docs on how to use them?

Not yet, I'll define them as I go along now. APG 1.0.0 will be the
next version, with it I'll publish the first Intents. For the
beginning it'll likely be: select public keys, select secret key,
decrypt message, encrypt message.
I still need to wrap my head around encoding issues and how to best
deal with HTML and multiple PGP MESSAGE blocks, and later add PGP/MIME
support and a file decryption Intent.

> > 1. Encrypt checkbox and sign checkbox somewhere in the compose
> > activity, which when enabled makes k9mail fire an Intent when "Send"
>
> Yes, as seamless as possible is good, with some options such as
> "always encrypt if key is available" and "always sign messages" etc.

Yep, I'd like to bind some of those preferences to the account. I
think that makes sense especially for the signing key.

> I also would want to have decryption of messages be as transparent as
> possible, and not a two or three step procedure. That could get
> annoying on a mobile device, so an "automatically decrypt" option
> would be best, along with a preference on how long to cache passwords.

APG has that caching preference, but I might have to wrap that into a
service. I'm not so sure automatic decryption is a good idea. Maybe
we'll find a good way later, but for now I'll always require the
Decrypt button clicked. Imagine browsing through your emails via the
"up" and "down" buttons in k9mail and each time you are sent to APG
and have to put in a password (worst case).

> > 2. Opening an email allows k9mail-side determination of the type of
> > email, if it is PGP/MIME or inline PGP MESSAGE/SIGNATURE, then it can
> > offer a button or two (maybe in a secondary bar above "Reply", etc.)
>
> Any thoughts on handling PGP/MIME attachments or .ASC encoded files,
> messages or keys?
>
> For whatever reason on the desktop, I send my encrypted messages using
> MIME attachments, not plain text encoded ciphertext in the body, so I
> don't think attachments should always be considered "files".

Yes, definitely should support that. But I don't know k9mail well
enough for any predictions yet. I'm guessing at some point we can just
hand over the attachments and treat them accordingly when they come
back unencrypted, somehow hooking into k9mail where it handles
plaintext emails.

Attached keys are another important point, but that'll also need some
more extra work to teach APG importing via an Intent. (and recognition
of keys)

> > on in k9mail should still work if some other app comes along and
> > offers to be able to handle those tasks. That being said... I'll try
> > to make sure there's never a better alternative. ;)
>
> I think documenting an open API intent for encryption is a very
> honorable approach, and would encourage you to do this. That said, I
> hope there is never a better alternative either b/c you've done such
> great work so far!

Cheers. :) Kind of you to say, you probably haven't looked at the code
in a while... but I'm working on a tidy up. ;)

As a bit of progress report: I recently made that APG branch, and
tonight added a Decrypt button to it, which already works quite
nicely. I'm gonna tackle message composing now.

In addition to the Intents I also want to implement a ContentProvider
in APG that can be queried by k9mail to read out key details. That'd
be useful for some things, but it might bind the functionality to APG
a bit more... tho that all could be optional or written with a
flexible URI choice in mind.

Oscilloscope,
Oliver

CqN

unread,
Jan 1, 2011, 2:09:21 PM1/1/11
to k-9-...@googlegroups.com
Happy New Year Oliver, Thialfihar, and all!

I am new here, just with a day experience in using APG/K9.  First, thank you for this great effort.  I am very long term user of pgp.  Your product is already quite useful!

A couple of suggestions, these might have been discussed before, pardon my ignorance.

1.  I think it would be very useful to have the passphrase longevity to be practically for ever, or a bit more conservatively until the phone is turned off, or locale changes or something like that.  Again, since this an option, the paranoid can keep it at 1sec or whatever :) For me my phone is more secure than all other computers I use, it may vary for others...

2.  Taking a leaf from one of the earliest seamless pgp integrated mailer of 15 years ago, PmMail:  Why show the encrypted text at all?  I cannot imagine it being remotely useful to view other than for debugging.  Instead replace it with icons 'Encrypted", "Signed", ...

3. Better still, IMO, when the passphrase is available (1. above, almost always), just proceed automatically to decrypt (with the current progress bar) and show result with the flag it was received 'encrypted'.

4. Of course for sending the current ui is excellent, it gives the option at the last minute to sign and/or encrypt!!

5. I had already given this feeback elsewhere (privately to T. also).   Key import to include key received in email as attachment or included.  PmMail does both.  The most used open source mailer does this part way.  Of course the complement of sending out ones public key thru the mail, again as attachment or included, without having to cut and paste.

If you guys need more help, I am willing to provide coding and other tasks.

Cordially, CqN

Thialfihar

unread,
Jan 1, 2011, 7:32:16 PM1/1/11
to k-9-...@googlegroups.com
> Happy New Year Oliver, Thialfihar, and all!

Heyup. Same to you and everybody else from me. :)

> 1.  I think it would be very useful to have the passphrase longevity to be
> practically for ever, or a bit more conservatively until the phone
> is turned off, or locale changes or something like that.  Again, since this
> an option, the paranoid can keep it at 1sec or whatever :) For me my phone
> is more secure than all other computers I use, it may vary for others...

I suppose the option "Until quit" is easily added. Mind creating an
issue on the APG Google Code site for that?

> 2.  Taking a leaf from one of the earliest seamless pgp integrated mailer of
> 15 years ago, PmMail:  Why show the encrypted text at all?  I cannot imagine
> it being remotely useful to view other than for debugging.  Instead replace
> it with icons 'Encrypted", "Signed", ...
> 3. Better still, IMO, when the passphrase is available (1. above, almost
> always), just proceed automatically to decrypt (with the current progress
> bar) and show result with the flag it was received 'encrypted'.

I'm assuming you mean the display in K9. I'm not in favour of doing
things like this automatically, especially on a device that isn't as
powerful as a desktop PC. One might reach an encrypted email by
moving/deleting another email, pressing previous/next, or simply
misclicking or wanting to check some header information... it'd be
very annoying if this automatically went to APG, where a possibly
lengthy decryption would be initiated. Especially once we get PGP/MIME
and encrypted attachments working this could result in quite useless
computation.

Also keep in mind that K9 has no information or access to the pass
phrase cache of APG. Of course one could implement an API that just
asks "got the pass phrase to this key?", but even that is data I don't
think any other app should have access to.

However, we could at some point add an option to automatically decrypt
for those who really want it. Perhaps even with some rules. That's all
still quite far away, tho. :)

> If you guys need more help, I am willing to provide coding and other tasks.
> Cordially, CqN

Thanks for the offer! An extra pair of eyes and skills are always
welcome, of course. Most of the issues above are purely APG related,
I'd say, so feel free to poke at the APG source a bit. Perhaps even
have a stab at providing a patch for the "Until quit" option to get
started. :)

In K9 I'd like to implement PGP/MIME next, but I'm not quite sure how
to do that yet. ;)

Ciao,
Thialfihar

Reply all
Reply to author
Forward
0 new messages