Open edent opened 2 years ago
Users should bear in mind that ORCID profiles are not themselves verified. It would therefore be possible for someone to fake both a Mastodon account and an ORCID profile and give the appearance of a strongly verified identity.
This is likely a discussion for elsewhere, but neither are GitHub profiles: it's the record of things that have been produced by a specific account which lead to trust in the identity.
The "danger" is that an ORCID profile looks rather official and unique, when it's not. A better comparison is with the analogous use of a university web page, where there would be some expectation that the institution would only give access after some minimum verification.
A Mastodon profile that has verified links to more strongly verified sites like a university page as well as to an ORCID profile would implicitly verity that ORCID profile, which would be another benefit of this feature.
@borisbarbour - faking an ORCID account would result in an empty account, no? I.e. one without publications. This would easily give it away as a fake account for anybody posing as anything else than a very "fresh" academic... I tend to lean towards @joshmoore's perspective where the work linked to an account provides the "trust". In addition, I'm not sure that institution pages provide a system that's so much better... It might be possible to fake those as well (by creating a page on your institution's site that is not, but looks like, an employee page). Mastodon verification is not meant as "hard" verification of an individual, just as proof that somebody is able to edit the website that is linked to, no? That is true for (well, should be true for) ORCID pages, I think.
@Matherion I haven't looked into faking ORCID accounts in detail, but I think you can enter papers by hand, keep the email (which isn't verified) private, etc. I suspect it could be convincing. There have been examples in the wild. People wishing to use eLife's commenting system anonymously reportedly created fake (maybe invented) ORCID profiles to work around the authentication system. And no doubt paper-mill operators create fake accounts for some of their invented authors and referees.
To be honest, ORCID should have an option for institutional validation of profiles, quite independently of the Mastodon question.
But this issue is about the Mastodon question, and I second @edent's request. If the rel=me attributes that ORCID generates can't be consumed by a request then they aren't fulfilling their purpose.
Yes, someone could forge an ORCiD profile, but without rel="me" verification it would even easier for a malicious user to point to someone else's profile and impersonate them. One problem at a time.
I think there is no such thing as a perfect verification. Some form of forgery will always be possible.
But let's keep in mind the status quo of verification on e.g. Twitter. The "regular scientists" I followed there, be it PhD candidates, post-docs or even most PIs did not go through any kind of verification there. And still account forgery was not a real problem there I suppose.
So the ORCID verification on Mastodon would already be a huge improvement over this.
And apart from forgery protection this could simply be a nice, credible way of pointing the network to one's academic work.
Hey Edent, thanks for the detailed info, and thanks to everyone else for their comments.
We've had a quick look into this and have created a card. As edent notes, we do actually provide the rel="me" information, but it's rendered by javascript (specifically, angular). It may be possible to duplicate this information in the header using tags, but it's unclear if this will work for mastodon. The spec appears to state this is valid, but it's kinda murky and needs more investigation. We did something similar with search engine metadata earlier this year - not because search engines didn't render the javascript, but because some records are so large they can't render them in a reasonable amount of time. Something to note here is that most search engines attempt to render the javascript, and the mastodon crawler should maybe consider doing so as their adoption grows.
On the subject of trust in ORCID records, this is a good read. To summarise, they accumulate trust through interactions with other services. For example: Universities can add verified information to ORCID records, such as employment information. This information is marked as coming from the university and validates their affiliation. Similarly Funders and Publishers can also add items such as articles, peer reviews and grants. We're aware that this isn't always as easy to understand as it could be, and hope to improve the visibility of trust markers next year.
Tom.
Woo! In my experience, you can use <link>
elements in the head - so this should work.
fwiw I've tested a link element in the head of a page linked from Mastodon, and Mastodon accepted it as confirmed. My Mastodon profile: https://code4lib.social/@pbinkley . The test link is the last one, "Annals of Cleveland"
It would also be technically possible for Mastodon to recognise an ORCiD profile URL via a regex and fetch the profileid/public-record.json to grab the addresses to verify. The concerns about new ORCiD profiles being able to claim works that are not theirs makes me doubt this is a good thing to verify - however, if there is some way to see the trust markers in the public-record.json (like some kind of easy yes/no test to look for) then that might be interesting to explore. I don't know if there is an appetite to special-case individual websites in the mastodon verification code, but it could be something to discuss.
I don't think Mastodon - or any other service - should have to hard-code workarounds for specific sites.
A plain link - either in the body as an <a>
or in the head as a <link>
- is the best way for a website to stay interoperable with any service which wants to check for bi-directional linking.
With all respect, while the notes above what Mastodon should/could or shouldn't do to solve the problem may be correct, or may be good ideas, or not: they are beside the point.
ORCID provides rel=me in the social media links. But it's implemented in a way that it's not straightforwardly consumable (without custom coding) by other web sites. But being automatically consumable is the entire purpose of the (otherwise invisible) rel=me attribute. This is a problem in the ORCID website's implementation, and it would be super nice to see it remedied.
I don't know if this will be helpful, but Mastodon will also attempt to resolve the href of the first rel=me link on the page by following 301/302 responses until it gets somewhere. This is a bit of special casing for the way Twitter used to render profiles, with the links there but shortened with the t.co link shortener (it is now considerably more broken). I was looking into updating the Twitter special casing, which is why I know that special casing isn't completely off the table (though I agree it is a bad idea in general). If the initial request can't have the dynamic data on it because of the way it is generated it may be possible to have a link to something that bounces to the right place with a 302 response? The code is here https://github.com/mastodon/mastodon/blob/main/app/services/verify_link_service.rb#L29 I agree with the general point about making it consumable generically, not just for compatibility with one other thing.
Does anyone have a list of other sites that support rel="me". That would be super helpful for us. I've looked but can't find anything up to date. From a quick check, giuthub does, facebook, twitter and google scholar do not.
Helpfully, mastodon itself uses tags in the header, so that's cleared up I think.
There's a handful of implementers here: https://microformats.org/wiki/rel-me#implementations (but I haven't verified them)
Hi everyone. I'm closing this as the requirement is now on our backlog. https://trello.com/c/M0pKNCPk/659-enable-relme-links-for-services-that-dont-render-javascript-eg-mastodon-so-that-they-can-be-verified
The change does require significant re-engineering of our application, as we currently are not able to render html elements server-side. We do hope to make it work at some point in the future, but I cannot promise a date. This sprint we are investigating the effort required.
@TomDemeranville I would find it helpful (and I bet others would, too) if this issue remained open, as it's a helpful way for us to be updated on the progress of your Trello card. (I can't find a way to subscribe to the card.)
This issue remains both important and urgent for academic users of Mastodon, so I'd really appreciate a way to track progress.
I have to agree. The issue got moved from "consider for next sprint" to "others" on the Trello tracker, and that just doesn't seem to capture or reflect the importance of this issue for academic users. Impersonation of accounts is a real problem and has already generated a lot of negativity from academic users trying to verify their presence on Fediverse instances. This needs to be solved right away!
Given the amount of interest this issue is generating, I'm going to re-open it and keep everyone up to date here.
We've done some initial investigation and have realised this is a LOT more work that it seems. Our application currently renders almost all the HTML on the client side using Angular 2. The problem is that mastodon does not execute the javascript so never sees the rel='me' markup. While it's understandable other services would rather not render out javascript, it has not caused any issues for other services in the past. Search engines such as google DO render the javascript while indexing so see all the content, and other services have used our APIs to obtain metadata, rather than looking for it embedded in the HTML.
There is a card in the current sprint that is investigating how we can tackle this and we're building prototypes for at least rendering the static contents of the
tag: https://trello.com/c/oUatN9W4/8383-rd-investigate-server-side-rendering-of-head . Once we know what needs to be done, we will prototype it, then release it.It's going to take multiple sprints. This is not something we're able to deliver quickly as it's a complex problem requiring a lot of developer time and devops work.
Thanks, @TomDemeranville, both for taking this on and for explaining what the difficulties are. It's going to be really nice to see that banner in my profile turn green :-)
It may be possible to duplicate this information in the header using tags, but it's unclear if this will work for mastodon.
Hi Tom :wave: FWIW: I know putting the link in the <head>
tag works as I did it for my personal blog.
<link rel="me" href="https://akademienl.social/@chartgerink" />
I didn't want to add a random link to verify it and wanted to hide it.
See also https://github.com/ORCID/orcid-angular/issues/1828 - I think I found the right place to make an update
Does ORCID have an archival copy of my suggestion for rel="me" in profiles, and subsequent discussion?
Sadly the link is dead and the Wayback machine does not have it:
If I recall, it was made circa 2012.
Has there been any movement on supporting this?
Websites like Mastodon, allow users to "verify" their profiles on other websites.
For example, adding
<a href="https://mastodon.example/@username" rel="me">Mastodon</a>
to a website will let a crawler know that the the userusername
on the servicemastodon.example
is related to that specific website.The ORCiD service adds the
rel="me"
correctly:However, the ORCiD.org website renders these links using Javascript. When the Mastodon crawler looks at the source code for a page, it won't see any
rel="me"
links and then fails.Error reports from users:
See also https://github.com/mastodon/mastodon/issues/18233
Would it be possible to render these links statically rather than using JS?