Kat questions whether users consent to public data exposure
2 Oct 30 · 12d ago · 1 article · 2 posts · 3 sources · development 2 of 2
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 KatMelanie Kat Security researcherBluesky / AT Protocol Social network and protocol
The whole story articlesposts the bright band is this development · numbered dots are the others · click one to jump
What was reported 1 claim about this development
-
first by HN Frontpage, 12d ago
What people said 24 voices · best of 33 · verbatim
-
> 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.
-
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…
-
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.
-
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.
-
> 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”…
-
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.
-
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…
-
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”.
-
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.
-
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 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…
-
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.
-
> 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…
-
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…
-
> 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.
-
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…
-
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…
-
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.
-
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.
-
>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…
-
> most major providers won’t accept messages without TLS I didn't think sender-side adoption of TLS was high enough to permit that. I know gmail accepts unencrypted email, they have a transparency report that details the progress. It rounds up to 100%, but if you drill down they still accept unecrypted email. Some oddities are sendgrid.net…
-
I was way too fuzzy in that. I meant mainly *incoming*, my understanding is that most major providers won’t accept messages without TLS. For outgoing, various providers let you choose to require TLS, and I get the impression it’s fairly common in enterprise to do so.
All 2 developments of Researcher exposes AT Protocol users' unexpectedly public… →
LobstersHacker NewsMastodonNewswires