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