@mangeurdenuage Something else to share with @x@neckbeard.xyz ...
It is possible that #Discord uses #OAuth. In that case, there should be something in account settings that lists the clients the person has authorized. De-authorizing clients could stop the problem if a client is automatically waking up and logging in (or if it is controlled by a malicious actor that is surreptitiously logging in to collect data). Naturally, this assumes that there are Discord clients and that the person has used at least one. Not being a user of their chat, I cannot tell you whether they even allow clients besides a browser.
In any case, the person should change their password using a password manager to generate and store the new randomish password. It should be as long as the service allows (and never fewer than 16 characters).
@mangeurdenuage It was more than one person that left the #OAuth 2.0 project, claiming the design was too complex to be reliably secure. Implementing it was notoriously difficult to get right. But now, we rely on premade libraries that we assume to be "secure enough".
#Mustard is old and unmaintained, but it works with GS #OAuth and I have it on my phone. For a few years now, posting has not worked (error message said “unauthorized”), so I’ve used #AndStatus to post (despite its own issues). I don’t know if the server migration or the version bump fixed things, but I’m glad that I can now use Mustard for posting again.
@clacke It's been a few years since I looked, but #OAuth 2.0 was known to be insecure almost from the time it was finalized, and known to be too difficult for most implementers to get correct before then.
If 2.1 simplifies the protocol and makes it more secure, that's a big plus.
2 Years ago when I first had to implement #OAuth into a #java-based #APIClient, I knew little about OAuth. So I searched for and found a library. It is named #ScribeJava.
And I learned that the #APIServer with which I communicated had implemented OAuth wrong, causing me to override half of what ScribeJava could do out of the box. Grrr.
The other week I implemented the simple client-necessary request for an #OAuth2#BearerToken, specific to a different APIServer. Half an hour: it works!
@js ah, ok. Thanks for the clarification. I wonder if Drew if planning to use #OAuth is sr.ht though? He seems to be opposed to using any of the protocols used in #ActivityPub for federating code forges, even though he seems to have no alternative to OAuth, #WebFinger for @mentions etc. My take is that sr.ht and #ForgeFed are addressing different aspects of the problem, and I've been trying to convince them to join forces. It's an uphill struggle so far ;)
@wakest Apps should see/store nothing related to your password. #OAuth replaces storing username/password with long, random, opaque codes that grant that one app limited access.
@notclacke @dwmatiz There's an #OAuth bug in #GNU_Social (introduced in the last 2-3 years) that make #Mustard "unauthorized" to post. Since #AndStatus only connects by username password, it isn't affected. That's the primary reason I use AS. I should conect Mustard by username / password and use it as my main client again. Faster, more responsive, shows posts that AS never does.
Working on a more thought-out post on this but I thought I'd get some feedback before diving too deep.
How about an Identity #coop ? A simple but solid #oauth identity provider that also advocates for it's inclusion as an idp to the services used by its members.
Convenience of single sign-on with the smallest possible security risk surface area and, being a co-op, members (users) decide what data is collected, shared, etc.
@stitchxd @hikerus Theoretically (since that isn't the way you implemented it) XMPP could use #OpenID or #OAuth to log in using account info from GS. I'm not even sure any #XMPP servers implement this yet, but it would help with similar integrations.
@HerraBRE #Mastodon works with !GNUsocial as it is pretty well. There were some issues that @gargron raised with me, some of which I believe I fixed and some that I couldn't really figure out (some profile avatar update thing for example?)
Regarding RFC7033 (#WebFinger) it - since standardisation - only _requires_ a JRD (application/jrd+json). application/xrd+xml is just a bonus from !GNUsocial (voluntary according to spec).
The host-meta XRD is XML that because it was standardised before people who reinvent everything (JSON fanpeeps) started developing standards: https://tools.ietf.org/html/rfc6415
But since JRD and XRD are easily translatable between each other it doesn't really matter. And while #Mastodon doesn't use it, the /.well-known/host-meta endpoint is good for discovery unrelated to profiles, such as #OAuth endpoints etc. (so clients can auto-configure them).