Skip to main content
Support
Docs / AssisT / Managed Deployment Guide

Managed Deployment Guide

Force-install AssisT across managed Chrome browsers and apply an institution branding key by enterprise policy.

Applies to AssisT 1.0.0 · Last updated 13 October 2026

This guide is for IT administrators deploying AssisT across a managed Chrome estate, usually at the request of a learning support or disability service. It assumes Chrome Enterprise (or Chrome Browser Cloud Management, or Microsoft Edge’s equivalent policy surface) is already in place.

There is nothing to buy and no licence key to obtain. AssisT is free under the EUPL-1.2 and a student can install it themselves from the Chrome Web Store. Force-installing it is a convenience for the institution, not a requirement of the product.

What you need

ItemValue
Extension IDdkekfjomoacmhbkekjkngmpbdlljjfhi
Update URLhttps://clients2.google.com/service/update2/crx
Chrome Web Store listingAssisT: Adaptive Augmentative Tool
Minimum browserChrome or Edge 109
LicenceEUPL-1.2

AssisT is not available for Firefox or Safari. Do not plan a deployment that assumes it is.

Force-install

Use the standard ExtensionInstallForcelist policy. The value is the extension ID, a semicolon, and the update URL:

dkekfjomoacmhbkekjkngmpbdlljjfhi;https://clients2.google.com/service/update2/crx

Google Admin console: Devices → Chrome → Apps & extensions → Users & browsers. Add the extension by ID and set the installation policy to Force install.

Windows Group Policy: Computer Configuration → Administrative Templates → Google → Google Chrome → Extensions → Configure the list of force-installed apps and extensions.

Registry equivalent:

HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist
  1 = "dkekfjomoacmhbkekjkngmpbdlljjfhi;https://clients2.google.com/service/update2/crx"

macOS (plist):

<key>ExtensionInstallForcelist</key>
<array>
  <string>dkekfjomoacmhbkekjkngmpbdlljjfhi;https://clients2.google.com/service/update2/crx</string>
</array>

Force-installed extensions cannot be removed by the user. If you would rather students opt in, use ExtensionInstallAllowlist instead and let them install it from the Web Store themselves. For a disability service this is often the better choice: the students who need AssisT will install it, and nobody else carries an extension they did not ask for.

Managed configuration (policy JSON)

AssisT declares a managed storage schema, so Chrome can push configuration to it by policy. The schema defines exactly one key. There is no policy for enabling features, locking settings, restricting AI providers, or pre-selecting a profile — those are all the student’s own choices and they are stored on the device.

KeyTypePurpose
institutionKeystringA signed AssisT institution key that applies your institution’s cosmetic interface (name and colours) automatically on managed browsers. Supplied by the institution; the extension verifies it and grants no additional capability.

The complete policy value is therefore:

{
  "institutionKey": {
    "Value": "<your signed institution key>"
  }
}

In the Google Admin console this goes in the extension’s Policy for extensions field, as:

{
  "institutionKey": { "Value": "eyJ...your key..." }
}

On Windows, the same value is written to HKLM\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\dkekfjomoacmhbkekjkngmpbdlljjfhi\policy.

What the institution key does and does not do

  • Does: applies your institution’s name and accent colour to the AssisT interface. The accent colour is darkened automatically until it holds WCAG 2.2 AA contrast, so a brand colour cannot make the interface unreadable.
  • Does not: unlock features, change defaults, grant the institution any visibility of what a student does, or send anything anywhere. Keys are Ed25519-signed, verified offline, and fail closed — an invalid key simply leaves the public appearance in place.
  • Optional: the public build carries no key, and AssisT is fully functional without one. Managed policy is the only way to apply a key in 1.0.0: the popup no longer has a field for pasting one. Branding already applied on a student’s machine keeps working.

To request a key for your institution, email [email protected].

These are recommendations, not policies — AssisT has no policy surface for them, so they are things to tell students in your onboarding material rather than things you can enforce centrally.

  1. Leave AI off, or start with Local AI. AssisT needs no AI at all, and AI is off until a student chooses a mode. Every support except the AI study tools works with AI switched off. If your service wants AI features without text leaving the institution, run Ollama on the student’s machine or a lab image and point AssisT at it.
  2. Do not distribute a shared cloud API key. Cloud AI uses the student’s own key, sends text directly to that provider, and makes the provider that student’s sub-processor. See the sub-processor list.
  3. Site access. By default AssisT runs only on Canvas, Moodle, Google Classroom and Google Docs. “Enable everywhere” is an optional permission the student grants. Tell them it exists; many students need it for library databases and publisher platforms. It is also needed if your school hosts Canvas or Moodle on its own web address (not instructure.com or moodlecloud.com).
  4. Explain the consent questions. On a fresh install AssisT sends nothing anywhere, unless a student picks an online read-aloud voice in the voice picker, which sends the text being read to the company that runs that voice. The welcome page, or the first use of a feature, asks the student once about each outside service their choices would use: the dictionary, translation, Crossref for citations, dictation (which uses Google’s speech recognition in Chrome), lecture capture, and any cloud AI provider. Nothing is sent until they say yes, and they can change any answer under Advanced options, Your data. Read from Images in another language than English asks too, before downloading that language’s file from jsDelivr. Chrome’s permission for each service is asked in the same press, and on a course page the question opens in a small AssisT window. Browser AI models download from Hugging Face when a student chooses one, with no text of theirs. Tell students what the questions are before they meet them, and what your service recommends. The sub-processor list says what each service receives.
  5. Local AI permission. If you plan to use Ollama, warn students that Chrome asks for permission the first time they switch Local AI on — not at install. A prompt nobody expects is a prompt people decline.
  6. Settings do not follow the student. Settings live in chrome.storage.local on one device. A student who moves between a lab machine and a laptop will set AssisT up twice, or save their settings to a file and restore it on the other machine. The file never carries AI keys or consent answers. Build that into your onboarding.
  7. Companion features are on by default. They are the newest part of 1.0.0. If you want a stable evaluation surface for a pilot, have students switch them off in the popup first. The two supports that watch how a student works, “Keep a record of how I work” and “Offer help when reading gets hard”, are off until the student turns them on.
  8. Google Docs, Sheets and Slides. Google draws documents in these editors on a canvas, so tools that need the document’s words do not work there. Google Classroom pages are not affected. See Troubleshooting.
  9. Plan for a student pilot before a general recommendation, particularly for screen-reader users. The Accessibility Conformance Report is a self-assessment, and no NVDA, JAWS or VoiceOver testing has been done.

Updates

Updates arrive through the Chrome Web Store like any other extension. Chrome checks for updates on its own schedule (roughly every few hours) and applies them silently. There is no separate installer, no MSI, and nothing for your team to repackage. If you need to pin a version, Chrome’s ExtensionSettings policy can do it, but you will then be responsible for taking accessibility and security fixes by hand.