Allow manual saving of encountered libraries

[METACEO]

In agreement with one of the Essential Next Steps...

• To keep this add-on from turning into bloatware, it's important to find out which versions of which libraries are most commonly used on websites, so that less popular resources can be removed from the default bundle.

...would a library automatically be saved upon its first encounter (assuming it's from a correct CDN?..) and if so, then could the user be provided Save for future intercepts. or Ignore any future intercepts. options?

Both Noscript and RequestPolicy offer standard menu buttons with very user-friendly prompts and controls. These menus are also very powerful and in-depth, potential I believe decentraleyes also has. Better to show than tell, but if I'm intercepting jQuery 3.0.0 from MaxCDN and out of nowhere some site is using jQuery 2.0.0 from MaxCDN, it'd be nifty to allow the user to decide whether or not to save and intercept for later (especially if they plan of visiting that site often or for whatever other reason.)

Configurations could also be made to automatically save and intercept newly encountered libraries from either white-listed domains or CDNs. Maybe we could scrape together some resource digests of as many libraries we can find and simply host them from this repository... the user's add-on could then verify the resource integrity before saving.

There's a lot available!

[Synzvato]

First off, many thanks for your suggestions!

You are very right about the added value of a non-essential (desktop) user interface to give users more control over the add-on. There is a bug (issue #16) and some localization efforts that have a slightly higher level of priority at the moment, but this is definitely on the radar (see #6 and #18).

I like your ideas on how to design the user interface. One thing to note, though, is that the bundled versions are also the most commonly used resources (according to W3Techs).

Allowing a website to fetch a resource that is extremely rare, would have a minimal effect on privacy apart from the fact that repeated integrity checks will not be sent out to the CDN when the user visits the website in question. That's why letting the end-user decide is definitely the way to go.

Last (but not least), Decentraleyes was originally designed to be a set-and-forget solution. That's why, once there is a panel, it might be best to not automatically place the corresponding toggle button on the toolbar. It's arguably better to make it a non-default tool that advanced users can enable.

Any other remarks or suggestions? Please post your response under either #6 or #18 depending on the exact subject. Thanks again for sharing your thoughts!