You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The core of the complaint is around Tor Browsers being either blocked, or if not blocked, losing anonymity whenever a site is hosted behind Cloudflare. Cloudflare is a 'classic MITM' because https is decrypted at Cloudflare's servers, not at ours. The plus for Audacity is having an easy to administer large responsive CDN with specific protection against DDOS attacks.
A second aspect of using Cloudflare that also deserves consideration is incorrect blocking, unnecessary CAPTCHAs and code corruption by misconfigured rules. Updates to Wiki which are fast on Wikipedia are really really slow on our wiki which is behind Varnish and Cloudflare. At one point Cloudflare blocked Google from spidering our sites, so leading to a sustained plunge in SEO, because we spotted the problem very late indeed. Bug fixers have been blocked in our Bugzilla by CAPTCHAS that time out before they can answer them. The code corruption (of Javascript) happened because of 'Rocket Code' - an accelerator for Javascript applied by Cloudflare by default. Rocket Code breaks some perfectly valid javascript, unless you put specific tags in to disable it.
On the plus side, default acceleration provided by Cloudflare reduces the size of images (pngs) in our manual and general wiki without us doing any extra work to code it, and with no visible loss in image quality.
The various incorrect blockings matter a lot. Open source depends on volunteer contributions. If we block accredited users with CAPTCHAs just because they are querying our bugzilla bugs, or because they use a semi colon on our wiki page and Cloudflare rules regard it as a potential SQL exploit, we are shooting ourselves in the foot.
I am expecting this issue will get discussed, and then closed 'no action necessary'. However, the issues do matter, and we should talk about them in public. Cloudflare may be inappropriate for a small independent organisation that does not have the time and resources of a large organisation to tune the rules and keep a hawk eye on new rules and features that may create often initially hidden problems.
The feature request is for an alternative way of having a CDN and DDOS protection that is altogether lighter and that does less collateral damage.
The text was updated successfully, but these errors were encountered:
The way cloudflare is currently configured is way overkill. Since bugzilla and the wikis can only be edited after having an account created for you, there's very little risk of attempts at SQL injection or the like; it just interferes with existing users. And, furthermore, https://bugzilla.mozilla.org and https://www.mediawiki.org/ do not use cloudflare, so it seems that they're fairly confident about the lack of injection exploits (or that if an exploit does exist, it will be found and fixed in a new version).
I think at minimum, that functionality should be disabled for bugzilla and the wikis. I don't really have an opinion on whether it should be left on for the main site.
To expand more on the issue, the mw2html.py script seems to only work when running from Windows. When I run from my Debian 10 machine, I get a Status 503 return error like below:
Status 503 Service Temporarily Unavailable accessing /man
The same script works when running on Windows 10. I figure that it's Cloudflare thinking my machine is a bot of some sort.
I agree that the current configuration is overkill more than anything.
This issue is split out from issue #538
A contributor who gave very useful bug/code information stated:
"If you want some links, you can just search for something like "Why Cloudflare is Bad". Here's only a couple:
https://lists.gnu.org/archive/html/gnu-system-discuss/2017-03/msg00126.html
http://techrights.org/2019/02/17/the-cloudflare-trap/
https://pixie.garden/~/ThufiesBlog/don%27t-trust-cloud-flare (beware, certificate expired, but site itself isn't dubious and the article is very worth reading)"
The core of the complaint is around Tor Browsers being either blocked, or if not blocked, losing anonymity whenever a site is hosted behind Cloudflare. Cloudflare is a 'classic MITM' because https is decrypted at Cloudflare's servers, not at ours. The plus for Audacity is having an easy to administer large responsive CDN with specific protection against DDOS attacks.
A second aspect of using Cloudflare that also deserves consideration is incorrect blocking, unnecessary CAPTCHAs and code corruption by misconfigured rules. Updates to Wiki which are fast on Wikipedia are really really slow on our wiki which is behind Varnish and Cloudflare. At one point Cloudflare blocked Google from spidering our sites, so leading to a sustained plunge in SEO, because we spotted the problem very late indeed. Bug fixers have been blocked in our Bugzilla by CAPTCHAS that time out before they can answer them. The code corruption (of Javascript) happened because of 'Rocket Code' - an accelerator for Javascript applied by Cloudflare by default. Rocket Code breaks some perfectly valid javascript, unless you put specific tags in to disable it.
On the plus side, default acceleration provided by Cloudflare reduces the size of images (pngs) in our manual and general wiki without us doing any extra work to code it, and with no visible loss in image quality.
The various incorrect blockings matter a lot. Open source depends on volunteer contributions. If we block accredited users with CAPTCHAs just because they are querying our bugzilla bugs, or because they use a semi colon on our wiki page and Cloudflare rules regard it as a potential SQL exploit, we are shooting ourselves in the foot.
I am expecting this issue will get discussed, and then closed 'no action necessary'. However, the issues do matter, and we should talk about them in public. Cloudflare may be inappropriate for a small independent organisation that does not have the time and resources of a large organisation to tune the rules and keep a hawk eye on new rules and features that may create often initially hidden problems.
The feature request is for an alternative way of having a CDN and DDOS protection that is altogether lighter and that does less collateral damage.
The text was updated successfully, but these errors were encountered: