One problem I’ve noticed that I don’t see many people talking about which seems extremely relevant to this is the insufficiency of OAuth scopes for leaving comments on a personal website and similar interactions that occur in a low-trust environment.
See, platforms are assumed to be more-or-less neutral third parties, but websites owned by the person whose posts you are commenting on aren’t and can’t be (there’s literally no third party). Websites have always been able to monkey with user comments on-site more-or-less arbitrarily, but on atproto your comments live on a server of your choice, which can opens up new abuse vectors (eg, a website rewriting your comments to be content that is illegal in the region your PDS is hosted). The much larger problems, however, are that if a site uses a shared lexicon for their comments, you can’t grant that site permissions on your account to let you comment without also granting the site permission to comment as you on other websites.
Imagine a spammer creates puppy.blog, a self-hosted blog showing pictures of puppies, uses the leaflet lexicons for content, and adds pub.leaflet.comment based comments to it. Everything is working as intended, we have interop, you can reuse other people’s lexicons to solve problems… except that on order to post a comment through puppy.blog on the puppies, you now need to grant pub.leaflet.commentwriting permissions to puppy.blog to post a comment on that website, and now the spammer can post comments on anyone else’s leaflets as you. Not good!
Now, you can “solve” this problem by making scopes more sophisticated. You can continue to do this until you’re embedding a datalog interpreter into the PDS to figure out whether a given token grants permission to make a given post. I don’t think this is a real solution, however. Why not?
-
Complexity of implementation. Adding fine-grained scopes is complicated and annoying. On the client side, scopes are already sufficiently complicated that atproto.com hosts a web-based tool to help developers get them right, and while frankly I think implementation burden on PDS developers is an acceptable trade-off, shipping something so complicated nobody can use it isn’t, and will cause developers to just reach for broader scopes.
-
User Education. How do we explain to users “oh, well, this set of OAuth scopes is okay to give to someone’s blog, but this very similar-looking set is emphatically not okay and puts your account and/or reputation at risk?” We have this problem already, and I wouldn’t be shocked if some users just blindly click through the OAuth permission screen. Making scopes more complex makes this problem dramatically worse.
-
No scope can actually be fine enough. While finer-grained scopes are possible, there are kinds of highly impactful abuse that can be done using even perfectly constrained scopes.
To help explain what I mean, consider puppyblog in a world where OAuth scopes can have a linking constraint. That is, you can specify in the scope that a given link field must refer to a record owned by one of set of DIDs defined when the OAuth token was requested. Now, if another publication was made under the same DID this could still be used to forge comments you didn’t write on a blog you’ve never seen, but this might be surmountable with more sophisticated forms of linking constraint. What you can’t solve is puppyblog getting an OAuth token and immediately publishing site.standard.graph.recommend records from you for each of its posts, juicing its recommendations and helping it get a broader audience, which will allow the spammer to get a much higher price for puppyblog when they flip their account three months down the line to someone who will take it and turn it into hitlerblog. Something this overt will probably get noticed, but subtler variants of the same attack may not be.
You can’t solve this with linking constraints (or any other finer-scoped oauth scope scheme I can think of—maybe someone here is smarter than me and had a solution to this) because puppyblog actually has a legitimate need to create site.standard.graph.recommend records for its site.standard.documents on the user’s behalf, so they can click the “recommend” button on the site!
The reason for this issue is that OAuth, by its nature, grants a site a token that enables it to act on the user’s behalf. In this scenario that is actually undesirable! We want to grant the user the option to take an action, without permitting the site to take autonomous action.
Now, does FedCM save us in this context? I… don’t think so? If someone who understands the inner workings of FedCM better than I do wants to chime in and explain how it can I’ll be very relieved, but my understanding is that at the end of the day the site still gets an OAuth token back. And even if that token isn’t a refresh token… well, you can still do damage before the token expired
I think (and again, it would be very cool if I was wrong) that the only tool the web platform has to give us something resembling the affordance we want here is an <iframe> pointing to a site the user can trust to create records in a given lexicon on their behalf (and has presumably given permission to do so). iframes have their problems (clickjacking to manipulate the user into creator records, for example), but this would at least mean that a malicious site would have to trick the user into taking an action, rather than performing one on their behalf, significantly reducing abuse potential. Problem is, we don’t actually know what sites the user trusts to do that, and assuming they trust eg, bluesky or leaflet could be wrong and it de-facto centralizes power over the network.
My proposal for solving this is, in broad strokes, providing a standardized way for users to define a set of delegate sites that they trust to create records on their behalf, and something akin to oembed so these delegates can tell a client site how to embed them, but that in particular and iframe-based solutions in general have some serious complications, so I’d love to hear about alternatives.
Alternative solutions I’ve already heard that I’m somewhat skeptical of but are worth mentioning:
- Tell people to create their own lexicons to for interactions on their site: well, this breaks down for things like
site.standard.graph.*, but also, like. Being able to use shared lexicons is one of the coolest things about atproto and folks with their own websites will resent being told not to do it (and consequently do it anyways). Also, creating a new lexicon is WAAAY more work than just using someone else’s. Never underestimate the power of human laziness in guiding how people build stuff.
- Suggest people use Atproto OAuth like OpenID: This an always an option (hell, at this point we’re more OpenID than OIDC is), and it’s an important capability for integrating into mixed environments where the Atmosphere acts as one IDP of many… but again, this locks people with their own websites out of what’s cool and exciting about atproto, so I don’t think people will follow that recommendation.
- Browser Extensions: I love Margin a lot, but if you have a website and want interactions, “install this browser extension to interact with my website” is just a bridge too far for most people. And in a world where mobile is as dominant as it is, we can’t assume users have the capability to install browser extensions, even if they want to.
- target=”_blank”: Instead of embedding an iframe, we can open the comment/subscribe/whatever UI in a new tab or window. This is more secure, but the ergonomics are terrible and people will start looking for alternatives to make their UX better, even if it leaves users open to greater risk.
- Finer-grained scopes are fine actually: I mean, I don’t know if I agree but I’m definitely willing to be sold on this! Proposals for making OAuth scopes more expressive do solve at least some of these problems, and maybe there’s more that can be done with that than I realize? I am emphatically not an expert here.
I know this is kinda tangential and extremely long-winded, but I genuinely think this issue is something we need to be considering if we’re going to start trying to integrate the atmosphere more with the blogosphere and with web2.0 sites in general, lest established practice become just casually slinging over-scoped oauth tokens around with no safeguards to speak of.