Built to keep your course data in your hands

Morrow runs in Chrome on your own Canvas session. Proxy swaps student details for stable local codes before AI sees them. Your reports and course work stay in your browser; Morrow's backend only ever sees your account email and subscription status.

Reports and evidence stay in your browser, never on Morrow’s servers The AI runs through the ChatGPT account you connect, not one Morrow operates Local-first operations keep active course data and cookies in your session
Last reviewed June 23, 2026

The short version for reviewers

Three properties define Morrow’s posture. The rest of this page is the detail behind each one.

A Manifest V3 extension

Morrow ships as a Chrome MV3 extension. All executable code lives inside the package: no remote code, no eval, and no scripts loaded from a CDN. This is a hard platform requirement and Morrow’s standing posture.

Client-side, on your session

Morrow acts inside your browser, using your existing Canvas login. It reads and edits the course you authorize, as you, the way you would yourself.

Course-changing work is not performed by a hidden server. Only account sign-in and subscription checks use Morrow’s cloud services.

Reports Stay In Your Browser

Active course data, chats, and generated reports all stay in your browser. Nothing about them is synced anywhere, and the local Proxy map never leaves your device either.

Where your data goes, and what stays out

Morrow sits between your browser, Canvas, and your own AI account. The diagram is the data-flow map; the table below names what crosses each boundary.

Chrome + Morrow runs beside your course Proxy map Learner A1 ↔ the student browser only Canvas (your LMS) current Canvas course data ChatGPT (your AI account) stable codes, no map Morrow cloud account + subscription only
Your active course data, chats, and generated reports all stay in your browser session. Proxy keeps the code-to-name map local and sends stable codes to your AI account. Morrow's backend stores only your account email and subscription status — it never receives your course content or reports.

Data flow: Morrow runs in Chrome, reads Canvas through your session, Proxy keeps the local code map in the browser, and sends de-identified requests to your AI account. Morrow's backend only ever sees your account email and subscription status, never your course content or reports.

  • Canvas stays the source of current course data. Morrow reads it through your browser session.
  • Proxy links real students to stable local codes in the browser and strips student-identifying details before a request reaches your AI account.
  • The AI provider receives stable codes, not the local code-to-name map.
  • Morrow's backend stores only your account email and subscription status. It never receives your course content, chats, or reports.
Data boundaries: what crosses, and what stays out
Boundary What crosses it What stays out
Browser → your AI provider Redacted chat and the course context you ask about Student names and IDs, session cookies, account credentials
Browser → Canvas Canvas API calls made as you, for the course you authorize Data from any other site or course you have not opened
Browser → Morrow account backend Account email and subscription status only Course content, chats, reports, student-identifying details, Canvas credentials, or payment card numbers
Browser → unlisted destinations No configured product route Course data sent by Morrow

Every Chrome permission, in plain English

Morrow maps each Chrome permission to a product capability. The table below gives reviewers the reason for each one.

Host access scope. Morrow uses host access for the Canvas origin you authorize, the connected AI provider, and Morrow account services used only for sign-in and subscription status.

Chrome describes that permission broadly, but the actual origins are listed below and tied to specific capabilities.

Because Morrow works through your Canvas session, it registers no server-side OAuth app and requests no Canvas API scopes of its own. The only OAuth in play is the scoped sign-in to your own AI account.

API permissions

  • sidePanel Opens Morrow as a panel beside your Canvas course pages. This is the whole product surface.
  • storage Saves your settings, session state, and audit history on your device.
  • unlimitedStorage Keeps local chat and report history from hitting Chrome’s small default quota.
  • tabs Recognizes the active Canvas tab so conversations bind to the right course. Morrow does not keep browsing history.
  • scripting Attaches packaged Morrow code to the Canvas tab or custom Canvas address you authorize.
  • cookies Uses your existing Canvas login for Canvas API calls. Cookies are read in flight and never stored by Morrow.
  • downloads Saves generated reports and exports, including PDF, Word, HTML, and JSON files.
  • offscreen Builds document exports in a background extension page, using code packaged inside Morrow.
  • alarms Clears old finished background tasks and stale local work on a schedule.
  • notifications Tells you when long-running work finishes or needs approval while the panel is closed.
  • clipboardWrite Powers the Copy buttons on chat messages and code blocks.
Host permissions: the exact sites Morrow may reach

Host permissions are tight, named origins. Morrow talks to Canvas, to your own AI provider, and to the Morrow account API listed in the extension manifest. It does not request every site by default.

  • https://*.instructure.com Talks to your Canvas site as you. Institution subdomains cannot be known in advance, so the match covers your school’s Canvas host.
  • https://*.beta.instructure.com · https://*.test.instructure.com Works on the Canvas beta and test environments some institutions use for staging.
  • Canvas New Quizzes hosts (quiz-lti.* and quiz-api.*, by region) New Quizzes runs in separate Canvas frames and APIs. Morrow needs the region your institution is hosted in to read and edit New Quizzes.
  • Your own AI provider (api.openai.com, auth.openai.com, chatgpt.com) Sends your redacted messages to your own AI account, and lets you sign in with ChatGPT.
  • meetmorrow.app account API Checks your Morrow account and subscription only, never course content. The exact production origin is listed in the extension manifest and customer security packet.

Custom Canvas web addresses. Some schools serve Canvas from their own domain. Morrow does not request a broad wildcard up front.

When you authorize your school’s address in Settings, Morrow asks Chrome for that one exact origin. Nothing is granted without your explicit action.

Proxy checks before anything reaches AI

AI-bound course text passes through Proxy in your browser first. Known student names become stable, de-identified codes, so the AI can act on Student X without ever receiving the name.

The same layer strips the identifiers it recognizes (names, student and user IDs, email addresses, phone numbers, and other personal details) from chat context and gradebook rows.

In the current extension architecture, Proxy is the AI-bound text path.

Student-identifying tool data is also kept out of saved history and stripped from exports. Proxy checks AI-bound requests automatically.

What Morrow’s backend stores

Morrow's backend manages account sign-in and subscription status only. Course work and generated reports stay entirely in your browser and are never sent to Morrow's servers.

Account & Subscription Only

Our backend manages sign-in and verifies your subscription status. It never receives your reports, course content, Canvas credentials, AI API keys, raw rosters, or local Proxy code map.

Account Status

The backend checks account and subscription state only. It does not receive Canvas credentials, raw course content, reports, rosters, grades, session cookies, or AI keys.

Stored records are deliberately narrow. Morrow's backend stores only your account email and subscription status — generated reports and alignment evidence never leave your browser.

Account and subscription records are the entire storage boundary, so course reports, raw rosters, grades tied to names, Canvas credentials, and the local Proxy code map are never stored on our servers.

If the backend were compromised, there is no course evidence to expose: it stores account details and subscription status only, never reports, course content, or student identifiers.

Canvas access remains governed by your institution. Active editing and analysis run inside the authenticated Canvas session you already hold. Morrow does not bypass Canvas sign-in, provisioning, roles, or permissions.

No product analytics or usage tracking. Morrow does not collect product analytics, usage pings, or crash reports in this posture.

Admin and deployment controls

Institutional control stays where reviewers expect it: Canvas roles in Canvas, AI terms on the connected AI account, and Morrow records limited to account state and subscription status.

Canvas roles stay authoritative

Morrow works through the Canvas user who is already signed in. Course access, permissions, sections, and enrollments remain controlled by the institution.

AI account stays customer-controlled

Each user or institution connects its own ChatGPT or OpenAI account. Morrow does not run a shared model account for customer prompts.

Evidence can leave with the institution

Reports, readbacks, and audit evidence export as review materials. The institution keeps its own retention rules for exported files.

Morrow account services stay narrow

Morrow manages access and subscription state only. Canvas credentials, raw rosters, course content, reports, and the local Proxy map stay outside that backend.

Status and availability

Morrow separates its own account and subscription service from the systems your institution already manages.

Morrow services

Morrow account access and subscription status checks are operated by Morrow's backend services.

Formal uptime commitments are handled in customer terms.

Customer systems

Canvas availability, Canvas roles, institution SSO, devices, and local network controls remain customer-managed.

AI provider

AI availability follows the ChatGPT or OpenAI account your institution or user connects.

Proxy still applies before AI-bound course text leaves the browser.

Report a security issue

If you believe you found a vulnerability or security concern, send enough detail for us to reproduce and assess it.

Email security reports to

Include the affected URL or feature, reproduction steps, impact, and your preferred contact method.

Please avoid accessing data that is not yours, disrupting customer systems, or publicly disclosing details before we can review them.

Customer incident notice, response targets, and legal terms are handled in the customer agreement.

Compliance artifacts and their current status

Each artifact is labeled by status: available, current evidence, readiness packet, public overview, response brief, or on request. Public documents are linked, and restricted packets route through review.

The status table uses worded states. A document reads as Available, Current Evidence, Readiness Packet, or a public overview/brief, so you know what is public today.

We never claim a certification we do not hold.

  • Available Published and linked from this page or the privacy pages, ready to read now.
  • Current Evidence Published as current ACR evidence or readiness material, with final attestations handled only when complete.
  • Public Overview Public overview or response brief available, with signed terms or workbook materials handled per institution.
Compliance and trust artifacts, current status
Artifact Status Version Last reviewed Access Action
Privacy Policy Public policy statement, not a legal attestation Evidence Proxy boundary walkthroughStorage boundarySubprocessor summary Available 2026.06 Jun 23, 2026 Next review Sep 23, 2026 Public
Security Overview Control overview, not an independent audit report Evidence Browser permission postureCSP and security headersNo analytics or telemetryAI governance boundaryAdmin and deployment controlsStatus and availability postureSecurity reporting route Available 2026.06 Jun 23, 2026 Next review Sep 23, 2026 Public
Proxy / Student Data Student-data filtering explanation, not a legal attestation Evidence Local Proxy code mapAI-bound redaction pathReports stay local Available 2026.06 Jun 23, 2026 Next review Sep 23, 2026 Public
Accessibility Statement Accessibility posture and known testing scope, not final third-party conformance Evidence Keyboard and focus checksSemantic HTML practicesGenerated accessibility gate Available 2026.06 Jun 23, 2026 Next review Sep 23, 2026 Public
Terms of Use Public terms for review, not a signed institutional agreement Evidence Approval-first boundaryCustomer account boundary Available 2026.06 Jun 23, 2026 Next review Sep 23, 2026 Public
VPAT / ACR Evidence Accessibility Conformance Report evidence, not VPAT certification Evidence WCAG review scopeKnown accessibility workAssistive-technology evidence scope Current Evidence VPAT 2.5Rev WCAG evidence Jun 23, 2026 Next review Aug 23, 2026 Public evidence
SOC 2 Type II Readiness Readiness packet only, not a SOC 2 report or completed audit Evidence Trust Services Criteria mapControl posture matrixReadiness status Readiness Packet Readiness 2026.06 Jun 23, 2026 Next review Aug 23, 2026 Public readiness summary NDA usually required
DPA Overview Public DPA overview, not a signed DPA Evidence Subprocessor listController and processor rolesRights and deletion path Public Overview 2026.06 Jun 23, 2026 Next review Sep 23, 2026 Public overview; signed packet on request
HECVAT Response Brief Response brief, not a completed institution-specific workbook Evidence HECVAT version trackedSecurity, privacy, and accessibility coverageWorkbook-specific details Response Brief HECVAT 4.1.6 brief Jun 23, 2026 Next review Aug 23, 2026 Public brief; workbook on request NDA usually required

Reviewing Morrow for your institution? We can walk through architecture, permissions, and data handling, and share what is available. Talk to our security team.

Bringing Morrow through review?

Tell us about your institution and what your security team needs. We will walk through the architecture and share the documentation that is available.