5 ms·

All encryption is done clientside, all we see are armored PGP messages. Cleartext signing isn't supported right now, but it's in our issue tracker and I believ

All encryption is done clientside, all we see are armored PGP messages. Cleartext signing isn't supported right now, but it's in our issue tracker and I believe that it should be implemented during the next few weeks.

e12e 11y ago
> All encryption is done clientside, all we see are armored PGP messages. Are you saying 3) above is wrong? Or are you saying that the client, when sending a plain-text message, first encrypts that message, and stores it on your servers, and then sends the email directly? Because that is the only way you can guarantee that you don't have a means to access a copy of the email that is sent un-encrypted. I understand that when sending encrypted emails (which I gather is your current main focus), the email is encrypted by the client before it is sent on to you. Another question: how well does this all interop with traditional email+gpg? Would it take a lot of effort to use your service with something like mutt? Without looking at the client code, I'm guessing client-server is all http(s)? So in order to make a non-browser client one would have to wrap the client-server communication some how (eg: sync mail from server to disk, and set up a binary("sendmail"), or smtp proxy for sending mail)?
- pzduniak 11y ago
  Right, I ignored sending unencrypted emails as they can be already considered "broken" as soon as they reach Gmail. Those emails are the only ones whose plaintext we see for a short amount of time, but we get rid of it as soon as we send it out to a remote server. Regarding RFC-compatible PGP emails - unfortunately right now it doesn't interop well at all. The server does support sending of PGP/MIME emails, but IIRC the frontend doesn't have any code for that. Internally we try to use our own PGP Manifest format for everything - it leaks the attachments count, but it's a lot faster and easier to parse (for example during clientside search index generation that we're working on). PGP/MIME switch in the app is in plans, but we're far from implementing such thing. Client-server is all HTTPS, either over plain requests or a SockJS bridge. I've already written a non-browser client that automatically sends "onboarding" emails and forwards emails to our support system - you can see its sourcecode here: https://github.com/lavab/lavabot https://github.com/lavab/lavabot. If there's enough interest, we might even create an official CLI client for the service - I've recently suggested a native app design that might work pretty well in such use case ;)
  - e12e 11y ago
    Thank you for the link -- I suppose it should've been obvious you'll have some use for command line tools internally, if only for automation (but automation is important, how else can my backup cron job let me know it's completed/failed? :-) Not so good that you don't (currently) interop all that well. I can understand that gpg/mime is a bit hard, and have some properties that aren't great (metadata/subject header...). As for plaintext being "broken" when reaching gmail, I suppose I've grown to be a different kind of pragmatic lately. Lets put it this way: I still enjoy postcards, and while (some) encryption is trivial (with the right tools, some of which you are building!) -- I really don't need "another messaging app" (but secure!). I need email that is easy to secure/so easy that always encrypt is useful. Then again, most of the email I send and receive go to public mailinglists -- without clearsigning, I'd have no use for your product (yet -- none of my private contacts use gpg, and are likely to move to your platform just to get it). That's not to say I'm not interested to see where you end up, and wish you all the best with your project!

e12e 11y ago

> All encryption is done clientside, all we see are armored PGP messages. Are you saying 3) above is wrong? Or are you saying that the client, when sending a plain-text message, first encrypts that message, and stores it on your servers, and then sends the email directly? Because that is the only way you can guarantee that you don't have a means to access a copy of the email that is sent un-encrypted. I understand that when sending encrypted emails (which I gather is your current main focus), the email is encrypted by the client before it is sent on to you. Another question: how well does this all interop with traditional email+gpg? Would it take a lot of effort to use your service with something like mutt? Without looking at the client code, I'm guessing client-server is all http(s)? So in order to make a non-browser client one would have to wrap the client-server communication some how (eg: sync mail from server to disk, and set up a binary("sendmail"), or smtp proxy for sending mail)?

pzduniak 11y ago
Right, I ignored sending unencrypted emails as they can be already considered "broken" as soon as they reach Gmail. Those emails are the only ones whose plaintext we see for a short amount of time, but we get rid of it as soon as we send it out to a remote server. Regarding RFC-compatible PGP emails - unfortunately right now it doesn't interop well at all. The server does support sending of PGP/MIME emails, but IIRC the frontend doesn't have any code for that. Internally we try to use our own PGP Manifest format for everything - it leaks the attachments count, but it's a lot faster and easier to parse (for example during clientside search index generation that we're working on). PGP/MIME switch in the app is in plans, but we're far from implementing such thing. Client-server is all HTTPS, either over plain requests or a SockJS bridge. I've already written a non-browser client that automatically sends "onboarding" emails and forwards emails to our support system - you can see its sourcecode here: https://github.com/lavab/lavabot https://github.com/lavab/lavabot. If there's enough interest, we might even create an official CLI client for the service - I've recently suggested a native app design that might work pretty well in such use case ;)
- e12e 11y ago
  Thank you for the link -- I suppose it should've been obvious you'll have some use for command line tools internally, if only for automation (but automation is important, how else can my backup cron job let me know it's completed/failed? :-) Not so good that you don't (currently) interop all that well. I can understand that gpg/mime is a bit hard, and have some properties that aren't great (metadata/subject header...). As for plaintext being "broken" when reaching gmail, I suppose I've grown to be a different kind of pragmatic lately. Lets put it this way: I still enjoy postcards, and while (some) encryption is trivial (with the right tools, some of which you are building!) -- I really don't need "another messaging app" (but secure!). I need email that is easy to secure/so easy that always encrypt is useful. Then again, most of the email I send and receive go to public mailinglists -- without clearsigning, I'd have no use for your product (yet -- none of my private contacts use gpg, and are likely to move to your platform just to get it). That's not to say I'm not interested to see where you end up, and wish you all the best with your project!