• 1 Post
  • 6 Comments
Joined 26 days ago
cake
Cake day: March 12th, 2025

help-circle
  • Right there are plenty of ways for businesses to get consumers to choose to use their product other than advertising which are far more conducive to consumers being able to make an informed purchase decision without being manipulated. But doing so would upend the existing power structures of who gets to sell more product, so disturbing the status quo just requires more political will than anybody really has.


  • Currently you need to trust the app and your instance. Most instances are implementing off-the-shelf lemmy but there is no way to confirm that.

    Yes that is what I wanted to know. My question was more directed towards other fedi software where you might want to secure/recover your account instead of using completely disposable accounts. So providing an e-mail address to an instance manager is what I was worried about, in case the instance manager decides to doxx their user. It’s just a possibility that needs to be taken into account when signing up on the fediverse, which is not what most people are used to.

    Honestly didn’t think about relay addresses which is a handy tip. But I asked because I wanted to use the alexandrite front end on my desktop browser and was wondering how safe it is to hand over my login credentials to lemmy skins. Since those are hosted on closed source servers, you can’t really verify what’s happening on the server side and how safe it is to hand over your login credentials to them if you’re not using a disposable account and a unique password.


  • zedage@lemm.eeOPtoMeta (lemm.ee)@lemm.eeHow does lemmy implement Auth?
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 day ago

    There’s a whole multitude of resons that could be argued for both approaches. I prefer this option because:

    • Most people don’t follow cyber security best practices and reuse the same password on multiple platforms. Currently, you have to trust the instance managers are competent enough to secure their databases properly from unauthorized access.
    • Again, your average netizen does not have relay addresses for every service they sign up to. If my instance manager does not like what I say, they can publish my sign up information and dox me. I don’t want instance managers to have this power.
    • If I want to use somebody else’s front end to browse on a browser, I have to pass my credentials to them to validate authentication details. Again a huge security risk if the hosting service for the front end is malicious. Why leave this vulnerability when there is a better alternative.
    • Your average netizen does not want to familiarize themselves with the nuances of the implementation of each fedi software. They want a seamless experience with the same trust framework of legacy social networks, where they trust their data is safe. Not everybody is going to know that their sign-up information and login credentials are managed by each instance, with anybody having the ability to spin up an instance.

    Why would you not want to trust the developers of each fedi software to hold this information, instead of trusting every instance manager to hold this instead? IMO that is a more vulnerable design choice instead of having a central authority managing user authentication, unless I am missing something?

    I suppose this discussion is more suited on each software’s github instead of a place to discuss this instance in particular, I didn’t know how each software implements user authentication so I posted here.

    E: I can now see why you are alarmed by my question. That is actually a good point. I am not sure if user authentication being handled by a central authority would violate principles of decentralization, which emphasize on interoperability and freedom of movement between different software and instances, instead of implementation of one component. I’m not sure if the management of authentication needs to be decentralized in the fediverse, as decentralization of freedom of movement itself is sufficient to prevent undesirable software implementations. I’d argue that managing authentication by instance managers is still a concentration of authority, albeit it is less centralized than a single source of truth. But I would love to hear arguments for why managing authentication by a single source is dangerous.



  • zedage@lemm.eetoFediverse@lemmy.worldThe fediverse has a bullying problem
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    8 days ago

    I think the confusion from fediverse’s claims of privacy stem from poor enunciation elucidation of the nature of the privacy from its proponents. It is definitely more private in the amount of passive data mining for ad tracking purposes compared to for profit social media. The architecture is designed to discourage instance managers from implementing ad-tech from building sophisticated user profiles of your behaviour in order to serve you more targeted ads from the people that manage the infrastructure. There’s no monitoring of clicks, click through rates, time spent on the platform, the type of content you like, etc. And the price for that mechanism is, making public, data that cannot be monetised on a large scale, which for profit social media guaranteed “privacy” to(in quotes because it was private from prying eyes through E2EE but not your keys not your data.)

    I can see where the confusion might arise for nontechnical people who aren’t familiar with the technical aspects of ActivityPub implementations. I don’t think there should be any confusion for technical people in understanding the architecture clearly guarantees a total lack of private data, seeing as how decentralisation works.


  • I think the confusion from fediverse’s claims of privacy stem from poor enunciation from its proponents. It is more private in the amount of passive data mining for ad tracking purposes compared to for profit social media. The architecture is designed to discourage these practices from the people that manage the infrastructure. And the price for that mechanism is, making public, data that cannot be monetised on a large scale, which for profit social media guaranteed “privacy” to(in quotes because it was private from prying eyes through E2EE but not your keys not your data.)

    I can see where the confusion might arise for nontechnical people who aren’t familiar with the technical aspects of ActivityPub implementations. I don’t think there should be any confusion for technical people in understanding the architecture clearly guarantees a total lack of private data, seeing as how decentralisation works.