On Wed, Jun 12, 2013 at 6:58 PM, Jamie Strandboge <[email protected]> wrote: > On 06/12/2013 04:25 PM, Martin Albisetti wrote: >> On Wed, Jun 12, 2013 at 4:57 PM, Marc Deslauriers >> <[email protected]> wrote: >>> >>> I'm pretty sure some carriers will force us to remove option #3, and >>> some movie providers will force us to disable DRM when #3 is used. >> >> Why? >> On Android that's only the case if you root the device, where apps can >> go beyond their confinement. Installing unrestricted confined apps >> shouldn't affect DRM, right? > > This is actually an interesting question. Consider that: > > * click packages must have a manifest file to successfully > install > * the manifest file must define valid security accesses to > successfully install > > I think Martin's point (and one I've heard echoed elsewhere) is that if > both of the above work correctly, the worst an unsigned app can do is be > installed with the widest permission set that we allow. The argument > goes that those permissions won't include access to ~/.gnupg or direct > access to ~/Videos, so the app can't attack the whole system or upload > one's movie collection. > > In a lot of ways, this is a valid argument because we will define our > policy for the APIs we expose around SDK-apps such that the app review > process can likely be highly-automated. This will work well enough in > the short term since click packages will initially only use these APIs. > > The problem comes when we are trying to ship click packages for things > not developed with the Ubuntu SDK. Eg, thinking about the converged > device, if we ever try to ship LibreOffice as a click package, it is > likely going to need different types of access than our pre-defined > policy will provide. The security accesses in the manifest file may need > to be extended in such a way as to provide wider access (eg, read/write > access to large portions of $HOME). On upload to our appstore, we can > flag packages with these extended access permissions for manual review > before making them available in our trusted appstore just fine. The > problem comes in that if the security manifest file allows for this > flexibility and the user disables hash verification it necessarily means > that when the user installs a click package from outside the trusted > appstore, the security manifest could specify very lenient permissions > such that the application effectually runs unconfined (ie, it is able to > upload the user's entire movie collection to some server).
This makes a lot of sense. Thanks for the explanation. I worry that we'll be making it harder to sideload apps on the ubuntu phone than on android, but, I guess, people will still be able to install debs and provide the root password? -- Martin -- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
