RequestPolicy/requestpolicy — Issue #185: reconsider mozilla.org permanent whitelist entries
Author: jsamuel
Created: 2011-12-22 05:59:00+00:00
State: open
Labels: extension

There are permanent whitelist entries allowing all requests originating from:

{{{
http(s)://download.mozilla.org/
http(s)://addons.mozilla.org/
http(s)://releases.mozilla.org/
}}}

These were added due to previous problems downloading/updating extensions and a fear of interfering with the download of Firefox updates (though I don't believe problems with Firefox updates were ever observed, I'm not sure). However, concerns about blocked updates may no longer be valid since r325 which allowed all redirects of non-content requests (note: non-content requests don't get sent through nsIContentPolicy::shouldLoad, so we won't accidentally block them there).

Aside from updates, I believe RP also used to create confusion when downloading addons directly from AMO. From what I remember, there was javascript that handled the link click and initiated a cross-site request which was then blocked (at least, under some strictness settings). If removing these whitelist entries, it would be worth looking into whether this makes it difficult to download addons from AMO. If so, we should consider what UI changes would need to be made to help users realize that something was blocked that they should be notified about in a more obvious manner than turning the flag red. This is a general issue with RP and it would be good to have a reason to have to address it.

It's worth remembering that if a Firefox update causes RP to break further Firefox updates and extension updates, a user is then stuck and may not realize they are running insecure software. Lots of caution should be exercised when changing RP code that might cause updates to break if some of our understanding or assumptions are wrong. Of course, if we were relying only on these permanent whitelist entries, all it would take for RP to break updates is for a different domain or subdomain to be used for updates.

There are other permanent whitelist rules for mozilla sites that we can't even consider removing until we have a better story to tell about how users deal with blocked requests. The examples that come to mind are about:addons (#126) and about:home (#140). There's an argument that if we can't fundamentally fix all of these, instead of removing compatibility rules we should just add an advanced option for users to disable the compatibility rules altogether (where the default will be to have them enabled).

Finally, it would probably be a good idea to have the soon-to-be-implemented blacklist take priority over compatibility rules. For example, it would be nice to know that if if I've blacklisted requests to google-analytics.com, if AMO adds this later then I won't get burned by RP allowing such requests and not telling me.