flipboard.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Welcome to Flipboard on Mastodon. A place for our community of curators and enthusiasts to inform and inspire each other. If you'd like to join please request an invitation via the sign-up page.

Administered by:

Server stats:

1K
active users

A thread on some tenets regarding open systems I feel compelled to relay:

- It’s extremely hard for open to ever compete with closed. It almost never succeeds.

- Every now and then open is given a chance due to unprecedented external events or pressures.

- In the rare event that open gains momentum, any actor can adopt it. That’s the point.

- The actors who adopt open will inevitably range from good to indifferent to bad.

1/

- If those who have been working on open revert to closed in the name of preventing bad actors, closed will win.

- If open wins we get things like the web. Imperfect but far greater for humanity than most everyone being online via AOL.

- We’re at a precious moment in time for the fediverse. When it comes to social media, open has a real chance right now. And closed is on the ropes. Let’s not blow it.

@mike

Completely agree we are in a moment in time that is precious and we will not easily get another chance at this. The real prospect of a broad based open social web is incredibly exciting.

For it to succeed, users will need explicit protections from surveillance and exploitation. Open will not work if users feel like they are just throwing open the door for all their thoughts and ideas to be hoovered up and processed into sophisticated personalized influence campaigns.

1/

@mike

It therefore becomes incumbent on those who are building the protocols and applications to communicate the value proposition. Not just the wonderful future that such interoperability will give users. Also, the comfort they can derive from technical features and legal terms, ensuring them that their personal data and content contributions will not be exploited without their consent.

Mike McCue

@mastodonmigration I think there are some important actions to take in the coming months to prepare for the federation with threads. Has anyone made a list of key things we should focus on to protect people in the fediverse? For example @evan talked recently about the importance of being able to delete replies from a thread you started. I think people should also be able to opt out of quote posts as another example. Is there a group of people already talking about this?

@mike @evan

Technical features are one thing. Not familiar with any organized work, but that doesn't mean there isn't any. But the other area which would go a very long way to addressing user concerns is explicit public data use and privacy terms. Thinking of an opt-in/out-out framework that gives users explicit control over their content and personal data. Such frameworks, particularly in the EU, are now common for internet services. If we want open social to work, we should do it here too.

@mastodonmigration @evan great point. Mastodon already has a number of these built in which is a good start.

@mike @evan

Kind of. Actually, the Mastodon Privacy Policy is very limited. It really only gives the instance the right to republish content and not share personal data. When user information and content starts crossing commercial entity lines things get much less defined and potentially problematic. Corporate applications have much different terms and many include license agreements for various purposes, including commercial purposes, which of course users agree to when they sign up.

1/

@mike @evan

So, how do rights track content and personal data around this new open social web? If we can answer these questions and construct a satisfactory framework for both users and providers, before it turns into a mess and regulatory solutions start being fought over and mandated, we'd be way ahead and off to the races.

@mike @mastodonmigration @evan Blocking threads/meta *is* part of being the open social web, because it's a necessary act of defense to keep us from becoming absorbed into Facebook

like there NEEDS to be a part of federated social media that has no Facebook connection at all, in case Facebook tries some sort of buyout or copyright lawsuit or buying servers or incorporating proprietary tools or whatever

@mike @mastodonmigration @evan To use a capitalist/business comparison (ugh), it's like refusing to let Walmart carry your products being a defense of your business, because at some point you will either be beholden to Walmart supply chains or standards or such, or Walmart selling your products will mean *no one* is buying them from you anymore, etc

@mike @mastodonmigration @evan and then, your/your invention's/business's fate is entirely tied to Walmart, and that's worked out really poorly for people who've either sold out, been bought out, or been overwhelmed, because when the Walmart fails or goes out locally - they can't just pick up and start where they were before that

@mike @mastodonmigration @evan either way, the best idea is to keep Big Blue Corporation out in the first place, *before* they devour and engulf everything special, unique, local - and then either run away with it or implode

@mike @mastodonmigration @evan

This is a 5 months old list of PR’s for Mastodon I created when threads announced federation, over holiday break was going to look at which made it into mastodon 4.2 or which new ones should added or old removed. docs.google.com/spreadsheets/d

docs.google.comKey Features for Mastodon / ActivtyPub Prior to Threads Launch - Google Drive

@mike back in June or July @tchambers was collecting recommendations at the product level. Here's the ones I had via @thenexusofprivacy - infosec.exchange/@thenexusofpr there's a link out to the (draft) privacy threat model that goes into more detail.

@mastodonmigration

Infosec ExchangeThe Nexus of Privacy (@thenexusofprivacy@infosec.exchange)Recommendations for how Mastodon and other Fedivese solftware needs to evolve to deal with Threads @tchambers@indieweb.social, these are from the "Recommendations" section at the end of https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/#developers -- the main text discusses the rationale (although, it's a draft). * "Privacy by default": Set defaults so that people start with stronger privacy protections, and can then choose to give it up. For example, make "Authorized Fetch" the default setting, and ensure documention explains it well. * Develop processes and tooling for blocking Meta instances and all instances that federate with them. For example, extend nodeinfo to have a field with an instance's policy towards Meta (transitively block, block but federate with instances that federate with Meta domains, federate with Meta domains). Investigate solutions for blocklists Meta and federating-with-Meta domains (taking into account that there are likely to be a huge number of them hosted on different domains), and for allow-lists for instances that don't share data with Meta * Investigate shifting to allow-list federation, and look at alternative approaches like "approval first" federation. * Reduce the number of public pages and the amount of data in them, including supporting private profiles, increasing use of non-public visibility like local-only posts, investigating new visibility levels like "viewable only to people logged into instances that don't federate with Meta", differentiating between what's shown at different levels of visibility, and (potentially) requiring login to view unlisted statuses * Provide a usable way for instances and individual users to protect all profiles, timelines, statuses, images, etc from anonymous access. * Provide control for individuals and sites to determine whether RSS feeds are available, and implement an option to remove unlisted statuses from RSS feeds * Educate people on (and potentially package) existing processes and tools for IP Blocking, integrate with suspend/limit federation-level processes and infrastructure, and potentially develop new tools and look for ways to address downsides. * Look at potential app-based dataflows and potential counter-measures, possibly including allow- and block-lists for apps as well * Pursue funding from anti-surveillance-capitalism companies, civil society groups, governments, and crowdfunding to allow more detailed analysis, design, and rapid implementation of privacy and safety features – and ensure that the funding is directed in a way that increases equity and diversity. * Press the project leaders to prioritize privacy and safety in their planning. If they don't, consider voting with your feet and creating a fork that prioritizes privacy and safety (as well as equity, usability, onboarding and all the other issues that need to be prioritized). #fediverse #mastodon #threads @fediverse@lemmy.ml @fediversenews@venera.social

@mike also here's a concrete project -- not just focused on Meta -- that could be a good next step. I submitted at the last minute to NLNet, and didn't have any EU folks involved or dev projects committed to work on it, so not surprisingly it didn't get funded, but it's an interesting starting point.

nexusofprivacy.net/ipsfs-nlnet

The Nexus Of Privacy · Improving privacy and safety in fediverse softwareA resource page for a work on threat modeling and other approaches to improve the fediverse.