Comment by underscore | Hacker News Reader

Comment by underscore | Hacker News Reader

I like the protocol-agnostic (and locally-stored) connection information, but I don't like the fact that I (I'm assuming) have to manually synchronize them between my devices -- if I understand right, if I friended someone on my phone, I'd have to somehow synchronize that information to my laptop if I wanted to use it there. Probably the provider would keep that information locally, and then prompt my browser to accept a new copy -- I know I wouldn't want to deal with anything much more fiddly than that. Is there a compelling reason to have that (edit: where "that" is the connection information stored in the browser, as suggested in the article when I wrote this) instead of a defined-in-the-protocol way of on-demand data export?

I guess the hash is just to fool spammers? It seems to add a fair amount of complication to the protocol to address just that one use case.

How do you define privacy? How does your protocol protect it?

edit: clarify clumsy wording

Regarding your first point, yes, I agree it doesn't make much sense to manually synchronize between devices. Providers would probably need to store that information to begin with, and you would have the option to export that information at your leisure.

Yeah, that's the primary use of the hash. It does add a bit of complication, but I think it's necessary for widespread adoption.

Privacy is provider-specific, therefore it's not up to the protocol to say what and what shouldn't be private. It's up to the provider.

I assume that your centralized repository of (email, id, provider) tuples wouldn't just spill out all of its contents to the world, preventing mass email harvesting. Instead, it would reply with the appropriate (email, id, provider) tuple when asked for an email (hashed or not) that it knows about, and return nothing or an error or whatever when asked about an email that it doesn't know about. In either case, as arethuza points about elsewhere in this thread, it is essentially an email address validity oracle for emails that it knows about -- hashed or not -- since a spammer can sit there all day and ask it about random email addresses and record its responses. If you hash an email address, the only thing you buy is to make the spammer add a line of code to their script. In short, I think that using a hash is functionally equivalent to not using a hash, at least for spam purposes. What do you think?

(note that a partial email validity oracle isn't necessarily a deal killer; PGP/GPG keyservers, for example, are partial email validity oracles, and have not only existed for years but have also gained acceptance amongst (some of) the security conscious and the paranoid)

(also note that a hash would be a safeguard (whose effectiveness is dependent on how resistant the hash function is to first preimage attacks and other factors) against disclosure following a compromise of the central database/authority, in addition to its questionable utility at fighting spam in normal situations)

What if a dynamic salt were added to the hash, i.e. instead of just email, it were email+first_name? I think that would solve most of the email harvesting issues that have been brought up.

Reply on news.ycombinator.com