Some Derivita questions load resources (diagrams, math libraries, visualizations) from third-party servers. If your school or district blocks these servers, those questions will show a loading spinner that never finishes. This page checks which servers are reachable from this computer so we can give your IT team a precise list of what to allow.
| Resource | Used for | Status | Time |
|---|
Each row issues an HTTPS request from this browser to a known asset on the listed origin. There are two kinds of check, and they prove different things.
Rows reporting "Image loaded" or "Image blocked" download a real image and require it to decode at its known pixel dimensions. This is the stronger check: a block-page interstitial, a truncated download, or a filter-substituted placeholder image all register as Image blocked. These rows are cache-busted on every run, so a previously cached copy cannot mask a live block.
Rows reporting "Reachable" or "Blocked" only establish that the origin answers at all — DNS resolves, the connection is accepted, and TLS completes. They cannot read the response, so a content filter that intercepts the request and returns its own HTTP response still registers as Reachable. Treat Reachable as "not blocked at the network layer," not as "working."
How to read the three
storage.googleapis.com rows. That host is
checked both ways on purpose, and comparing the results tells you
where the problem is. If the (domain) row fails, the domain
is blocked or unreachable and allowlisting it is the right fix. If
the (domain) row passes but an image row fails, the domain
is already allowed — something is inspecting or rewriting the
content itself (TLS interception, image scanning, or response
rewriting), and allowlisting the domain will not fix it. If the
small image passes but the large one fails, the filter is treating
images differently by size: payload scanning, truncation, or
bandwidth shaping.
How to read the two cdn.jsdelivr.net
rows. Both hit the same host on different library paths.
Filters commonly allow a CDN by hostname and still block
individual paths or file types under it. If
(components) passes but (interactive diagrams)
fails, JSXGraph is being blocked specifically and interactive
geometry diagrams will hang on an empty frame even though the
rest of the app works.
The three interactive figure rows. Figures — the
graphs and diagrams students drag and click — do not load like the
rest of Derivita. Each one renders inside a frame served from
storage.googleapis.com, and that frame reaches back
across to homework.derivita.com for its styling and
fonts. That cross-domain request is a different kind of request from
the ones every other row makes, and filters routinely treat it
differently, so these rows can fail while every other row on
this page passes. If any of them fails, figures will appear
as blank boxes, or with unreadable numbers and labels, even though
Derivita otherwise works normally — students can log in, open
assignments, and answer ordinary questions. The styling and math font
rows are checked from a small test page on
storage.googleapis.com, so they make the same
cross-domain request a figure makes; if that test page itself never
loads, they say so rather than report a result. Allowlisting the two
domains is not enough on its own; the filter must also leave the
content and its headers alone.
If images are missing but every row passes: the
most likely causes are TLS interception, image content scanning, or
DNS redirection applied to
firebasestorage.googleapis.com, which hosts every
user-uploaded image and has no public asset this tool can verify.
Allowlisting a domain does not help when enforcement happens at one
of those layers. Capture the failing request from the device's
browser developer tools and send it to Derivita support.
The "Show" buttons. Rows that downloaded something you can look at keep it and offer to reveal it: the images, the figure page, and a figure drawn by the drawing library that arrived. Revealing costs no new requests — it displays what the check already had in hand, so what you see is what the check saw, from the same request in the same context. Opening a link to the same address instead would be a fresh, top-level request that filters routinely treat differently, which is how a blocked resource comes to look fine. Nothing a check reports depends on whether you reveal it.
The build line at the bottom of this page identifies the exact copy you are running. A proxy or filter can serve a cached older copy of this page whatever it asks for, so if Derivita support asks for that string, read it out — it is the only way to confirm which version you are actually seeing.
To allow blocked resources, allowlist the listed origins on your
network's web filter. Origin-level allowlisting (e.g.
cdn.jsdelivr.net) is the right starting point, but it
is not sufficient on its own if your filter also decrypts, scans,
or rewrites traffic for those origins.