A New Gossip Tool That Keeps Fake Tipsters Away, but Guards Anonymity | Hacker News Reader

A New Gossip Tool That Keeps Fake Tipsters Away, but Guards Anonymity

wired.com

23 pointshawk6788 comments

Keep in mind that according to their T&C, if you disclose anything you shouldn't about your company, it's products, etc. Heard intends to fully comply and work toward providing them with your identification. So really, nothing of significance can be released here.

The verification server won’t know what e-mail address or credit card statement you used in order to get the badge, only that it was created by a particular issuer.

That's pretty clever but in case of serious leaks, and they do suggest it could be used by government employees, it doesn't provide much additional protection. Investigators will need two subpoenas/warrants instead of one.

Some verification services could simply not keep logs of what they verified, and documents they used. The problem here is that there is no way for the issuer to prove they really don't.

Heard is starting out by running one that verifies whether you’re a “tech industry insider” by checking to see if you have an email address from one of about 20 major technology companies.

Another problem is that your employer will know that you signed up for an anonymous gossip/leak site.

Getting the two subpoenas will not help you, because you cannot associate the information from the badge issuer with the information in the badge consumer. there is no link there at all.

There is some cryptographic token. It should be a pretty strong link since otherwise the whole system unravels.

That does seem to be the biggest limitation -- you have to trust that the issuer is running an unmodified version of the open source code.

"Another problem is that your employer will know that you signed up for an anonymous gossip/leak site."

Only if they check your email logs and see that a verification code was sent, which you could plausibly deny having requested. Of course, if you're the only person at your company to sign-up, and you're therefore the only one with one of those codes, that would obviously expose you.

Verification services can avoid some of the "your employer will know that you signed up for an anonymous gossip/leak site" problem by:

1. determine if it really is $Person by using personal verification independent of employer controlled email/sms/etc then

2. verifying $Person actually is employed in such a capacity.

However, the log thing is a problem. As is the problem of "how do we know the verification services aren't just lying to us about $Person's identity/credentials"?

Hi this is Dave from Heard. (Hacker News does not accept badges yet, so you just have to trust that it is me. :-) )

I wanted to clear up a confusion on badging.

Badges are a way to prove a verified fact about you without requiring you to trust any additional parties. So you already trust Visa with knowing your purchase history, and Netflix with knowing what you watch, and Facebook with knowing who your friends are, etc. If I want to post something on Facebook that says "This movie sucks, and by the way I watched this movie AND I watch a ton of movies", I should not have to trust Facebook with my viewing history and purchase history. I already trust Visa and NetFlix with that so I should just get a badge from NetFlix that says "Dave watched 500 movies last month" and one from Visa that says "Dave watched this movie last week" and then be able to use those badges on Facebook.

Badging is a mediated transaction between the service issuing the badge (the badge provider) and the service where the user wants to use the badge (the badge consumer).

The badge consumer starts a transaction asking a badge provider to issue a badge.

A badge provider can issue one or more types badges - like, say, a Microsoft.com, a tech insider badge, a movie watcher badge, a "is friends on Facebook with Van Diesel" badge, etc.

The badge provider then communicates directly with the user to determine if the user is eligible. So it might ask for your actual email address, send you a code, and then have you enter the code in. This all happens without talking to the badge consumer at all. Finally, if everything checks out, the provider will issue the badge to the consumer.

Once the badge is issued, the badge provider can either discard your email address or it can decide to retain it. Different providers might retain different amounts of data.

The Badge Consumer only gets the badge itself. It gets none of the information that you provided to get the badge. So while Heard will know you got a Microsoft.com badge, it has no idea how you got it. It certainly would never know your email address. Meanwhile, the badge provider never receives your Heard ID.

So in the worst case, where the badge provider was retaining all badging information, and "the bad guys" compromise both the Badge Provider and Heard itself via cyber attack or court order, they are limited in what they can discover: - They could determine the emails of everyone who was ever issued a Microsoft.com badge (and potentially related meta-data like times, ip addresses, etc.) - They can see that an incriminating post was left on Heard by someone with a microsoft.com badge (again, potentially with meta-data)

But they would not be able to determine with certainty that any one individual made that post. Not because it is encrypted, or the parties trust one another, etc., but because that information just does not exist. (Assuming you are handling your meta-data issues according to best practices).

The approach is not a magic bullet and still requires some amount of trust, but the trust is reasonable and easily understood.

You have to trust the badge provider to issue badges that are accurate. And you of course need to trust the badge provider with the information you are using to get the badge. But in most cases this is not a big deal, because the badge provider IS the entity that already knows this information. For example, ideally Microsoft itself would stand up a badging service for Microsoft employees. So while it is true that you would have to identify yourself as a Microsoft employee to Microsoft to get the badge, Microsoft already knows this about you.

Our goal with Heard is not run ANY badge providers at all ourselves, and let the market create ones that are needed - and judge their trustworthiness. We are running our email badging service just as a proof of concept. Once things calm down from our launch we plan to provide public APIs and reference implementations of both badge providers and badge consumers on our public github.

If you have other technical questions about how the badging works, I am happy to answer.

I'm not sure why the solution is to remove the anonymity instead of the credentialism. My solution is far more simple and takes considerably less time to implement: don't be dismissive of people.

Reply on news.ycombinator.com