ReadSpeaker DocReader in SEB 3.7

[Mobron]

Describe the Bug
Recently, we encountered an issue with DocReader bt ReadSpeaker in Safe Exam Browser (SEB) version 3.7. When attempting to open a file, it gets stuck while trying to read it out loud (see image attached to this message). Interestingly, this problem does not exist in version 3.6 and earlier.

Our Moodle provider, OpenEdu, as well as ReadSpeaker support have confirmed the issue after conducting their analysis. They recommended that I file this bug for further assistance.

Steps to Reproduce
Steps to reproduce the behavior:

1. Create Quiz with SEB in Moodle with ReadSpeaker plugin
2. Create Question with link to uploaden PDF file
3. Open Quiz in SEB
4. Open PDF with ReadSpeaker/DocReader
5. Click 'Read' button on top
6. See error

Expected Behavior
Up untill version 3.6 ReadSpeaker DocReader would read the text aloud.

Screenshots

Version Information

• Windows 11 (any version)
• SEB-Version 3.7

Additional Context
ReadSpeaker is an important accessibility tool in the online world. Support seems critical. They asked me to file this bug report, but they can be reached at [email protected]. Lisa knows the issue and can provide further assistance.

[dbuechel]

We'd need access to a quiz with that specific plugin, I personally do not know it nor how to install / configure it. In other words, it would be great if you could take care of steps 1 and 2 as specified abvoe so that we can investigate the remaining steps.

[Mobron]

Thank you for your reply, Damian. I've created an account for you on our Moodle instance, with access to a simple Quiz. The Quiz contains one question, linking to a PDF file.

Go to elo.keizerkarelcollege.nl
Click 'Inloggen' and then 'Reguliere login'
Log in with username: Damian
Password: SEB4ever
Here is the example test you can use..
Open the test in SEB 3.7 with password 'Doei' (exit password is the same)
Click on the ReadSpeaker icon behind the link in the question to open the PDF in DocReader.
DockReader opens the PDF, but will fail to read it.

NB: SEB 3.6 and earlier will work just fine.

Kind regards,
Robin

[dbuechel]

Excellent, thank you. I shall investigate the issue as soon as I have time, presumably in the upcoming 1-2 weeks.

[Mobron]

Very good. Thank you. We and all our dyslectic students will keep our fingers crossed for a solution

[ObscureScience]

Hi @dbuechel
I work with ReadSpeaker and am interested if any findings has been made.
If changes in CSP configuration of SEB has been made that could be something to look at.
As this is a open source project, are there instruction on how to enable a debug build, which will make inspector tools available?

[thomasvergouwe]

Following this thread, as we have the exact same issue in our schools.

[dbuechel]

As this is a open source project, are there instruction on how to enable a debug build, which will make inspector tools available?

You can enable the development tools via the configuration under User Interface > Enable browser toolbar > Show developer tools (see https://safeexambrowser.org/windows/win_usermanual_en.html#AppearancePane).

[ObscureScience]

@dbuechel
Thank you! What we've been able to see is that some responses from ReadSpeaker servers are blocked by the browser because the browser sets CORS credentials mode "include" on fetches, and ReadSpeaker has "Access-Control-Allow-Origin" set to "*" on responses.

The error is basically this: "Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '*'"

This must have changed between v3.6 and 3.7.
My recommendation would be to at least allow the header parameter to be set (including "omit").

[dbuechel]

Thanks for the information, that might very well be the case due to a change in the browser engine. I shall thus try to set the credentials mode as mentioned above, though we obviously need to make sure that this won't impact other requests resp. use cases.

[Dirk-K-076]

Good morning @dbuechel
Are there any relevant updates for this issue with SEB 3.7.0? Or can you maybey confirm this issue is going to be fixed with a new browser engine in SEB 3.8 or later? Thanks in advance also on behalve of our students

[dbuechel]

We will definitely have a look at it and do already have an internal work item created. It currently is scheduled for version 3.8.0, but most unfortunately and due to various factors we'll probably need to reschedule it for a later version.

The code change itself may be and hopefully is minor, but the possible side effects and required testing unfortunately not. We already had quite a few issues related to CORS, thus experiences has taught that any related changes must be made with great caution.

[thomasvergouwe]

Is there an update on this problem? We start schools again in september and we'd like to use Readspeaker Docreader in combination with SEB.

[dbuechel]

Most unfortunately not, we were not able to have a look at the issue due to other priorities. The issue is however still in our backlog and we will inform here once we were able to make any changes.

[Mobron]

For anyone tuning in. I can confirm that version 3.6 still works for now. The problem is however, that in my experience older versions will eventually stop working as automated SEB config creators (such as Moodle's) get updated.

[Dirk-K-076]

Hi @dbuechel
We see a new release at the SEB website for SEB 3.8. Is the docreader issue solved in this release? Thanks in advance!

[thomasvergouwe]

I've tried it and sadly, it didn't work with me. Verzonden vanaf Outlook voor Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Dirk Keustermans ***@***.***> Sent: Monday, October 7, 2024 3:05:59 PM To: SafeExamBrowser/seb-win-refactoring ***@***.***> Cc: thomasvergouwe ***@***.***>; Comment ***@***.***> Subject: Re: [SafeExamBrowser/seb-win-refactoring] ReadSpeaker DocReader in SEB 3.7 (Issue #889) Hi @dbuechel<https://github.com/dbuechel> We see a new release at the SEB website for SEB 3.8. Is the docreader issue solved in this release? Thanks in advance! — Reply to this email directly, view it on GitHub<#889 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AU2K53W3AMZNLCSKIO4L5P3Z2KBLPAVCNFSM6AAAAABIHGFAFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJWHA3TQMBXGM>. You are receiving this because you commented.Message ID: ***@***.***>

[dbuechel]

Unfortunately not, but the issue remains in our backlog and will be tackled once time and other priorities permit.

[Mobron]

Update: We've had an enormous amount of problems using SEB version 3.6 during our last exam-week. We've seen crashes and red-screens all over the place. Apparently these were caused by a known issue that was solved in version 3.8. We've then updated our non-dyslectic students to this version and most problems were gone.

This means, however, that staying with SEB 3.6 is no longer a viable option. Not even for the smaller group of students that rely on ReadSpeaker as their accessibility tool. It's just become too unstable. Could you, therefore, be so kind as to move the issue up the list of priorities?

[dbuechel]

Update: We've had an enormous amount of problems using SEB version 3.6 during our last exam-week. We've seen crashes and red-screens all over the place. Apparently these were caused by a known issue that was solved in version 3.8. We've then updated our non-dyslectic students to this version and most problems were gone.

That is unfortunately correct, hence we do always recommend to use the latest release version (and here particularly at least version 3.7.1 or newer).

Could you, therefore, be so kind as to move the issue up the list of priorities?

I unfortunately cannot do this, as the prioritization is done by our product owner board (of which I am not a part of). I will however forward the urgency of this issue, but I'm afraid the backlog of version 3.9.0 is already full so any resolution won't be available before the second half of 2025.

Becoming a member of the SEB Alliance could potentially speed up things on our end, please refer to https://safeexambrowser.org/alliance/members.html for more information.

[dbuechel]

To all involved: Have you contacted the manufacturer of ReadSpeaker and made sure that the issue cannot be resolved on their end, perhaps even faster than we could do so?

To reiterate, changes to the CORS headers can have a wide range of unintended effects, which is why this would be a major change for us requiring extensive testing to ensure that other use cases are not affected.

[calsil]

To all involved: Have you contacted the manufacturer of ReadSpeaker and made sure that the issue cannot be resolved on their end, perhaps even faster than we could do so?

@dbuechel do you have any suggestion of how this could be done?
The product is in no way specific for use in SEB. Not having Access-Control-Allow-Origin: * set would not really be a possibility as the product needs to be possible to load from any domain.

EDIT: To clarify, docReader loads correctly, but it's the request to the audio synthesis endpoint which is used in many products other than docReader, and is a "public" API, so * is the most reasonable value for allowed origins.

In the "competitor" Respondus Lockdown browser docReader does work without issues.

[JarnoNL]

To all involved: Have you contacted the manufacturer of ReadSpeaker and made sure that the issue cannot be resolved on their end, perhaps even faster than we could do so?

To reiterate, changes to the CORS headers can have a wide range of unintended effects, which is why this would be a major change for us requiring extensive testing to ensure that other use cases are not affected.

Hi DBeuchel,
Yes, all Github-ers in this topic have contacted us here at ReadSpeaker. ReadSpeaker's lead developer even left a suggestion for the solution, as posted by ObscureScience on June 17th.

Do you happen to know if there is any way we at ReadSpeaker can get in touch with SEB's Product Owner Board? I cannot find any such information on the SEB ewebsite.
This ongoing issue is now unnecessarily effecting numerous dyslexic learners (as this is most probably also negatively impacting the learning / exam experiencing for SEB Alliance Contributors like Skolverket and Dugga, who also use ReadSpeaker TTS), and it is most probably not the SEB Alliance's intention to create inaccessible yet secure exams for these student/pupils/kids?

Hoping you can help point us in the right direction to initiate dialogue between us/ReadSpeaker and SEB's Product Owner Board, thanks!

[dbuechel]

Thanks for the additional information @calsil. I unfortunately do not have any suggestions and am still busy with other priorities, but I invested some extra time in order to get to the root of the issue: According to my current understanding, the issue appears to be that when fetching a resource using fetch(), the credentials option of the provided RequestInit object is set to include instead of omit or same-origin.

Now, we definitely haven't changed anything related to the above mentioned API (as a matter of fact, we currently do not alter any browser APIs at all). The issue must thus be either caused by the web application code actually performing the resource fetch (which I consider to be the most likely case) or then by an upstream change in either the C# wrapper of the browser engine (CefSharp) or the engine itself (CEF).

Hence, and please correct me if I'm wrong, we cannot resolve the issue, as we'd actually need to hard-code the credentials option to omit or same-origin, which in turn would most certainly break other use cases. And even if it were a viable option, I am not aware that there exists a possibility for us to do so, as the browser APIs are part of the engine code and not our code base.

[dbuechel]

@JarnoNL Thanks for the input, and I most definitely agree, this issue should be resolved as soon as possible. Our project leader @danschlet is part of the product owner board and may be able to help here.

[danschlet]

@JarnoNL you can contact us by email info at safeexambrowser . org or contact the SEB Alliance manager at alliance safeexambrowser . org.

In general I agree with @dbuechel that changes to the browser engine seem very risky and we can't really prioritize those, if this is only reported for one specific web application/solution. To me it seems that Google changed these CORS policies probably for security reasons in the Chromium browser engine or that some related bug was introduced in a specific version of Chromium / Chromium Embed Framework (CEF). In both cases, someone should try to find similar issues related to CEF/Cef Sharp or Chromium/Chrome.

We are no browser engine or web application specialists, therefore researching such issues could cost us significant amounts of time and there is the risk that we anyways can't do anything else than filing a bug report to Google / Chromium / CEF. So if your developers could do further research if this is a known issue for new releases of Chromium, this might help finding a solution faster.

[calsil]

Thanks for the additional information @calsil. I unfortunately do not have any suggestions and am still busy with other priorities, but I invested some extra time in order to get to the root of the issue: According to my current understanding, the issue appears to be that when fetching a resource using fetch(), the credentials option of the provided RequestInit object is set to include instead of omit or same-origin.

Now, we definitely haven't changed anything related to the above mentioned API (as a matter of fact, we currently do not alter any browser APIs at all). The issue must thus be either caused by the web application code actually performing the resource fetch (which I consider to be the most likely case) or then by an upstream change in either the C# wrapper of the browser engine (CefSharp) or the engine itself (CEF).

Hence, and please correct me if I'm wrong, we cannot resolve the issue, as we'd actually need to hard-code the credentials option to omit or same-origin, which in turn would most certainly break other use cases. And even if it were a viable option, I am not aware that there exists a possibility for us to do so, as the browser APIs are part of the engine code and not our code base.

Thank you for this deeper look!

Just to make sure there are no confusions here, no regular browser exhibits this behavior with the docReader app (Chrome/Edge, Firefox, Safari) and neither does Respondus LockDown Browser. So it's not the normal behavior of these engines, and must be down to special configuration or redefinition of the fetch/XMLHttpRequest API.

I'm suspecting the CefSharp in that case. I assume this version is vendored in this project, and are you thus able to determine the CefSharp version change between SEB 3.6 and 3.7?

[dbuechel]

@calsil That is very well possible. The engine version information is available in the release notes of every version here on GitHub, see https://github.com/SafeExamBrowser/seb-win-refactoring/releases.

There exist a CEF sample application as well as a CefSharp minimal example application, you may want to try reproducing the behavior with both in order to verify whether this indeed is an upstream issue:

• https://cef-builds.spotifycdn.com/index.html
• https://github.com/cefsharp/CefSharp.MinimalExample

[github-actions]

This issue is stale because it has been open for 28 days with no activity. It will soon be closed automatically if there are no updates.

[Mobron]

Stale..... I really hope this issue can stay active until it's resolved. We need versions of SEB and/or DocReader that can be friends, for the benefit of our poor dyslectic of visually impaired students.

[Dirk-K-076]

Hi, at our high school we also keep hitting this issue with as a result that we are still running version 3.5.0. It would be a pitty if this issue is getting closed, because there is not a resolvement.

I saw the suggestion earlier mentioned by @dbuechel on november 4th, to report this issue to the readspeaker support staff. Has aynone already been in the opportunity to do this? If not so we can maybe try to report the issue to them. There is a small challenge in this because my team and me are only managing the software functioanlly i would love to have some advice of what to report to them exactly as well with the technical details.

Hopefully whe can get to a quick solution together?

[thomasvergouwe]

@Dirk-K-076 calsil and JarnoNL are 2 people that work with readspeaker. I've been in contact with them because this has caused immense issues for our 7 high schools.

I have no idea how this can be resolved, but it's becoming quite rediculous...

[Dirk-K-076]

Thanks for your quick response @thomasvergouwe ;

If i read the article top-down it looks like the root cause is clear. So is readspeaker currently investigating this issue, and is there already a plannen date for implementing a fix?

I know the issue is going on for months, but i'm just trying no to see or investigate who is responsible to take action now. And if we can help we would love to! Otherwise we are very interested in following this issue...

[Dirk-K-076]

Anyone with a update please, or anyone who can help what exactly to ask to the technical support staff from readspeaker?

[danschlet]

From the SEB side, we won't be able to investigate this issue earlier than February.

[calsil]

One additional point of information.
The problem was not exhibited by the actual CEF engine: https://cef-builds.spotifycdn.com/index.html
So the modification of the fetch mechanism must be done by either CefSharp or SafeExamBrowser.