Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MS Edge (any channel build) reverts the within-sandbox file/protocol associations to MS Edge.Stable build when running sandboxed #2949

Open
MuddyBleach opened this issue May 24, 2023 · 3 comments
Labels
Issue: Reproduced Issue reproduced without uncertainties Workaround Temporary or alternative solution

Comments

@MuddyBleach
Copy link

Describe what you noticed and did

  1. Have a version of MS Edge (Chromium-based) other than Edge.Stable installed on your PC. I personally am going to address Edge.Dev here below.
  2. Make Edge.Dev your default browser. Make sure the same is for htm, html, pdf...-files and http, https... -protocols.
    3.Now you can select any htm, html, pdf-file and start it unsandboxed. It will open in Edge.Dev. Any time, predictably, irrespective of newer OS updates etc.
  3. Create a new empty sandbox.
  4. Select the same file and start it sandboxed. It will open in Edge.Dev. as expected.
  5. Keep Edge running for a while, it may take a couple of minutes sometimes, until it does a check (?) and introduces changes.
  6. Start the same file sandboxed for a second time. Now it will open in... Edge.Stable. Otherwise it will return an error in case Edge.Stable is not available on your PC (removed or blocked). The same is for http, https... -protocols. Sandboxed programs that need to open windows in external browsers either revert to that existing Edge.Stable or begin to show errors or do nothing where Edge.Stable is absent.

How often did you encounter it so far?

everytime

Affected program

Ms Edge, Chromium-based, any channel build

Download link

not relevant

Where is the program located?

The program is installed only outside the sandbox.

Expected behavior

File association should stay preserved, i.e. be the same as generally in the unsandboxed Windows.
Indeed, the most obvious move in that situation, when using alternative browsers, would be to avoid starting Edge in specific sandboxes at all. But the catch is that in that way alternative Edge channel builds would cancel themselves completely out since they get forced to reassociate their files with Edge.Stable again when running sandboxed and thereupon go almost impracticable.
So the links surprisingly open in Edge.Stable having different user profile, settings and per-build functionality as the default Edge browser or do not open at all as Edge.Stable not present and replaced, say, with Edge.Dev (which does not cause any single issue outside sandboxes)

What is your Windows edition and version?

Windows 10Pro 22H2, build 19045

In which Windows account you have this problem?

A local account (Standard user)., A local account (Administrator).

Please mention any installed security software

MS Defender

What version of Sandboxie are you running?

Sandboxie Plus 1.9.3

Is it a new installation of Sandboxie?

I recently did a new clean installation.

Is it a regression?

not sure about that

In which sandbox type you have this problem?

In a standard isolation sandbox (yellow sandbox icon).

Can you reproduce this problem on a new empty sandbox?

I can confirm it also on a new empty sandbox.

Did you previously enable some security policy settings outside Sandboxie?

No response

Crash dump

No response

Trace log

No response

Sandboxie.ini configuration

No response

@MuddyBleach MuddyBleach added the Confirmation pending Further confirmation is requested label May 24, 2023
@offhub offhub added Issue: Reproduced Issue reproduced without uncertainties and removed Confirmation pending Further confirmation is requested labels May 24, 2023
@offhub
Copy link
Collaborator

offhub commented May 24, 2023

For some reason the UserChoice subkey is being created in the sandbox registry even though it is present in the host registry.

Try with the following settings:

ReadKeyPath=HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\*\UserChoice
ReadKeyPath=HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.*\UserChoice
sbie-issue2949.mp4

@offhub offhub added the Workaround Temporary or alternative solution label May 24, 2023
@MuddyBleach
Copy link
Author

Oh, thanks. These settings have worked out so far. But I assume they might prevent properlty associating other programs that are being installed inside the sandbox, so we will then need to disable them temporarily anyway.

@offhub
Copy link
Collaborator

offhub commented May 25, 2023

You can assign rules to a specific program or program group.

msedge.exe:

ReadKeyPath=msedge.exe,HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\*\UserChoice\*
ReadKeyPath=msedge.exe,HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.*\UserChoice\*

chrome.exe:

ReadKeyPath=chrome.exe,HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\*\UserChoice\*
ReadKeyPath=chrome.exe,HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.*\UserChoice\*

Both:

ProcessGroup=<PreventDefault>,msedge.exe,chrome.exe
ReadKeyPath=<PreventDefault>,HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\*\UserChoice\*
ReadKeyPath=<PreventDefault>,HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.*\UserChoice\*

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: Reproduced Issue reproduced without uncertainties Workaround Temporary or alternative solution
Projects
None yet
Development

No branches or pull requests

2 participants