Hi,
We use the Error Logging Service getsentry.com in our application, and we use their script hosted on their CDN :
https://cdn.ravenjs.com/3.0.4/angular/raven.min.js
AdBlock and similar extensions which refer to this list, I presume, are blocking this script, causing our application to not load.
Can this script added to the whitelist?
Thanks,
Prabin Varma
getsentry.com error logging script
-
prabinvarma
- New Member
- Posts: 1
- Joined: Mon Jul 25, 2016 6:55 pm
Even for good, its still tracking users. Probably why its blocked
Hi there,
I'm a developer on the Sentry project (https://github.com/getsentry/sentry) and I want to make a few arguments for why this should be removed:
1) ravenjs.com is a cookieless domain that only serves static content over Fastly. We only use this domain as a convenience for serving the raven-js library, which is an open source library (https://github.com/getsentry/raven-js). Just loading the script on its own does not perform any tracking. This domain literally does nothing but serve this one script (and different static versions of it).
2) raven-js is most often loaded into web applications via a package manager like npm or Bower, and bundled into application source code (i.e. app.js or vendor.js). Meaning, in most cases it cannot be blocked without blocking the entire application. The current blocking rule merely blocks a convenience method (ravenjs.com) for some users who want to serve this from our CDN (saving them bandwidth, configuration) rather than serve it themselves.
3) raven-js itself collects uncaught exceptions / bugs in application code and transfers them to the Sentry server, informing developers that something is broken. Keeping this rule, for website developers that use the convenience ravenjs.com CDN, contributes to a poorer experience by ensuring that bug reports are not sent and web applications remain broken.
4) This rule is actively breaking applications on the web, because raven-js itself is not a tracking script, but rather a JavaScript library with API methods that are often called from deep within web application code. When that code attempts to call API methods that do not exist because Raven.js is not loaded, they will break the application (and worst of all, those breakages cannot be reported to Sentry either). See: viewtopic.php?f=64&t=31784&p=99251, https://github.com/getsentry/raven-js/issues/659.
5) There are many other products in this space – bugsnag.com, rollbar.com, raygun.io, others - all with similar CDN convenience methods for loading their scripts. This rule blocks the only product that happens to be completely open source, while other closed-source products are unaffected.
For these reasons I'd ask you to consider removing this rule. I'd be glad to expand on any of these if you have questions.
Thanks,
@bentlegen
https://github.com/benvinegar
I'm a developer on the Sentry project (https://github.com/getsentry/sentry) and I want to make a few arguments for why this should be removed:
1) ravenjs.com is a cookieless domain that only serves static content over Fastly. We only use this domain as a convenience for serving the raven-js library, which is an open source library (https://github.com/getsentry/raven-js). Just loading the script on its own does not perform any tracking. This domain literally does nothing but serve this one script (and different static versions of it).
2) raven-js is most often loaded into web applications via a package manager like npm or Bower, and bundled into application source code (i.e. app.js or vendor.js). Meaning, in most cases it cannot be blocked without blocking the entire application. The current blocking rule merely blocks a convenience method (ravenjs.com) for some users who want to serve this from our CDN (saving them bandwidth, configuration) rather than serve it themselves.
3) raven-js itself collects uncaught exceptions / bugs in application code and transfers them to the Sentry server, informing developers that something is broken. Keeping this rule, for website developers that use the convenience ravenjs.com CDN, contributes to a poorer experience by ensuring that bug reports are not sent and web applications remain broken.
4) This rule is actively breaking applications on the web, because raven-js itself is not a tracking script, but rather a JavaScript library with API methods that are often called from deep within web application code. When that code attempts to call API methods that do not exist because Raven.js is not loaded, they will break the application (and worst of all, those breakages cannot be reported to Sentry either). See: viewtopic.php?f=64&t=31784&p=99251, https://github.com/getsentry/raven-js/issues/659.
5) There are many other products in this space – bugsnag.com, rollbar.com, raygun.io, others - all with similar CDN convenience methods for loading their scripts. This rule blocks the only product that happens to be completely open source, while other closed-source products are unaffected.
For these reasons I'd ask you to consider removing this rule. I'd be glad to expand on any of these if you have questions.
Thanks,
@bentlegen
https://github.com/benvinegar
As a developer for an application in healthcare space that has nothing to do with tracking, i second Bens request to stop blocking Raven's CDNs.
Raven is used for automatically reporting application errors that happen in the real world which cause user's grief. It enables application developers to respond quickly to those errors and to provide a delightful user experience.
Without it, we would be in the dark. Like Ben said, the script can be delivered as part of the main application bundle, but using the cdn is very convenient, we employ that. This will force us to give up that convenience and also the end user will not benefit from the caching convenience of a CDN script.
Overall, i think that blocking an error-reporting application cdn by an ad blocker software is misguided
Raven is used for automatically reporting application errors that happen in the real world which cause user's grief. It enables application developers to respond quickly to those errors and to provide a delightful user experience.
Without it, we would be in the dark. Like Ben said, the script can be delivered as part of the main application bundle, but using the cdn is very convenient, we employ that. This will force us to give up that convenience and also the end user will not benefit from the caching convenience of a CDN script.
Overall, i think that blocking an error-reporting application cdn by an ad blocker software is misguided
Give me an workable/reproducible example where its broken, and it maybe considered
Here is an example:fanboy wrote:Give me an workable/reproducible example where its broken, and it maybe considered
http://cooking.mealime.com/recipes/arugula-crispy-chickpea-salad-cucumber-avocado-parmesan/136.Clicking "Find cookware", "Grab ingredients" or "Cook & enjoy!" does nothing.
This is caused by EasyPrivacy's
||ravenjs.com^$third-party, which blocks https://cdn.ravenjs.com/2.3.0/raven.min.js.