ubuntu-appstore-developers team mailing list archive
-
ubuntu-appstore-developers team
-
Mailing list archive
-
Message #00673
Re: Disallowing custom namespaces
On 13-10-17 08:50 AM, Jamie Strandboge wrote:
> 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 don't think removing it is helpful either...it's in the filesyste, etc.
>
> 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.
Facebook can simply use com.facebook.app2.
If they really want to make a stink about it, sure, we can revoke the app, and
say the developer didn't respect the trademark provision in the terms of use,
and now com.facebook.app is blacklisted, and facebook simply needs to use
com.facebook.app2, just like what happens on other platforms.
Using a reverse domain isn't a new problem...it's what's used basically
everywhere right now, even in Ubuntu with java apps, gsettings, dbus, etc.
>
> 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
>
This implies you only want single developers in your appstore, and not
companies. I'm not sure facebook is going to want
com.ubuntu.developer.joeemployee.facebookapp, and even for my own app, I'll want
to use my own domain.
Marc.
Follow ups
References
-
Disallowing custom namespaces
From: Martin Albisetti, 2013-10-10
-
Re: Disallowing custom namespaces
From: Marc Deslauriers, 2013-10-10
-
Re: Disallowing custom namespaces
From: Thomas Voß, 2013-10-14
-
Re: Disallowing custom namespaces
From: Michael Nelson, 2013-10-14
-
Re: Disallowing custom namespaces
From: Jamie Strandboge, 2013-10-15
-
Re: Disallowing custom namespaces
From: Martin Albisetti, 2013-10-16
-
Re: Disallowing custom namespaces
From: Marc Deslauriers, 2013-10-16
-
Re: Disallowing custom namespaces
From: Martin Albisetti, 2013-10-16
-
Re: Disallowing custom namespaces
From: Michael Nelson, 2013-10-17
-
Re: Disallowing custom namespaces
From: Jamie Strandboge, 2013-10-17