Omissions in jQuery UI coverage about decentraleyes HOT 1 CLOSED

By convention (if not outright definition), the minified copy of a js library file must not substantively differ from the non-minified file. Therefore, no need to mirror both.

You'll be happy to know that both non-minified and minified resources are mapped to the very same minified local file. So, technically, this proposal is already in place.

Currently, decentraeyes "bundle" does not consider the imagefiles employed as jqueryui buttons -- therefore is ineffectual in preventing contact with the CDN.

It's only ineffective if you do not block requests for missing resources. jQuery UI's core scripts are in place to keep various websites from completely breaking when you run a strict policy.

Clearly, the current "many-to-many" mappings construct not only begs ongoing maintenance, it prevents decentraleyes from effectively fulfilling its goal.

So, in essence you're proposal entails generalizing the concept to any website. Feel free to post your thoughts on this inside the existing issue about it #4. I'm always open to new ideas, but I would very much like to stress that the current system is anything but ineffective.

With attention to what I've outlined above, along with attention to the limited storage space available on client mobile devices, the necessity of employing text.replace() regex matching should be clear.

I don't see how a different resource mapping system would suddenly make Decentraleyes require less storage space. I also don't see any severe issues that beg for an acute drastic overhaul.

I have also read that you intend decentraleyes to serve as an "install-n-forget" extension. Why so? Feed a man a fish vs teach a man to fish...

Yes. Decentraleyes is, in the first place, an install-and-forget extension. Privacy should be accessible. In the future, there will be a non-default (optional) user interface for power users. Teaching a man to fish is one thing, but I highly doubt regular web users want to worry about configuring a CDN emulator.

All entries (perhaps 2 groupings, mobile-relevant vs general) are tickmarked by default. User self-selects which libs he wishes to permacache and, at that juncture, the extension retrieves and permacaches the selected libs/resources.

Again, an advanced mapping system and an interface for power users are all nice ideas, but there is no direct urgency here. The add-on is just over 5 MB and contains a pre-selection of library versions that are known to be commonly used (according to web crawling statistics).

Really? C'mon, that's "a solution, looking for a problem".

I don't agree with that. Decentraleyes was designed to cut off the middleman. So, making it depend on CDNs (or other remote resources) in any way would go against the project's core principles. I want to be absolutely sure that what's included (and signed by Mozilla) is what people load up.

In any event, the xpi is already 16Mb (?check my math) and is destined to grow.

It's just over 5 MB, actually. It might grow a bit when new types of resources are included (such as popular web fonts, or style libraries), but it's not going to keep growing uncontrollably. Since only popular library versions are included, the bundle will simply follow usage trends.

Please understand that I share your goal of achieving enhanced privacy and I have great enthusiasm for the decentraleyes project. I trust you'll look beyond any 'abrasiveness' which might be inferred from my prose.

I'm very happy to hear you're excited about the concept. No offense taken. I highly welcome user input and proposals. One request though, please split separate topics up into individual issues. That way it's easier for me (and others) to keep track of things. Also, Pull Requests are welcome.

from decentraleyes.