Uhh… not clear on what you’re claiming here… you can validate the traffic is going to the expected instance using a web app, without requiring any special software by running Developer tools and heading to the network tab.
Web front ends currently require a backend service that then routes to your intended destination because Lemmy servers by default are configured with cors to only allow requests from their intended domain. There is a PR to fix it but I don’t believe it’s been merged in. This may be out of date but that was true as of a few weeks ago per the dev of Voyager which is the web frontend I use
edit: this is no longer true. A PR 2 weeks ago fixed this issue and web front ends are able to work just as well as a native app now.
1.) Turns out this is no longer true because the cors issue is fixed as of two weeks ago.
But to answer your question:
Well that’s the really silly part about it. You see, the way CORS works is that it only works if the client making the request implements cors. In this case when I say client I’m talking about your web browser itself. Native applications, or hitting an API directly via network calls, don’t implement cors and thus you can make the calls all you want and the server responds. So even when cors was configured to only allow requests from the correct domain it only affected people with web browsers.
However two weeks ago a PR was merged into the Lemmy source code setting the cors to by default allow requests from anyone instead of a specific domain.
That checks it only for the current session, though. The app might do nefarious things only on new moons, or on a specific date. It might also get updated at any point with completely new code without you noticing.
Uhh… not clear on what you’re claiming here… you can validate the traffic is going to the expected instance using a web app, without requiring any special software by running Developer tools and heading to the network tab.
Web front ends currently require a backend service that then routes to your intended destination because Lemmy servers by default are configured with cors to only allow requests from their intended domain. There is a PR to fix it but I don’t believe it’s been merged in. This may be out of date but that was true as of a few weeks ago per the dev of Voyager which is the web frontend I use
edit: this is no longer true. A PR 2 weeks ago fixed this issue and web front ends are able to work just as well as a native app now.
I’ve looked at the traffic, and all calls go directly to the API of my instance. I don’t think Alexandrite even runs a backend.
Turns out the cors issue was fixed the other week. Nevermind then.
I see, but how is this different in a phone app? Wouldn’t the request still be made to a backend?
1.) Turns out this is no longer true because the cors issue is fixed as of two weeks ago.
But to answer your question:
Well that’s the really silly part about it. You see, the way CORS works is that it only works if the client making the request implements cors. In this case when I say client I’m talking about your web browser itself. Native applications, or hitting an API directly via network calls, don’t implement cors and thus you can make the calls all you want and the server responds. So even when cors was configured to only allow requests from the correct domain it only affected people with web browsers.
However two weeks ago a PR was merged into the Lemmy source code setting the cors to by default allow requests from anyone instead of a specific domain.
That checks it only for the current session, though. The app might do nefarious things only on new moons, or on a specific date. It might also get updated at any point with completely new code without you noticing.
Seems needlessly paranoid
Same level of paranoia that makes someone check the dev tools for data transfers in the first place.