Omissions in jQuery UI coverage

[stewie]

redundancy:
(using jqueryui as an example, but applicaple to many other libs)
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 ~~ mappings for both forms of a given library file can (should, sez me) point to a single locally cached item. Yes, I recognize that "auditability" necessitates the redundancy. Hold that thought...

omissions:
(using jqueryui as an example; I have not yet examined other other libs)
refer to
http://code.jquery.com/ui/1.11.0-beta.2/jquery-ui.js
and search in file for:
"buttonImage", "_attachments: function(input, inst) {", "attr({ src: buttonImage"

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

walk with me... (and, don't shoot the messenger, eh)
http://code.jquery.com/ui/
Effectively mirroring jqueryui would require bundling a BOATLOAD of additional resources.
Permutations: css stylesheet plus imagefiles for each available jqueryuiTHeme X libVersionPath

Next (still referring to http://code.jquery.com ) note the in-page declaration
"powered by MaxCDN"
Click the MaxCDN link, then go read about their "Origin Shield" offering.
Yeah, browser will often (still) be contacting the CDN ~~ decentraleyes will just be providing a panacea each time an apparent "first-party" subdomain is actually DNS aliased to a CDN-hosted server (which, due to geo-targeting and load balancing, is increasingly commonplace).

Clearly, the current "many-to-many" mappings construct not only begs ongoing maintenance, it prevents decentraleyes from effectively fulfilling its goal. For many of the covered libraries, I believe that efficacious handling requires an "ANY-to-ONE" approach (based on filename match). If a site developer is so stupid (or so devious) to name his custom script "jquery-1.2.1.min.js" ...so sad , too bad. We should demand that our sole permacached copy of "jquery-1.2.1.min.js" is injected, regardless of the remote URL specified by a webpage author.

Yes, I've read that you are concerned about the potential performance impact from mappings employing regex. Fuggedaboutit. 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.

Following in that train of thought, a one-size-fits-all (mobile, vs desktop) permacache doesn't seem reasonable. Each decentraleyes user will be saddled with the overhead of libraries/versions which will NEVER be specified for his device's platform.

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... Howabout let's give personal responsibility (and choice) its due. Each member of the expected userbase has chosen to use an alternative browser, has chosen to install this 'privacy' extension. So, the following is a perfectly reasonable first-run setup scenario: user is presented with a (yes, looong) treeview displaying "known" libraries for which mappings are available. 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.

quoted from issue #6

the current implementation puts even less trust in centralized delivery networks. If every user would fetch copies of files from these central parties, it technically re-opens the door for big players to inject malicious code into specific environments (highly targeted, so next to impossible to detect).

Really? C'mon, that's "a solution, looking for a problem".
No hashsums, no secret handshakes. Just map the resources so that a (the) definitive copy is downloaded from each project's site, rather than from a CDN. Alternatively, for many libs you could map to the files already mirrored here (github) by the 'jsdelivr' project.

In any event, the xpi is already 16Mb (?check my math) and is destined to grow.
Regardless whether the permacached resources are bundled inside the xpi or are retrieved at time of setup, we should bear in mind their cumulative overhead is carried in every profile sync dataset, every FEBE backup.

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. In addition to the privacy aspect, I'm enthusiastic about the HUGE amount of wasted bandwith we'll collectively avoid by using decentraleyes

[Synzvato]

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.