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).
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.
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?
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.
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.
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.
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'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
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.
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 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).
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.
51 comments
[ 2.7 ms ] story [ 112 ms ] threadThis sounds like a horrible idea.
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
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.
The developer of this extension doesn't have that.
This can be mitigated by disabling auto-update functionality and insisting on reproducible builds.
edit: What I originally wondered was what was meant with the "RIP karma" comment by the parent?
I asked this the other day on a similar comment, and the best they could do is critique Moxie for having a savior complex
seems to be unmaintained/inactive.
https://news.ycombinator.com/item?id=23780009
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.
https://git.synz.io/Synzvato/decentraleyes/-/commits/master
I don't think the goal really is to speed things up, but to eliminate the privacy-sensitive hits to those CDNs.
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.
https://codeberg.org/nobody/LocalCDN/wiki#user-content-14-i-...
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...
By flushing versions and integrity checks down the toilet, this new one could probably easily reduce traffic much further! What a great idea.
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?
Good point!
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.
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).
Cool, Font Awesome is supported