{"issue":{"user":{"id":1240282,"login":"jsamuel","url":"https://api.github.com/users/jsamuel","avatar_url":"https://secure.gravatar.com/avatar/bc1d195cedb959a3946572b08ce9e7c7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"bc1d195cedb959a3946572b08ce9e7c7"},"milestone":null,"created_at":"2011-12-22T02:33:49Z","title":"Update Scanner: all cross-site request from old versions/diffs of pages are blocked","state":"open","updated_at":"2011-12-22T02:33:55Z","labels":[{"name":"extension","url":"https://api.github.com/repos/RequestPolicy/tractest/labels/extension","color":"ededed"}],"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","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.","number":55,"url":"https://api.github.com/repos/RequestPolicy/tractest/issues/55","comments":3,"assignee":null},"comment":{"user":{"id":1240282,"login":"jsamuel","url":"https://api.github.com/users/jsamuel","avatar_url":"https://secure.gravatar.com/avatar/bc1d195cedb959a3946572b08ce9e7c7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"bc1d195cedb959a3946572b08ce9e7c7"},"created_at":"2011-12-22T02:33:55Z","updated_at":"2011-12-22T02:33:55Z","id":3242892,"body":"[justin] The problem with link clicks from Update Scanner webpage versions/diffs being blocked has been resolved as of !RequestPolicy 0.5.17. Specifically, r380 and r381 (the fix for #134) translates moz-nullprincipal origins to the true origin so !RequestPolicy can use the true origin to determine if the request was from a link click.\r\n\r\nThe remaining conflict with Update Scanner, afaik, is that there is no way to selectively whitelist requests made when viewing a specific version or diff with Update Scanner. One can allow most of these requests by whitelisting the origin `about:blank`. Whitelisting the origin `about:blank` will open up the ability for malicious or crafty sites to bypass !RequestPolicy, but arguably if one is going to disable RP because of the conflict with Update Scanner, one might as well just allow the origin `about:blank` and get the rest of the protection that RP can offer.","url":"https://api.github.com/repos/RequestPolicy/tractest/issues/comments/3242892"},"action":"created"}