AirBnB attestation: public username?

[tyleryasaka]

We have some functional code for adding AirBnB attestations to one's profile. https://github.com/OriginProtocol/origin-dapp/pull/278

Currently our attestations just show the fact that some pieces of data has been verified (in this case the ownership of some AirBnB profile). The actual data itself is being kept private.

In the case of AirBnB, a use case has been outlined for making the username public; namely the importing of reputation from AirBnB to Origin. See https://github.com/OriginProtocol/origin-js/issues/226

It is possible for us to store the AirBnB username on IPFS, and then store the IPFS hash on the attestation that exists on the blockchain. This is public data (and possibly permanently so, assuming the IPFS data is not lost). So if we're going to make the username public in this way, we should at least be aware of the implications.

There are possibly other alternatives for publicizing the username (such as storing it on the bridge server rather than IPFS, which feels a bit less permanent).

On the same note, we may want to take this time to also consider similar implications for Facebook/Twitter attestations.

[wanderingstan]

As I mentioned in https://github.com/OriginProtocol/origin-js/issues/226, making an AirBnB profile public strikes me as not so bad as other online identities to be revealed.

That said, it occurred to me there's also a route where our attestation server does more than just verify that the identity is owned, but also does some analysis of the reputation.

I.e. Instead of the attestation being "This person has an AirBnB profile", it would be "This person has an AirBnB profile, has been a guest 42 times and a host 6 times, and has an average review of 4.2 stars". Thus the reputation is "exported" without the identity being revealed.

This strikes me as a lot of work, as being a brittle page-scraping app, and maybe scope creep, but worth considering.

[tyleryasaka]

@wanderingstan Yeah we could do something like that (attesting various attributes of the profile). I'm also skeptical of that approach though. In addition to being a non-trivial implementation, it's also more centralized than simply posting the username and letting people view it for themselves.

I agree that it's fine for an AirBnB profile to be public. I think the key is making sure users are aware of this, and avoiding confusion if Facebook and Twitter are private.

That said, I do think AirBnB is a different use case than Facebook/Twitter profiles. Facebook and Twitter stamps can more or less add some trustworthiness (I just used letgo to buy something actually; letgo just uses social media stamps without actually letting users see the profile; same as we're doing right now.) An AirBnB profile on the other hand would be used to make it as easy as possible to onboard AirBnB users. AirBnB is a parallel service to Origin in a way that Facebook and Twitter are not.

All that said - imho this shouldn't be priority right now. I think an AirBnB stamp is a great start, and we can revisit making it public later. (I say this given all the other big tasks in front of us.)

[joshfraser]

This issue actually goes far beyond Airbnb as we eventually want to support attestations from all sorts of providers. We can generalize the question to what information should actually be stored on-chain for attestations. We basically have 3 options:

1. We store the raw data on-chain. ie. Publish my email address, phone number, link to my Airbnb account, etc on the blockchain. I don't think it's responsible for us to encourage people to publish too much of their personally identifiable information on an immutable blockchain, especially as many people will not understand the potential consequences.

2. We store a hash of their data. This is probably where we want to end up long term. We can verify some data, and publish an attestation without having to store personally identifiable information on our own servers. In this model, the end-user is still responsible for holding and revealing their own personal information, but we can attest that we've verified it. Remember, we'd rather not be holding personal information if we can help it. The reason we didn't roll this out right away is that we wanted to make sure we are comfortable storing even hashed versions of people's data on an immutable blockchain. Rainbow tables & brute force attacks could easily be used to deanonymize a lot of data (for example, a phone number). I asked Vitalik about this challenge and he recommended we use Merkle tree proofs. That makes sense to me at a high level, but I haven't dug into the details. Another challenge with this approach is figuring out how & when to reveal the information if the user is the only person who holds that information. Does a seller have to manually reveal their identity each time a buyer asks? How does arbitration work if we don't know who people are anymore?

3. We store a check mark on the blockchain & store the raw data in our own DB. This works for centralized services because you trust that the centralized service has the data and will be able to help if something goes wrong. The check mark is pretty meaningless if no one is storing the raw data anywhere. For the check mark to work, you need to be a trusted authority, but we're trying to remove ourselves from that role.

Basically, we're going with #3 for now and hoping to transition to #2 once we have a better handle on the security implications & usability challenges. I think it makes sense for users to be able to opt for #1 if they're comfortable with revealing that information publicly. I'd be happy to publish my Twitter handle on the blockchain for example. We just need to make sure that people actually understand what they're doing.