LocalCDN – an extension that emulates CDN to improve your online privacy | Hacker News Reader

LocalCDN – an extension that emulates CDN to improve your online privacy

localcdn.org

68 pointsURfejk49 comments

The flowchart [1] looks wrong to me. The website says load jQuery v3.3.1 and LocalCDN loads jQuery v3.4.1 instead while removing integrity checks. LocalCDN seems to assume that it knows better than the website which version of a library works for that site. It may be harmless for certain library versions, but could wreak havoc for others. Sorry, this is not responsible behavior from an extension.

I looked at the wiki and found this: [2]

> Can I check if LocalCDN really works?

> Yes you can

Really??? This sounds like a snarky answer instead of providing some ways for a user to check that it works.

I think I'll stick with Decentraleyes for now.

[1]: https://www.localcdn.org/img/replacement.png

[2]: https://codeberg.org/nobody/LocalCDN/wiki#user-content-11-ca...

The "Yes you can" expands when you click on the arrow next to it. No obvious though. ( Might be new? )

I'm using LocalCDN for a few weeks and it looks pretty good so far. The developer once answered me and said that there are so many jQuery versions and that the extension would be very big. I checked and there are actually over 150

I have used Decentraleyes for a long time and it has only offloaded me 55 times. That is less than I thought.

By flushing versions and integrity checks down the toilet, this new one could probably easily reduce traffic much further! What a great idea.

I don't get why it removes integrity checks.

SHA checks should be fast enough, and it a "must have" feature for an extension promising to replace a file with another.

The add-on is from a user "nobody" that was registered early this year, vs decebtraleyes from a real name account from 2013.

It's probably to get better cache hits. Otherwise they need to store every version of jquery, for instance.

Yes, they do. That's kinda the point here.

Apparently it will potentially use a different version of the library, so the hash of course wouldn't match. That feels like a wrong decision to me.

Lol "If you just need a name to trust me, just call me Marc"

https://codeberg.org/nobody/LocalCDN/wiki#user-content-14-i-...

I used to use this extension, but it broke multiple sites and I decided to uninstall it.

It might be because it doesn't always return the exact resource the site requests, like it will upgrade jQuery v1.2.3 to v1.4.2. It could also have to do with CORS.

'SOP = Same-origin policy': https://codeberg.org/nobody/LocalCDN/wiki#user-content-7-a-w...

For what it’s worth I’ve used Decentraleyes, which this extension is forked from, for years and have never noticed it break a site.

Yep, when I used Decentraleyes it was always fine. Only LocalCDN broke things.

Yes, because decentraleyes have an internal list of problematic URLs and disables itself without the user can see that. The icon is still green. I think this sucks because the user is being deceived.

Ah, that is good to know and unfortunate.

Sounds similar to Decentraleyes. How is LocalCDN different?

Look here: https://codeberg.org/nobody/LocalCDN#user-content-difference...

Why is it removing integrity?

"... remove crossorigin and integrity attributes of script and stylesheet tags to increase replacements ..."

Yeah but I don't understand why that would be needed. It sounds dangerous.

With these things you can't replace anything. The website has to be whitelisted or you live with the fact that the libraries can't be replaced and the site is broken.

Indeed - integrity should be dependent on the content, not the URI. It looks like they do it to allow "replacements" (e.g. serve package version x.y.z-1 if it can't find x.y.z).

This sounds like a horrible idea.

It seems that it is "upgrading" libraries. If you look at the graph it replaces jQuery 3.3.1 with 3.4.1.

Two reasons:

1. It deliberately replaces some versions of libraries with different versions. That's a feature I could do without.

2. The use of integrity hashes on cross-origin resources breaks Decentraleyes[0], and it's not fixable without browser changes.[1]

[0]: https://git.synz.io/Synzvato/decentraleyes/-/issues/16 [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1419459

It's a fork of decentraleyes, why not contribute to it?

And I'd have to trust substantial permissions to an addon from 'nobody'. I don't believe in mandatory real-world identities but at least have a nick with some street cred :) Trust is important with browser extensions, just look at the news today about Nano Defender being compromised and spamming Instagram likes: https://github.com/jspenguin2017/Snippets/issues/5

Just saying, this is something I'll skip for now for the above reasons, but I'll keep an eye on it.

Loads of people use Signal by "Moxie Marlinspike" though, and whenever I bring that issue up here its RIP karma.

https://en.wikipedia.org/wiki/Moxie_Marlinspike

Yeah but that's an example of a nick with good street cred :)

The developer of this extension doesn't have that.

But the issue itself is what?

The issue is that even with open source software, "trust" enter into play when everyone cannot possibly inspect the source code at every update. So the publisher of the software does need a certain amount of (subjective) "credibility", even though the source is available.

This can be mitigated by disabling auto-update functionality and insisting on reproducible builds.

I agree. Even if I theoretically could inspect the sources I never do, and pretty much solely rely on "if this had something malicious in it, somebody would have screamed about it already".

edit: What I originally wondered was what was meant with the "RIP karma" comment by the parent?

Whenever I brought it up in past, I got downvoted to oblivion. I find that peculiar. Although it is not OK to complain about moderation.

What's the issue though? Their bio seems fine, they're experienced//well known, the signal protocol is open-source with no issues thus far as I'm aware...

I asked this the other day on a similar comment, and the best they could do is critique Moxie for having a savior complex

The issue depends on the software. In this case, the stakes are high, and the government already knows the developers name for sure, so I don't understand why they try to obfuscate their name given the importance of the application.

>It's a fork of decentraleyes, why not contribute to it?

seems to be unmaintained/inactive.

https://news.ycombinator.com/item?id=23780009

The libraries of Decentraleyes are completely outdated

Browsers are already bloated as it is, why not just add all those "popular" libraries to the browser and make things local fetch by default? No, i'm not talking browser extensions because that would require users to proactively install something for a webmaster (yeah, i said "webmaster", i don't care if it shows my age)...I'm talking about integrating the top X most implemented javascript libraries into the browser itself...why not just do that i wonder?

I'm half-winking as i state this (bloated aspect) because i give much respect to browser makers for all that browsers actually do/have to do for us when rendering web experiences. So, i don't take adding even more stuff into browsers as a simply, hand-wavy thing to consider. But I also wonder if these libraries do in fact provide such helpful (and ubiquitous) utilities, why not incorporate them into the default - what is called - ecmascript?

I'd prefer browser makers focus on improving the browser and stack support, and leaving "creative functionality that only a fraction of the users might want" to extension authors. I don't need the already tiny number of folks actually working on a browser to be spread even thinner by also having to become versioned registry maintainers (because you can bet your teeth no one's going to hire additional FTEs for that)

> ...I don't need the already tiny number of folks actually working on a browser to be spread even thinner...

Good point!

I long wondered, we have long had sha 256+ hashes being used for SRI, but why haven't we used them for global caching?

Browsers move in the direction of removing any cross-origin caches to reduce fingerprinting and other information leaks.

A browser vendor could just decide to prepopulate the cache with 20 MB of the most common minified JS libraries, though. That would only fingerprint the browser version, not the user.

I just looked at the source code. It isn't difficult to understand. Same as decentraleyes. Looks like removing integrity is only optional per site or permanent for all. The remove list then becomes a non-removable list. The libraries are so far identical to those of Cloudflare.

Cool, Font Awesome is supported

What is the difference between this and Decentraleyes?

I had the idea to write a HTTP proxy which parses all traffic and caches CDN results on a local network and use those instead, but this might be even better.

Huh, isn't that just a normal caching HTTP proxy like Squid?

If 2 sites both use jquery.cdn/1.3.4/jquery.min.js, your browser should have it in the cache, or alternatively your caching proxy server would just serve you the bits it already downloaded earlier.

> Huh, isn't that just a normal caching HTTP proxy like Squid?

I don't think caching HTTP proxies are as useful any more now that most sites are using HTTPS. They can't easily cache content from origins that use TLS due to the encryption, unless you install a root certificate that allows the proxy to spoof any origin.

You could connect to the proxy via HTTP which then uses HTTPS to the origin, but then you'd get mixed content warnings (loading scripts via HTTP when the page is loaded via HTTPS).

Are there any benchmarck of localCDN/decentraleyes? I always wondered how much it can improve performance by reducing download time to zero

I haven't noticed any (however haven't done any benchmarking either) but of course these CDNs are fast, that is their primary job.

I don't think the goal really is to speed things up, but to eliminate the privacy-sensitive hits to those CDNs.

Reply on news.ycombinator.com