Write mapping exceptions for mixed case CDN paths

Created by: Gitoffthelawn

Handle jquery from ajax.aspnetcdn.com

Example site: https://www.codeplex.com/

This is a very interesting find! Thanks for sharing. It's caused by the fact that this website does not use the /jQuery/ example provided by Microsoft but went for a lowercase /jquery/ implementation.

I must say that I find it quite strange that Microsoft uses uppercase characters in example URLs, and I can see why Codeplex thinks it looks better without the capital letter.

Since URLs are case-insensitive by nature, Decentraleyes should not behave the way it does. Taking case sensitivity out of the mapping mechanism should prevent these sorts of issues.

Created by: Gitoffthelawn

Thanks!

Created by: austinhartzheim

@Synzvato I would like to point out that URLs are case-sensitive according to the W3C.

By introducing this behavior, it is now possible to fingerprint users of this add-on by trying to load a script that would normally fail due to an upper-case URL.

For example, I could include this normally broken script in my page:

<script src="https://cdn.jsdelivr.net/jquery/3.0.0-beta1/jQuery.min.js"></script>

and then check if jQuery becomes available. If it does, the user is likely using this add-on.

As a solution, maybe we can add a case-insensitive setting in mappings.js.

@austinhartzheim Great points, thanks for the corrections! Since there are currently no more than two mixed case entries in the mapping file, it might be best to write up two exception entries.

Created by: austinhartzheim

@Synzvato These changes can now be fingerprinted in reverse. For example, by using an upper-case variation of the file name that we don't have a rule for.

To gain additional certainty that this add-on is in use (as opposed to a general script/connection blocker), a website could load one file with a lower-case name and a second file using an uppercase variation that we don't have an exception for.

I think the best solution is adding a setting to the mappings file indicating if it is case-sensitive and then performing the .toLowerCase() transformation only when a case-insensitive CDN is used.

{
// ...
    'ajax.aspnetcdn.com': {
        'case-sensitive': false,
        'urls': {
            '/ajax/': {
                'jQuery/jquery-{version}.': resources.jQuery,
                'jquery/jquery-{version}.': resources.jQuery,
                'modernizr/modernizr-{version}.': resources.modernizr
            }
        }
    },
// ...
}

@austinhartzheim

These changes can now be fingerprinted in reverse. For example, by using an upper-case variation of the file name that we don't have a rule for.

A failing request would be less telling than a successful response from an invalid path. Also, if we would want to cover all of these edge cases, we would have to implement all kinds of other exceptions like URL query strings ?decentraleyes=true as well. It might be best to discuss this inside of a new issue.

To gain additional certainty that this add-on is in use (as opposed to a general script/connection blocker), a website could load one file with a lower-case name and a second file using an uppercase variation that we don't have an exception for.

By default, Decentraleyes allows requests for missing resources to go through. So both the lowercase and uppercase load attempts will be successful. In addition, the add-on does not inject any resources that are blocked by any other types of content blockers (e.g. uBlock Origin).

mentioned in issue #306 (closed)