Breaks view-source:

[wilkowy]

It looks like RP started to introduce security fixes same as "No Resource URI Leak", because the same issue was present several days ago in theirs addon. Anyway: URIs "view-source:" are broken (not formatted) with RequestPolicy Continued 1.0.beta12.2 (but worked fine with version before).

OK, Request Log confirms blocked connection to "resource://gre-resources/viewsource.css"

[wilkowy]

Aside from common "null" problem which in some revisions does not exist only to hit in other new version since previously mentioned RP version it started blocking also "pluginproblem" and "noscript_XXXXXX" (Xs seems to be random numbers, but it looks like they change only on browser restart, not F5).

From Request Log: "resource://noscript_0.XXXXXXXXXXX/flash16.png" and "chrome://pluginproblem/content/pluginProblem.xml"

[myrdd]

I can reproduce the view-source and the noscript+flash issue, and I'll provide a fix today.

noscript-related code: link

"chrome://pluginproblem/content/pluginProblem.xml"

What is the origin uri of that request? Is it a website (http/https)?

[wilkowy]

Yes, it's any website which uses flash (click_to_play is enabled) like liveleak, youtube, kongregate. It seems that having up to date (or not) flash does not matter (I also had outdated plugin for a short time) and this blocked request seems to block a whole flash container as well. This can be of course fixed by allowing requests to "chrome://pluginproblem" for selected domains - however I'd prefer to narrow it to "/content/pluginProblem.xml" path, but RP does not offer such feature.

As for view-source this is valid for any page, but also can be fixed with temporary allowing. I'd rather not allow "gre-resources" as global, because this probably would defy the whole purpose of blocking access to resources:// (and chrome://).

The problem with NoScript is that it seems to use random identifier in place of "XXXXXXX" each time browser is started and RP does not allow to place wildcards other place that at the beginning (has wildcard matching really such a performance impact?). However this is really a slight issue as it only blocks tiny "F" icon for blocked resources (flash). No other problems with NS (or other addons) were noticed so far.

[myrdd]

Thanks for the quick response.

This can be of course fixed by allowing requests to "chrome://pluginproblem" for selected domains - however I'd prefer to narrow it to "/content/pluginProblem.xml" path, but RP does not offer such feature

True, RP does not have this feature, yet, but I can implement the full path internally/statically.

As for view-source, it's only necessary to allow the css file you've mentioned in your first post.

The problem with NoScript is that it seems to use random identifier in place of "XXXXXXX" each time browser is started

exactly.

has wildcard matching really such a performance impact?

I think the point is that exact domain parts can be much more optimized than domain parts containing wildcards. Also, it could be a security impact if you don't know what you're doing, for example when allowing *.*cdn*.com. However, if this feature is really wanted, it woudn't be too difficult to implement in the back-end.

[wilkowy]

However, if this feature is really wanted, it woudn't be too difficult to implement in the back-end.

The idea behind this is to block globally patterns like „ads.” (I know, we could use uBlock or similar addons, but this will cause even bigger performance hit). Anyway, when we allow commonly visited and safe sites through .host than we also allow all (probably) unwanted requests to for example ad.host/ads.host/pixel.host/piwik.host etc. To pinpoint such requests means we have to monitor Request Log or developer tools and add this subdomains manually for each site separately. Here also comes the problem with NoScript when we allow scripts for a whole safe domain than scripts from subdomain are also executed (default RP's UI options are all *.host so it always includes subdomains in patterns).

Other example are mentioned by you CDNs. Now we need either allow all requests from .facebook.com to .akamaihd.net or add a dozen of entries like "fbcdn-photos-e-a.akamaihd.net", "fbcdn-video-a.akamaihd.net" etc. With deep wildcards we could reduce them to "fbcdn-*.akamaihd.net" or any other CDN domain. (I use default deny w/o subdomains + own whitelist)

Of course it all depends on how big hit on performance this would have, as I've read that restricting to wildcards at he beginning of URL was made on purpose. I think that security impact is the problem of individual user. If he wants to break own security it is his own decision.

There exists also some misconception in my opinion When we use blocking with no subdomains policy than context menu aside of "Allow requests from .host to .host" should also display strict "Allow requests from host to host". But for this I'll make a feature request in a moment.

(edited by @myrdd, changed * to \*)

[myrdd]

I've released version 1.0.beta12.2.1518.r5b93f50.pre. Please check if the issues are solved, i.e. viewsource, noscript, and pluginproblem.

---

@wilkowy This is quite off-topic, but I still post my answer here.

The idea behind this is to block globally patterns like „ads.*”

Okay, in default-allow mode this could be interesting indeed.

(I know, we could use uBlock or similar addons, but this will cause even bigger performance hit)

Related issue: implement support for other/custom subscription formats (#768)

Anyway, when we allow commonly visited and safe sites through *.host than we also allow all (probably) unwanted requests to for example ad.host/ads.host/pixel.host/piwik.host etc.

You could set the "allowSameDomain" option to "false". See also the "strictness" issue #474. NoScript as well has the possibility to set rules based on the full host.

I've read that restricting to wildcards at he beginning of URL was made on purpose. I think that security impact is the problem of individual user. If he wants to break own security it is his own decision.

I don't know the exact reasons for that restriction, but I agree with you. Still, we need good defaults, so my suggestion would be to provide a setting which toggles "insecure wildcards".

[wilkowy]

Tested RP 1.0.beta12.2.1518.r5b93f50.pre:

• "view-source" issue seems to be fixed
• "noscript_0.XXX" issue seems to be fixed
• "pluginproblem" issue still exists

There is also weird behavior (however it was present in previous version as well):

1. make sure there are no "pluginproblem" allow rules
2. restart Firefox
3. open a site with Flash plugin (safe/outdated plugin status does not matter)
4. the RP context menu will have "pluginproblem" in other origins
5. temporary allow it & reload a page
6. now the click-to-play container is displayed (or pluginproblem overlay)
7. revoke all temporary permissions & reload a page

Now there should be "pluginproblem" again available to allow, but not! Since now browser will show click-to-play container immediately on this and any other page - until another Firefox restart. It looks like some caching or some flag is set when the resource is accessed at least once or the issue is in RP and it passes further such requests.

Okay, in default-allow mode this could be interesting indeed.

In default-deny as well, because we can enable single safe domain with subdomains and still have some of them blacklisted. Now we have to make blocking rules for each site separately. More rules = more matching = slower.

[myrdd]

"pluginproblem" issue still exists

Oops, I must have lost it during git-rebase. Please refer to #797, which is now dedicated to this pluginproblem issue.

Regarding wildcards in domain names, please follow #417.

Now we have to make blocking rules for each site separately. More rules = more matching = slower.

Not exactly. RP uses a hierarchical data structure for rule-matching, which improves performance.

[jstetten]

Hello. Sorry to ask a dumb question, but what exactly is gre-resources? Is it flash related (I don't have flash installed)? I see it all about the web in RPC's menu but can't find anything about it.

[jstetten]

I also see that ebay.com requests to connect to just gre. What are these resources? Thanks.

[wilkowy]

jstetten, those are internal browser's resources which unfortunately might be accessed from outside. They are harmless, but may be used to fingerprint particular browser. Check them yourself (enter as URLs in browser): resource://gre/ and resource://gre-resources/.

[jstetten]

Thanks, @wilkowy. I took a look.

I trust you if you say it's harmless, but it's a little unnerving that an external site can request internal browser cryptography, location, keyboard and payment settings and methods. I haven't browsed the relevant FF or RPC code, so don't understand the protocol, but it seems wrong on the surface.

Regardless, I hate fingerprinting, so will leave these resources blocked.