1365332 - Use chrome:// urls for Activity Stream content files

Status: RESOLVED INVALID

(Firefox Graveyard :: Activity Streams: General, enhancement)

Description

[Kate Hudson :k88hudson]

We should update Activity Stream to use chrome:// URLs for content files so they cannot be loaded in regular web pages (resource:// URLs can).

This needs to be done in MC first because it requires a change to aboutNewTabService.js, we can port back to Github after that lands.

Comment 1

[Kate Hudson :k88hudson]

Attachment: Bug 1365332 - Use chrome:// urls for Activity Stream content files

Review commit: https://reviewboard.mozilla.org/r/139800/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/139800/

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Can you unpack the thinking a bit here?  In particular, have a look at <https://dxr.mozilla.org/mozilla-central/source/browser/components/about/AboutRedirector.cpp#32>.  Currently, we don't supply the URI_SAFE_FOR_UNTRUSTED_CONTENT flag, meaning that our stuff is running with chrome privs.  However, I suspect we don't want or need those privs, if we can use smaller privilege blocks (eg the way about:home does today).  If I'm right, and we add URI_SAFE_FOR_UNTRUSTED_CONTENT, then that content makes them viewable by web content anyway, although more secure than they are today.

Why is having them be viewable by web content a problem that is important to solve?

Comment 3

[Ed Lee :Mardak]

There's other system-addons with resource URIs:

https://dxr.mozilla.org/mozilla-central/search?q=resource%20path%3Ajar.mn%20path%3Aextensions

Comment 4

[Kate Hudson :k88hudson]

The original reason we wanted to do this because ursula was working on trying to switch our code over to use file path references for screenshots, and resource:// urls don't have access to the filesystem, whereas chrome:// urls do. The eventual solution for this will be by fixing the page-thumbs protocol to work in content (which ursula is going to work on in https://bugzilla.mozilla.org/show_bug.cgi?id=1184701), however mconley mentioned that it would be a good idea to use a chrome url anyway for security reasons since they can't be included as sub resources inside a resource:// or a regular html page. It would prevent people from doing something weird like embedding the new tab page in an iframe etc.

Comment 5

[Kate Hudson :k88hudson]

What do you think about this bholley? Are there any reasons why we should use either resource:// or chrome:// URLs for Activity Stream on the new tab page (note that it's unprivileged and will be in a separate content process)

Comment 6

[Bobby Holley (:bholley)]

In general it's a good goal to prevent web content from loading or linking to internal pages. That, an even more important goal is ensuring that all of the content we write runs with minimal (i.e. non-system-principal) privileges. If we can achieve both that's worth doing, but the latter is more important.

There were some efforts at some point to load browser content in <iframe sandbox> to minimize their privileges and apply a CSP, but I don't recall exactly what happened there. I've been too busy with stylo stuff in recent times to keep up with how the frontend architecture is evolving, so I'm not a great source for full guidance on the specifics unfortunately.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I'm a little confused about the problem we are trying to solve by switching to chrome:// URLs here.  Is it just that resource:// has no concept of contentaccessible as defined at <https://developer.mozilla.org/en/docs/Chrome_Registration#contentaccessible>?  If so, the patches in bug 863246 are adding such a concept, I believe.

Comment 8

[Ed Lee :Mardak]

Comment on attachment 8868224 [details]
Bug 1365332 - Use chrome:// urls for Activity Stream content files

Sounds like this won't be necessary anymore? Could you provide some details and resolve if so?

Comment 9

[Kate Hudson :k88hudson]

After some discussion we decided this isn't necessary (given that we Activity-Stream will be unprivileged and can handle other security issues with a CSP)