fix(browser): broaden the Canvas blocklist entry to instructure.com - #1202
Merged
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The blocklist seed was the single host
boisestatecanvas.instructure.com. It is nowinstructure.com, which covers that host and its subdomains — so the.test.and.beta.Canvas instances are no longer unlisted side doors.Chromium's
URLBlocklistmatches 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.eduload 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_webto a blocked host is refused withERR_BLOCKED_BY_ADMINISTRATOR.automationStream: DISABLEDwhile 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 --noEmitclean.🤖 Generated with Claude Code