{"issue":{"user":{"id":1240282,"login":"jsamuel","url":"https://api.github.com/users/jsamuel","gravatar_id":"bc1d195cedb959a3946572b08ce9e7c7","avatar_url":"https://secure.gravatar.com/avatar/bc1d195cedb959a3946572b08ce9e7c7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"milestone":null,"title":"Update Scanner: all cross-site request from old versions/diffs of pages are blocked","created_at":"2011-12-22T02:33:49Z","labels":[{"name":"extension","url":"https://api.github.com/repos/RequestPolicy/tractest/labels/extension","color":"ededed"}],"state":"open","updated_at":"2011-12-22T02:33:58Z","id":2632273,"closed_at":null,"pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"html_url":"https://github.com/RequestPolicy/tractest/issues/55","number":55,"body":"A user asks:\r\n  Is there any way to enable the links in Update Scanner while Request Policy is enabled? I tried whitelisting chrome://updatescan/content/, but that did not help.\r\n\r\nHere's what I can see from some quick testing:\r\n\r\nUpdate Scanner saves old versions of pages one wants to monitor. When looking at the old versions of pages or at the differences, all cross-site requests are blocked. The url will be something like:\r\n\r\n{{{\r\nchrome://updatescan/content/diffPage.xul?id=63&title=Slashdot%20-%20News%20for%20nerds%2C%20stuff%20that%20matters\r\n&newDate=today%20at%209%3A28&oldDate=today%20at%209%3A28&url=http%3A//slashdot.org/&view=old\r\n}}}\r\n\r\nHowever, the blocked requests will be from two origins:\r\n  * about:blank\r\n  * data:text/html,then the entire page's html here\r\n\r\nSo that's why the user's attempt at whitelisting \"chrome://updatescan/content/\" failed: the requests aren't coming from that origin even though that's what's in the visible url when using Update Scanner. Because the blocked requests have non-chrome origins, they don't get automatically allowed. However, there may not be an easy way to whitelist these without being at risk from attacks whose origins involve `about:blank` or `data:`.\r\n\r\nThe additionally sad thing here is that the user points out that the breakage only happens with the newer version of Update Scanner that fixed their highly-publicized vulnerability from August. This may lead some people to want to keep using the old version of Update Scanner if they aren't aware of the vulnerability.","url":"https://api.github.com/repos/RequestPolicy/tractest/issues/55","comments":5,"assignee":null},"comment":{"user":{"id":1240282,"login":"jsamuel","url":"https://api.github.com/users/jsamuel","gravatar_id":"bc1d195cedb959a3946572b08ce9e7c7","avatar_url":"https://secure.gravatar.com/avatar/bc1d195cedb959a3946572b08ce9e7c7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"created_at":"2011-12-22T02:33:58Z","updated_at":"2011-12-22T02:33:58Z","id":3242896,"body":"[justin] Fixed in r407 and r408.\r\n\r\nThis solution is a combination of:\r\n  * When RP's nsIContentPolicy::shouldLoad implementation is called, try to convert origins of \"about:blank\" to something more useful by looking in the context argument. In the case of Update Scanner (and probably others), this allows converting \"about:blank\" origins to the corresponding \"data:text/html...\" document that actually originated the request.\r\n  * Consider \"data:[MIME-type]\" to be a URI identifier. RP used to use the entire data URI as an identifier by not giving it special treatment and allowing the URI identifier determination to fail.\r\n  * Add a concept of top-level document translation rules. This allows RP to decide to pretend that the current tab's top-level document URI is different than it actually is.\r\n  * Add a top-level document translation rule for Update Scanner that pretends that document URIs starting with \"chrome://updatescan/content/diffPage.xul\" are actually just \"data:text/html\".\r\n  * Rely on some unintuitive implementation details of RP that, when combined with these changes, allow the correct destinations to be shown in the RP menu when viewing Update Scanner diff pages (partly explained in r408).\r\n\r\nI tried to make these changes as general as possible in the hope that they would be applicable in cases other than Update Scanner.\r\n\r\nI don't doubt there may be other conflicts with Update Scanner or blocked requests that turn out not to be easy to whitelist. Separate tickets should probably be opened for those issues unless the current changes aren't really working as well as I believe they are.\r\n\r\nNote that I see some different behavior with Firefox 3.6.13 + Update Scanner 3.1.3 (most recent for Firefox 3) vs. Firefox 4.0b12pre + Update Scanner 3.1.4 (most recent for Firefox 4). I don't know if these differences are due to Firefox changes or Update Scanner changes. The major difference I've seen is that the RP menu with Firefox 3 + Update Scanner 3.1.3 doesn't show individual destinations but one can still \"temporarily allow all from data:text/html\". When using Firefox 4 with Update Scanner 3.1.4, one does see the individual destinations and can \"temporarily allow all from data:text/html to example.com\". Given that the better behavior is on Firefox 4, I'm not inclined to look into this further nor to try to fix this for Update Scanner + RP on Firefox 3.","url":"https://api.github.com/repos/RequestPolicy/tractest/issues/comments/3242896"},"action":"created"}