> To learn more, or to download and install the free browser extension:
Edit: After re-reading this multiple times, I don't think this wording is helpful. There should be a transparent description of what this extension offers before users navigate to download and install options.
You likely misread the sentence. It doesn't say "To learn more, download and install the free browser extension:" - it says, "To learn more, or to download and install the free browser extension:" and then provides you with links to the stores that contain the description for the extension:
> Websites have increasingly begun to rely much more on large third-parties for content delivery. Canceling requests for ads or trackers is usually without issue, however blocking actual content, not unexpectedly, breaks pages. The aim of this add-on is to cut out the middleman by providing lightning speed delivery of local (bundled) files to improve online privacy.
I agree that it's a very weird frontpage and means of describing an extension, but you don't need to run their code before reading what the extension does.
Yeah, a little oddly worded. It's basically saying visit the Firefox/Chrome store to either download OR find out more about the add-on. I'm not sure why the website I'm on can't tell me more about it.. But I agree with the other poster in that you parsed the sentence incorrectly.
Yeah exactly... It just says how to install it. Not what it is or why it should want it ;)
It should have a description on their own site, not rely on one in an app store. I wouldn't even click on that until I'm convinced I want it.
In fact I didn't, I saw the page, was like "???" and then went to the comments here to read what this was about ;)
But yeah I always wondered what Google does with all these calls to the javascript libraries they're hosting... I bet they milk them for data somehow. It's a good effort but I'm not sure I'll install it as I already have so many plugins in Firefox that it constantly complains about slow startup.
I like the idea of the extension, but the implementation in lacking. According to the project's gitlab[1], there's only a dozen or so libraries are actually being served. It doesn't seem to cache google web fonts, for instance. Some sibling comments mentioned LocalCDN, which has more libraries and also includes fontawesome, but still lacks google fonts.
Plus which, in the last decade I can remember exactly two instances where I was positively surprised by a custom font. All other times I didn't notice, would have preferred another font, or even opened up dev tools to revert the font. Given that the latter occurred more often than the instances where the custom font was a nice-to-have, I tend to agree that web fonts are just a lost cause, especially if it's (practically) a package deal with centralized tracking.
The extension is at least 3 years old (by the oldest review comment, I also remember trying it around 2 years ago) and has 130k installs. It's a little beyond an MVP. I guess they don't do telemetry (oh the irony) so they don't have a way to know which files are most reused across CDNs.
The extension idea is really good but is does break some websites plus its really slowing down the browser, after removing it was like a breath of fresh air.
It's a cool idea, even if just for performance reasons. So many things come from CDNs these days, we may as well start shopping the common ones ahead of time.
But recently I learned something unexpected. Lots of extensions are terrible with their resources. On a page targeting tech-savvy people, around 1% of requests has some extension content injected into the website which requests an external font file. (info comes from CSP reports) There's so much tracking opportunity exposed through them.
In recent years libraries haven't been used off CDN like this much but rather bundled, tree-shaken, and uploaded to a CDN with the library baked into a JavaScript app.
The answer at that Stack Overflow question is seriously incomplete (and even it doesn’t say there’s no cache). Browsers today will, for the most part, cache CDN responses, not need to revalidate them, and share that cache across sites (though I think first-party isolation changes that to a per-site cache).
This addon is also useful when traveling in China. Since everything Google is blocked by the Great Firewall, the Google CDN is, by extension, also blocked. This breaks a lot of sites that would otherwise be reachable. Since with Decentraleyes, no requests to CDNs need to be made, those sites will continue to work as expected.
After clicking through several more times and ending up in a gitlab wiki, this seems to be how it works:
> It comes bundled with a fair amount of commonly used files, and serves them locally whenever a site tries to fetch them from a delivery network.
The docs, both on the site that is linked to and on the wiki is extremely bare bones, but the gist of it is that a CDN can track you through the `referer` header of the request for (say) jquery, since even if the browser has jquery already cached it will send out a request to check if the resource might have been modified.
> What does it do to protect me when it has no choice but to allow a request?
> Even if a resource is not locally available, Decentraleyes offers improved protection by stripping optional headers from intercepted CDN-requests. This keeps specific data, such as what page you are on, from reaching delivery networks. Whitelisting a domain does not affect this measure.
I've used Decentraleyes for a while now and it works great. I would actually like to see it—or more specifically, the idea—integrated into browsers. It would improve privacy, (potentially) security, and speed at the cost of disk space.
Was Opera's "Turbo" mode not a similar feature? A feature launched in the early mobile/late dail-up days. Albeit the proxy CDN was provided by Opera. It would take proxy JPEGs, compress them more, serve them from an edge node. It don't think it was marketed as a privacy feature but mostly bandwidth/speed. But in theory if you trust Opera, you'd get more privacy?
Opera Turbo was a bit different, I think, in that it used Opera servers as CDN and provided additional compression, while Decentraleyes uses your local file system as CDN without modifying the resources.
So proxies intercepting your traffic are fine but VPN intercepting your traffic is not?
Of course, this should be super explicit and opt-in, but Mozilla is in a position where a lot of people would trust them (you can agree or disagree whether that trust is misplaced) and if the goal is privacy and/or saving bandwidth on poor connections, this could be very useful.
I was thinking the same but then browsers have caches and most of the CDNs (e.g. jsdeliver) set max-age to a year and immutable so you're only tracked once
For privacy reasons caches are per site these days. So even if you visit 1 page using a CDN and it is cached, if you visit a different website using the same CDN it will be downloaded again.
> My browser caches downloaded CDN libraries, doesn't that protect my privacy?
> Sadly, no. Even if the file in question is stored inside of your cache, your browser might still contact the referenced Content Delivery Network to check if the resource has been modified.
Careful with performance if you're on an underpowered machine, as with all content injectors, it could provoke frequent freezes if you have a decent to large amount of tabs open.
I kind of wonder how effective these extensions are for js libraries since dependencies are often bundled into a single file. I have been using decentraleyes for a while and when I have spot checked it on occasion it hasn’t intercepted any requests on the page. I am assuming this is due to bundling.
From a security standpoint bundling is not an issue as no additional requests are made but from a speed and performance standpoint I don’t think there is much extensions like this or browser caching can do. It kind of makes me wish bundling wasn’t a thing now that we have QUIC/HTTP3 being adopted.
With all that said I am still glad to have this extension around.
Note that Decentraleyes appears to break some sites due to CSP and SRI issues. I uninstalled it months/years ago, but forgot which sites broke. The bug tracker link is at https://git.synz.io/Synzvato/decentraleyes/-/issues/16 .
According to their whitelist[1], cdnjs.com, dropbox.com, glowing-bear.org, minigames.mail.ru, report-uri.io, scotthelme.co.uk, securityheaders.io, stefansundin.github.io, udacity.com, yadi.sk, and yourvotematters.co.uk are known to have issues. For as long as I can remeber, you can also whitelist sites yourself.
The whole maintainers and forks thingy between Decentraleyes and LocalCDN seems so strange to me that I'm left with more suspicious about which should I use, if I ever should use any given their both behavior regarding the forks. I don't feel "safe" to use something so critical privacy-wise in that situation.
What's strange about it? Decentraleyes isn't being maintained very actively. The author of LocalCDN found the pace too slow and forked to update things for themselves. They are very civil about it.
Another of the million huge enhancements that could be built natively into browsers if browsers weren’t intentionally stuck in the 90s by advertising/tracking companies.
I wonder when we’ll see a real browser alternative that includes no-brainer features like bundling the most common libraries in local forever-cache by SRI hash.
To summarize some of the limitations I’ve read in sibling comments:
– Recent trend appears to be bundling resources (e.g. Webpack) instead of using CDNs.
– This trend is complemented by browsers moving to per-site caches that limit the benefit of CDNs.
– Content-Security-Policy and/or Subresource Integrity restrictions can break some websites.
– Only a limited set of resources are included with Decentraleyes.
All that said, this is a really cool idea from both privacy and performance standpoints. Would love to see ways to address those limitations in the future.
Does this addon have any security implications when used in combination with uBlock or NoScript? If the JS is being injected, does that induce any risks of JS being executed when it should be blocked?
Blocking a resource has precedence over redirecting a resource. If your blocker blocks a resource, Decentraleyes or any other extension won't be able to redirect it.
I think it intercepts the requests to load from CDN and then loads it locally. The instructions for the extension tell you to whitelist the CDNs in uBlock/uMatrix. If you are blocking them then they won't load from Decentralyze either.
If it is taking third party resources and inlining them then this extension will be breaking the protections offered by the domain and JavaScript security model.
Edit: After re-reading this multiple times, I don't think this wording is helpful. There should be a transparent description of what this extension offers before users navigate to download and install options.