No, I'm not going to do that. I absolutely hate even _considering_ changing
how I want to do something for an extension that doesn't know the difference
between an IP address and a script.

There are no "Scripts" on the remote IP addresses.

Putting everything into DNS would be a problem. They are ephemeral
IPs (not all, but some), literally the cloud may bring some up for an hour
and then take them down, then bring them up with another IP.
And keeping DNS uptodate even with low TTL is a problem plus I have
fast learned that many people do not have reliable ISP DNS servers.
Some are missing info, some are very slow, some are flaky. The
test is not testing DNS reliability. There are other tests that do that
pretty well.

So .. No. lol.

I have however made the error crystal clear, it now instructs the user
to set the noscript option to "Cascade" permissions from the page
to "3rd party scripts" (lol).

To give an example of the kind of ridiculous stuff these extensions do:
a user wanted to know why something was broken on the site because
they "did not trust cloudflare.com" (which hosts jQuery for everyone).
Now if I change the location of that resource to "cdn.dslreports.com",
it would be approved by noscript  because the user trusts us.
However cdn.dslreports.com is run by.. Amazon CDN. Exactly and
perfectly the same, from a privacy/security viewpoint.

Another example, the people spending days tinkering with their noscript
or other security setup will one-click accept flash (if they wanted to run
a speed test). Or more probably, just whitelist flash, because youtube
was all flash and they want their videos. Right, that's real secure. flash
is a black box to noscript.

Alright I'm going to go away and bang my forehead against the wall now
it is more productive than thinking about NOSCRIPT !

/rant

On Sun, Apr 26, 2015 at 4:26 PM, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:
On 26/04/15 06:17, jb wrote:
> The warning is correct in that it is probably NOSCRIPT. I think.
> All the speed test knows is that an API call to all servers was brutally
> failed
> in an unexpected way. There is no visibility into what caused the
> failure, only
> that it should not occur in a clean browser. If you open the console
> you can probably see more than the javascript gets told.

Hi Justin,

I think the problem is that you may be referring to the test servers by
IP address rather than by DNS names. Here is why I think that:

I picked Noscript's "disable everywhere" option, then successfully ran
the test. I was then able to see in Noscript which sites were running
scripts and saw a number of IP addresses among them. I then added these
IP addresses to the whitelist, re-enabled Noscript and verified that I
was able to still run the test.

If you are able to put all of these servers in a DNS domain under your
control then a single whitelist entry in Noscript would make them all
work, and not just the ones that are being picked at my location.

By the way: I then re-enabled Adblock and was still able to run the
test. So I recommend blaming Noscript in the error message rather than
Adblock (and then perhaps also mentioning the whitelist rule that fixes it).

Thanks, Jan