microsoft
[Feature]: Sign windows Binaries and browser exe's
🚀 Feature Request
Version 1.40.0
Steps to reproduce It has now been established that it is the chrome.exe file that does not have a digital signature on the file that is blocked by Microsoft Applocker. The exe file is located outside C:\Program Files and C:\Program Files (x86) which causes files without a digital signature to be blocked by Microsoft Applocker. We have used our own certificate to temporarily solve the problem and have digitally signed the file and have tested that this is the cause. Would be good if the exe file has a digital signature from the beginning in future versions.
In the Windows log when Applocker blocked
%OSDRIVE%\USERS\uuyP\APPDATA\LOCAL\MS-PLAYWRIGHT\CHROMIUM-1091\CHROME-WIN\CHROME.EXE was prevented from running.
on further googling, this is what we found:
When you install Chromium through MS Playwright using C#, it downloads Chromium from the Playwright servers. As Chromium is an open-source project, it may not have a digital signature because it's not necessarily released by an officially recognized entity that would provide a digital signature, such as Google or Microsoft.
However, if you need to add a digital signature to the Chromium executable for your specific use case, you would need a code-signing certificate and a tool like signtool.exe (part of the Windows SDK) to manually sign the executable.
Can Playwright solve this problem better, as its making Playwright non-usable.
Expected behavior Playwright should use Chrome.exe with digital signature for security reasons.
Actual behavior Playwright looks non-usable.
Additional context No response
Environment Windows10 - 64 bit
Example
No response
Motivation
https://github.com/microsoft/playwright/issues/34862 https://github.com/microsoft/playwright-dotnet/issues/3070 https://github.com/microsoft/playwright/issues/17165 https://github.com/microsoft/playwright-java/issues/1016 https://github.com/microsoft/playwright-java/issues/1089
Multiple issues reported from various enterprise customers
hey i would join this request. We (big company) decided to use playwright and need the trust management to permit the executables (printdeps.exe, headless_shell.exe). Currently we are blocked because the executables are not signed by you.
Hey everybody, also affected by this. Partial solution for me was using this. It allows me to run browser tests, but the "Shot trace viewer" in VS code extention is not working, as its part of the custom binary, and this forces pw to use the system chrome.
{ name: "UI", testDir: "./tests/UI", use: { ...devices["Desktop Chrome"], channel: "chrome", }, },
instead of just
{ name: "UI", testDir: "./tests/UI", use: { ...devices["Desktop Chrome"], }, },
Looking forward for the v1.56
EDIT This is this causing npx plawright show-trace to fail as spawnUnknown
Ok I just looked more into the history of this issue here in github
Sep 2022 - https://github.com/microsoft/playwright/issues/17165 Oct 2022 - https://github.com/microsoft/playwright-java/issues/1089 Jul 2023 - https://github.com/microsoft/playwright/issues/2365 Nov 2024 - https://github.com/microsoft/playwright-dotnet/issues/3070 Mar 2025 - https://github.com/microsoft/playwright/issues/35363
@mxschmitt Any Real plan when this will be fixed? We are evaluating PW as our testing framework, and the non sighed binaries and the time to address that could be problem. Thanks for the answer
We are internally working on it and preparing our browser building infrastructure to allow signing the binaries.
@mxschmitt Great to hear that, is there any ETA. It looks like options Pick a locator and Record at cursor at Test Explorer extention are also affected by this and cannot be lauched.