On 06/14/2013 01:02 PM, Martin Albisetti wrote: > 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? > Well, Marc's point isn't to make it difficult-- we should allow for it and it should be easy for a developer to opt into; it's just that we we can't control if OEMs disable it or if movie providers will require us to disable DRM when in insecure mode.
-- Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- 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
