ubuntu-appstore-developers team mailing list archive
-
ubuntu-appstore-developers team
-
Mailing list archive
-
Message #00674
Re: Disallowing custom namespaces
On 10/17/2013 08:15 AM, Marc Deslauriers wrote:
> On 13-10-17 09:06 AM, Jamie Strandboge wrote:
>> On 10/17/2013 06:30 AM, Marc Deslauriers wrote:
>>> On 13-10-17 03: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).
>>>
>>> But now you get back to the issue of having name collisions, which allowing the
>>> developer to pick their own namespace, as on android, solves.
>>>
>>> If you tie the application namespace to the developer username, you then can't
>>> have the possibility of an application moving between developers without the
>>> user losing all their settings.
>>>
>>> For example, forcing com.ubuntu.developer.joeemployee.facebookapp instead of
>>> allowing com.facebook.facebookapp means that when Joe Employee is no longer a
>>> Facebook employee, the app can't be migrated to a new account without losing
>>> user data.
>>>
>> This is a different problem and one that I think is either already or is about
>> to be solved. It doesn't have to be tied to an individual username and teams are
>> able to upload to a namespace. Eg, all the webapps are setup for this now:
>> com.ubuntu.developer.webapps.webapp-amazon_webapp-amazon_1.0.6
>> com.ubuntu.developer.webapps.webapp-ebay_webapp-ebay_1.0.8
>> com.ubuntu.developer.webapps.webapp-facebook_webapp-facebook_1.0.5
>> com.ubuntu.developer.webapps.webapp-gmail_webapp-gmail_1.0.7
>> com.ubuntu.developer.webapps.webapp-twitter_webapp-twitter_1.0.5
>> com.ubuntu.developer.webapps.webapp-ubuntuone_webapp-ubuntuone_1.0.4
>
> So now you get back to the problem of having to validate team names. Can I
> register 'facebook' as a team?
>
> If you have to validate a 'facebook' team, you can simply validate a
> 'com.facebook' namespace.
>
I'm saying we don't have to validate the facebook team because it isn't in their
namespace. This allows us to more easily give out com.facebook to facebook the
company when we support that.
>>
>>> I don't see why this is a problem for us, but isn't for other platforms.
>>>
>> I can't say either way if it is a problem on other platforms-- they've also been
>> around a lot longer and perhaps have internal/manual policies and procedures
>> that have developed over time to deal with this sort of thing (I don't know). I
>> know that people and companies will be bent out of shape if they encounter
>> namespace collisions in the appstore, because that is human nature.
>
> There are numerous namespace collisions on android right now. The namespace
> isn't meant as a security measure or an identity measure. If someone takes
> com.facebook.app, then facebook can take com.facebook.goodapp.
>
I don't think it is a security measure. It also isn't a meaningful identity
measure, but I maintain that people perceive it as such (rightfully or not--
some in the store now are certainly using their own domain because they feel it
is). When I see com.facebook.app vs com.facebook.goodapp, I can't help but feel
this is a deficiency in android.
>>
>> Beyond that, I can think of other interesting situations. Suppose a carrier
>> wants to preinstall something on Ubuntu Touch. Eg, com.carrier.billing-app. This
>> is installed in /usr/share/click/preinstalled and everything is fine-- until
>> some decides to upload a trojaned app to the app store that is also
>> com.carrier.billing-app. Users get the 'upgrade' installed (into /opt) and are
>> no longer using the preinstalled app. Sure, we can have policies around how to
>> handle this, etc, etc, but wouldn't it be easier to just avoid scenarios like
>> this altogether (at the very least while we are bootstrapping the system)?
>>
>
> We validate namespace uniqueness. As on other platforms, if the carrier didn't
> register the namespace with us, they're out of luck.
>
Or we can provide a system where we avoid the problem altogether.
--
Jamie Strandboge http://www.ubuntu.com/
Attachment:
signature.asc
Description: OpenPGP digital signature
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: Marc Deslauriers, 2013-10-17
-
Re: Disallowing custom namespaces
From: Jamie Strandboge, 2013-10-17
-
Re: Disallowing custom namespaces
From: Marc Deslauriers, 2013-10-17