45

If you're a developer working on a fediverse app or service and want to get it right – or just don't want to be the center of the next firestorm – here are a few suggestions.

Preemption is bonkers from a privacy perspective, and also flies in the face of the basic principle that the states are "the laboratories of democracy." But from a corporate perspective preemption is wonderful ... it keeps pesky pro-privacy states like California and Washington from ever raising the bar above whatever can get through Congress! So historically privacy advocates and organizations have always opposed preemptive federal legislation. But that wall cracked in 2022, where EPIC Privacy joined pro-industry privacy orgs like Future of Privacy Forum to support a preemptive bill (although EFF and ACLU continued to oppose the preemptive aspects).

The argument for supporting a preemptive bill (not that I agree with it, I'm just relaying it) is that the federal bill is stronger than state privacy bills (California unsurprisingly disagreed), and many states won't pass any privacy bill. Industry hates preemption, industry hates the idea of a private right of action where people can sue companies, most Republicans and corporate Democrats will do what industry wants, so the only way to pass a bill is to include at most one of those. So the only way to get that level of privacy protection for everybody is for people in California, Maine, Illinois, etc, to give up some of their existing protection, and for people in Washington etc to give up the chance of passing stronger consumer privacy laws in the future. California of course didn't like that (neither did other states but California has a lot of votes in Congress), and Cantwell's staffers also told us in Washington that she was opposed to any preemptive bill, so things deadlocked in 2022.

With this bill, I'm not sure why Cantwell's position has changed -- we're trying to set up a meeting with her, if we find out I'll let you know. I'm also not sure whether the changes in this bill are enough to get California on board. So, we shall see.

64

cross-posted from: https://lemmy.blahaj.zone/post/10889989

Big news in DC: a new bipartisan, bicameral proposal for a "compromise" federal privacy bill, the American Privacy Rights Act (APRA). At this point, take it all with a grain of salt; in 2022, the initial draft of the bill was promising, but it got weakened substantially by the subcommittee and then weakened further by the committee. I haven't read the discussion draft yet so don't have any strong opinions on it.

27

There's another wave of discourse about The Bad Space on the microblogging side of the fediverse, so here's my article from a couple of months ago.

If you're familiar with Fediseer, there's some discussion of similarities and differences in Compare and contrast: Fediseer, FIRES, and The Bad Space

And, it gives cops another excuse to overpolice Black and brown neighborhoods.

There have been other waves, it's just that once they get shut down everybody loses interest and moves on. The PR for the one of the changes Mastodon just made was implemented in May 2023 after the Doge spam wave. And here's a June 2019 post talking about exactly the same kind of attack: "The problem we are experiencing is the spammer signing up on random open instances and sending spam remotely."

102
107

A really interesting look at the recent spam wave.

A very good idea! https://startrek.website/ took this approach, it'd be intersting to check in with them to see what they learned.

65
Steps towards a safer fediverse (privacy.thenexus.today)

The good news is that there are some straightforward opportunities for significant short-term safety improvements. If fediverse funders, developers, businesses, and "influencers" start prioritizing investing in safety, the fediverse can turn what's currently a big weakness into a huge strategic advantage.

Contents:

  • It's about people, not just the software and the protocol

  • It's also about the software

  • And it's about the protocol, too

  • Threat modeling and privacy by design can play a big role here

  • Design from the margins – and fund it!

41

KOSA's supporters are claiming that the latest version addresses concerns from the LGBTQ community, and a few LGBTQ organizations (including GLAAD and HRC) have endorsed this version, but don't be fooled: the dozens of LGBTQ and human rights organizations who have been opposing KOSA were not consulted about these changes and so while there are improvements, it's still far from sufficient. This article's EFF's take on the amended version. TL;DR summary:

  • LGBTQ+ Youth will be at risk of having content, educational material, and their own online identities erased.
  • Young people searching for sexual health and reproductive rights information will find their search results stymied.

We are asking everyone reading this to oppose this latest version, and to demand that their representatives oppose it—even if you have already done so.

151

EFF's take on the amended version of KOSA. TL;DR summary:

We are asking everyone reading this to oppose this latest version, and to demand that their representatives oppose it—even if you have already done so.

20

This is the just-released unclassified version of the Privacy and Civil Liberties Oversight Board's December 2020 classified report on the National Security Agency’s (NSA’s) use of XKEYSCORE, an intelligence analysis tool.

Fediblockhole does something along those lines for on Mastodon ... not sure if there's an equivlaent in the Lemmy world.

39

cross-posted from: https://lemmy.blahaj.zone/post/7992691

There are some straightforward opportunities for short-term safety improvements, but this is only the start of what's needed to change the dynamic more completely.

This is a draft, so feedback welcome!

50

A deep dive into the Data Protection Review Court by Alfred Ng and John Sakellariadis, including some great perspectives from Max Schrems of noyb.eu

They don't, at least not from your instance.

I can't speak for others but yes, I want a fediverse that doesn't have white supremacists and fascists.

36

cross-posted from: https://lemmy.blahaj.zone/post/7477620

Transitive defederation -- defederating from instances that federate with Threads as well as defederating from Threads -- isn't likely to be an all-or-nothing thing in the free fediverses. Tradeoffs are different for different people and instances. This is one of the strengths of the fediverse, so however much transitive defederation there winds up being, I see it as overall as a positive thing -- although also messy and complicated.

The recommendation here is for instances to consider #TransitiveDefederation: discuss, and decide what to do. I've also got some thoughts on how to have the discussion -- and the strategic aspects.

(Part 7 of Strategies for the free fediverses )

A website like that would be very helpful. A lot of people I talk to think that unlisted gives more protection than it actually does (they're used to how it behaves on YouTube where it's harder to discover), don't realize that it's still likely to get indexed by Googe et al even if they haven't opted in to search engines (because their post may well appear in a thread by somebody who has opted in), don't understand the limited protection of blocking if authorized fetch isn't enabled, don't realized that RSS leaves everything open etc.

Yes, I think in terms of protecting data generally, not just from Meta but also data brokers, Google, and other data harvesters -- as well as stalkers. Meta's a concrete and timely example so it's a chance to focus attention and improve privacy protections, both for instances that don't federate and for instances that do. I agree that most (although not all) of the information Meta can get from federating they already can by scraping and they certainly could scrape (and quite possibly are already scraping) most if not all profiles and public and unlisted posts on most instances, and so could everybody else ... it's a great opportunity to make progress on this. https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/ has more about how I look at it.

Specifically in terms of data that flows to Threads through federating that isn't otherwise easily scrapable today, three specific examples I know of are

  • followers-only posts for people who have followers on Threads, or who have approve followers turned off
  • some unlisted posts from people who have opted out of discovery and search engine indexing that aren't visible today (i.e. haven't been interacted with via a boost or reply by somebody who has opted in). it's very hard to predict how many of these there are; it's not just posts that are boosted by somebody who has followers on threads, it also relates to how replies are retrieved
  • identifying information in replies to followers-only posts by people who have followers on Threads. This can flow to Threads even if the original poster has blocked Threads (because blocking information doesn't get inherited by replies)

That said this isn't based on a full analysis so there may well be other paths. As far as I know the draft privacy threat model I did last summer is the deepest dive - And the software is buggy enough in general that it wouldn't surprise me if there are paths that shouldn't exist.

In terms of concerns about tracking others have about federating ... like I say for most people this isn't the top concern. To the extent it is about data going to Threads, for a lot of people it's about consent and/or risk management, full stop. They do not want to give Meta or accounts on Threads easy access to data from their fediverse account, even if Meta can get it without consent now (and even if they have some other Meta accounts). There's also a lot of "well Eugen said it's all fine", and especially from techies a lot of "well they can scrape it all anyhow, whatever" and "everything is public anyhow on social networks".

Yes, I'd say Lemmy communities are cross-instance communities - people can join communities on a different instance than their account.

You do realize that instances federating with Threads will share data with Threads, and that Meta's supplemental privacy policy specifically says that they'll use all activity that federates to meta for tracking and ad targeting, right?

So for example, if you're on an instance that federates with Threads, and somebody on Threads is following you, all of your posts -- including your followers-only posts -- will get tracked by Meta. Or if somebody who boosts your post and they've got followers on Threads, your post will be tracked by Meta. Or if you like, boost, or reply to a post that originated on Threads, it gets tracked my Meta. And these are just the most obvious cases. What about if somebody on an instance that's not Threads replies to a Threads post, and you reply to the reply? It depends on the how the various software implements replies -- ActivityPub allows different possibilities here. And there are plenty of other potential data flows to Meta as well.

Of course they're still just at the early stages of federation so it's hard to know just how it'll work out. Individually blocking Threads might well provide a lot of protection. But in general, instances which federate with Meta will almost certainly be tracked significantly more than instances that don't.

Today almost no instances run ads (misskey is as far as I know the only platform that's got support for ads) and Threads is the only one that does tracking. I'm using "free fediverses" the way https://freefediverse.org/index.php/Main_Page does -- instances that reject federation with Meta.

On Lemmy? Certainly not. But on other fediverse software, there are followers-only posts, direct messages, local-only posts ... none of it's encrypted, but still it's not public.

view more: next ›

thenexusofprivacy

joined 6 months ago