I think Robert is also write that this should have been a list thread and LEP before it was a branch. But thanks for posting now. Use the dev wiki or a branch, not a pastebin!
> The ultimate purpose of this branch is to stop third-party developers > from writing horrible hacks that bypass the OAuth token authorization > protocol. These people are my customers. I can't stop them through > technical means, any more than music companies can stop *their* > customers from sharing songs with each other. But I can get my > customers back on my side, by improving the experience of the > "legitimate" alternative. I'm so glad you look at it that way. There are some snags in the api client experience at the moment but I don't feel authorizing new clients is top of the list. There aren't that many different clients, and I suspect there's a steep tail-off in the number of different programs any single person uses. I think making the first use of apport or of quickly smooth is far more important than the incremental burden of authorizing the 10th client. It may be a matter of fact that the desktop is a single security context but I don't think we should design for that unless it gives us a big benefit - and for the reasons above, I don't think the potential win is all that big. Kees puts it better than I could. One of the main innovations of Chrome is breaking a single desktop app into multiple security contexts... By analogy to browsers and web apps users _may_ want to say "allow access for this session but don't save the token", which should be easy to implement in the apps. I expect some of the more security-conscious developers would take that option. You touch on something like this around <http://pastebin.ubuntu.com/499131/> line 188, but that's contemplating having the token expire on the server. That's useful, but having the client just discard the token is useful too, and avoids problems with it expiring while the app is still running. I realize both the APIs and the security model need to be general but I do think there is something to be learned from looking at what specific applications need to do. Apport, for instance, needs to upload crash data and mark it private. It doesn't need to read any other bugs(?) and it doesn't need to see private data(?) other than in the course of writing it. Yet it ends up getting very broad access. I don't know if we want specific knowledge about apport in Launchpad, but perhaps we can make something that fits smoothly: the right to "create a new private bug with attachments" probably only has the risk of spam/dos attacks and is far less scary than "read/write private data." > For instance, my computer would beauthorized as "Ubuntu Desktop (remora)". Clearly the most important use case is Ubuntu desktops, but Ubuntu runs on things that aren't desktops (in either the hardware or the gui sense of the word), and we have important Launchpad developer users who aren't on Ubuntu. Perhaps this is just a matter of naming, and of separating out the general approach from how it's done with GNOME Keyring etc. > * OK, give Quickly access to my Launchpad account for fifteen minutes. "access to my account" is a bit vague; perhaps you should say "Let Quickly change my security credentials." We previously discussed sending mail after the change, which I presume you would still do. In some ways it would be cleaner and safer to let Quickly just propose the change through its regular access level, but require the user accept the change through the web ui or through email before it takes effect. As a matter of fact the desktop is some senses a single security context, but I don't draw the same conclusion that we should just jump right in to it. I think the implementation would go faster and in smoother steps if some of this happened as either libraries that clients could use or standards for how they should behave. For instance, if we do want one token per machine, let's just document it goes into ~/.local/private/launchpad/token or whatever. How about a reusable gtk dialog to run a captive browser, or to ask if you want to save the token for later use? Solutions to launchpadlib security that mandate writing new client processes seem conceptually wrong to me: it's a web service and we should be more often recommending patterns for clients than mandating implementation. -- Martin _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
