Author: Elizabeth Gordon, Ali Hugo, and Arunmozhi Periasamy
Affiliation: Arizona State University and OpenCraft
Target Release: Verawood

Summary

This proposal introduces a new, free, open-source Proctoring Toolset for Open edX. It is designed to enhance the integrity of summative assessments in Open edX courses by offering secure, flexible, and configurable proctoring features - implemented natively within the Open edX platform using standard browser APIs. These features include identity verification, webcam recording with manual or AI review, and comprehensive instructor dashboards. Institutions may optionally enable integration with Safe Exam Browser (SEB) to add device lockdown and screen monitoring. The tool will serve as an alternative to costly third-party proctoring platforms like Respondus LockDown Browser, Wheebox, and ProctorU, reducing institutional costs while maintaining academic integrity.

Motivation

The need for academic integrity during high-stakes online assessments has led many institutions to rely on expensive, proprietary proctoring services. However, these services can be cost-prohibitive for many educational organizations and raise concerns about privacy, accessibility, and openness.

Open edX currently lacks a fully integrated, feature-rich, and free proctoring option. This gap disproportionately affects institutions serving learners in the Global South or underfunded academic settings. By developing a native Proctoring Toolset, the Open edX ecosystem will better support accessible, trustworthy learning experiences aligned with its open-source mission.

Proposed Change

We propose the development of a new Proctoring Toolset with the following key elements:

Feature Set (Instructor-Configurable per Exam)

1. Identity Verification: Learners upload a photo of an official ID before beginning the exam.

2. Secure Browser Lockdown (Optional): Institutions may optionally integrate the open-source Safe Exam Browser (SEB) to enforce device lockdown and screen monitoring. SEB will not be required for core functionality. Core proctoring features—webcam recording, ID upload, and exam time limits—will be implemented directly within the Open edX Learning MFE using standard browser APIs.

3. Timed Exams with Accommodations: Integrated time limit enforcement and per-learner time extensions using existing Open edX timed exam functionality.

4. Webcam Recording: Learner webcam recording during the exam will be implemented directly in the browser using standard web APIs. Recordings will be optimized for lightweight video storage and stored and retained securely based on organizational configuration.

5. Instructor (MVP) or AI-Powered Review:

   • Default manual review by instructors.

   • Optional integration with an institution-configured LLM/AI service for automatic flagging (future feature)

   • Flags indicate potential suspicious behavior (e.g., multiple faces, looking off screen for long durations).

6. Accessibility:

   • Audit the entire proctoring flow with assistive technologies (JAWS, NVDA, TalkBack).

   • Ensure the interface includes:

     1. Voice command support

     2. Closed captions for video tutorials

     3. Alt-text for all visual elements

     4. Skip links and keyboard navigation for users with limited mobility

7. Scalable Review Workflow:

   • Implement filters to help instructors efficiently review flagged sessions

   • Enable bulk review and flag resolution actions

8. Export:

   • Webcam review logs

   • Behavior flags

   • Metadata for integration with LMS and institutional compliance systems

9. Ethical AI Integration:

   • Add transparent AI decision logs showing:

     1. Why a flag was triggered (e.g., multiple faces, suspicious gaze behavior)

     2. Allow instructors to override or dismiss AI flags

     3. Provide template policies for institutions on ethical and responsible use of AI proctoring tools

10. Exam Reuse and Backup:

    • Allow instructors to:

      1. Reuse the same proctored exam in different course runs or semesters

      2. Export and import full exam configurations (including proctoring settings and group restrictions)

11. Exam Restriction by Group Policy:

    • Add support for restricting exam access based on learner groups:

      1. Allow specific groups or cohorts to take the exam

      2. Disallow access for users outside the defined group

      3. Enable time-window configuration per group (if needed)

Archival and Data Policies

• Retention of ID and video recordings will be organization-configurable.

• Auto-deletion logic will default to X days after the course end date.

LMS Instructor Interface

We envision a new "Proctoring" tab on the LMS instructor dashboard (similar to ORA) which may include:

• A list of proctored exams

• Number of students assigned / completed / flagged

• Settings summary for each exam

• Student-by-student detail view with:

  • Exam status (not started, in progress, submitted)

  • Completion time and time used

  • Whether accommodations were granted

  • Score (if available)

  • ID image (if uploaded)

  • Webcam recording (if captured)

  • Flag status (AI/manual)

We will keep an eye on the progress of the related Instructor Dashboard MFE Conversion proposal to ensure our approach aligns with the decisions made there. 

LMS Student Interface

Upon launching a proctored exam, students will see a “Welcome to Your Proctored Exam” screen:

• Proctoring summary (ID, webcam, lockdown, time, etc.)

• A short video tutorial + system check

• Custom instructor instructions (optional)

• “Start Exam” button

The UX approach for the Instructor and Student interfaces will be refined and validated during the wireframing phase.

Benefits

• Free and open source alternative to expensive tools like Respondus or ProctorU

• Supports equity and access, especially for institutions with limited resources

• Enhances academic integrity through multiple security layers

• Aligns with Open edX's goals for modular and extensible MFEs

• Fully integrated with existing grading mechanisms and LMS interfaces

Technical Implementation

• Build a new MicroFrontEnd in the instructor dashboard using Paragon

• Implement the features as a collection of backend and frontend plugins (modelled on sample-plugin), leveraging plugin interfaces in edx-platform and the frontend plugin framework.

• Leverage existing timed exam logic for time management

• Backend platform plugins for handling video uploads, ID verification storage, and review logic.

• Integration with the Learning MFE via custom views or plugins to support student-facing proctoring flows within courseware.

• Enable optional integration with the Safe Exam Browser (SEB) for institutions that require lockdown features. Core proctoring capabilities—webcam recording, ID verification, and exam timing—will be implemented using browser-native APIs within the Learning MFE.

• Implement Webcam Tracking independently using in-browser APIs to ensure this core proctoring feature is universally available, regardless of SEB use. (Although SEB does not explicitly block webcam access, it does not support webcam-based monitoring out of the box.)

• Store recordings in organization-configured object storage (e.g. S3)

• Support pluggable backend for optional AI analysis of video (using OpenAI, Azure, etc.)

• MVP will support standard problem blocks and randomized content blocks (quiz libraries); extensible to other gradable xBlocks

Risks and Mitigations

Alternatives Considered

• Continuing with third-party proctoring tools: too costly and proprietary

• Browser-based tab monitoring only: insufficient for academic integrity at scale

• Proctoring via Zoom or live video: not scalable or secure

Next Steps

• Open discussion with the community on the Open edX Product WG Discourse

• The revised SEB-optional approach has been agreed upon by initial stakeholders and is now reflected in this version of the proposal.

• The proposed solution architecture includes MFE-native webcam recording and ID verification, with SEB available as an optional lockdown layer.

• Technical discovery has confirmed the feasibility of this architecture, and development planning can now proceed.

• The team welcomes community input and potential co-funding discussions (e.g., with Axim, 2U, or other contributors).

• Toolset implementation in a private repo or via named contributor until ready for inclusion

Request for Community Feedback

We are specifically seeking feedback on:

• Institutional interest in a free Open edX-native proctoring tool

• Preferred AI services for video review

• Accessibility or privacy considerations for global deployments

• Integration priorities beyond MVP (e.g., support for all xBlocks)
  https://edx.readthedocs.io/projects/edx-partner-course-staff/en/latest/proctored_exams/overview.html#comparison-of-rpnow-and-proctortrack  

Technical Discovery

Existing Tech Stack for Safe Exam Browser

The Safe Exam Browser provides a screen monitoring-enabled Proctoring solution using a combination of services.

1. Safe Exam Browser (SEB)

SEB is the desktop/mobile software that runs in Windows, Mac OS and iOS environments. This is responsible for locking down access to the device used for exams and showing relevant web pages.

2. Safe Exam Browser Server (SEB server)

SEB Server is a web service that provides a centralized way to configure the SEB clients with relevant configurations for specific exams.

• It has direct integration with Open edX instances that are running the seb-openedx plugin.

• It can automatically pull the courses from Open edX and let exam staff blacklist/whitelist specific sections of a course.

Open

3. SEB Screen Proctoring Service (SPS)

The SPS is another independent web service that provides the backend infrastructure necessary to use the Screen Monitoring functionality in exams. The SEB sends periodic screenshots of the student’s screen to the SPS, which is indexed and stored in an AWS S3 Bucket.

4. SEB Screen Proctoring GUI (SPS-GUI)

This provides the GUI for accessing the data collected by the SPS service in the web browser. Think of this as the Monitoring MFE for SEB.

Typical User Flows in the current Stack

The following user-flows are based on a Teak release of the Open edX and the seb-openedx plugin. These are simplified so as to not get too technical, but only provide product level understanding.

Admin Actions (Pre-requisites)

1. Seb-openedx is installed with MFE Access enabled.

2. SEB Server deployed and necessary configuration to link the SEB Server and Open edX instance using the “Assessment Tool Setup”.

Staff User Flow

1. Log into the Open edX Studio (Authoring MFE)

2. Creates courses with exams as independent subsections.

3. Staff logins into the SEB Server UI.

4. Staff selects the necessary course from the “Assessment Tool Lookups”.

5. Import the course as an Exam into the SEB.

6. Blacklist the exam subsections (chapters) and configure other things as necessary.

7. Export the exam configuration file.

8. Go back to Open edX Studio and attach it to the course as a downloadable file, with necessary instructions for students.

Learner User Flow

1. While pursuing the course, the learner encounters the instructions about SEB. (NOTE: If the learner tries to access the exam subsection, they get an error message asking them to use SEB Browser)

2. Downloads and Installs the Safe Exam Browser in their own computer or uses the University computer equipped with Safe Exam Browser.

3. Downloads the linked configuration file from the course.

4. Double-clicking the SEB file launches the Safe Exam Browser, allowing the learner to access the Exam.

5. Completes the Exam.

Limitations of the Existing Stack

1. No Camera Tracking

Although SEB’s proctoring solution does not explicitly block webcam access, it does not support webcam-based monitoring out of the box, only Screen Monitoring. While they have had integrations with Video Conferencing tools like Zoom and Jitsi Meet. That has been discontinued. As such, webcam tracking will be implemented independently using in-browser APIs to ensure this core proctoring feature is universally available, regardless of SEB use.

Consequence: The Camera tracking feature needs to be built. Without this feature, the main premise of this proposal won’t be feasible.

2. Limited Access Controls for Content

The whitelisting and blacklisting feature currently implemented by seb-openedx plugin only provides one way restrictions. That is, the user can be locked out of the full course or specific part of the course when accessing with a normal browser. But they can’t be locked out of content when accessing from the Safe Exam Browser.

So, a learner will have access to the exam and the rest of the content when accessing from SEB. They can’t be locked out of the course content when doing their exam.

Workaround: This limitation can be worked around by doing things like setting the content visibility off for specific durations, creating exams as independent courses and setting the end date for the main course with the course content ..etc.

Consequence: The seb-openedx was created during the Hawthorn and Ironwood releases when the LMS UI was rendered natively instead of an MFE. While this has been updated to support the MFEs, it is still a backend only solution. 

The frontend-lib-specialized-exams library provides the necessary functionality for proctoring solutions used in Open edX Learning MFE. This library can be updated, or a similar one be created that will enhance the functionality of the seb-openedx plugin for better content access controls.

3. Written in Java, not Python

The SEB’s web services are written in Java, which makes it difficult for the Python-based Open edX community to contribute new features or maintain the code. For better integration with Open edX, these services could be re-implemented in Python—allowing easier contributions and enabling the addition of new features. However, this would require a significant development effort.

4. Requirement to Download and Install SEB

While SEB traditionally requires users to download a config file or the SEB application, this requirement may be partially streamlined by launching SEB via a direct link, depending on institutional configuration. However, the need to install SEB software on local machines remains a UX hurdle compared to fully in-browser solutions.

Scope for Future Work

Both the SEB Server and SPS server are built as modular software, with the backend service providing an REST API and the frontend UI using the provided API.

This allows for alternate frontends to be built on top of them similar to the MFE approach used in Open edX. The plugins ideated in this proposal can use the API from SEB Server, SPS Server and Open edX platform to provide a cohesive UX for staff to set up proctoring for exams and review the monitoring data.

Proposed Implementation Phases

The implementation of the features listed in the proposal are split into the following phases.

IMPORTANT: These are for initial planning only. The timelines and scope will have to be adjusted after the UI/UX work to set the right expectations.

Phase 1 - MVP

The MVP will focus on getting all the important pieces in place for progressively implementing additional features in the next phases.

Target Release: Verawood

Create the new Proctoring Toolset

• Implement Instructor UI to accomplish the following:

  • Review timed exam data

  • Review IDs of students

  • Review video recordings manually

• Implement Learner UI for

  • Uploading IDs as images

  • Review exam instructions

Proctoring Backend

This could be a platform plugin or independent IDA. The exact method is not defined in this proposal and will be decided in the future.

The Proctoring Backend will provide the necessary API for:

• Handling ID Uploads in a secure way

• Handling webcam recording streams

• Storage of proctoring configurations

Augment Learning MFE

• Use the proctoring backend to enable proctoring requirements on exams.

• Enable navigating from Learning MFE to Proctoring UI for ID upload

• Launch Webcam recording at the start of a Proctored Exam

Augment Authoring MFE

• Provide integration with the Proctoring toolset that can allow instructors to enable proctoring on exams within Authoring MFE.

Phase 2 and beyond

Target Release: W and after

The subsequent phases will focus on enhancing the capabilities of Proctoring Toolset.

• Introduce support for multiple review backends - human, automated, 3rd Party AI..etc.,

• Implement Accessibility features

• Bulk reviewing and triaging

• Import/Export exam settings for reusability

• Grouping and access restrictions ..etc.,
  
  

Open Questions

• Besides SEB, are there any other proctoring tools currently in use across the community? Knowing this would help us test against a broader range of tools and make our approach more generic.