Look up words on Mac

[aurelienb1]

Hi,

We think we have a big problem with macOS, you can quickly look up definitions of words and phrases while working in your SEB exam.

See https://support.apple.com/guide/mac-help/look-up-words-mchl3983326c/mac

Is it possible to block this feature ?

Regards

[danschlet]

Did you try it with the latest release SEB 3.2.2? It should be fixed there.

[aurelienb1]

Ok my mistake I had not seen the latest version of SEB for mac, we will test this.

[aurelienb1]

Hi, we can use look up word with 3.2.2 under Ventura 13.0 ...

[danschlet]

Well, I can't.

Are you sure you didn't allow it in Preferences/User Interface/Allow dictionary look up? Are you sure SEB 3.3.2 was started? If you have an older version on your Mac, that one might be started if you open SEB with a sebs:// link (best is to delete the older one or ZIP it).

[aurelienb1]

Hummm, in preference i didn't allow dictionary look up.

i use a template in moodle, in my mac in Mojave with SEB 3.2.2, i'am not able to access to dictionary look up in my exam. But another user with recent mac can. We could make another tests today.

Thank you

[aurelienb1]

Ok, so we found the problem, you can configure trackpad for look up word with 2 ways

• one with 3 fingers and it's block by SEB
• another with one finger 1 (use pressure on trackpad) and it's pass in SEB

Regards,

[danschlet]

I know and I tested both, and it was blocked in both cases. What Mac did you test it on (Apple Silicon or Intel) and on the internal trackpad? Otherwise send me a testing access to your system. On a regular web site I can't reproduce it.

[aurelienb1]

Hi.

• mac Intel i7 on Ventura 13.0

So i send you email with seb file to make some tests.

Regards

[danschlet]

Ok, so I was finally able to reproduce the issue. It was tricky, as it happens only with a specific macOS version and macOS/SEB settings combination:

• Only on macOS Ventura 13
• Only with Force Touch
• Only in the classic WebView (not when the modern WebView is used, which depends on various SEB settings)

I found out how I can prevent it also in that case and I'm adding it to the upcoming minor update SEB 3.2.3. There are also two possible workarounds you can use with current SEB versions:

1. Update the SEB-Moodle integration plugin in your Moodle instance, so that the modern WebView (WebKit 2 browser engine) is used. The updated plugin is available in Moodle 4.1 (and in the next maintenance update for Moodle 4.0, I think 4.0.7) or you can install it in Moodle 3.9 or later from our repository. Using the modern WebView is highly advisable (see our news/download pages about the 3.2.2 release). For lookup to be blocked in the modern WebView, use SEB 3.2.2 (not older SEB versions).

2. Or add two prohibited processes to your custom SEB settings, activate the "Force terminate" property for both and use these strings for "Identifier" (any name for Executable, relevant is only the identifier):

   • com.apple.quicklook.ui.helper
   • com.apple.LookupViewService

Thanks for reporting this bug!

[aurelienb1]

Hi,

Thank you very much for work !

Regards,

Aurélien Besson | Concepteur TI / ITIL TI - Portefeuille technopédagogique | Université de Montréal

De : Daniel R. Schneider @.> Envoyé : 3 février 2023 14:25 À : SafeExamBrowser/seb-mac @.> Cc : Aurélien Besson @.>; Author @.> Objet : Re: [SafeExamBrowser/seb-mac] Look up words on Mac (Issue #270)

AVIS: Ce courriel provient de l'extérieur de l'Université de Montréal. Veuillez ne pas cliquer sur les liens ni ouvrir les fichiers joints si vous n'êtes pas certain(e) de la légitimité du courriel.

Ok, so I was finally able to reproduce the issue. It was tricky, as it happens only with a specific macOS version and macOS/SEB settings combination:

• Only on macOS Ventura 13
• Only with Force Touch
• Only in the classic WebView (not when the modern WebView is used, which depends on various SEB settings)

I found out how I can prevent it also in that case and I'm adding it to the upcoming minor update SEB 3.2.3. There are also two possible workarounds you can use with current SEB versions:

1. Update the SEB-Moodle integration plugin in your Moodle instance, so that the modern WebView (WebKit 2 browser engine) is used. The updated plugin is available in Moodle 4.1 (and in the next maintenance update for Moodle 4.0, I think 4.0.7) or you can install it in Moodle 3.9 or later from our repositoryhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fethz-let%2Fmoodle-quiz_accessrule_seb_js_api&data=05%7C01%7Caurelien.besson%40umontreal.ca%7Ce02aa0d2a32a4e27554208db061c6904%7Cd27eefec2a474be7981e0f8977fa31d8%7C1%7C0%7C638110491309982901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KdsBz%2Fm08EFtakDtf8iglBwpBW2xBBYgJQHDMqHwXNs%3D&reserved=0. Using the modern WebView is highly advisable (see our news/download pages about the 3.2.2 release). For lookup to be blocked in the modern WebView, use SEB 3.2.2 (not older SEB versions).

2. Or add two prohibited processes to your custom SEB settings, activate the "Force terminate" property for both and use these strings for "Identifier" (any name for Executable, relevant is only the identifier):

   • com.apple.quicklook.ui.helper
   • com.apple.LookupViewService

Thanks for reporting this bug!

- Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSafeExamBrowser%2Fseb-mac%2Fissues%2F270%23issuecomment-1416308049&data=05%7C01%7Caurelien.besson%40umontreal.ca%7Ce02aa0d2a32a4e27554208db061c6904%7Cd27eefec2a474be7981e0f8977fa31d8%7C1%7C0%7C638110491309982901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FGcjxapGX7%2FEWDDlvolDzC%2BXLjc%2BMK6j0P5rfRG7yik%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMFDTDLWILNRKYH36WNVF7DWVVLSTANCNFSM6AAAAAAUB4WE2E&data=05%7C01%7Caurelien.besson%40umontreal.ca%7Ce02aa0d2a32a4e27554208db061c6904%7Cd27eefec2a474be7981e0f8977fa31d8%7C1%7C0%7C638110491309982901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=E%2BsvCqPTixEtvkn2hvQBsSHcTLGGEJm3vwZUWdaOHjs%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.**@.>>

[danschlet]

Fixed in SEB 3.2.3 and the upcoming 3.2.4 (where an issue in 3.2.3 with downloads was fixed).

[t00]

A workaround for an old WebView (which we use due to lack of BEK support in new WebView) does not entirely work.

There is an empty lookup view shown instead of word lookup which is a step in a good direction but ideally nothing should be shown to the user.

This roughly means that LookupViewService is correctly identified (and killed) yet the com.apple.quicklook.ui.helper is not killed when launching the SEB.

Working part:

executable: LookupViewService
identifier: com.apple.LookupViewService

Not working part:

executable: QuickLookUIHelper
identifier: com.apple.quicklook.ui.helper

@danschlet Do you possibly have any ideas why the UI helper is not found? When enabled, prohibited process list window only shows com.apple.LookupViewService.

Another question is will it be ever possible to enable BEK headers in the new WebView? I wish we would have switched to it.

[danschlet]

It is absolutely impossible to add custom HTTP request headers in the modern WebView (WKWebView). Years ago I made feature requests at Apple, spoke with various WebKit engineers and the WebKit leading manager about it and with my other Apple contacts, so I'm quite confident they will never introduce an API for it. Also Chromium seemed to have moved in the direction of not allowing to change HTTP request headers (currently for cross-site requests), so I guess that might be a general security concern of browser engine vendors.

Regarding the lookup part, maybe you could attach some pictures how it looks now. But in general I'm not planing to spend any time for improvements for the classic WebView (maximum for some simple bug fixes) as it is deprecated by Apple since several years and might be removed completely at some time. On iOS it's already not possible to submit new apps which still use the classic UIWebView (only existing apps with UIWebView can still be updated).

[t00]

With the current setup the popup when launching SEB looks like on the screenshot.

The WebKit part is really worrying as SEB needs to identify itself securely for the web page to recognize it. Possibly client certificates are a better alternative but these need to be generated per exam, delivered and installed. Chromium v3 manifest is indeed problematic but in theory an embedded Chromum browser should not be affected by V3 extension limitations as it is not a general purpose browser.

Not sure how we will proceed further as without BEK in header we will not be capable of generating custom configs and checking them (with obviously limited trust for BEK ExamKey+URL hash check).

[danschlet]

Is the SEB Javascript API to query the BEK and CK not an alternative for you? This was now already implemented in several LMS (Moodle, OpenOlat for sure, I think others as well) and exam products.

Have you manually added the LookupViewService to prohibited processes in your settings (looks like, otherwise it should not be displayed in this dialog)? In the latest SEB versions, terminating both services is hardcoded. Also when you add the processes and enable their "Force terminate" property, this dialog should also not be displayed. Force terminate is not set for applications which might lose unsaved changes, but for background services that's not relevant.

[t00]

I guess it is just about time do make the switch to a JS API.

For the Angular SPA it seems fairly straightforward to include the headers in an interceptor (I have not tested the code below) but it feels like a step back in terms of security as SafeExamBrowser.browserExamKey will not contain an actual request URL (to the API) but the currently opened location URL which in SPA might not change often and will be easier to spoof by a bad actor.

Obviously SafeExamBrowser.configKey will still contain a hashed configuration which is hard to retrieve moments before the exam but it in our case BEK will never change throughout the exam as the router.url won't change during it.

Static content is served in our case by a web server so BEK checking is not viable as it would require launching a separate service to check only some URLs for SEB-only access.

declare var SafeExamBrowser: ISafeExamBrowser;

interface ISafeExamBrowserSecurity {
  browserExamKey: string;
  configKey: string;
}

interface ISafeExamBrowser {
  security: ISafeExamBrowserSecurity;
  version: string;
}

private addSebHeader(headers: HttpHeaders): HttpHeaders {
  if (typeof(SafeExamBrowser) === 'undefined' || !SafeExamBrowser.security) {
    return headers;
  }
  if (SafeExamBrowser.security.configKey) {
    headers = headers.set('X-SafeExamBrowser-ConfigKeyHash', SafeExamBrowser.configKey);
    // needed to calculate BEK from the current URL
    headers = headers.set('X-SafeExamBrowser-RequestUrl', this.router.url);
  }
  if (SafeExamBrowser.security.browserExamKey) {
    // Not useful at all in SPA
    headers = headers.set('X-SafeExamBrowser-RequestHash', SafeExamBrowser.browserExamKey);
  }
  if (SafeExamBrowser.version) {
    // For auditing
    headers = headers.set('X-SafeExamBrowser-Version', SafeExamBrowser.version);
  }

  return headers;
}

Thank you for pointing me to the right direction though, at least I know that the days of WebView are numbered :)

Regarding LookupViewService present in hardcoded services it won't work for us as the config is generated on fly so all default entries in the plist are overwritten, yet I just checked the logic and it seems com.apple.quicklook.ui.helper is used independently of settings so it really should work - I will do more testing.

Thanks for a very helpful reply, I will update here how did we solve the problem of an empty spellcheck window (or not).

[t00]

PS: I will revert autoQuitApplications as just as you mentioned it is excessive in the latest seb-mac and can interfere with genuine apps - thanks for a heads up on this one!

[danschlet]

There is an empty lookup view shown instead of word lookup which is a step in a good direction but ideally nothing should be shown to the user.

Ah, I think I know now what you mean. Unfortunately that's the best I can do on macOS 13. If I remember right, the system starts QuickLookUIHelper when the lookup is initiated. SEB kills it immediately after it's started, but cannot prevent the empty window to show up shortly. But to be fair I would consider that only a minor visual issue, or am I missing something?

[t00]

Indeed it is just a minor issue and to see it someone had to try to open it meaning likely they knew what they were doing :)

[danschlet]

Btw. the best solution for checking the SEB app integrity is the new AppSignatureKey ASK. But that works only with SEB Server, as it requires a trusted connection between SEB client and SEB Server and it just shows which clients send the same ASK. You can use trusted reference machines or heuristics to figure out which clients send the correct ASKs and which deviate (send a different ASK than the reference machines or different than the majority of SEB clients). But you don't need to copy any BEK from Config Tool/Preferences to an exam system and the ASK value itself is different in every exam session, encrypted with a different secret for every client and we can replace the algorithm to calculate it in any SEB release, if we feel like it might have been compromised. And it's calculated in the obfuscated binary security modules.

But unfortunately I don't think it would be easy to implement it with the same security for third party exam systems which are not connected to SEB Server.

[t00]

I will definitely put SEB server on a watch list, especially since if I remember correctly it has some proctoring support. Running an extra docker service is not a problem. Thanks for your time - much appreciated!

[aurelienb1]

We did some tests and the problem persists even with the new version of seb. Regards

[danschlet]

Did you test it with SEB 3.2.3 and 3.2.4 or only 3.2.4? It would be helpful to get feedback like this before the second new version is released. Anyways, as this only seems to happen with the classic WebView which is anyways deprecated and will be removed by Apple in future macOS releases, I would recommend to update your exam setup to use the modern WebView.

[aurelienb1]

We test both version 3.2.3 and 3.2.4, I don't have a mac that's why the return is longer. We can coordinate, I can even test the versions before they are released if you wish. Regards

[danschlet]

Yes, at least in macOS Ventura 13.3 lookup with force touch in the classic WebView with the standard SEB kiosk mode is not blocked (it seems to be when using the AAC Assessment Mode, see Security pane).

[danschlet]

I improved monitoring and terminating those two lockup system processes, so in my tests no content was displayed anymore.

The pre-release version is available from here.

@aurelienb1, could you retest if it works now for you? Thanks!

[danschlet]

@menziesrm can you also check if the issue is fixed in the pre-release version?

[menziesrm]

@danschlet Thank you Dan, I will test this out and let you know. Do you have any idea when 3.2.5 would be released if this does fix the issue?

[danschlet]

Thanks! I could release it immediately, if it fixes the issue.

Btw: In my testing, there is still a pop up window displayed, but it's empty. That was the best I could achieve by terminating the QuickLookUIHelper process (which should be more reliable now than in the previous solution).

[aurelienb1]

Ok, we have just tested with 3.2.5 and it is fixed, the window appears but it is empty. Great work.

[danschlet]

I released SEB 3.2.5 for macOS last Friday after @aurelienb1's feedback. Hope it also works for you, @menziesrm.