ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 10/17/2013 02:27 AM, Michael Nelson wrote:
> On Wed, Oct 16, 2013 at 11:54 PM, Martin Albisetti
> <martin.albisetti@xxxxxxxxxxxxx> wrote:
>> On Wed, Oct 16, 2013 at 6:38 PM, Marc Deslauriers
>> <marc.deslauriers@xxxxxxxxxxxxx> wrote:
>>> We care what it looks like, we just aren't going to enforce it until it becomes
>>> a problem.
>>>
>>> Isn't it already hidden?
>>
>> Yes to the user, no to the developer. Which is why it feels odd making
>> the developer decide about something that isn't really user visible.
>>
> 
> +1 for removing the unnecessary decision for the moment. Given that we
> haven't (yet) implemented an automated verification of the domains,
> let's not let devs choose (and communicate) them unnecessarily.
> Automatically assigning com.ubuntu.developer domains would seem to
> sanest option and create the least work right now (as it avoids the
> possibility of reaching a problem that we need to clean-up and start
> enforcing).
> 
> IMHO, enabling people to choose com.google.whatever is only going to
> lead to pain later. It really is user-visible information at the
> moment, as per Jamie's Permy app - "Easily see the permissions of your
> apps with Permy. Includes viewing the policy vendor, policy version,
> template, groups, APP_ID, and more." which will help people decide
> whether they are comfortable with the permissions of an app.
> 
Well, I don't think removing it from Permy is particularly helpful because the
APP_ID is used *everywhere* just under the hood. Permy doesn't list the APP_ID
(which contains the reverse domain) because that is security relevant-- it lists
it so people can find the apparmor profile name as used by the system.

I'm not sure I agree that if we allow picking any domain that we shouldn't put
limitations on that. Reverse domains imply ownership regardless of if they are
user visible or not (perceived or otherwise). I know that I would be a bit
miffed if someone published something in a domain I owned when they didn't have
any affiliation with my domain. Doing no checks opens it up to potential
problems down the line as well as abuse. Eg, a well-intentioned person writes a
facebook app and uses com.facebook.app. Now, facebook, the company, wants to use
com.facebook.app for their app and we'd like to comply with their request, so
then what? Either we cannot help facebook the company, which seems rather
unprofessional, or we try to migrate users. For users that installed the first
one, directories and files are on the filesystem associated with the first that
are not with the second and we somehow have to migrate people from one to the
other, potentially losing data from the first in the process. Sure, we could
yank the app out of the store or forcibly change the name, but this developer
was well-intentioned-- it would be bad for this developer as well as the first
app's users be in this sistuation at all. As cool as having a personalized
normally-non-user-visible APP_ID might be for developers, it would be *so* much
easier if we could just avoid this problem altogether.

What if we simply had people use com.ubuntu.developer for everything for now--
the scripts could warn/error on any domain that is not that (obviously if we
change now we need to consider existing namespaces). Then in the future if
demand warrants it, we could have some sort of form for people to request
something different with processes in place to somehow manually verify the
request. Server side automated checks would augment the simple 'is not
com.ubuntu.developer' to also check whatever server side database that stores
vetted domains. Eg:
if domain.startswith('com.ubuntu.developer.'): # check username and appname too
  pass
elif was_manually_verified(domain):
  pass
else:
  fail

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature