Add the supportedSurrogates.json file

[kzar]

If the block list is more recent than the bundled tracker-surrogates, it's possible that requests will be redirected to a file that does not exist. To handle that, we need a list of currently supported surrogate scripts that can be checked before performing the redirection.

Notes:

• Along with mapping.json, supportedSurrogates.json should be updated manually when scripts are added/removed from the repository.
• It was decided not to use the existing mapping.json file for this purpose, since we want to maintain flexibility in the mapping.json file format by avoiding using it for any other purposes.

[jonathanKingston]

Nice thanks.

Can you move over the generation of this file from the extension to reduce the chance it's maintained wrong?

[kzar]

Nice thanks.

Can you move over the generation of this file from the extension to reduce the chance it's maintained wrong?

There's not really a build step in this repository, so I don't see how to do that without adding a manual "type this command" step that could also be forgotten. Open to suggestions though.

[jonathanKingston]

IMO a script is better than nothing, I agree there's no build step. Automating it to ensure the script is ran on each commit to ensure it's been ran would be simple enough (we do this in C-S-S to ensure the checked in files are correct)

[kdzwinel]

I don't understand why we need this. Why extension can't check while creating a rule if surrogate file exists? Why creating that list while bunding surrogates is not good? Does any other platform need that?

[kzar]

IMO a script is better than nothing, I agree there's no build step.

OK, I have added a script similar to the existing test-mapping.js to catch mistakes in supportedSurrogtes.json.

I don't understand why we need this. Why extension can't check while creating a rule if surrogate file exists? Why creating that list while bunding surrogates is not good? Does any other platform need that?

We need a list of supported surrogates to know if a request that matches a surrogate rule should really be redirected (see commit message / PR description). Previously, I was going to generate that at build time in the extension code, but @jonathanKingston suggested instead having the file be a part of the tracker-surrogates repository (especially since now all surrogates are in the tracker-surrogates repository, previously the CTL ones weren't).

[kdzwinel]

I see. I don't think it's worth arguing about, so if you feel strongly about having this here please go ahead, but I don't understand the motivation. We are making something that was automatic half-manual and duplicating information in this repo. If extension is the only platform benefiting from this helper file I don't see a point of putting it here.

[kzar]

I see. I don't think it's worth arguing about, so if you feel strongly about having this here please go ahead, but I don't understand the motivation. We are making something that was automatic half-manual and duplicating information in this repo. If extension is the only platform benefiting from this helper file I don't see a point of putting it here.

I don't feel too strongly about it, but to be fair I think having the list in tracker-surrogates makes as much sense as the alternative. I think so far the only consumer would be the extension, but in the future I could see it being used by other products + it might help avoid accidental dependencies on mapping.json that we are trying to avoid. This way, we could also add supportedSurrogates.json to the reference tests which would be a bonus, I've had to hard-code the list of test surrogate scripts so far (or I would have had to write a basic parser for the test surrogates.txt.)

[jonathanKingston]

or I would have had to write a basic parser for the test surrogates.txt

The extension could optionally call into privacy-grade which would avoid duplicating anything. We could then clear up privacy grade to remove the .txt file.