
Loading…
Consider not storing lists assets on Github #84
If I link directly to the source, I lose the ability to download only what changed -- this is detected through https://github.com/gorhill/uBlock/blob/master/assets/checksums.txt, and the ability to ensure that the resource was downloaded properly.
I can see there could be a problem if ever the extension become way more popular than I expect. Now I am worried.
I suppose I should fix #6 asap, so that the infrastructure to download the lists from other sources exists. For the critical resources though, I need to still rely on the above checksums.txt file and download directly from Github -- but these critical resources are either small (ex. https://github.com/gorhill/uBlock/blob/master/assets/ublock/filter-lists.json), or either change rarely (ex. https://github.com/gorhill/uBlock/blob/master/assets/thirdparties/publicsuffix.org/list/effective_tld_names.dat).
Thinking about it, I could update the resources every day, and reflecting the result in the checksums.txt file, but download from original sources and still validate the downloaded result against the checksum entry on Github.
Ok, I think I will address this the following way:
The checksums.txt is too useful, I will still rely on it. Aside ensuring download went well, it allows to download only what is changed, so it does save bandwidth for both sides (I could improve this to further download only what is used).
For each resource found to have a new version, the original source URL version will be tried first. If there is an error, or if the checksum doesn't match, the Github repository will be tried. If this also fails (network, error), the current cached copy will be used (that's the current behavior), and if there is no cached copy, the install copy is used (that's the current behavior).
As their policy does not encourage it. As more people starts to use uBlock, you might end up with a disabled repository.
https://github.com/blog/1482
Or uBlock could download directly from the original source.