Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google's end-to-end key distribution proposal

code.google.com

Post reply on HN
Print view View original

31–40 of 95 posts

Re: Google's end-to-end key distribution proposal

#31

Post by vidarh »

lifeisstillgood wrote: post #12
y0ghur7_xxx wrote: post #8

Earlier quoted context omitted.

> And then... maybe just maybe... spammers will be faced with a serious challenge. Why? Couldn't spammers encrypt the mail they send to you just like everybody else?

Because, I think, they would have to be part of the Key Directory too, listed under "Spammer". This kind if implies a secondary directory market of ratings and rankings of the prime source (ie isASpammer, isWithinThreeHopsOnLinkedIn)

They'd just keep creating new keys, and use a botnet to exchange seemingly valid e-mails with itself and a trickle of seemingly legit e-mails (buy access to a few small legit mailing lists to make sure their botnet isn't a total island). It's not clear to me that this won't make it possible for spammers to manufacture/buy sufficient "trust" to put themselves in a better situation than they're in today.

Re: Google's end-to-end key distribution proposal

#33

Post by higherpurpose »

My suggestion is for them to work at least another 12 months on this, before they even begin to publicly test it on Gmail accounts. We need more privacy quickly, but let's not rush into a protocol that could last for another 20 years, if all the major e-mail providers adopt it. We need to get this right.

I wish the DIME (former Dark Mail) protocol was out already, too, so we can compare. There's also Adam Langley's Pond [1], but sounds like it's too complex, and it only works over Tor. And TextSecure/Axolotl could probably be used as a secure e-mail protocol, too, if you add a proper e-mail like interface. I hope the team behind End-to-End is looking at all of them.

[1] - https://pond.imperialviolet.org/

Re: Google's end-to-end key distribution proposal

#34

Post by blueking »

blueskin_ wrote: post #30
blueking wrote: post #26

Earlier quoted context omitted.

You think google can write a proposal like this without the NSA getting involved ? The fact that they are preserving metadata is revealing and meaningful. Its another PR stunt. Google can never never be trusted again. They publicly lied about PRISM, and they got caught. These people have no business making security protocols for us.

I wasn't implying any trust in google on my part (I didn't trust them even before PRISM, but that shut the door on the chance of my ever trusting them again), and chances are this will never progress beyond a draft spec, but there isn't any real way to implement something like this without doing so. the NSA would find the block chain of this helpful, yes, but it isn't data they don't already have unless it is somehow…

Thats how google works. Piecemeal. You think loon was about internet for the poor and oppressed ? Thats just how they get their foot in the door. Im sure google just wanted to write a draft spec for the fun of it.

Google is a front for US intelligence. We should give no quarter. Shun them.

Re: Google's end-to-end key distribution proposal

#35

Post by lifeisstillgood »

vidarh wrote: post #31
lifeisstillgood wrote: post #12

Earlier quoted context omitted.

Because, I think, they would have to be part of the Key Directory too, listed under "Spammer". This kind if implies a secondary directory market of ratings and rankings of the prime source (ie isASpammer, isWithinThreeHopsOnLinkedIn)

They'd just keep creating new keys, and use a botnet to exchange seemingly valid e-mails with itself and a trickle of seemingly legit e-mails (buy access to a few small legit mailing lists to make sure their botnet isn't a total island). It's not clear to me that this won't make it possible for spammers to manufacture/buy sufficient "trust" to put themselves in a better situation than they're in today.

Darn - I think you are right... Ah well, defeating spam is only a nice to have from this

Re: Google's end-to-end key distribution proposal

#36

Post by jonttaylor »

I have been through this thought process before. The conclusion I came too was that the implementations should be transparent, but that the user information should not.

Basically I was not going to put up a list of everyones email addresses and keys anywhere, and certainly not who they connect with.

The more I looked into the problem, the more I realised that the vast majority of users would rather sacrifice security for usability. Even in my implementation people would rather not see the "Please verify this key with the recipient" page. They just want to get something done. I think this proposal from google would work well so long as their base implementation involves no additional steps beyond that of a normal email client.

My implementation uses a central key authority, however the application is pure javascript, and the entire javascript is downloaded to the browser prior to the user entering their email address and password. After that no more code gets sent to the client. You can verify it wont steal your data.

I have the same problem of initial key exchange that everyone else does, but I give the user options to verify they keys themselves. Once they have they encrypt their own contact list (along with keys) and re-upload it. Therefore limiting the attack vector to initial key exchange.

If anyone wants to have a look check out http://senditonthenet.com/

Re: Google's end-to-end key distribution proposal

#37

Post by lifeisstillgood »

tubelite wrote: post #21
jpgvm wrote: post #11

Earlier quoted context omitted.

The blockchain (as most people understand it atleast) is an implementation of a Merkle tree. Which is why Git/Bitcoin are eerily similar - they both utilize Merkle trees for integrity. The real innovation in the "blockchain" was using proof of work in combination with the Merkle tree in order to enforce a single history. Take that away and yes, it looks alot like Git. :)

And if you consider that a git commit is actually "proof of work" and find a way to quantify the value of that commit (fixes issue x which was worth y points, passes all regression tests), you would have... gitcoin.

Passing automated tests ?

Would that work? I design and build a set of tests that extend existing OSS business app A. I post them up and ask for contributions ... Only to be accepted if tests pass.

But really the value I want is in "quality" a very hard to quantify idea.

But Test first development as a means of proving compliance is a good idea. Not sure the git chain is useful though.

Re: Google's end-to-end key distribution proposal

#38

Post by nomailing »

vidarh wrote: post #27
Semaphor wrote: post #20

The first comment by Mailpile seems to highlight the biggest problem to me: >Hello! Bjarni from the Mailpile team here. >This is an interesting proposal and sounds like a significant improvement over the current centralized key-server model. >The main quibble I have with it, is it seems there's no concern given to the privacy of user's communications - the proposed gossip mechanism seems designed to indiscriminately…

As I just posted as a comment to the proposal: In the EU, e-mail addresses are personally identifiable information. It's not clear that an append-only log with no expiration or means for individuals to delete the content will even be legal in many EU countries.

One more reason to implement the append-only log using blockchain technology. Seems like a good fit. I don't think privacy laws can be applied to a blockchain, but probably that is still unclear. For example, if I post my email address in a Bitcoin transaction, can I then force every user to delete their blockchain?

Re: Google's end-to-end key distribution proposal

#39

Post by vidarh »

nomailing wrote: post #38
vidarh wrote: post #27

Earlier quoted context omitted.

As I just posted as a comment to the proposal: In the EU, e-mail addresses are personally identifiable information. It's not clear that an append-only log with no expiration or means for individuals to delete the content will even be legal in many EU countries.

One more reason to implement the append-only log using blockchain technology. Seems like a good fit. I don't think privacy laws can be applied to a blockchain, but probably that is still unclear. For example, if I post my email address in a Bitcoin transaction, can I then force every user to delete their blockchain?

You would not be able to stop individual users from doing so, but you could potentially make it legally untenable for commercial/corporate operators.

But personally, regardless of legality, if Google implements this with the degree of disclosure of e-mail details, I'll find another operator that isn't implementing this proposal.

Re: Google's end-to-end key distribution proposal

#40

Post by tomp »

vidarh wrote: post #27
Semaphor wrote: post #20

The first comment by Mailpile seems to highlight the biggest problem to me: >Hello! Bjarni from the Mailpile team here. >This is an interesting proposal and sounds like a significant improvement over the current centralized key-server model. >The main quibble I have with it, is it seems there's no concern given to the privacy of user's communications - the proposed gossip mechanism seems designed to indiscriminately…

As I just posted as a comment to the proposal: In the EU, e-mail addresses are personally identifiable information. It's not clear that an append-only log with no expiration or means for individuals to delete the content will even be legal in many EU countries.

What do you mean? When users sign up to a Key Registry, they are explicitly acknowledging that their emails and public keys can be used in the way described by the protocol. AFAIK, that's perfectly legal.
Post reply on HN