search

appdotnet / api-spec

App.net API Documentation is on the web at https://developers.app.net. Source for these docs is in the new-docs branch here. Please use the issue tracker and submit pull requests! Help us build the real-time social service where users and developers come first, not advertisers.
https://developers.app.net
952 stars 99 forks source link

Access control when creating Post objects #33

Closed stevestreza closed 11 years ago

stevestreza commented 11 years ago

Posts should be able to be restricted in their visibility at the API. This means a Post is never delivered through the API to a Stream which is not allowed to see it. The inclusion of access control would have a profound impact on the platform and would enable a huge variety of apps and use cases that are not possible under existing social networks and message routing systems.

This will enable lots of use cases that could really blow up the utility of the service beyond a Twitter-style system. Some examples include:

maks commented 11 years ago

Sounds like a very interesting idea.

And how about the use case of implementing a micro-newspaper, with users with specific auth tokens being subscribers and/or publishers. In essence I guess access control would enable private subnetworks. What would be really nice is to have some sort of provisioning API as well, so that app.net really does act as infrastructure for third parties who want to build various forms of publishing services on top.

joecarney commented 11 years ago

This is a good idea as it would remove the need for private accounts that most are usually set up on Twitter to achieve the same type of interaction... Also, anything that differentiates app.net from what is already out there has to be a win-win...

tommoor commented 11 years ago

I like this idea a lot, the simple model would be easy to follow for developers but allows a lot of previously impossible applications to be built.

markwilcox commented 11 years ago

This is definitely the right direction to make app.net into so much more than Twitter.

So to summarise, you wan't access control lists for users and apps, a whitelist and a blacklist for each, right?

I'm 100% in support of this for users. Not entirely sure if it's the right way to go for apps.

I was thinking such restricted post visibility for users would exist in #21 - I think @daltonc and/or @berg had already mentioned they were interested in doing similar to fix direct messaging.

I've been thinking about similar use cases in #20. If you have the post creator determine which apps can see the post then it restricts/prevents multiple apps from supporting the same "protocols". Might it be better if there was a way to register your app as supporting certain "protocols" in the developer console. You could have private protocols that no-one else can register to support if you want to keep your tech proprietary, or your business model depends on selling the only compatible client.

Having the API not deliver unsupported content to clients that haven't registered for it would be better for devs than the apps explicitly setting filters, as I suggested in #20, although more work for the platform. If clients had to set their own filters then you couldn't prevent people from finding and reverse-engineering your messages to create compatible apps, so that probably shifts the balance to a server side solution for the benefit of developer business models.

Thoughts?

treygriffith commented 11 years ago

The idea of restricting posts by 'protocol' instead of app is interesting, and would definitely support a larger number of use-cases than authorizing app-by-app. For example if you had a direct video message app that supported embedded video, you would want to restrict by user, and by the 'video message' protocol, as opposed to only allowing one specific app to receive it.

There are certainly cases where you want to be sure that only your app can access the content, so I think the distinction between private and public protocols is important.

That being said, implementing different 'protocols' might lead to fragmentation.

stevestreza commented 11 years ago

@joecarney You could definitely build a private accounts system with this. Want a private account? Get an app that posts to a certain list of people. You could even have a hybrid account where some posts are public and some are private (a feature sorely lacking from Twitter today, which users solve by having two accounts, ugh). There would presumably have to be some sort of list management, and perhaps the access control API would accept the name of lists (and meta lists like "followers" and "following").

@markwilcox I'm not sure what the practical difference is between the protocols idea and restricting access to specific apps. The ideas aren't mutually exclusive either. But there are definitely apps which would want to be super explicit about which apps get to read their content. Cutting off access at the API level for those kinds of posts would be necessary.

markwilcox commented 11 years ago

@amazingsyco Agree that they're not mutually exclusive.

An example, consider I write a chess game. The notation is well known (at least there are some well known ones to choose from). If we make the protocol public then lots of people can write clients to play chess across multiple platforms. If the apps which are allowed to access posts which contain moves are fixed at post creation time then it's hard to add new apps, since it requires updating all the current apps to include the ID of the new app.

The limit case for this - what if I want to write a generic Session Initiation Protocol for establishing a direct TCP/IP connection between two clients?

If the list of which apps can access a particular type of post (will continue to call "protocol" from now on but that's just one suggestion) is managed on the server side rather than by the posting client then it can be added to (and removed from for misbehaving, or non-maintained and not supporting new protocol versions) apps dynamically.

Splitting things into protocols rather than purely by app also allows more re-use (hopefully of client code as well as protocols).

Developers could be allowed to create both public and private protocols on the server. For public protocols you'd need to publish an interface spec and anyone could register their app as supporting the protocol. For private protocols you could use them across several of your own apps, or share the details (and permission to read them) with select other developers.

duerig commented 11 years ago

It seems like adding 'groups' into this mix would be useful. First, from a user perspective being able to say "This set of users are my friends" and then "Send this message to just my friends" is very convenient.

From an API perspective, tagging a post as being available to a particular group name allows access control to that post be changed over time by adding or removing people from that group. Suppose I have an online diary that only my friends can access. I'd like to be able to retroactively allow a new friend to access all the posts in that diary. Or, contrariwise, revoke access to somebody who is no longer my friend. This extra layer of indirection allows that.

fields commented 11 years ago

This sounds like it's mixing permissions and capabilities filtering. They have similar semantics, but they're not the same. One benefit of a capabilities model for some of these decisions is that it would be up to the client what to do with the content. For example, a post with embedded video might be displayed inline in one client, but another client might just link to it, even though they are displaying a discrete stream of posts that have videos.

kristianfreeman commented 11 years ago

Yes. As I mentioned on App.net (@kristian there), this is fascinating and incredibly thought-provoking.

(my post) — @teawithcarl ... Why build to old use cases when we can make entire new ones? It's genius.

I'm not too familiar with APIs so I don't know the amount of work this puts on the dev team, but it's a splendid idea. I think there's something to be said for the consumer to know that the product they're investing in has a ridiculous amount of usage spread. Telling someone that they're investing in something that covers email, DM, Facebook, gaming, mailing lists and all sorts of whatever we can dream up with is insane.

I don't know how much my say is on this as just a user, but +1 here. So awesome.

markwilcox commented 11 years ago

@duerig I like groups. You could have user opt-in groups (like subscribing to a mailing list) and administered groups. With the latter you could build some enterprise apps that have more advanced user admin/management functions. Sounds like a more expensive funding tier too. :)

@fields Yes, I prefer a capabilities model to a straight permissions model, it's more flexible. Don't see any strong reason not to layer permissions on top though?

cmerrill commented 11 years ago

@markwilcox I think the default for groups should always be opt-in, even if the group is administered. There's quite a risk of user annoyance associated with allowing other users to add you to groups -- this should instead be delegated to the application level, if it comes up at all. Applications can communicate with each other to tell a user to try and join a group. Removing users is a more justifiable case, though, and needs to be controllable by the owner of the group.

duerig commented 11 years ago

@cmerrill Recall that posts will only show up in your stream if you are following another user. If they add you to a group, they are giving you the ability to view the posts tagged with that group. In order to actually see those post, you have to follow them (or otherwise go looking for them).

The question of who is allowed to access a post is (mostly) orthogonal from the question of who to deliver posts to.

Stephanie-Maks commented 11 years ago

I'm liking the sound of ACL as it's developing here. The outline in the OP sounds like a good place to start, and looks to be powerful enough to handle a wide variety of use-cases. FWIW I'm @stephanie on App.Net cheers!

fields commented 11 years ago

I think this would be maximally useful with both an 'allow/deny' matrix (permissions from the sender of the post determining who can see the post) and 'accept from' (filtering what the receiver wants to see in the stream). i.e.: if I'm following someone, I don't necessarily want to be following everything they do - maybe I just want their text posts but not their photos. If app.net is to be the fundamental building block for many services, there should be a way to filter on that easily, at the stream request level. It would also be nice if there was a way to support invitation requests (i.e.: user x who you aren't following wants to start a game with you), but it's hard to allow that without it quickly becoming spambait. There's definitely some challenge there.

duerig commented 11 years ago

fields, I think we want to carefully distinguish between access control and curation. There are several threads on app.net regarding what we've started calling #sentags (and see #sentagfaq too). These would be about tagging posts and filtering based on interest. This is a separate question from deciding who you want to allow to view your post. The set of people you allow to view your post will often be larger than the set of people who are interested in viewing it.

datariot commented 11 years ago

I agree with the need for ACLs (https://github.com/appdotnet/api-spec/issues/4#issuecomment-7515849). Having post level user/group privacy will open app.net to business customers and apps meant for private consumption.

fields commented 11 years ago

I think best when I can diagram this stuff. Here's a stab at arranging and simplifying some of the use cases:

https://www.evernote.com/shard/s11/sh/e602c63f-371d-4a5f-b3c5-dd5f08c66acf/5001e141a3b68d713f20128001504d1e/res/b3915f14-7faf-49a0-949b-fb56c9863e74/appnet_acl_flow_20120813.graffle-20120813-013100.png.jpg

Does this mesh with what you had in mind?

(Does github have a gist equivalent for sharing images?)

duerig commented 11 years ago

@fields I like your diagram. I would make two changes: First, I would say that tagged streams should still flow along the follower graph. I think that a user typically wouldn't subscribe to a global stream of all posts tagged 'funny'. They would instead follow posts tagged as 'funny' by a particular person they follow and whose sense of humor they enjoy.

Second, I'm not sure that 'Friend' should be a first-class entity and I would suggest that an abstract 'Group' of recipients would be a better first class entity.

Thanks for diagramming this. It definitely clarifies some things.

fields commented 11 years ago

I think that there certainly are lots of people who follow global tags regardless of who they're from. No reason tagged couldn't also be a subset of followers though. I'm not convinced that tags should go in with permissions - they may make more sense as a completely separate entity.

I actually think it makes sense that all of the visibility targets can either be an individual or a group. (Except public, which is only a group.)

JoshBlake commented 11 years ago

@fields Diagram link does not load. Try sharing via http://twitter.yfrog.com or dropbox.

fields commented 11 years ago

How about this? http://i.imgur.com/DNs1t.jpg

fields commented 11 years ago

I put up a new version with notes for groupings and tags (and removing tagged posts as top-level items). These are minor changes, but I think it does a great deal to clarify.

http://i.imgur.com/miQEa.jpg

JoshBlake commented 11 years ago

@fields I follow your logic; however, the diagram makes it seem like there would be a bunch of distinct post types. Maybe you're just thinking of the boxes as use cases, but either way it's unclear. The intended visibility would be a new post property that has a value of one or more of the following:

The named group option implies an API for setting up groups. Alternately the functionality could be implemented by clients if they could store groups as user-scoped metadata and using the ad-hoc list option.

A post's reply to would be a property as it is now, either it's a reply to another post or not. A reply could be public, private, etc.

With that, you could choose to make a G+ circles clone, or many more subtle interactions. For example, suppose I want to post:

Although it's interesting academically, I don't think making an exclusion list would work practically and would not be worth the effort. That feature would allow you to broadcast to the world (or logged in users) that @bojangles is a tool without letting @bojangles see the post, but there are many other ways he'd see it via reposts or replies or being logged out.

duerig commented 11 years ago

@JoshBlake Some tweaks:

Authorization fields (who is allowed to view a post):

The list of authorized viewers is the union of the list of usernames and the memberships of all the groups listed.

Filtering fields (used to create or filter posts of streams by clients):

The first set are specified by the creator of the post to determine who may read the post. The others are used by clients to determine if the user wants to read the post. It may be the case that a client will use some of the first fields to always allow DMs or messages to a group I'm subscribed to through, but that will be rarer.

fields commented 11 years ago

@JoshBlake Yes, it's meant to be use cases and not model closely to the underlying data model. I'm a little burned out at the moment (and getting late on the east coast) - I'll probably have some more thoughts tomorrow.

fields commented 11 years ago

I think if groups are not supported in the API and stored with the user's metadata, there will be a number of competing non-interoperable implementations. Differentiating features are one thing, but it'll be bad for the users if they move from one client to another and that data doesn't automatically transfer. I think that's a good litmus test for whether something should be in the API or not.

fields commented 11 years ago

To that point, it has always bugged me when IM clients don't store my contact groupings. Some systems support this, some don't. I prefer the ones that do.

JoshBlake commented 11 years ago

@duerig We still need a way to specify the type of post or intended audience type in terms of human, bot, or arbitrary string (e.g. app or protocol name).

There's actually three sides of the bot coin. (Roll a D3.)

  1. Human submitting posts readable by human followers.
  2. An authorized client app (a bot) submitting posts on my behalf on my account, not directly authored by me, readable by human followers. Might be paper.li type of stuff, or scheduled postings, or promotional posts like "I just scored over 9000 on GameApp!"
  3. An authorized client app (a bot) submitting posts on my behalf on my account, not directly authored by me, readable only by other bots or specific clients. The post may be encoded or obfuscated.

The bot-to-bot traffic could be many things:

All of the above would appear on my unfiltered stream as from @joshblake but that is a human account.

I think we need post type or intended audience in every post, in addition to or instead of account type on the account object.

fields commented 11 years ago

I think botness can be easily subsumed into a general tag implementation. Not all tags need be human settable by the user directly.

duerig commented 11 years ago

@JoshBlake I absolutely agree. I put that in the second list. But it is not a matter of access control, it is one of filtering. Bots may send traffic on users behalf but users are still allowed to view them if they choose. Most human-facing clients will filter out bot traffic.

JoshBlake commented 11 years ago

@fields Most likely correct. A general tag implementation can cover a lot of that; however, there would have to be a few well-known tags, like #BotReadable, that all clients should support filtering out by default.

JoshBlake commented 11 years ago

@duerig Yep, second list, and agree bots can certainly consume human posts (and vice versa for developers doing debugging or artists making visualization projects). I just needed to write out the ideas, but forgot all the different points I was responding to. ;)

fields commented 11 years ago

To be clear, I think that "tags", which is probably a bad name, covers both user tagging and also any general name/value pair metadata where the name/value pairs are not defined in advance. I've usually referred to the former as "folksonomy" and it's usually stored separately or at least in a separate part of the tags hierarchy. (Yes, I also think it makes sense to have a parent structure for tags.) This can get confusing, and I certainly don't expect people to manage it by themselves; it's mostly for application support of flexible and extensible metadata.

duerig commented 11 years ago

@fields I agree with you about the idea of general tags with the exception that they should be name/value/user triplets. This way user attribution is a fundamental part of the architecture. Even if a client adds tags, it does so on behalf of a particular user.

fields commented 11 years ago

For sure - I don't even know what it would mean for an application to add a tagging without a user attached to it. That user would presumably be identified by whatever auth token was used to validate the tagging request.

extremeboredom commented 11 years ago

@JoshBlake Thinking about the different types of traffic you've discussed above; I'm wondering about the kind of permissions that users grant to apps.

If I play a game that takes advantage of the App.Net infrastructure, I may not want to grant it permission to post human-targetted content. Is there a granular enough permissions system to permit this right now?

jschlesser commented 11 years ago

Filters used on the inbound route of a post could work like ACL. I put some ideas down on issue #69 https://github.com/appdotnet/api-spec/issues/69 I would like to see a few maximally useful constructs in the api overall. If filters could work for ACL, that would reduce the number of things we have to learn.

shawnhooper commented 11 years ago

@extremeboredom I believe the implemented modeled here does support that level of control.

I could also see a hybrid, where an application, for example a game, could be handling bot-bot communications (game control), but also have human readable content (player-to-player chat) that should only be visible in the context of that application.

markwilcox commented 11 years ago

@extremeboredom That's a tricky one. For example what about in-game chat, or sending an invite with a link to download the game? Might be better to police that with a delete feature and reporting apps that abuse their message posting capability. Currently there are no permissions for this but I don't know if adding them is a good idea or not.

extremeboredom commented 11 years ago

@shawnhooper I could easily have missed it, but it seemed to me like everyone here was discussing the visibility of particular posts; not whether a particular client would be allowed to create specific types of posts.

jschlesser commented 11 years ago

@extremeboredom thinking of user experience it might be nice to not have users manage tons of permissions and apps be able to make "the right thing happen". I don't actually want to manage any permissions, I would like the ability to change things if necessary, but would like apps to make reasonable decisions by default. The burden shouldn't be on users. Such as I don't need to read low level app messaging messages for things like games. User Grant needs to be higher level so that Users can Grant permissions to do the right thing.

extremeboredom commented 11 years ago

@markwilcox I can see what you're saying; the thought has crossed my mind too. I'm just thinking about things that might make me cautious about allowing an application access to my App.net account. In general I don't allow applications access to my Twitter account for this kind of reason, but since App.net is intended as infrastructure I know I'm going to have to be a bit more open with my account. I don't necessarily want that to evolve into lots of applications having the ability to post on my behalf.

extremeboredom commented 11 years ago

@jschlesser I can definitely understand where you're coming from with that, I don't want to micromanage my permissions either. But I think I would be more comfortable with opening up to more apps if one of the OAuth permissions were 'Post Bot Messages', instead of always 'Post Messages on my behalf'.

fields commented 11 years ago

The question of which apps are allowed to generate what kinds of posts is an interesting one. Some will want interoperability while some will not want other apps injecting messages into "their" stream. e.g.: if you're scrabble, you probably don't want words with friends to have the ability to let users attach to your games and make moves, even if they technically could. But if you're a photo sharing service, maybe you don't care what client people are using.

JoshBlake commented 11 years ago

@extremeboredom That's a great point, although as others replies it's not as clear cut. I think that differentiating between (based upon my comment above):

  1. Can create posts from me. (Human readable post authored by me. twitter-like client apps would need this.)
  2. Can create posts from the app to human followers. (Human readable post submitted by a bot/client and not authored by me. Games or auto-posters could use this for announcements, invites, shown in my stream but obviously from the app.) Maybe shows up as "@chessapp (on behalf of @joshblake)"
  3. Can create posts from the app to other apps. (Bot readable posts submitted by bot/client intended for other bots/clients.)
jschlesser commented 11 years ago

The problem i see is with context and intent and understanding. When i first go to authorize an app, i dont understand if it needs bot access or not, i must trust that it does if i want to use the app. It would be much more helpful if the app told me what it was going to do and why rather than the technical permissions it wants. It just gets worse when the user is my mom. Second, what is my recourse? Grant only some of the permissions or just not authorize the app at all? Im not saying i have an answer but i think this is an area where app.net could lead in making this work for most people most of the time and be understandable by my mom. Most people will just click yes when they dont understand. They just want to play words with enemies.

On Aug 14, 2012, at 10:10 PM, extremeboredom notifications@github.com wrote:

@jschlesser I can definitely understand where you're coming from with that, I don't want to micromanage my permissions either. But I think I would be more comfortable with opening up to more apps if one of the OAuth permissions were 'Post Bot Messages', instead of always 'Post Messages on my behalf'.

— Reply to this email directly or view it on GitHub.

markwilcox commented 11 years ago

Being a paid developer platform, I think app.net might have a better mechanism for managing misbehaving apps than permissions. Why not simply have developers provide a description of what their app does/doesn't do to/with your account before you authorise it. If you don't like it, don't authorise it. Apps that do things which aren't in their description can be reported and removed from the network - badly offending or repeat offending developers get kicked out the developer tier.

Community policing is probably going to work a lot better than technical measures to keep apps honest. I think this issue is starting to balloon into a very broad discussion though! :)

jschlesser commented 11 years ago

I like this better. Its more sane for users and reflects how most people think of apps. Share photos with everybody vs share with family should be in the app and presented that way, allow app bot access doesnt mean anything to me.

On Aug 14, 2012, at 10:35 PM, Mark Wilcox notifications@github.com wrote:

Being a paid developer platform, I think app.net might have a better mechanism for managing misbehaving apps than permissions. Why not simply have developers provide a description of what their app does/doesn't do to/with your account before you authorise it. If you don't like it, don't authorise it. Apps that do things which aren't in their description can be reported and removed from the network - badly offending or repeat offending developers get kicked out the developer tier.

Community policing is probably going to work a lot better than technical measures to keep apps honest. I think this issue is starting to ballon into a very broad discussion though! :)

— Reply to this email directly or view it on GitHub.

extremeboredom commented 11 years ago

You could allow for optional and required access, e.g. a chess game might require app to app posting to work, but optionally can use app to human posting if you want to post your scores. It does make things more complicated though.

My worry is that I'm going to give positing permissions out to a massive bunch of apps, and then one of the apps is compromised and suddenly your entire App.net stream is controllable by others. A lot of damage could be done in a short time like that. Maybe I'm just being paranoid though.