Closed Bug 1093210 Opened 10 years ago Closed 8 years ago

Turn on CSP in the Marketplace

Categories

(Marketplace Graveyard :: General, defect, P5)

Product:
Marketplace Graveyard
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: clouserw, Assigned: clouserw)

References

Details

(Whiteboard: [blocked on New Relic][marketplace-transition]) 

With bug 989121 landed I think we can turn on CSP for real (not just report-only).  We should be wary of potential DoS still.
Priority: -- → P5
As of today there are rules to report violations on -dev of script-src and object-src.  Scripts have a whitelist, objects are simply None.

However, the real blocker to pushing this live is our inline scripts.  The way new relic works is by injecting inline scripts into the page[1].  It sounds like they are developing alternatives to their current methods but they aren't available as of today.

So.....blocked on that for now. :-/


[1] https://discuss.newrelic.com/t/content-security-policy-and-browser-injection/2629
Whiteboard: [blocked on New Relic]

Instead of using `newrelic.agent.get_browser_timing_header()` you can use the "Copy-paste" deployment https://docs.newrelic.com/docs/browser/new-relic-browser/installation-configuration/adding-apps-new-relic-browser#copy-paste-app

Instead of just pasting their snippet you can move that to a static file and include with <script src>. 

If you read that thread (https://discuss.newrelic.com/t/content-security-policy-and-browser-injection/2629) you find that you just lose accuracy for browsers that don't support navigator.performance on the first hit of the page.
If you want to get the transaction tracking you can strip ";NREUM.info=.*$" from the snippet and parse the transaction information out of newrelic.agent.get_browser_timing_footer
Here's a PR with my proposal: https://github.com/mozilla/zamboni/pull/3039
Thanks for the patch.  We've taken great care to improve the performance on the Marketplace, particularly around our low memory / low bandwidth phones.  It looks like we'll need to decide on whether 2 additional HTTP requests (one page blocking in the <head>) is worth the benefits of what New Relic offers.

We're pushing forward in some African countries right now.  While we don't have the same poor memory limitations we had, I imagine their network infrastructure isn't as reliable or fast as the US and this might affect their perception more than we'd initially think.
We can move the second script into the application bundle to reduce the number of scripts. With caching, external scripts are more efficient than inline scripts.
You can also move the initial JavaScript from the head to the to of the application bundle. You just have to make sure it is bundled as the first code to be executed.
If we could move both scripts to our bundle that'd be cool. If you want to experiment with that, look at https://github.com/mozilla/fireplace , that's our consumer pages repository. http://marketplace-frontend.readthedocs.org/en/latest/topics/usage.html has some more info about it.
Out of interest, what language agent are you using with Marketplace ? The Python agent ? 

I'd love to see support for CSP added via the nonce/hash whitelisting for inline scripts but it would help to know what agent to target first to help you out here :)
Ah, I haven't checked out the CSP spec since nonce appeared.  That's interesting.  I'll need to read more about it this week.

The UA coming from the marketplace is https://github.com/mozilla/zamboni/blob/master/mkt/settings.py#L900
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Whiteboard: [blocked on New Relic] → [blocked on New Relic][marketplace-transition]
You need to log in before you can comment on or make changes to this bug.