launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

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