Closed Bug 883185 Opened 11 years ago Closed 11 years ago

Verify domain ownership for packaged app origins

Categories

(Marketplace Graveyard :: Developer Pages, defect, P2)

Product:
Marketplace Graveyard
Component:
Developer Pages
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: robhudson, Unassigned)

References

Details

The Marketplace should verify domain ownership for packaged app origins in some way to avoid anyone "taking" an origin. Origins are unique. Packaged apps specify an origin in the manifest in the zip file. Since the zip files are uploaded to marketplace we have no proof that they own the domain they claim as their origin.
This sounds like a bug for adora.
(In reply to Matt Basta [:basta] from comment #1) > This sounds like a bug for adora. We'll need to do this programmatically, similar to how google does it (text file on the domain, DNS, etc.)
Priority: -- → P2
Google provides 3 options, which seem like a generally good approach for various use cases. Would we want to implement each of these? Should we file separate bugs? 1. Add a TXT record or CNAME to DNS. We can probably verify this by shelling out to `dig` or other DNS tool. E.g. `dig -t TXT google.com +short`. 2. Add a specifically named HTML file on the server of the domain being verified. We can verify this by using requests and ensuring it is a 200 response. 3. Add a <meta> tag to the <head> section of your website's home page. We can verify this using requests and parsing the HTML and ensuring it matches the meta tag values we provided to the user. In the devhub I imagine that we would detect that a packaged app was uploaded which specified an origin in the manifest, which would trigger an extra domain verification step somewhere. The developer could choose one of the above methods. Once chosen, we would need to periodically check to verify giving time for things to propagate or caches to clear. Should domain verification block the approval of the app? Or the review process itself? If we have this functionality should we also do it for hosted apps as well?
My first inclination is to say this check shouldn't block submission, at least for apps using the DNS method, since the app will likely be waiting a few days before a reviewer looks at it, anyway. Just make sure the developer's aware that if the verification doesn't pass by the time we go to review the app, it'll be rejected. For hosted apps, isn't verification of domain ownership already covered by setting the content-type for manifest files?
Since the origins that you're allowed to specify are app:// origins, do we really care what they're allowed to be? If someone takes app://twitter.com, there's nothing stopping twitter from taking app://twitter or app://twtr or anything else. The "domain" in the origin field doesn't correlate with real domain names in the real world, it's simply a namespace.
(In reply to Matt Basta [:basta] from comment #5) > Since the origins that you're allowed to specify are app:// origins, do we > really care what they're allowed to be? If someone takes app://twitter.com, > there's nothing stopping twitter from taking app://twitter or app://twtr or > anything else. The "domain" in the origin field doesn't correlate with real > domain names in the real world, it's simply a namespace. Packaged app origins are required to be unique on device, so it seems worthwhile to avoid a case where a non-official twitter app takes the app://twitter.com origin. I thought it wasn't simply a namespace and that the domain is or can be used for other things, like the audience for Persona logins, or opening up some extra permissions for XHRs to this domain.
(In reply to Rob Hudson [:robhudson] from comment #6) > Packaged app origins are required to be unique on device, so it seems > worthwhile to avoid a case where a non-official twitter app takes the > app://twitter.com origin. I think this is really a non-issue in the same way that a Java JAR file could have the namespace "com.twitter.foo". Making sure they're unique is one thing, but proving that Twitter produced it isn't really necessary or relevant as long as the JAR does its job. > I thought it wasn't simply a namespace and that the domain is or can be used > for other things, like the audience for Persona logins, or opening up some > extra permissions for XHRs to this domain. You unfortunately don't get any XHR permissions (you still need to request the systemXHR privilege to make un-CORSed requests). The origin is really only used to allow the app to identify itself and verify a server response. For instance with Persona, the origin is shown to the user ("you're logging in to app://foo.bar") but the real goal is to provide a stable audience that the assertion can be verified against. The same goes for OAuth and other remote services where the origin of the request needs to be fixed.
(In reply to Matt Basta [:basta] from comment #7) > (In reply to Rob Hudson [:robhudson] from comment #6) > > Packaged app origins are required to be unique on device, so it seems > > worthwhile to avoid a case where a non-official twitter app takes the > > app://twitter.com origin. > > I think this is really a non-issue in the same way that a Java JAR file > could have the namespace "com.twitter.foo". Making sure they're unique is > one thing, but proving that Twitter produced it isn't really necessary or > relevant as long as the JAR does its job. vote wontfix ?
Yes. We should look at this again in a few months when origins are supported and proper docs exist, though
first-person-wins to claim facebook.com seems pretty serious. We need to solve it somehow.
Depends on: 852720
Late to the party here, but why isn't this origin verification just handled in the review process? Why do we need a programmatic solution? We're only allowing the origin property to be specified for signed privileged packaged apps to my understanding.
(In reply to Jason Smith [:jsmith] from comment #11) > Late to the party here, but why isn't this origin verification just handled > in the review process? Why do we need a programmatic solution? It could be handled during the review process, but it wouldn't be a 100% solution. We'd catch joe1245@gmail.com trying to use facebook.com but verifying that ireallylovecats@gmail.com owns ireallylovecats.com is more difficult. (Lest we think its only obscure websites, it is a real problem outside of the reviewer's home market where they may not be aware which are high profile websites.) Personally though, I'm with basta on this - I don't think its a big issue. We can add it to the review guidelines and only take action (i.e. blocklist) if the genuine owner comes a knockin'. > We're only > allowing the origin property to be specified for signed privileged packaged > apps to my understanding. I thought it was available to unprivileged packaged apps also.
Nope, origin is only available to privileged apps or certified apps. See the discussion on the original bug in bug 852720 along with specifically http://hg.mozilla.org/mozilla-central/file/c7e005de1329/dom/apps/src/Webapps.jsm#l2596.
Amazon web apps use a verification_key that you define in your manifest to verify domain ownership https://developer.amazon.com/sdk/webapps/manifest.html might be some ideas to steal there.
(In reply to Kumar McMillan [:kumar] from comment #14) > Amazon web apps use a verification_key that you define in your manifest to > verify domain ownership > https://developer.amazon.com/sdk/webapps/manifest.html might be some ideas > to steal there. how would this work with packaged apps (its a privileged only property) - an additional manifest file on the server?
I'm not convinced that this is needed or appropriate. The origin field doesn't even need to be a valid domain to be used. app://trolololo.basta is a perfectly valid value for the origin. I think the only check necessary here is a common sense check by the reviewers.
(In reply to Matt Basta [:basta] from comment #16) > I think the only check necessary here is a common sense check by the > reviewers. We need to define what that check is exactly. How does a reviewer verify that a packaged app submitter is authorised* to use a particular origin? *(and how do we define 'authorised')
whoops, awesomebar fail. I was looking for the bug about verifying that a developer owns a domain. Now I can't find, ultimate awesomebar fail. If someone submits a manifest for facebook.com before facebook does then they can own it. I think we wontfixed it because an admin could manually rectify such a problem. The custom http header for manifests was also supposed to address this but most things support that header out of the box now.
(In reply to Andrew Williamson [:eviljeff] from comment #17) > We need to define what that check is exactly. How does a reviewer verify > that a packaged app submitter is authorised* to use a particular origin? > > *(and how do we define 'authorised') I think if someone provides an origin which looks like a "real" domain, that domain should be one that the developer probably owns. If user "ninjascriptkiddie@hotmail.com" submits an app with origin "app://google.com", that's obviously invalid. If the same user submits an app with origin "app://l33tapp.is.the.best", then I think that's totally allowable. The same goes for obvious app names. "app://messaging.whatsapp" should probably only be submitted by a developer associated with Whatsapp. (In reply to Kumar McMillan [:kumar] from comment #18) > whoops, awesomebar fail. I was looking for the bug about verifying that a > developer owns a domain. Now I can't find, ultimate awesomebar fail. 10 years dungeon.
(In reply to Matt Basta [:basta] from comment #19) > I think if someone provides an origin which looks like a "real" domain, that > domain should be one that the developer probably owns. If user > "ninjascriptkiddie@hotmail.com" submits an app with origin > "app://google.com", that's obviously invalid. If the same user submits an > app with origin "app://l33tapp.is.the.best", then I think that's totally > allowable. I agree with the sentiment, but practically, if mattbasta@liamg.moc submits an app that uses marketplace.firefox.com as the origin how would I know he is or isn't authorised to do it? We don't have any developer registration, nor 'official' tags to fall back on. > The same goes for obvious app names. "app://messaging.whatsapp" should > probably only be submitted by a developer associated with Whatsapp. Blacklisting trademark names and phrases in non-domain name style origins throws up even more issues and is leading us into DMCA territory. IMO, if we're going to *anything*, it should be something that relies on server access like the suggestions in comment #3. I'd still lean towards WONTFIXing the bug though.
I suppose we're also making the assumption that having colliding names or "unauthorized" use of origins will even be a problem. The worst that could happen is an app could report itself as potentially being another app. Perhaps the solution here is to WONTFIX and wait until there's a problem and deal with it when that problem arises. Since this only applies to packaged apps, we can blocklist any apps that are doing abusive things.
Agreeing with the WONTFIX in the absence of any other ideas. Anyone can re-open if they have a different opinion.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.