Cookies
This portal sets three cookies. Two of them run sign-in: one keeps you signed in, one records which of your roles you are currently acting as. The third exists only while an administrator is using “View as”. None of them is used to track you, build a profile, or measure anything.
The three cookies
| Name | What it does | Lifetime |
|---|---|---|
| authjs.session-token | Your signed-in session. It is a signed token, not a database key — the portal reads who you are from it on every request.Whenever you are signed in. Over HTTPS it is named __Secure-authjs.session-token, and it may be split across numbered parts (.0, .1) when the token is long. | 7 days at most |
| ssp-active-role | Which of your roles you are currently acting as, for accounts that hold more than one. The server checks the value against the roles you actually have; a tampered value falls back to your main role.Only if you have used “Switch account”. | 30 days |
| ssp_impersonate | Exists only while an administrator is using “View as” to see the portal as someone else. It is a signed token holding both people's names and account ids, and the use is written to the audit trail.Only during an administrator's “View as” session. | 4 hours |
The sign-in framework may also set its own short-lived cookies while a sign-in is in progress. Those belong to the framework rather than to this application, and only the session cookie above is named anywhere in this codebase, so this page does not list them as if it had checked.
These three are all the cookies there are, and each one is listed above with what it is for. Two are what signing in is made of. The third, ssp_impersonate, is never set for an ordinary user at all: it appears only while an administrator is using the “View as” feature, and without it that one administrator feature stops working rather than anybody’s sign-in.
This page describes what the software does and stops there. Whether a consent banner is required of this program is a question for the program’s legal owner, not something this codebase can answer — see the note every one of these pages carries.
There is no analytics, advertising or tracking code anywhere in this application — no analytics library, no tag manager, no session-replay tool, no error-reporting service. Nothing counts your visits, and nothing follows you off this site.
This is checked automatically, not just asserted
The statement above is an absence, and an absence is easy to lose by accident. So the project’s test suite fails the build if a known analytics, session-replay, error-reporting or consent-management package is added to it. If tracking is ever introduced, this page has to be rewritten in the same change — it cannot quietly fall out of date while still telling you nothing here measures anything.
Settings kept in your own browser
These are not cookies and are never sent to the server. Your browser stores them and only this site’s own pages read them:
- your colour theme (light or dark)
- your display density (comfortable or compact)
- whether you have dismissed the guided walkthrough
- whether you have dismissed the feedback-survey prompt
Clearing your browser’s site data removes them; you will get the defaults back.
Embedded videos
A learning resource can have a video embedded in it. When you open such a page, your browser contacts the video host directly — that is how any embedded video works, and that host may then set storage of its own. Only two hosts can ever appear in this portal, and the browser’s own security rules enforce it:
www.youtube-nocookie.complayer.vimeo.com
Adding a third host would take a code change and a deployment; it cannot be done from inside the app. Nothing on a page without an embedded video contacts either of them.