960221 - Make package names unique by manifest URL for APK Factory

Status: RESOLVED FIXED

(Marketplace Graveyard :: Integration, defect)

Description

[Austin King [:ozten]]

Moved from https://github.com/mozilla/apk-factory-service/issues/5

For packaged apps on our Marketplace, we take the manifest URL and turn them into Java Packages.

We must guarantee that these package names are globally unique between apps, since this is a fundamental aspect of how Android apps are organized.

We should have some unit tests for this piece of code.

Comment 1

[Austin King [:ozten]]

Current behavior:

http://people.mozilla.org/~fdesre/openwebapps/package.manifest becomes
org.mozilla.people.openwebapps.xfdesre


http://deltron3030.testmanifest.com/manifest.webapp becomes
com.testmanifest.deltron3030


Proposed behavior:

Take subdomain and make reverse package name. Take the SHA1 of the manifest URL and prefix it with the character p.

Example:
org.mozilla.people.p14e70b4b60353001e4b049fec7bbf3a3c7d807cf
com.testmanifest.deltron3030.p3e51918e6347b2e7fb48a9cf99ad32ca45992135

Does this work? CCing jhugman and myk.

Comment 2

[Austin King [:ozten]]

Actually, will use MD5 for less egregious package names.

Comment 3

[Austin King [:ozten]]

https://github.com/mozilla/apk-factory-service/pull/35

Comment 4

[Myk Melez [:myk] [@mykmelez]]

(In reply to Austin King [:ozten] from comment #1)
> Current behavior:
> 
> http://people.mozilla.org/~fdesre/openwebapps/package.manifest becomes
> org.mozilla.people.openwebapps.xfdesre

Hmm, I would have thought it would become org.mozilla.people.xfdesre.openwebapps.


> Proposed behavior:
> 
> Take subdomain and make reverse package name. Take the SHA1 of the manifest
> URL and prefix it with the character p.
> 
> Example:
> org.mozilla.people.p14e70b4b60353001e4b049fec7bbf3a3c7d807cf
> com.testmanifest.deltron3030.p3e51918e6347b2e7fb48a9cf99ad32ca45992135
> 
> Does this work? CCing jhugman and myk.

I think it works, although I'm not sure it's optimal.

The key requirement is that the package name be unique across both webapp and native app namespaces, of which the latter is the greater concern, because a developer with the website my.example.com might well build a webapp and host it at my.example.com/manifest.webapp, which currently gives it the package name com.example.my, while also building a native app whose package name is com.example.my.

For that reason, blassey has suggested appending something like ".webapp" to all package names the APK Factory generates, so the webapp in the previous example gets the name com.example.my.webapp, which the developer is unlikely to reuse for their native app.

The hash of the manifest URL would also work, and we do something similar to ensure uniqueness of data directories in the desktop runtime (f.e. <http://hg.mozilla.org/mozilla-central/file/bfe4ed6d47ce/toolkit/webapps/WebappsInstaller.jsm#l283>).  But it sure is ugly. ;-)

And note that it doesn't provide a greater guarantee of uniqueness across the native app namespace than simply appending a part like "webapp".  Either way, a developer *could* still cause a namespace collision deliberately by giving their native app that package name.

(A related concern is package name squatting, whereby a malicious third-party deliberately creates a native app with the same package name as a webapp and uploads it to a native app store, preventing the developer from uploading the APK for their webapp to that store.  I don't think this proposal affects that possibility one way or the other.)

FWIW, Android package names follow the "same rules as packages in the Java programming language," according to Android's introductory tutorial <http://developer.android.com/training/basics/firstapp/creating-project.html>, which are described on the "Java package" Wikipedia page <http://en.wikipedia.org/wiki/Java_package#Package_naming_conventions>.

In any case, jhugman is the better person to give input here, as he has more context on the reasoning behind the current naming scheme.  So requesting info from him.

Comment 5

[Austin King [:ozten]]

A package name containing the hash is ugly, but has a better chance of being unique as well as harder to maliciously "package name squat" on.

If I publish these two apps:
http://ozten.com/foo.webapp
http://ozten.com/bar.webapp

Then just adding ".webapp" to the package name isn't sufficient, you'd end up with the same package name "com.ozten.webapp".

Comment 6

[James Hugman [:jhugman] [@jhugman]]

The package squatting problem is made easier by needing to be in control of the server.

com.ozten.foo.webapp and com.ozten.bar.webapp could never be squatted on by someone who is not in control of ozten.com. 

Similarly, on hosts which have their own namespaces (e.g. ozten.github.io or github.io/ozten) is ok.

The ones I can't fix are packaged apps that come from the FF marketplace, which all come from the same domain, but vary by query.

In answer to the question: will using a hash as part or all of the package name work? Yes. Is it desirable? No.

Comment 7

[Austin King [:ozten]]

The hash based approach is available at
https://github.com/mozilla/apk-factory-service/pull/35

Can we document the desirable algorithm for generating package names here? Happy to build it.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

(In reply to Austin King [:ozten] from comment #5)
> A package name containing the hash is ugly, but has a better chance of being
> unique as well as harder to maliciously "package name squat" on.

It does have a slightly better chance of being unique, since developers are unlikely to choose it by accident; but it's only trivially harder to maliciously squat, since it's easy to regenerate the name (or simply copy it from the legitimate package).


> If I publish these two apps:
> http://ozten.com/foo.webapp
> http://ozten.com/bar.webapp
> 
> Then just adding ".webapp" to the package name isn't sufficient, you'd end
> up with the same package name "com.ozten.webapp".

Currently, you can't publish two apps on the same origin, due to the unique origin restriction; so these manifests are considered to represent the same app, and if you install both, then the second install will update the first.

However, we intend to remove that restriction eventually.  And even with it in place, http://ozten.com and https://ozten.com are different origins.  So I see the value in a package name generation algorithm that ensures uniqueness, even if it's only across the webapp namespace.

But jhugman is more familiar with Java/Android package naming conventions and issues, so I'd like to get his input (which I see he's now provided!).

Comment 9

[Austin King [:ozten]]

Okay, I'm blocked. Please advise.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

(In reply to Austin King [:ozten] from comment #9)
> Okay, I'm blocked. Please advise.

Since multiple people have identified cases where names clash, and no one has proposed a better solution (or any other solution, for that matter), go ahead and implement the hash-based one!

Comment 11

[Austin King [:ozten]]

Thanks! Merged.

Will deploy soon, which may cause some issues with updates for existing apps. I'll ping #mobile as a heads up.