You're absolutely right - the point is to break the app. This is great if the user breaks the apps in exactly the ways they want, but my point is that users rar

You're absolutely right - the point is to break the app. This is great if the user breaks the apps in exactly the ways they want, but my point is that users rarely understand the scope of the app, and may (and likely will) end up revoking permissions that break functionality they want. For example. I sign up with Foobar's Widgets with my Facebook account, and manually deny the "publish_stream" permission, because I just want to browse Foobar's widgets, and I don't want Foobar posting mean things about my mom on my stream behind my back. Three weeks later, I come across a really boss widget, and see the "Share this widget with your friends on Facebook!" button. "Neat!", I think, and click the button. That fires off a job that gets stuck into a background queue (because doing external applications work in your web app directly is a recipe for self-DDOSing), and the worker pops the job, tries to run it, fails because the publish_stream permission is missing, logs the error, and closes the job. I, the user, go to Facebook, expecting to see the widget there, but it's not there. I'll just assume it's lag. Things are slow sometimes. But it never shows up. I'm left with the assumption that it's Foobar's fault, for having a buggy "Share to Facebook" button. The problem is that by putting permission revocation in the hands of the users without any documentation on what those permissions are used for, you leave it open to each user to assume what those permissions are used for. Imagination runs wild, the user freaks out and revokes the permission, things break, and people go home unhappy. The case where this is absolutely needed is where an application is known to engage in some behavior that is undesirable, and you want to be able to prevent it from doing so. However, that's doable via the Facebook application permissions panel already, so I'm not sure that this is a big win. By placing it up front as a part of the authorization process, you're inviting people to break things in ways that they can't really see at the time of authorization. I don't think the solution is "always trust the developer". There are bad developers out there writing abusive apps, and we need the tools to deal with them. The solution is also not "fully rely on the user to evaluate and grant/revoke permissions", because most users can't be bothered to read anything longer than your average tweet. Developers need better ways to tell people why they need permissions, and users need more powerful tools to cut out permissions that they know are resulting in abusive behaviors.