Should Proxy Usage Be Included in Byte Counts?

Question

Using this challenge as an example and this JavaScript solution, you can see that Kaiido had to include the following additional 49 bytes in order to be able to retrieve the images from XKCD's servers:

i.crossOrigin="anonymous";

https://crossorigin.me/

This happens a lot with JavaScript (and, I'd imagine, other languages too). In fact, I've encountered this issue in every challenge I've attempted that requires the retrieval of a file from an external site (excluding some APIs).

My question is: should the byte count of solutions in answers that can't retrieve files directly due to restrictions in place on the servers hosting the files be penalised for having to include workarounds? Using the example above, should Kaiido's entry be considered valid without the additional code, with it only being added to the Snippet/TIO in order to demonstrate that the solution works?

Answer 1

According to this meta, if the code runs fine on a certain domain (cough, xkcd.com) then the program is valid and acceptable.

The proxy, then, is just so it can run as a snippet on SE in which case, no, the 49 additional bytes don't need to be counted.

Answer 2

Yes

I don't see any argument for removing those bytes.

1. They're a required part of the solution in that language and execution environment.
2. The bytes aren't fixed. Tomorrow you might find a shorter domain that does the same thing. Or you might find a third-party script that does the same thing, which save bytes for multiple requests.
3. A CORS proxy isn't always required, anyway.

It seems equivalent to complaining that in C you always have to waste bytes doing #include <stdlib> or something.

Answer 3

If every implementation of the language requires the proxy, yes; otherwise, no

Suppose there were a programming language which had issues representing strings (say, x simply wasn't in the language's character set). It nonetheless be able to solve the challenge via means of a proxy (although see this loophole, which might additionally make the proxy unusable due to storing information in the proxy itself); it's somewhat subjective about whether it applies. However, I wouldn't recommend saying "OK, the language doesn't have an x in its character set, let's load akcd.com rather than xkcd.com". In this case, it's a limitation of the language which means we can't load URLs directly, and working around the limitation should cost bytes.

The situation with proxies seems similar. JavaScript, as implemented in browsers, can't make a cross-origin request without extra setup code, so if you're using a browser implementation of JavaScript, you'd have to pay for that.

However, languages can have more than one implementation, and you can use whichever you like. So I'd recommend choosing one where the builtins you need don't require extra setup code to get around security restrictions. In the case of JavaScript, for example, that might involve using a non-browser implementation (there are a few to choose from), although make sure it's compatible with the rest of your answer!

(If your answer is interpreter-specific but an interpreter-agnostic version is easy to create, you might want to post the latter version as well to make the program easier to test. This is similar to, e.g., breaking up infinite loops for TIO testing purposes.)