ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

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 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.

> 
> 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.

Marc.