What happened to https://mlmym.org?

[RonSijm]

Hey there, I was using https://mlmym.org/ before, and now it just redirects to https://gist.github.com/rystaf/4d591ffdcbaab1c49efa406885efd814

I was wondering if this was intended, and if instances should start running their own version of mlmym at old. subdomain instead of using https://mlmym.org directly?

[yukichigai]

At the top of the referenced text file are two domains which can be used the same way as mlmym.org was previously used (currently lemmy.bolha.one and o.opnxng.com). I believe the intent is to direct users to one of those instances. The mlmym.org instance was described as a "demo" instance from the start, after all.

[KaKi87]

Okay but there's no information on who these instances' owners are and whether these are likely to remain up in the future.

[yukichigai]

Fair enough. Might be worth spinning up your own instance just to be safe. Docker does make it fairly trivial to self-host for personal use.

[RandomUsername404]

It would be nice if this list of instances was included in the readme directly. It would also be nice to know where they are operating from. We know o.opnxng.com is hosted in Singapore, but we don't know anything about lemmy.bolha.one, for example (I think it's hosted in Brazil).

[poVoq]

In general it is highly advisable to only use alternative fontends hosted by your Lemmy instance as passwords are processed by the frontend. Until Lemmy supports an OIDC login flow, this makes it very insecure to use any 3rd-party frontend hosted on 3rd party servers.

But many instances do already (try old.yourinstancedomain.org) and if not ask your admin as it is indeed very easy to add mlmym to an instance.

[KaKi87]

it is highly advisable to only use alternative fontends hosted by your Lemmy instance

Or hosted by the project owner, if only there still would be one.

[poVoq]

Or hosted by the project owner, if only there still would be one.

No offense to the mlmym developer, but I disagree. This still means you are giving the mlmym developer access to your password, which normally only you and your instance admin should have access to.

Of course a malicious app developer could still exfiltrate passwords even if hosted by the instance itself, but that is active malware then, while in the other case it is just good security practise to not share passwords with 3rd parties like app developers.

[KaKi87]

you are giving the mlmym developer access to your password

We're way past the 90s, browsers can make requests and store credentials nowadays.

your instance admin should have access to

No, they should only have access to a hash of it.

[poVoq]

Yes of course, but you realized that you are still connecting to and inputting your password on a 3rd party domain? That's just very bad security practise and anyone with access to that 3rd party server can get your clear-text password.

But I am starting to suspect that you lack the security background to understand why this is strongly discouraged and the reason why systems like Oauth2 for password-less login were invented...

[RonSijm]

you are giving the mlmym developer access to your password

We're way past the 90s, browsers can make requests and store credentials nowadays.

Not sure what you're talking about, mlmym credentials are send back in cleartext to the mlmym backend before it gets passed on the Lemmy API:

[KaKi87]

Oh I'm sorry I didn't know this app was performing requests server-side unlike Alexandrite and Photon which perform requests client-side.

Well, knowing this, I now won't recommend this app at all nor add it to my Fediverse Redirector app.

[poVoq]

Even if you try to do everything client side in javascript, a compromised 3rd party server can easily be modified to serve different javascript to get the clear-text passwords.

[KaKi87]

Yes, but that would be visible in DevTools.

[rystaf]

I wish this displayed frontend info https://github.com/maltfield/awesome-lemmy-instances