launchpadlib

Bug #532055
Comment #23

Comment 23 for bug 532055

Revision history for this message

Gary Poster (gary) wrote on 2010-03-29: Re: Trusted credential-management apps are broken and doomed

#23

Jonathan: yes, option 1 ("Enabling a desktop application that would handle authentication and would be another way for users to allow third-party apps to access their LP data").

Martin Owens: I believe you are arguing that some variant of option 1 might be designed in such a way to be much better than a marginal improvement from the perspective of non-programmer end-users. If so, I agree. However, I don't really matter in that regard.

As I've said before, I'm willing, even happy, to push its priority up if it gains enough steam among the developers of launchpadlib-based desktop applications.

Note that re-enabling password authentication is not an option at this time--within a week, we won't even have access to the passwords.

Here's what I think needs to happen for all interested parties.

- identify each other (all launchpadlib users for user-facing desktop GUI apps)
- advance your ideas and work with the Launchpad team and the other developers to come up with a plan that gets buy-in both from the Launchpad team (for design of the server-side changes) and the other developers (so that the Launchpad priority is raised).
- Pursue more formal buy-ins. This would be the time to get the DUX team involved, for instance.

At the moment, the only workable option I've heard is "option 1."

I'll close with some random thoughts.

Martin Owens, maybe it would be helpful to sketch out a more concrete picture of your desired user interaction, as you try to sell this idea to other devs? From my perspective, we need to have a one-time browser approval of the auth-management desktop application. Maybe an embedded browser would be possible, and an improvement from the desktop perspective over launching a browser in a separate window? Then it might be nice for a given application to be able to ask the auth-management desktop application for one or more specific permissions, so that the user has to think less (e.g., instead of radio buttons to decide what permissions the program has, there's simply a description of the requested permissions and "yes" or "no"). The importance of the auth-management application in subsequent authentication requests is that it deliver the Launchpad security descriptions clearly and authoritatively, so showing that would be essential in a sketch.

Another thought: the client-side application itself would be something that Launchpad supports, rather than develops, so whether it would be limited to Ubuntu or developed cross-platform is only something of indirect importance to me. That said, on the one hand, we are primarily about supporting Ubuntu and its development, so being limited to that platform does not strike me as a significant disadvantage in many cases. On the other hand, the client-side application could certainly be developed cross-patform, if the developers so desired.

Jonathan: yes, option 1 ("Enabling a desktop application that would handle authentication and would be another way for users to allow third-party apps to access their LP data").

Martin Owens: I believe you are arguing that some variant of option 1 might be designed in such a way to be much better than a marginal improvement from the perspective of non-programmer end-users.  If so, I agree.  However, I don't really matter in that regard.

As I've said before, I'm willing, even happy, to push its priority up if it gains enough steam among the developers of launchpadlib-based desktop applications.

Note that re-enabling password authentication is not an option at this time--within a week, we won't even have access to the passwords.

Here's what I think needs to happen for all interested parties.

- identify each other (all launchpadlib users for user-facing desktop GUI apps)
- advance your ideas and work with the Launchpad team and the other developers to come up with a plan that gets buy-in both from the Launchpad team (for design of the server-side changes) and the other developers (so that the Launchpad priority is raised).
- Pursue more formal buy-ins.  This would be the time to get the DUX team involved, for instance.

At the moment, the only workable option I've heard is "option 1."

I'll close with some random thoughts.

Martin Owens, maybe it would be helpful to sketch out a more concrete picture of your desired user interaction, as you try to sell this idea to other devs?  From my perspective, we need to have a one-time browser approval of the auth-management desktop application.  Maybe an embedded browser would be possible, and an improvement from the desktop perspective over launching a browser in a separate window?  Then it might be nice for a given application to be able to ask the auth-management desktop application for one or more specific permissions, so that the user has to think less (e.g., instead of radio buttons to decide what permissions the program has, there's simply a description of the requested permissions and "yes" or "no").  The importance of the auth-management application in subsequent authentication requests is that it deliver the Launchpad security descriptions clearly and authoritatively, so showing that would be essential in a sketch.

Another thought: the client-side application itself would be something that Launchpad supports, rather than develops, so whether it would be limited to Ubuntu or developed cross-platform is only something of indirect importance to me.  That said, on the one hand, we are primarily about supporting Ubuntu and its development, so being limited to that platform does not strike me as a significant disadvantage in many cases.  On the other hand, the client-side application could certainly be developed cross-patform, if the developers so desired.