Twitter proof tweets look like app spam

[zackw]

Verbal feedback from the UI designer sitting across the office from me: the Twitter proof tweets look so much like app spam and/or some sort of XSS virus, that they were actively avoiding clicking through to any sort of explanation, because they expected it to instead hijack their Twitter account.

I do not have a better idea, unfortunately.

[zQueal]

That well may be, but keep in mind that keybase is still in pre-alpha. The developers are more concerned with getting all the features working out of the box than the formatting of tweets required for validation.

I do believe it's a valid issue--just not a pressing one.

[zackw]

Aforementioned UI designer considers this a catastrophic design flaw. Quote: "go back to the drawing board and find another way to present this information". Does not think there is a band-aid that can be applied later.

[malgorithms]

Your coworker's point is valid, and it's helpful to hear this response -- we expect a lot of people will not click the links because of this ugliness. I've been trying to find a way to make them prettier, but with no luck yet.

But his/her conclusion is a bit short-sighted -- in my opinion -- both because it only considers 1 use case of the tweets (there are 3 important ones), and also because it assumes everyone will have the same fears.

The tweets are serving multiple purposes:

• a technical one; of course they are public proofs of identity that need to be verifiable by software. in that case it doesn't matter what they look like to a person
• human readable coming from the other direction: if you know my Keybase id and follow a link to the tweet, you simply want to read that the tweet exists and the usernames match; it works quite well in this case
• a possible promotion of the service, as the tweets are discoverable. Some fraction of people like your coworker are particularly sensitive to what these things look like, but his/her conclusion that they don't work at all on this front is wrong. They're generating loads of human traffic and signup requests to the site now, with very few users. Which is especially good news since our early adopters are most sensitive to XSS attacks and the like.

Still, I'd like to make them cleaner if possible because I would like the tweets to be a helpful promotion of both Keybase and the tweeters' public keys. So I appreciate suggestions on cleaning up the tweets.

I'll argue it's not a "catastrophic design flaw" but a carefully considered feature that legitimately irks your UI designer on half of one dimension. Hah. Open to suggestions.

[zQueal]

In another thread we discussed the possibility of authenticating twitter via oAuth2.0. Maybe that's an avenue that could be addressed at a later date?

[elliotmoore]

Why not have the tweets @ reply to your twitter user @keybaseio that way it's out of the way.

(unless one follows both @keybaseio and the new keybase user, in that case you are an interested party !-)

[MattSurabian]

This doesn't seem like a problem, IMO.

The use case here isn't "let me scroll/search through a users timeline to see if they have Keybase", and/or "oh this person says they have Keybase let me click this link and check that out" even though those do seem to be beneficial side effects of the verification tweet going on what @malgorithms said.

The individual tweet is a matter of record so when someone opens a user profile on Keybase and sees "this person is verified on twitter" they can see the verification tweet actually exists in the timeline. On a long enough time scale (which might be very short in the case of some people's feeds) the tweet will just be completely buried rendering its semi-spamy appearance a non-issue.

[winks]

Suggestion:

• Grab a @keybase_verify account at twitter.
• Let an auto-refollow bot use this account
• Tell people to follow it, (it autofollows back) then let them DM this account.
• Bingo, invisible authentication.

[MattSurabian]

@winks The transparency of someone being able to click on the verified profile links in a user's keybase profile and see the proof of ownership for themselves is essential. Otherwise we're left simply taking a third party's word for it.

Invisible authentication should not be the goal for a public key directory, transparency should be.

[Seldaek]

I came here to suggest using the bio instead of a tweet, because there is no way I spam all my followers with the current verification text. I agree though that keeping it in the timeline does make sense for later verification, but having it be an @mention to keybaseio or even a dummy account would fix the issue of spamming one's followers, which I would appreciate very much.

[malgorithms]

you can put @keybaseio in front of the tweet if you want. it still works if you prepend an at-reply.

[Seldaek]

OK good to know, then I think there are two simple steps that would drastically improve the experience:

• Add a @keybaseio prefix to the default tweet text
• Remove the signature, since it is already present in the keybase.io/USER/sigs/SIGNATURE link that follows it could be parsed in there. The link would still look shady, but people are more used to ignoring random stuff in urls than in a tweet itself, especially since twitter shortens the URLs visually.

So it'd look like this:

@keybaseio Verifying myself: I am bob on Keybase.io. https://keybase.io/bob/sigs/asdlsdjflkjsdflkdjslkdfjsldfkjdfkljf

I think that's a lot nicer.

[winks]

@MattSurabian You're right, but seeing the rest of the thread, the @ reply is a nice enough workaround.

[MattSurabian]

Yeah I've got no issue with the @ reply to prevent sending the tweet to all one's followers, @winks. I'm only opposed to DM and bio based auth schemes that have been proposed on this thread.

What's nice is that the @ reply already works :+1:

[zQueal]

Well... I mean with oAuth why send a tweet at all? If all we're checking for is that the user has control over the account, a simple script could be written to authenticate a user via twitter, and if said user is indeed authenticated, then they have access to the account. It's the same level of security as the previous form of tweeting, only it can be used on any service that also uses oAuth, like Facebook, Instagram, LinkedIn, etc.

[AndrewKvalheim]

@Xanza Because OAuth is not transparent to other users.

[zQueal]

This is very true--but I meant to use them in tandem. If tweets are no longer used for validation by the keybase system, then can become much more pretty.

For example:

Validating @keybase ownership! Public Key Fingerprint: 7715 BB39 2D00 19C4 https://keybase.io/zQueal/verify/7715BB392D0019C4

Upon visiting the URL (in lue of the /sigs/kSrx-p3_ofWBLZKxIm5CDNSXq3GsGhOWzG1d) you'd publicly see the 64bit public key hash right there on the page along with the reasons for verification:

It's simple!

1. zQueal joined Keybase and posted or generated a public key
2. They then signed a statement, which is hosted on this page
    * it's verifiable with the public key
    * the statement claims that keybase/zQueal and twitter/@zQueal are the same person
3. @zQueal then authenticated with oAuth 2.0 using their twitter account
4. Keybase monitors twitter to check the signature, however you can see the tweet, too
5. You and anyone else can verify the signatures with standard crypto tools such as GPG

Or something like that. The major complaint is the topic of this issue, that the actual hash's look like spam of some sort. Making the URI's a bit more pretty could help alleviate some issues with verification.

[gosko]

Tweeting in the form of an @ reply seems like a decent workaround but didn't work for me: https://twitter.com/ger/status/451502674098135040

Check Twitter now? [Y/n] y
warn: Didn't find the posted proof.
Check Twitter again now? [Y/n] y
warn: Didn't find the posted proof.

[zQueal]

@gosko Seems to be working just fine?

[gosko]

oh, yes, it has gone through now. Strange, I tried "Check Twitter again now?" 5 times over a period of 10 minutes before posting here. thanks!

[malgorithms]

@gosko - it was unrelated to the at-reply prefix, I think; our proof checker is getting into a weird hung state tonight and we need to keep restarting it.

[sreynen]

For what it's worth, I'm not able to verify my identity because all of the identify verification methods are tied to content publishing, which is not how i identify myself. I've actually identified myself as a person who does not post spammy tweets, so posting that should make people question my identify, not trust it. What would make people trust my identity is knowing that I am the person who controls the account with all the tweets they already trust I've posted, which is accomplished by OAuth. Same with Github identity. This comment I'm leaving here is much more closely tied to my identify than what Keybase is wanting me to publish, and anyone can confirm who published it with OAuth.

[malgorithms]

Hi @sreynen - can you walk me through how a Twitter user would use OAuth to prove in a publicly-auditable way that they have a certain public key, without a spammy tweet? Or am I misunderstanding?

[sreynen]

@malgorithms I didn't realize the Twitter verification was intended for public auditing. That's not very clear from the UI, and "prove my identity" is a common process on sites as private auditing. So making that clearer would be good.

Looking more closely at the process, I'm not sure OAuth would be useful, but I'm also not sure why I need to Tweet a hash at all, other than to help Keybase find the relevant, which doesn't seem necessary for public auditing. Here's the current description of the proof in this process:

1. scottreynen joined Keybase and posted or generated a public key...
2. ...then signed a statement, which is hosted on this page
3. @scottr tweeted a hash of that signature on twitter, proving access to the twitter account.
4. Keybase monitors twitter to check the signature, however you can see the tweet, too.
5. You and anyone else can verify the signatures with standard crypto tools such as GPG.

I'm not clear on what exactly is being proven at each step, but as I understand it, we have 3 identities claiming that they are the same as other identities, and we're treating cross-directional claims as proof. So if I use my key to sign a statement pointing to a Twitter account and use my Twitter account to point to that key's signed statement, we know those are the same identity. If that's right, I think maybe the current process includes redundant claims. Specifically...

When I sign a reference to my Keybase account with my key and put that claim on my Keybase account, that proves that my key and my Keybase account are the same identity, right?

And when I post a tweet claiming my Keybase account and claim my Twitter account on Keybase, that proves that my Keybase account and my Twitter account are the same identity, right?

Don't those two combined prove that my Twitter account and my key are the same identity? Why do I need to make that claim on Twitter at all?

[alexmuller]

I agree with some of the above. I wasn't going to verify myself on Twitter because I object to spamming my followers with text I didn't write, until I came to this thread and learned you can prefix the reply with @keybaseio.

I think @Seldaek's comments in this thread are sensible.

[mfczureal]

I have attempted to send my proof to @keybaseio, but I cannot seem to get it to work. Not to mention, the text it wants me to tweet is like 12 characters longer than the allowable tweet length.

[maxtaco]

Link?

[mfczureal]

https://twitter.com/zureal/status/471042114319417344

[maxtaco]

It's weirdly mangled. It's missing the hash and for some reason the URL was broken so twitter's URL shortener didn't work.

Here's an example of one that's proper: https://twitter.com/kennwhite/status/452110756452892672

[mfczureal]

Okay, I see what's going on. The copy and paste from the cmd prompt was mangling the https line and causing the URL shortener not to kick in. I took out the extra space and that fixed things. Stupid Windows. :)

Thanks

[maxtaco]

No worries, glad it's working.

[kylemcdonald]

was also expecting the tweet to have an @keybaseio prefix, or allow that as an option. decided not to verify right now because it has no prefix. having the prefix would afford the same publicly-auditable but non-blatant situation as a keybase.txt file on a webserver or a gist.

[zQueal]

was also expecting the tweet to have an @keybaseio prefix, or allow that as an option. decided not to verify right now because it has no prefix. having the prefix would afford the same publicly-auditable but non-blatant situation as a keybase.txt file on a webserver or a gist.

I'm pretty sure if the 140 character limit isn't reached, you can simply add it before it's posted and it will still correctly verify. It just has to be done manually.

[kylemcdonald]

thanks, just did that.