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