Privacy

Privacy Policy

This page describes the current technical status of Cognimize Classroom as of June 11, 2026.

Last updated
June 11, 2026
Controller
Dr. Marian Sauter
Albert-Einstein-Allee 43
89081 Ulm
marian.sauter@uni-ulm.de
+49 (0)731 50 31155
Hosting
Currently hosted via bwCloud (Baden-Württemberg Cloud / bwCloud-OS) in the context of teaching and research infrastructure in Baden-Württemberg, Germany.
Privacy contact
For privacy-related requests, please use the controller contact details listed above.

1. Overview

Cognimize Classroom is a browser-based teaching application for running short classroom experiments. Students can join a classroom session with a session code, complete a task on their own device, review a local result page, and optionally share an anonymous-style summary with the instructor dashboard.

This privacy policy reflects the application's current implementation status. It is intentionally written to match the system as it works today, including browser-side storage, optional summary submission, and instructor live updates.

2. Controller

The controller for the processing described on this page is currently listed as Dr. Marian Sauter at the contact details shown above.

The fact that the service is hosted on bwCloud does not by itself determine who the controller is. Hosting concerns technical infrastructure; the controller is the person or entity deciding the purposes and means of the processing. For this draft, the controller is therefore stated personally as requested.

3. What data is processed when the website is accessed

When this website is accessed, technically necessary connection data is processed. Depending on the web server, reverse proxy, and bwCloud deployment configuration, this can include IP address, date and time of access, requested URL, browser and protocol information, referrer information, and server log data.

These data are processed in order to deliver the website, keep the service stable, and defend against misuse or attacks. The exact log retention of the future production setup must still be fixed separately at deployment level.

4. Cookies and browser-side storage

The application currently uses a technically necessary locale cookie named cognimize_locale to remember the selected language.

In addition, the application stores state locally in the browser. This local storage currently includes a pseudonymous client ID, the current session code, whether participation consent was confirmed, whether summary sharing is enabled, the current task configuration, local result data, and, where applicable, a queued summary payload for later retry if transmission fails.

For instructors, the browser additionally stores the per-session instructor key (required for session controls) and, after publishing, a publication management token (required to update or retract the published aggregate).

  • Language preference cookie: cognimize_locale
  • Local browser storage for session continuity and task results
  • Queued local retry storage for optional summary submission

5. Student participation in a classroom session

Students join a classroom session by entering or opening a six-character session code. When a session code is checked, the server processes the code and returns the current task configuration and session state if the session exists.

The service does not currently require students to create an account or provide a name or email address in order to participate.

6. Local task execution and local result data

The experimental task itself is currently executed primarily in the student's browser. Trial-level result data are stored locally on the device and are shown again on the local result page if the session is resumed on the same device.

The current implementation is therefore data-minimised, but not fully anonymous in the strict legal sense, because browser-side identifiers, connection data, and technical metadata are still involved.

7. Optional summary submission to the instructor dashboard

After the task is completed, the application can submit a summary payload to the server for classroom aggregation. In the current implementation, this may include the session code, pseudonymous client ID, task name and version, a summary ID, summary metrics, quality indicators, user-agent information, viewport width and height, and a timestamp.

The submitted summary is used to compute classroom aggregates and instructor-facing presenter views. The current system does not submit the full local trial dataset as part of this summary route.

If the instructor enabled the optional demographic questions for a session, the summary may additionally contain the participant's voluntary answers (age group, and whether the teaching language is the participant's first language). These questions can always be skipped, and the answers only ever leave the live session as anonymous group counts.

  • Session code
  • Pseudonymous client ID
  • Task name and task version
  • Summary metrics and quality indicators
  • User agent
  • Viewport width and height
  • Submission timestamp
  • Voluntary demographic answers (age group, first-language match) — only if the instructor enabled these optional questions

8. Publishing of class aggregates (Global Highscore)

Instructors can explicitly publish a session's class-level aggregate to a public comparison page. A published entry contains the task name, country, institution name, an optional session label, the participant count, and aggregated class statistics. It never contains individual results, client IDs, or any other per-student data.

Publishing requires a minimum of 10 participating students per session, so that published aggregates cannot be traced back to individual participants; the participant count is always displayed alongside each published entry. Published entries are stored in a database on the server in Germany and remain publicly visible until the publishing instructor retracts them or the operator removes them.

If the instructor enabled the optional demographic questions, a published entry may additionally include anonymous group counts per age band and per language answer — never individual answers. These counts are only included if at least 10 students volunteered an answer; below this threshold they remain inside the live session and are never published.

9. Instructor dashboard and real-time updates

The instructor dashboard displays session status, participant count, aggregated summary statistics, presentation plots, and diagnostic indicators. In the current implementation, live dashboard refreshes are delivered through a WebSocket connection.

For this purpose, the server processes session metadata and dashboard subscription data and pushes aggregate updates to connected instructor clients.

10. Purposes of processing

  • Providing the website and maintaining secure operation
  • Enabling classroom sessions and task delivery
  • Running browser-based experiments on the participant device
  • Optionally transmitting summary data to the instructor dashboard
  • Displaying live classroom aggregates and diagnostics
  • Recovering local session state after interruption
  • Detecting errors, misuse, and integrity problems

11. Legal bases

To the extent technically necessary data are processed to provide and secure the website, processing is currently based on Art. 6(1)(f) GDPR or, where a public-institution context applies, potentially Art. 6(1)(e) GDPR.

Storage of technically necessary information on the end device or access to such information is currently intended to rely on the rules for necessary storage/access operations, in particular Section 25(2) No. 2 TDDDG, where applicable.

Where summary sharing is offered as an optional participant choice, the current draft assumes Art. 6(1)(a) GDPR as the legal basis for that optional transmission.

12. Recipients

Depending on the deployment setup, recipients can include the controller, technical administrators, hosting infrastructure involved in operating the service, and instructors viewing classroom aggregates.

The service currently does not implement advertising trackers or external marketing analytics in the application code.

13. Storage duration

Local browser storage remains on the device until it is overwritten, discarded, or deleted by the user or browser settings.

Server-side data for live sessions (session metadata and submitted summaries) is held in volatile in-memory storage. Ended sessions are eligible for automatic cleanup after they have been ended for more than 60 minutes, and server restarts can remove in-memory session data earlier.

Published class aggregates (see section 8) are the only permanently stored data. They are kept in a database on the server, contain no individual-level data, are covered by daily backups, and remain stored until retracted or removed.

Technical server logs depend on the final production hosting setup and should be documented separately before rollout.

14. International transfers

Based on the current hosting description, the application is intended to run on bwCloud infrastructure in Germany. No deliberate transfer to third countries is part of the present application design. If external providers are added later, this section must be updated.

15. Your rights

You have the rights provided by the GDPR, subject to the applicable legal conditions. These include the right of access, rectification, erasure, restriction of processing, objection, withdrawal of consent for future processing where consent is relied upon, data portability where applicable, and the right to lodge a complaint with a supervisory authority.

Because the service currently works largely with pseudonymous technical identifiers rather than directly named accounts, additional information may be required to match a request to a specific session or summary.

16. Changes to this policy

This privacy policy may be updated if the technical implementation, hosting setup, security architecture, or legal assessment changes. The version published on this page is the version that applies to the current website state.