874967 - Privileged apps cannot use Google Analytics (or others) because of CSP

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Matt Basta [:basta]]

This blocks the Marketplace from becoming a "true" packaged app.

The CSP prevents GA from being loaded (since it's a remote script). This means that app developers that do cool things in their apps cannot implement any kind of analytics unless they write it from scratch.

Comment 1

[Jason Smith [:jsmith]]

Paul - Thoughts?

Comment 2

[Garrett Robinson [:grobinson]]

(In reply to Matt Basta [:basta] from comment #0)
> This blocks the Marketplace from becoming a "true" packaged app.
> 
> The CSP prevents GA from being loaded (since it's a remote script).

This is just the "old", synchronous Google Analytics code [1]. The new asyc code is designed to be loaded via an inline script [2], which is even worse from the perspective of trying to define a reasonable default CSP.

[1] https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingOverview
[2] https://developers.google.com/analytics/devguides/collection/gajs/asyncTracking

> This means that app developers that do cool things in their apps cannot
> implement any kind of analytics unless they write it from scratch.

They could use an open source analytics platform such as Piwik [3]. This would allow them to serve the tracking code from their own domain, making it compatible with the default CSP. This is already considered best practice by some especially privacy-conscious sites, such as eff.org. [4]

[3] http://piwik.org/
[4] https://www.youtube.com/watch?v=q38HdGGWS78&feature=youtu.be&t=23m17s

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Chrome apps has a very similar CSP policy to what we have for privileged/certified apps. In fact, their CSP policy is even more strict.

It'd be interesting to know if this is something that Google has run into with Chrome apps.

If they have an inline-script solution then it should be possible to simply stick that inline script in a separate .js file and put it in the application package. However that still requires that the script doesn't attempt to script-src other files from Google. But if they use XHR that should work fine.

Comment 4

[Matt Basta [:basta]]

(In reply to Jonas Sicking (:sicking) from comment #3)
> Chrome apps has a very similar CSP policy to what we have for
> privileged/certified apps. In fact, their CSP policy is even more strict.
> 
> It'd be interesting to know if this is something that Google has run into
> with Chrome apps.

Chrome apps allow you to have "sandboxed" pages which can load and run arbitrary content, but don't have any permissions (kind of like an iframe).

The Marketplace is hacking something together that does basically the same thing, except it does it inside of a data URI iframe. This isn't ideal, though, and really limits the kind of things we can do with GA. It's also not a one-size-fits-all solution that other folks can use without any gotchas.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

How is the google solution with a "sandbox" different from an <iframe>?

I.e. what advantages does the google solution have?

I'm open to suggestions, but simply running a remote script in the context of the page defeats the purpose of signing, so we can't do that as long as the marketplace wants to keep being a privileged app.

Of course, one option is for marketplace to not be a privileged app. It can still be packaged if it wants the offline/performance benefits that comes with that.

Comment 6

[Matt Basta [:basta]]

(In reply to Jonas Sicking (:sicking) from comment #5)
> How is the google solution with a "sandbox" different from an <iframe>?

Google's solution lets you specify a "sandbox" field in the manifest that loads the sandboxed page in the background. You can add script tags to it to load code that runs in tandem with your app, doing all the CSP-unfriendly things and postMessaging the results back. This means that when the app goes through the review process, all of the onmessage code is still fixed in the app, meaning you can't fake the intentions of what your app is doing or execute code that has snuck past a reviewer.

With an iframe, you have to do things like this:

https://github.com/mozilla/fireplace/blob/master/hearth/media/js/tracking.js#L101

I'm not saying Google's solution is better, I'm saying they have a solution. There are plenty of reasons you'd want to use a remote script. Perhaps you want to integrate with Firebase, or maybe you're loading in a script to do error reporting, or maybe you're trying to use some of Google's crazy Maps APIs that require you to load their library files to do it.

> Of course, one option is for marketplace to not be a privileged app. It can
> still be packaged if it wants the offline/performance benefits that comes
> with that.

I'd love to dump GA and just not need to do it entirely, but unfortunately there's about three levels of managers above me that eagerly await the reports that it produces every month. I'd love to not be privileged (and make everyone's life about 75% easier), but we need to get the user's MCC and MNC to detect region and carrier because that's what the carriers asked for.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.