Skip to content

fix(browser): broaden the Canvas blocklist entry to instructure.com - #1202

Merged
philmerrell merged 2 commits into
developfrom
fix/browser-blocklist-canvas-aliases
Sep 20, 2026
Merged

philmerrell merged 2 commits into
developfrom
fix/browser-blocklist-canvas-aliases

Conversation

@philmerrell

@philmerrell philmerrell commented Sep 20, 2026 •

Copy link
Copy Markdown
Contributor

What

The blocklist seed was the single host boisestatecanvas.instructure.com. It is now instructure.com, which covers that host and its subdomains — so the .test. and .beta. Canvas instances are no longer unlisted side doors.

Chromium's URLBlocklist matches on host, not on the service behind it, so a site is only as blocked as its hostname list is complete. The config and test now say so, and say to enumerate a service's aliases before adding it.

Correcting an overreach in this PR's first version

I saw canvas.boisestate.edu load during a takeover and called it a bypass. It isn't — that is Boise State's sign-in / discovery page, not the Canvas app. Phil corrected it.

The first version of this PR blocked it, and that would have been actively wrong: reaching a login page is exactly what an accessibility or VPAT review needs to do, which is the use case this feature exists to serve. I would have broken the primary purpose to defend a page where no work is submitted. It is now explicitly not blocked, with a test asserting the seed does not swallow it.

What is verified

  • browse_web to a blocked host is refused with ERR_BLOCKED_BY_ADMINISTRATOR.
  • The live view works end to end: a human drove the remote browser during a takeover.
  • automationStream: DISABLED while the user holds it, so the agent is provably locked out.

What is NOT yet verified

Signing in from the discovery page and confirming the destination is refused. The doorway being open is fine; the room must not be. That is the test that decides whether this control actually holds, and it needs one more takeover.

Suite: 881 pass, tsc --noEmit clean.

🤖 Generated with Claude Code

philmerrell and others added 2 commits September 19, 2026 18:22
The blocklist was DEFEATED on dev in about ten seconds. During a takeover a
human typed `canvas.boisestate.edu` and the Canvas login page loaded
normally. The list contained only `boisestatecanvas.instructure.com`.

Chromium's URLBlocklist matches on HOST, not on the service behind it. Both
names resolve into Instructure's 99.86.101.0/24 and serve the same LMS, so
naming one of them stopped nothing that mattered — a student would use the
address they already know.

The enforcement mechanism was never the problem: the agent is refused with
ERR_BLOCKED_BY_ADMINISTRATOR, and that holds under human control too. The
DATA was wrong.

  instructure.com        covers the host AND its subdomains, so the
                         boisestatecanvas/.test/.beta instances are included
  canvas.boisestate.edu  is not a subdomain of anything blocked and has to
                         be listed on its own

The general lesson, recorded in both the config and the test: when adding a
site, enumerate its aliases FIRST — vanity CNAMEs, regional hosts, the
mobile hostname. A list naming only the obvious host is a control that looks
real and is not, and it fails silently because the blocked name still blocks.

Mutation-checked: restoring the single-host list fails both guards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Correcting my own overreach. `canvas.boisestate.edu` is Boise State's
sign-in / discovery page, not the Canvas app, so seeing it load during a
takeover was not the bypass I called it.

Blocking it would have been actively wrong: reaching a login page is exactly
what an accessibility or VPAT review needs to do, which is the use case this
feature exists to serve. I would have broken the primary purpose to defend
against a page where no work is submitted.

What survives from that alarm is a real improvement. The seed was the single
host `boisestatecanvas.instructure.com`; it is now `instructure.com`, which
covers that host AND its subdomains, so the `.test.` and `.beta.` Canvas
instances are no longer unlisted side doors.

Still unverified, and the thing that actually decides whether this control
holds: signing in from the discovery page and confirming the destination is
refused. The doorway being open is fine; the room must not be.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@philmerrell philmerrell changed the title fix(browser): block Canvas by all its hostnames, not just the vendor one fix(browser): broaden the Canvas blocklist entry to instructure.com Sep 20, 2026
@philmerrell
philmerrell merged commit 6088af1 into develop Sep 20, 2026
6 checks passed
@philmerrell
philmerrell deleted the fix/browser-blocklist-canvas-aliases branch September 20, 2026 00:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant