Gregory's Server|
38 comments
@darius ignoring the snake oil of web3.0 / nft rubbish that undermines itโฆ identity is an area where blockchain as a technology could work well if youโre trying to maintain decentralised trust.  @darius Any thoughts of adding something like the old PGP Web of Trust concept? Solve Mastodon's verification problem and *also* solve PGP's key distribution problem?  @admin ah, yes, I was a (distant) advisor on a master's thesis that was similar to this And yes "you can check that on Google easily" implies that Google can be trusted and it can't all the time. Ultimately at some point you do have to simply trust SOMEone, SOMEwhere. What I'm saying is that I don't trust a random person who bought a domain with "fedi" in the name and set up a directory  @darius hang on lemme scroll through all 4000 words of https://book.keybase.io/guides/proof-integration-guide  @darius or random people with serversโthat issue of trust is what has held up some people I know from joining Mastodon  But also: this could be a mass harassment vector for journalists! Someone goes to trust.txt, scrapes every account there, and harasses them. But I do think that once you say in an official capacity "I am affiliated with [org]", you have to assume that anyone can find that info and can and will scrape it even if there isn't a directory available. idk. tough design space 
[DATA EXPUNGED]
@polymerwitch well, the fallback is a literal text file on the root of your domain. so someone could maintain that in excel and just export it as needed @darius I'm interested in this idea, could you elaborate on it? - What stops a malicious actor from spoofing a trust.txt and using that as validation in a similar way to phishing? ("verified by 'nytines' dot com", etc.) Would sites needs a whitelist of valid trust.txt sources? - On a related topic to the harassment vector point you had: how would you sell trust.txt to orgs that are interested in verification but do not normally want contact exposure for some personnel? (ex. directors and exec) (1/2) - you're right, spoofing is simply always going to be a threat where DNS is involved, but also anyone could spoof the service that I mention in the original post too the same way. "fedifeid" or whatnot. solutions that get around that are huge crypto-based things that are unlikely to play nice with IT infrastructure at say, news orgs (2/2) - it's a necessary tradeoff. if an exec wants to say "I am truly CEO of CorpX on LinkedIn" then the point there is to publicly broadcast that that is who they are. This is about linking public profile information to public institutions (at least in the journalism context here)  @darius i guess the advantage of an instance like journa.host (or even a nytimes-specific instance) is that they could be keep an eye out for attacks targeting newsrooms' entire trust.txt lists and possibly handle it faster or more efficiently. on the other hand, that might also overwhelm the moderation capabilities of a particular instance.  @darius To verify accounts associated with a public website (like newspapers or broadcasters): You could diminish the "harassment" aspect by having the "trust.txt" document actually be a list of *hashed* accounts. So when you want to verify whether an account is associated with a website, you can check this one-way (without being able to scrape the full trust.txt). @maxb huh? it's a website of a nonprofit called JournalList. the link is to a pdf. they don't know anything about federation. this is just a specification @darius i wonder if there'd be a way to let the mastodon user generate a short hash that they just need to place someplace on the page (maybe even temporarily?) like maybe i can't modify html in a page on my institution website but i can copy a hash string, place it at the page at the foot of the page, and then verify (maybe even let me place it temporarily if my IT admin doesn't like it; then you might want to say "last verified 6 weeks ago" or something) @darius I'm sure you're aware of them already but https://www.yoti.com are probably worth chatting to.  @darius Apparently qualified. "come for facts, stay for snark, & wear a mask | immigrant | husband + dad | equity advocate | recovering healthtech exec/entrepreneur | infosec researcher | anesthesiologist | nerd ๐ค JOINED  Man that whole idea sure does have strong "I just came in from Twitter and what this decentralized network needs is some SERIOUS CENTRALIZATION" energy. And lo and behold its creator has an account created a week and a half ago. Kudos to him for a super fast solution to a problem he sees, I guess, but... @darius @rysiek The obvious "other solution" is, at least for smaller instances, to run your own verification service, and let other users trust or not trust that verification. It all really depends a lot on what you're trying to verify and why - is it equivalence with AFK identity, or affiliation with certain groups, or being the actual beneficiary of a fundraiser or Patreon, and so on  > "well you can just buy any old domain name and pretend to be whatever org you want" And then that's how he came to buy Fedified.org and pretend to be whoever he wanted. |
Funny thing: I was going to set up some meetings at work this morning to talk with, you know, actual experts on content and identity verification to see if we can come up with some tools to AID rather than SUPPLANT the already rather good and decentralized system we have. (For example, your employer might literally just be unwilling to add a rel=me for you for baroque IT reasons. So how do we make that easier for them? Etc)
Anyway I'm still gonna do this