Algolia provides site search I believe, which seems reasonable. Cloudflare is generally used for DDOS protection, which is reasonable even if I personally think that Cloudflare is getting too monopolistic. Cloudinary is for image and video storage, probably for images in videos embedded in posts. I’m not sure about dl.drop, and I’m not sure why LW needs to use Dropbox. The Google connections are probably for analytics, although LW could and should definitely do that in-house. Intercom.io is for the messaging-with-developers that you can reach by clicking on the button in the bottom right corner of the screen. Jsdelivr.net is a caching service for Javascript, which helps you save internet bandwidth, which is reasonable. lr-ingest.io is apparently for analytics on user interaction with the site, which seems like a stretch for “does LW need it.” Typekit.net (presumably) provides the fonts used, which is useful for caching although LW could also do it locally.
So to summarize, dl.drop, Dropbox, and some of the Google usage are for unknown reasons. Using Google analytics and lr-ingest.io make me uncomfortable personally. And Typekit and Jsdelivr provide marginal benefit at some cost, which aren’t worth it in my opinion.
We have recently experimented with LogRocket, but it’s currently deactivated (though we might activate it again in the future). People should also feel free to block it, since the benefit for us is just from getting more data on how on-average users interact with the site.
We don’t use dropbox, and indeed it isn’t loaded on any page I could find. People often use Dropbox to host images for LessWrong posts, so my guess is that where that request came from. The same goes for dl.drop and the dropboxusercontent URL.
Google Analytics is just really useful. We are building up internal analytics infrastructure, but I think we are still quite a bit away from being able to shut down Google Analytics.
The Googleapis are likely for Google’s ReCaptcha which we use to identify bots.
Overall, feel free to deactivate basically all of them, and nothing horrible should break. With the exception of typekit, algolia, jsdelivr (which would break LaTeX editing) and cloudflare. You can just deactivate Intercom in your user settings if you don’t want it, but you can also just block requests to Intercom.com.
Typekit.net (presumably) provides the fonts used, which is useful for caching although LW could also do it locally.
Small comment on this: We have a Typekit subscription, which sadly does not actually allow us to download the fonts and serve them locally. We have to serve them directly from Adobe’s servers. It’s slightly annoying, but I don’t think it’s bad enough that I would want to stop using Typekit (which has overall been pretty decent and gives us access to a really wide range of fonts).
Jsdelivr provide marginal benefit at some cost, which aren’t worth it in my opinion.
The only place where we use jsdelivr is for serving MathJax, for which it is the canonical source that Mathjax links to in the documentation, which seems good because it allows people to cache Mathjax for multiple sites, so I think this is the best solution here. Seems worse for us to set up our own CDN, and worse for it to be served from the LessWrong server, since that makes our job harder.
I’m not sure, but here are some guesses.
Algolia provides site search I believe, which seems reasonable. Cloudflare is generally used for DDOS protection, which is reasonable even if I personally think that Cloudflare is getting too monopolistic. Cloudinary is for image and video storage, probably for images in videos embedded in posts. I’m not sure about dl.drop, and I’m not sure why LW needs to use Dropbox. The Google connections are probably for analytics, although LW could and should definitely do that in-house. Intercom.io is for the messaging-with-developers that you can reach by clicking on the button in the bottom right corner of the screen. Jsdelivr.net is a caching service for Javascript, which helps you save internet bandwidth, which is reasonable. lr-ingest.io is apparently for analytics on user interaction with the site, which seems like a stretch for “does LW need it.” Typekit.net (presumably) provides the fonts used, which is useful for caching although LW could also do it locally.
So to summarize, dl.drop, Dropbox, and some of the Google usage are for unknown reasons. Using Google analytics and lr-ingest.io make me uncomfortable personally. And Typekit and Jsdelivr provide marginal benefit at some cost, which aren’t worth it in my opinion.
Yep, this is basically right.
We have recently experimented with LogRocket, but it’s currently deactivated (though we might activate it again in the future). People should also feel free to block it, since the benefit for us is just from getting more data on how on-average users interact with the site.
We don’t use dropbox, and indeed it isn’t loaded on any page I could find. People often use Dropbox to host images for LessWrong posts, so my guess is that where that request came from. The same goes for dl.drop and the dropboxusercontent URL.
Google Analytics is just really useful. We are building up internal analytics infrastructure, but I think we are still quite a bit away from being able to shut down Google Analytics.
The Googleapis are likely for Google’s ReCaptcha which we use to identify bots.
Overall, feel free to deactivate basically all of them, and nothing horrible should break. With the exception of typekit, algolia, jsdelivr (which would break LaTeX editing) and cloudflare. You can just deactivate Intercom in your user settings if you don’t want it, but you can also just block requests to Intercom.com.
Small comment on this: We have a Typekit subscription, which sadly does not actually allow us to download the fonts and serve them locally. We have to serve them directly from Adobe’s servers. It’s slightly annoying, but I don’t think it’s bad enough that I would want to stop using Typekit (which has overall been pretty decent and gives us access to a really wide range of fonts).
The only place where we use jsdelivr is for serving MathJax, for which it is the canonical source that Mathjax links to in the documentation, which seems good because it allows people to cache Mathjax for multiple sites, so I think this is the best solution here. Seems worse for us to set up our own CDN, and worse for it to be served from the LessWrong server, since that makes our job harder.