The importance is a bit arbitrary. From the security point of view,
there is really no benefit in having this feature.

However, there is a real case for it, because service providers might
have some guidelines on where the application keys can appear and where
they cannot: I recall Ken telling me that Twitter was unhappy about
having the application keys visible in the Gwibber's source code, and
just moving them to the debian/rules files made them happier. It's
illogical, but it can happen.

There is anyway another reason why this feature is needed: in some
cases, authentication parameters are known only at run time, and
therefore cannot be encoded in any static file. The example (and the
reason why I hurried to fix this bug) is UbuntuOne, whose "TokenName"
parameter is based on the device's hostname, which is changeable.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-api in
Ubuntu.
https://bugs.launchpad.net/bugs/1554040

Title:
  Allow hiding authentication data in scope binary

Status in unity-scopes-api package in Ubuntu:
  In Progress

Bug description:
  The current scope API doesn't allow the developer to specify the OAuth client 
keys at runtime, they must reside in the .service files which end up installed 
on the filesystem.
  Some people are concerned about exposing their API keys, and would rather 
embed them in their scope binary and specify them at runtime. While 
acknowledging that this will actually not improve the security, this 
possibility is offered by all other Online Accounts APIs, and it would be nice 
if scopes offered this too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1554040/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to