Do At-Proto Users Know This Is Public?
87 points by robalex
87 points by robalex
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 the protocol i would expect at least rudimentary due diligence.
this is ongoing work to add authenticated data functionality to atproto, though presently they are hung up on minutia such as "should we use another protocol schema instead of at://" (to which the only sensible answer is obviously "no", it's not like http vs https).
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 so I could probably add a heuristic checker that warns when you add a feed that looks private/paid when you have sync enabled.
The real solution is moving subscriptions to atproto spaces once they're ready.
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, so i'm going predominantly off the top level discussion of atproto's privacy shortfalls, but i argue that if there is a reason for this warning while people would want to keep those things private then perhaps atproto at present is not the protocol that it should be using for that component, in the same way github keeps user details in a database instead of git repos.
however i also, given the constraints of "i want to use atproto for this", don't really think you could do much more than that. if there's an interstitial saying "hey you enable this, your data is now public, understand what this means here: link", then you've kinda hit the upper limit on your options. just remember that unless obligated to, the average user will not read documentation. the flow should be, including a warning above this button, "click the button that would make it public" -> "be presented with an interstitial that things are going to be public" -> "make them confirm on that interstitial". once again though, when you look at how many steps you're introducing to compensate for a protocol deficiency, makes you wonder if it's worth it.
it's for these sorts of reasons i am very much looking forward to spaces, assuming we ever work out what protocol scheme the authors want to use (at://, ats://, atsecure:// ipickedthisonelookatmemumihelped://, whatever).
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”.
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 that sort of "step-up approval" behaviour is almost standard-issue.
again, you're restricted by the protocol you're using, so the best options available really are "don't use it for that part of the app" (which you've indicated isn't feasible or useful) or, like you said, "warn the user". i'm simply saying there are more thorough ways you can warn a user if you are of the opinion that the activity is potentially dangerous, and to the strongest extent you can, you should take that path. looking at github again, moving a repository from private to public, for instance, is explicitly in a section labeled "danger zone", and just clicking that button offhand doesn't make it public outright.
when you look at it as "wow i'm implementing six things to patch over something in the design [of atproto, not of your app] here", is when i personally would consider whether or not implementing that part of it not on atproto would be useful and less painful in the long-term. i honestly don't know when spaces will land proper and it doesn't appear, from a brief re-reading of the forum i posted in the top level comment, that anyone else has a particularly firm timeline either.
edit: s/you/they/g, didn't realise you weren't the same as the person above.
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” rather than “by most people”.)
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 - you can literally outright block the plaintext version. this is a prime concern that things like hsts preloading attempt to mitigate (as hsts itself is still prone to such attacks), along with starttls being largely phased out of the world smtp infrastructure.
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 to DNS (e.g. DNSSEC/DANE), but it’s too late now.
I’ve used Firefox in HTTPS Only mode since it first landed on Nightly. It rewrites http: to https: and gives you an interstitial warning if a server doesn't speak HTTPS. That’s clearly where everything is headed, and it would have been decent in a shared-scheme world too.
For a long time, many people served the same content over HTTP and HTTPS, so the “block HTTPS” attack worked. Now, few do that, almost everyone just implements http: as redirect to https:, rendering http: essentially obsolete. And essentially no one implements different things on http: and https:. The last site I know of that did that (and the only one in at least a decade) was Australia’s Bureau of Meteorology, which served an “HTTPS not supported” message that redirected you to the homepage on http: until about two years ago. It was super annoying, messing up HTTPS Only mode, and they wouldn’t heed my pleas that they just stop accepting on :443 like normal people.
I believe most of the email world will refuse to talk cleartext now.
That hasn't been my experience. The best practice I see is MTA-STS and/or DANE (rare, 1-2% of domains), which refuse cleartext when active. Otherwise opportunistic encryption is used, which will use TLS when available, does not validate the certificate, and readily downgrades to cleartext to keep email flowing.
I haven't found a transactional email provider that does MTA-STS or DANE, which is awkward when you get your AWS root account password reset email delivered in cleartext. But everyone uses MFA...?
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.
Really what we needed was something tied to DNS (e.g. DNSSEC/DANE), but it’s too late now.
100% agree with you, but i'm not sure it's too late. we can still improve things slowly, it just won't be tomorrow. :)
The last site I know of that did that (and the only one in at least a decade) was Australia’s Bureau of Meteorology, which served an “HTTPS not supported” message that redirected you to the homepage on http: until about two years ago.
heh, i remember constant conversations about this (also an australian). it was a big "hooray" when they finally switched it on proper with the big migration.
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
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 proofs of concept implementations in various pds.
it's authentication standards introduced into the existing protocol, and largely nothing else changes - especially for an end-user. this would be like inventing a new scheme when we discovered basic authentication would be better than none, and then again when we invented form-based authentication. perhaps yet another for bearer token and similar? they are all http. https is because we put ssl (tls) on top, which is actually a proper difference at a protocol level. you can already 401 / 403 based on whatever you wish, there's simply no proper universal mechanism to do so.
the discussions around this are textbook bikeshedding. "oh, should we use ats:// or something else? it's just so important and i simply must have my say about it. have we considered atsecure://, perhaps?"
if i ever have to hear or see "was that at:// or ats://" i will know at that exact moment that the protocol is in an irrecoverable state.
iirc rn they are considering at:public/did:... and at:spaces/did:... which would also make at uris be real uris since the did wouldn't be in the authority position anymore!
i like that considerably more than a separate scheme entirely, but i still ask why anyone would use the public namespace in the face of the spaces one existing with a qualifier of "any". seems a bit pointless.
aside: i really like the vibe of your site. :)
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.
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'm sorry, yes i agree that it's egregious and unethical
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 never quite landed), so seeing it stuck in a quagmire like this causes me great angst because for me, specifically, this blocks private tangled repositories.
Do
At-ProtoUsers KnowThis 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 publishing private data, they either intend to do so, or don't care. the UX is quite obvious that they are making this public to the internet.
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.
Privacy is not something you bolt on to a protocol 4 years
ignoring the history, permissions spaces does solve the problem and there are several third party implementations of this already.
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 inclined to extend the benefit of the doubt and assume that, surely, there is some part of atproto that can be used for private direct messages, or selective visibility, or sensitive personal data, but no. Everything is public. Even if you bolt on some aftermarket encryption, all the metadata is still public. It's a social endeavor that I want nothing to do with.
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.
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 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.