Microsoft Portals crashing

[val_0]

In the last few weeks I noticed more and more Microsoft admin portal starting to hang and then crash. It started with the Intune admin portal and now spread to Azure and M365. I can stop the portals from crashing by disabling the NoScript add-on completely. I haven't been able to find a combination of permissions that works with NoScript on. This is a GIF of the behaviour - https://imgur.com/a/K0KV49y in the first load of Intune you can see that the network never stops and keeps loading a script consuming 100s of MB of data. Eventually, the tab freezes and crashes. The second load is with NoScript disabled - you can see that it loads the page successfully with 53MB of data. The same can be replicated on the portal.azure.com and admin.microsoft.com sitess. I am not sure how to address this issue except to disable the NoScript extension. The browser is Edge Version 141.0.3537.57 (Official build) (64-bit). Any advice or ideas would be greatly appreciated.

[therube]

(Your GIF link looks to be dead, or wrong?)

[val_0]

You are correct, I updated the link and it should work fine now.

[barbaz]

What version of NoScript?

I haven't been able to find a combination of permissions that works with NoScript on.

Have you tested with "Disable restrictions for this tab"?
If so and if that didn't help, have you tested with "Disable restrictions globally (dangerous)"?

[val_0]

Version 13.2.1. Tested with both and unfortunately no change in behaviour. Continuously tries to load the scripts and eventually crashes the tab.

[barbaz]

Does Edge have the Chromium developer tools Console? If so, do you see any related messages there?

[val_0]

It does and I spent quite a bit of time yesterday trying to understand what is relevant and what is not. I enabled "debug" in NoScript to try to catch any related messages. You'll have to forgive my ignorance as this part of web control is very foreign to me but this is what I was able ascertain.

1. When NoScript is disabled (when I say "disabled" I am referring to the extension itself vs site/tab; as long as NoScript extension is enabled the effect on the sites is the same) I see only 4 Dedicated Worker processes spawn in Browser Task Manager. https://imgur.com/a/8h2FGPf first image and everything is working as expected.
2. When NoScript is enabled, hundreds of Dedicated Worker processes are spawned which very quickly consume all available RAM (64GB machine) https://imgur.com/a/8h2FGPf second image.
3. In the Dev Tools console, there are no error msgs that have [NoScript], but I do see a lot of error messages related to that script. They are attached in the same link.

Let me know if I can get any other information for you. I've disabled all other extensions and run test in In-Private mode to remove any other unknown variables.

[barbaz]

4 Dedicated Worker processes

This could be very relevant, espsecially looking at your latest screenshots. To avoid workers bypassing NoScript's security measures, NoScript needs to be able to act in worker contexts, but since there is no proper WebExtensions API for that, NoScript has to resort to messy hacks to "patch" worker contexts. Unfortunately I'm out of troubleshooting ideas, sorry All I can suggest is waiting for Giorgio to find time to get to this thread

[val_0]

Thanks for looking into this. For comparison-sake, I tried using uBO to achieve the same result (blocking scripts, etc) and I was able to block scripts on the MS Portals without the same symptoms as with NoScript. I don't know how one works vs the other, but I don't see any additional Worker Processes being spawned or similar script injection errors. Just an FYI in case that helps.

Another interesting point, is that this originally started only with the Intune portal. Then, after a few weeks, the Azure portal started to suffer from the same issue. Now I can replicate this in Azure, Intune and Purview. I suspect that maybe MS is making changes to their portals one by one and the issue is becoming more "impactful".

Let me know if I can provide any more information.