Auto create temporary site-level scope is not working when page is blocked via CloudFlare

[skudo12]

This is a freshly loaded page and no site-level scope is created, as seen in the screenshot (box indicator is black). This happens only on this blocked page via CloudFlare. EDIT: My ip address is exposed in the first screenshot, will upload a new one.

[gorhill]

Yes, I've seen this regularly.

I believe cookies being blocked might be the cause. Thing is, once this happens, it seems there is a period for which the page will still be unavailable despite allowing cookies. I doubt there is anything HTTPSB can do, it's a server-side behavior, which ignores that people might be using a blocker as a way to protect their privacy.

Note: also, if you could supply a link which I can click that would be nice.

Edit: Regarding the lack of site-scope creation (which I forgot to address, as I focused on the resulting page), it is probably because a non "200 status ok" is returned by the server. Question becomes, should a site-level scope be created when an error is returned by the server?

[skudo12]

Here is a sample URL. -http://forum.gamesports.net/dota/showthread.php?t=77577

[skudo12]

Bumping this. Enabling the "Remove third-party HTTP referer information from requests to non-whitelisted hostnames" settings causes this. However disabling this setting and adding the --no-referrers switch to Chromium does not result to the browser being blocked by CloudFlare.

[gorhill]

I have the setting to remove HTTP referer on, and clicking on http://forum.gamesports.net/dota/showthread.php?t=77577 worked fine, I was not served with the CloudFlare 1010 error. Those CloudFlare errors are difficult to reproduce, their is some randomness going on, it may be cookies, HTTP referer or whatever else, I don't know since their heuristic for generating a "positive" is not public as far as I know.

Re. "CloudFlare Error 1010": https://support.cloudflare.com/hc/en-us/articles/200171806-Error-1010-The-owner-of-this-website-has-banned-your-access-based-on-your-browser-s-signature

I strongly dislike that whatever heuristic CloudFlare is using in his tools is impacting a user's own choice to not share specific information.

[gorhill]

Ok I clicked the home page http://www.joindota.com/ which caused the Error 1010 from CloudFlare to be served. Allowing cookies for the domain and refreshing fixed the problem. Blocked the cookie again and the page was still properly served.

So it's not HTTP referer or cookie specifically, there is a heuristic on CloudFlare-backed servers which may be one lack of information or another or a combination which will cause CloudFlare to presume a malicious visitor.

There is nothing HTTPSB can do, if a user chooses to block cookies or referers or whatever, the extension has to respect these settings.

[skudo12]

That was odd. I'm gonna test again on my end.

[yhager]

I can confirm that unchecking 'Remove third-party HTTP referer information from requests to non-whitelisted hostnames' a site that was giving me this error loaded fine.

This does seem random though.. I have a domain I use cloudflare with, and I have 'browser integrity check' set to on, and cloudflare does not block me regardless if this option is checked or not.. confusing..

[pepelepoo]

There might be something HTTPSB can do: how about an option to have the referrer be the requested page?

Also, I think what's tripping it up w/ the referrer is that it is actually transmitted, but it's empty.

An afterthought: an empty referrer or a referrer that's the URL of the page can both be used to identify someone. Isn't there a way to take out the Referer altogether?

[gorhill]

@pepelepoo Good idea. Yes I can take out the referer. I will do this, though I can't tell whether this takes care of all the cases.