[guardian-dev] looking for comments on secure email v2
c1.devrandom at niftybox.net
Sun Feb 23 14:59:22 EST 2014
Glad to see people working on secure email. I have a quesetion:
the private key for each user be compromised as they log in? If so, how
do you plan to mitigate this risk? Browser plug-in?
On Sun, 2014-02-23 at 14:33 -0500, Tim Prepscius wrote:
> So I'm writing a new version of mailiverse... I'm looking for some
> comments on specific design decisions.
> The fundamental reason is because the old one is too complicated, it
> was mostly built before I knew exactly what I was doing. And in
> retrospect, I think it was built the wrong way. GWT is nice because I
> can see things compile.. But GWT is not nice because it requires
> other people to have GWT.
> The goals for the new mailiverse are:
> 1. still, everything client side.
> 2. easy to modify, and easy to run without encryption. (for dev)
> 3. encryption is encapsulated into a single layer, replacement of
> ajax hook, basically
> 5. pgp
> 6. basically, something smaller and nimbler, easy to modify.
> Here is the question I have been pondering:
> In the old mailiverse, I didn't want to expose information about
> singular pieces of data. So I would group lots datas together into
> files. And then each data (let's say conversation) would have a
> pointer built from "file it's in, piece of the file index" (which
> would point to a mail data).
> But this made the design really complicated. If one file broke,
> because of some network difficulty or bug, lots of things might break.
> The server was simple, but it didn't offer any added "reliability"
> for the information graph to the client.
> So in the new mailiverse I was thinking about have the server be a
> restful server. Where each piece of data would have two elements
> exposed, "id" and "parentId." The rest would be encrypted. Well
> maybe there would be a "ordering" field, which would be based off of
> date. (for conversations to be ordered)
> So each folder would have a parentId of the userId.
> Each conversation would have a parentId of the folderId. (slightly
> different, but you get the point)
> Each mail would have conversationId as parentId.
> How bad is this?
> It would make the client interactions with the server be trivial. And
> actually, the whole rest of the design becomes relatively easy. The
> client no longer needs "pointers" stored everywhere and updated,
> because the pointers are essentially lookups "get all mail which has a
> parent conversation id of X"
> The encryption is simple. Everything is simple. So simple I'm blown
> away actually.
> But I think to myself. Ok, there definitely is information being leaked here.
> Somebody takes control of DB, would def be able to see how many
> messages you got, when you got them. How many messages in each
> conversation. If you've grouped them by folder, how many in each
> Also, because the messages are singular, they would be able to see the
> approximate size of each message. And they would be able to look at
> the conversations and approximate the size of the dictionary of words
> contained inside.
> What do you think about this?
> Do you think this trade off to make the client simple and the server
> simple is worth it?
> Can you see an alternate way of doing the pointers which I'm not
> seeing? Which gives some opacity to the graph relationships but
> perhaps allows the server to ensure the data is "well connected." (I
> just made that up ;-) )
> Thank you for your time. I realize this message is a bit off topic
> for guardian, but I think, broadly this is an appropriate place to
> Guardian-dev mailing list
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To Unsubscribe
> Send email to: Guardian-dev-unsubscribe at lists.mayfirst.org
> Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/c1.android%40niftybox.net
> You are subscribed as: c1.android at niftybox.net
More information about the Guardian-dev