Researcher exposes AT Protocol users' unexpectedly public data
Investigation finds RSS feeds, paywalled content, and private messages accessible without authentication across Bluesky ecosystem.
What to know
- AT Protocol's decentralized architecture makes user data on personal data servers (PDS) publicly queryable by default with no authentication required.
- A researcher accessed 1,300+ RSS subscriptions, paywalled feeds, Patreon content, and private repositories through public relays—demonstrating the scale of exposure.
- The tension: while this may be AT Protocol's intended design, most users likely don't understand or consent to how publicly accessible their data actually is.
Melanie Kat Security researcherBluesky / AT Protocol Social network and protocol
How it unfolded 2 developments, newest first · click a bar or a number to jump articlesposts
-
2
Kat questions whether users consent to public data exposure
The researcher noted that while AT Protocol's decentralized design may be intentionally public-by-default, users may not grasp the practical privacy implications. She expressed skepticism about informed consent, stating the architecture creates a gap between design philosophy and user understanding.
“I'm sure some people will say, "Sure, that's the point," but I'm not convinced the users understand the risk.”
— Melanie Kat -
first by HN Frontpage, 12d ago
-
> Do ~~At-Proto~~ Users Know ~~This Is Public~~? Generally no, which is why I'm of the opinion that it's the duty of the engineer to make the system such that users not knowing doesn't harm them.
2 more of the top 3 · 33 posts in this stretch
-
so i opened up skyreader to try it for myself. in multiple locations in the application and the docs, it indicates that data is private (stored on their servers), and can be published to the internet if you *choose to*: https://docs.skyreader.app/your-data/#at-a-glance the UX of the application also makes this an explicit option. if users are…
-
hey, Skyreader developer here. Just to be clear, subscription syncing is off by default with a big warning that enabling it will make your subscriptions public. I've tried to make it as clear as possible both in the UI and docs what is and isn't public. That said, some users forget or don't fully understand the implications of making feeds public…
-
-
background
Kat details data exposure methods across multiple AT Protocol apps — The researcher documented specific vulnerabilities: RSS feed subscriptions stored in Skyreader are published in plaintext within queryable data structures; Discord and Twitch clones running on AT Protocol store all messages openly and searchably; paywalled feeds, Patreon exclusive content, and private Git repositories became accessible through the open relay queries.
-
1
Researcher documents widespread unintended data exposure on AT Protocol
Security researcher Melanie Kat published findings showing that user data on AT Protocol—which powers Bluesky—is far more publicly accessible than most users likely understand. By querying public relays and using tools like PDSls.dev, Kat discovered she could access 1,300+ RSS feed subscriptions, private paywalled feeds, and sensitive content from AT Protocol apps with no authentication or restrictions.
“I've found is a bunch of private data I'm not sure people know is public. Not only public, it's easy to find.”
— Melanie Kat
What people are saying 21 voices from 1 site · best of 35 · verbatim
- Nov 1
-
atproto is unfortunately not designed with safety in mind. While some "fun" tech-demo style experiences have been possible on it, the underlying problem of it still being built and funded by the usual gang of investors and "Silicon Valley culture" makes safety and privacy problems on the user side of things unavoidable.
- Oct 31
-
It is "common knowledge" (read: widely repeated and likely true, but probably also overstated) that use of STARTTLS is a spam classifier signal for major email operators. Lack of TLS on incoming emails tends to mean a simpler/more trivially configured origin, which is more likely to be a compromised machine sending spam and less likely to be a…
-
You need a trusted PKI system for any communication. The simplest version is pre-shared-keys between 2 parties. Ur mixing up "web PKI via proprietary conglomerate companies" & "most TLS uses web PKI" to share the same downsides.
-
TLS over UCP & UDP is a good illustration of the phenomenon described by Joe Armstrong: > You wanted a banana but what you got was a gorilla holding the banana and the entire jungle In this case the banana is privacy, the gorilla is SSL/TLS, and the jungle is eMudhra and the…
- Oct 30
-
>not every user is you that was the point of my post. i try and read the documentation of the things i'm using, so likely wouldn't be surprised by something like this specifically because you've documented it and written warnings about it. this is an activity _you_ consider dangerous enough to have written that documentation, and for such things…
-
I believe most of the email world will refuse to talk cleartext now. It was viewed as a migration process there. For the web, there are more places where not everyone agrees encryption is useful or desirable. IETF describes how pervasive monitoring is an attack, but not everyone understands or accepts this. Really what we needed was something tied…
-
Wow, that’s certainly a reply, but not quite the “assume good intentions” I would hope for if I had taken some of my time to make something for anyone who wanted to use it and bothered to warn about the privacy implications. Also, not every user is you. Some people either don’t care or want that behavior. And that is ok. There is no “average user”.
-
> subscription syncing is off by default with a big warning that enabling it will make your subscriptions public. I've tried to make it as clear as possible both in the UI and docs what is and isn't public. i haven't really looked at skyreader and i honestly probably won't, but i argue that if there is a reason for this warning while people would…
-
ATProto makes a lot of stuff public. Everyone you have blocked, for example - https://bsky.app/profile/edent.tel/post/3l4rjxx32br2j That's certainly a bold design choice. I can see the technical merits in doing it that way. But the social aspects can be horrific.
-
ATProto is designed for data that you want to be public. That's the point of the protocol. ATProto spaces, which are currently being designed/implemented, will allow for permissioned data, so that you can have data that isn't public.
-
When I first looked into atproto, I was deeply grossed out by the privacy model: **none**. I think the reason for its popularity is how easy and fun it is to build a weekend project on top of the protocol, but the fundamental nature of atproto is that *nothing* is private. People familiar with other protocols like Signal or Matrix or Mastodon are…
-
I maintain that ATProto is fundamentally flawed for any application that is not open data fan out, basically boiling down its use cases to Twitter clones and government broadcast. Privacy is not something you bolt on to a protocol 4 years later. Let alone the PLC DID Achilles heel to the entire thing.
-
i can see the argument and from an ergonomics point of view i'd agree, protocol negotiation has plenty of benefits. however, in the specific case of plaintext-to-encrypted comms, the one benefit having it separate is it aids mitigation of [tofu attacks](https://en.wikipedia.org/wiki/Trust_on_first_use) - you can literally outright block the…
-
> it's not like http vs https Somewhat incidental, but I believe this s is commonly considered a mistake. https://www.w3.org/DesignIssues/Security-NotTheS.html is one discussion (from early 2015). The transition certainly changed a lot of URLs, and we’re still dealing with the troublesome consequences today. (I say “commonly” in the sense “often”…
-
that was more forceful than i'd have liked in reply, i apologise. i had started reading my link in the parent again and gotten frustrated at it all over again. i have a massive hope for the protocol because it's super interesting and it's already created some really cool stuff (e.g., tangled, which presents a dream of federated forges that forgejo…
-
as much as many wish it weren't true, it is entirely possible to develop something with llm assistance without doing so blind. it is of course very easy to go right off the rails when you get lost in the sauce about it, but that still makes it malpractice.
-
> i wouldn't necessarily expect an end-user to know it, but of a developer of an application building on top of the protocol i would expect at least rudimentary due diligence. given the prevalence of llm-assistance in atproto development in general, i don't think we can expect that.
-
i strongly disagree, honestly. it doesn't need to be (and very much shouldn't be) welded on in such a brutish way that it justifies needing to specifically call out, at a scheme level, that it's materially different. there are great pains being taken to try and mold this nicely into the existing atproto environment, as evidenced by the current…
-
When I was still in high school, a few of the guys I knew started using twitter and didn't know it was all public. They had some pretty horrible stuff up there for several years before they realized.
-
Given that the other protocol works so differently in terms of retrieval and expectations, it may make a lot of sense to have a different URI scheme, I think
-
at the moment i would argue this is malpractice of the application developer, if it's intended in any way by a user that such data shouldn't be publicly available. atproto user data being completely public has never been a hidden factor. i wouldn't necessarily expect an end-user to know it, but of a developer of an application building on top of…