LinkedIn Proof #18

Open
martin.sweeny wants to merge 10 commits from martin.sweeny/doipjs:feature/linkedin-proof into main

With this PR doip.js should now be able to check for social claims on LinkedIn

Users are expected to write a post with the OpenPGP key comment ( [Verifying my OpenPGP key: openpgp4fpr:$FINGERPRINT]) and are strongly recommended to disable comments on the post to deter fake claims.

The URL is obtained by selected Copy link to post in the post's menu, then the proof notation is simply that url

With this PR doip.js should now be able to check for social claims on LinkedIn Users are expected to write a post with the OpenPGP key comment (` [Verifying my OpenPGP key: openpgp4fpr:$FINGERPRINT]`) and are strongly recommended to disable comments on the post to deter fake claims. The URL is obtained by selected **Copy link to post** in the post's menu, then the proof notation is simply that url
martin.sweeny added 4 commits 10 months ago
martin.sweeny changed title from feature/linkedin-proof to LinkedIn Proof 10 months ago
martin.sweeny added 5 commits 10 months ago

Sorry about the messy commit history. If you're a stickler for clean logs I can squash these into their own branch and open a new PR with a cleaner history

Sorry about the messy commit history. If you're a stickler for clean logs I can squash these into their own branch and open a new PR with a cleaner history
Owner

Hey Martin, great work on the PR!

I am not a stickler for clean logs, I have yet to be stung by an unclean one 😄

The docs will indeed need to make it very clear that comments should really really be disabled. We could also look into making our HTML parsing smarter, something we discussed earlier. But I'd rather push for public APIs with JSON formatting.

If you don't mind adding one more commit, that would be great but this one is optional. I have finally added regex to the license check (3dd6b5ae1c), something I should have done a long long time ago. Since this is your contribution, you can now change the license header and add your own name. And change 2021 to 2022 :)

Hey Martin, great work on the PR! I am not a stickler for clean logs, I have yet to be stung by an unclean one 😄 The docs will indeed need to make it very clear that comments should really really be disabled. We could also look into making our HTML parsing smarter, something we discussed earlier. But I'd rather push for public APIs with JSON formatting. If you don't mind adding one more commit, that would be great but this one is optional. I have finally added regex to the license check (3dd6b5ae1c6d4f1fa5c41edf308484cb14021040), something I should have done a long long time ago. Since this is your contribution, you can now change the license header and add your own name. And change 2021 to 2022 :)
martin.sweeny added 1 commit 9 months ago
76ef11e6f4
chore: update license

@yarmo Done!

@yarmo Done!
Owner

Thx again. Sorry, didn't have time earlier to review. I have one question and two suggestions.

Thx again. Sorry, didn't have time earlier to review. I have [one question and two suggestions](https://codeberg.org/keyoxide/doipjs/pulls/18/files#issuecomment-384166).

Users are expected to write a post with the OpenPGP key comment ( [Verifying my OpenPGP key: openpgp4fpr:$FINGERPRINT]) and are strongly recommended to disable comments on the post to deter fake claims.

What stops me (as a bad actor) from doing the following?

  1. Add the above claim text as a comment to any one of your LinkedIn posts, using my fingerprint (not specifically the same post where you have made your claim and disabled comments)
  2. Add the permalink of that post as a claim notation on my own key
  3. PROFIT!!!

I don't see how the above can be avoided, except by (fragile) HTML parsing to ensure that only the main "post" can contain the key, and not any comments on that post.

> Users are expected to write a post with the OpenPGP key comment ( `[Verifying my OpenPGP key: openpgp4fpr:$FINGERPRINT]`) and are strongly recommended to disable comments on the post to deter fake claims. What stops me (as a bad actor) from doing the following? 1. Add the above claim text as a comment to *any one* of your LinkedIn posts, using my fingerprint (not specifically the same post where you have made your claim and disabled comments) 2. Add the permalink of that post as a claim notation on my own key 3. PROFIT!!! I don't see how the above can be avoided, except by (fragile) HTML parsing to ensure that only the main "post" can contain the key, and not any comments on that post.

@caesar the URL format is different for posts and comments, so a comments' permalink wouldn't work. Or, at least, it shouldn't. I'll add test cases for comments and other permalink formats specifically now that you've mentioned it

@caesar the URL format is different for posts and comments, so a comments' permalink wouldn't work. Or, at least, it shouldn't. I'll add test cases for comments and other permalink formats specifically now that you've mentioned it

Thx again. Sorry, didn't have time earlier to review. I have one question and two suggestions.

I never saw this - I'll take a look later this week.

> Thx again. Sorry, didn't have time earlier to review. I have [one question and two suggestions](https://codeberg.org/keyoxide/doipjs/pulls/18/files#issuecomment-384166). I never saw this - I'll take a look later this week.

the URL format is different for posts and comments, so a comments' permalink wouldn't work

No, I meant add a false claim in a comment on a post, then try to claim using the permalink of the post (not of the comment).

So far as I'm aware comments are displayed on the same page, below the post, so short of parsing the HTML and looking for a certain element id or class (which is fragile), how do you differentiate between the post content and the comment content?

I assume this is why you are saying comments must be turned off on the claim post – but wouldn't the same apply to any other post? Perhaps I've missed something.

> the URL format is different for posts and comments, so a comments' permalink wouldn't work No, I meant add a false claim in a comment on a post, then try to claim using the permalink of the post (not of the comment). So far as I'm aware comments are displayed on the same page, below the post, so short of parsing the HTML and looking for a certain element `id` or `class` (which is fragile), how do you differentiate between the post content and the comment content? I assume this is why you are saying comments must be turned off on the claim post – but wouldn't the same apply to any other post? Perhaps I've missed something.

No, I meant add a false claim in a comment on a post, then try to claim using the permalink of the post (not of the comment).

Oh, right. That is possible, sure. The real account owner would easily see this attempt and could remove it any time, though.

I'd like to see if there's a way we can leverage profile attributes (maybe links?) for proofs instead. 🤔

> No, I meant add a false claim in a comment on a post, then try to claim using the permalink of the post (not of the comment). Oh, right. That _is_ possible, sure. The real account owner would easily see this attempt and could remove it any time, though. I'd like to see if there's a way we can leverage profile attributes (maybe links?) for proofs instead. 🤔
martin.sweeny changed title from LinkedIn Proof to WIP: LinkedIn Proof 9 months ago

Setting this back to WIP while I improve the test cases

Setting this back to WIP while I improve the test cases
Owner

I assume this is why you are saying comments must be turned off on the claim post – but wouldn't the same apply to any other post? Perhaps I've missed something.

Oh shoot. You're absolutely right! Any post could be turned into a "fake proof" by commenting on any post allowing comments.

I had not considered this edge case and is a serious problem.

Sounds like maybe we should go the twitter route and (sadly) go centralized: clients should ask a Keyoxide proxy server to do the verification instead, where the Keyoxide proxy has a Linkedin auth token and access to the official API.

> I assume this is why you are saying comments must be turned off on the claim post – but wouldn't the same apply to any other post? Perhaps I've missed something. Oh shoot. You're absolutely right! Any post could be turned into a "fake proof" by commenting on any post allowing comments. I had not considered this edge case and is a serious problem. Sounds like maybe we should go the twitter route and (sadly) go centralized: clients should ask a Keyoxide proxy server to do the verification instead, where the Keyoxide proxy has a Linkedin auth token and access to the official API.

Actually, upon double-checking, the proof is fine as is.

LinkedIn does not show comments to unauthenticated users!

Check my LinkedIn claim post when logged out (preferably incognito/private window):
https://www.linkedin.com/posts/martinsweeny_verifying-my-openpgp-key-openpgp4fpr08a83f21244c4876d9ec2c6a5f88f7e8f01d4198-activity-6884620821181063168-WsxX

image

Actually, upon double-checking, the proof is fine as is. LinkedIn does not show comments to unauthenticated users! Check my LinkedIn claim post when logged out (preferably incognito/private window): https://www.linkedin.com/posts/martinsweeny_verifying-my-openpgp-key-openpgp4fpr08a83f21244c4876d9ec2c6a5f88f7e8f01d4198-activity-6884620821181063168-WsxX ![image](/attachments/cd0fca1d-e9a9-4ebe-9b14-88c646873581)
martin.sweeny changed title from WIP: LinkedIn Proof to LinkedIn Proof 8 months ago

Alternatively, there are two other places we can put the proofs:

Contact Info:

image

Featured Items:

image

Semantically, I think this is a better solution

Alternatively, there are two other places we can put the proofs: Contact Info: ![image](/attachments/052e27d5-371a-4691-8072-1d4bc3e631e1) Featured Items: ![image](/attachments/323a05a3-d0a3-4f1e-bd87-c3cfad24dc0d) Semantically, I think this is a better solution

Semantically, I think this is a better solution

I agree. Is there a way for Keyoxide to reliably scrape that data without having an API key?

> Semantically, I think this is a better solution I agree. Is there a way for Keyoxide to reliably scrape that data without having an API key?

Semantically, I think this is a better solution

I agree. Is there a way for Keyoxide to reliably scrape that data without having an API key?

Yup!

image

> > Semantically, I think this is a better solution > > I agree. Is there a way for Keyoxide to reliably scrape that data without having an API key? > > Yup! ![image](/attachments/6afd9e87-ae89-418b-a2dd-31946c01b9d2)
Owner

Semantically, I think this is a better solution

I agree. Is there a way for Keyoxide to reliably scrape that data without having an API key?

Yup!

I like the solution, but how exactly is this reliably scrapable? It still requires deep parsing of the HTML, as much of the content is dynamically generated and could thus fool a simple regex query.

> > > Semantically, I think this is a better solution > > > > I agree. Is there a way for Keyoxide to reliably scrape that data without having an API key? > > > > > > Yup! I like the solution, but how exactly is this reliably scrapable? It still requires deep parsing of the HTML, as much of the content is dynamically generated and could thus fool a simple regex query.
All checks were successful
continuous-integration/drone/pr Build is passing
This pull request has changes conflicting with the target branch.
src/claimDefinitions/index.js
Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: keyoxide/doipjs#18
Loading…
There is no content yet.