Chrome lists Network Provider as incompatible application
Reported by
mathieu....@gmail.com,
Aug 26
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. Install an application that implements a Network Provider (https://docs.microsoft.com/en-us/windows/desktop/secauthn/implementing-a-network-provider), such as WinFSP (http://www.secfs.net/winfsp/) 2. Open or save a file to a network location handled by the provider 3. Observe the application being listed in the incompatible application list (chrome://settings/incompatibleApplications) What is the expected behavior? What went wrong? Chrome should allow Network Provider applications to interact with Chrome within their intended boundaries, and shouldn't list them as incompatible. I'm worried that the upcoming blocking of 3rd party DLL may prevent Network Provider applications from working, i.e. open or save files to the locations it handles. Did this work before? N/A Chrome version: 68.0.3440.106 Channel: stable OS Version: 10.0 Flash Version: See https://github.com/billziss-gh/winfsp/issues/187#issuecomment-416080593 for WinFSP's author comment that it does not inject any code into other processes on its own.
,
Aug 27
In all likelyhood, the Network Provider DLL is loaded automatically by the Windows File Dialog, not when accessing a file handled by the provider as that happens through a kernel file system driver.
,
Aug 27
,
Aug 27
,
Aug 31
As per comment #0, this issue seems to be related WinFSP and Network Provider DLL. Hence Hence adding label "TE-NeedsTriageHelp" and requesting some one from Internals team to have a look into this and help in further triaging it. Thanks...!
,
Aug 31
Couple clarifications: - WinFSP is only one example of a Network Provider that I happen to be using. The issue is not restricted to this application. A quick search show that a wide variety of applications also implement a Network Provider: VMWare guest tools (vmhgfs), Dell Encryption (CMGShieldNP), Citrix Single Sign On (PnSson), Symantec Network Access Control (SnacNp) - In the case of WinFSP, just having the application installed is sufficient (no mappings need to be configured). Opening a File Dialog automatically loads the Network Provider DLL in Chrome's process. - I'm guessing the File Dialog is the way other DLLs providing file explorer shell extensions end up loaded into chrome, e.g. Dropbox, TortoiseSVN/GIT, FileZilla. I'm not using any of these so I can't verify, but they're all listed in the following product forums topic: https://groups.google.com/a/googleproductforums.com/d/topic/chrome/pTxH3Yu7XVc Arguably this is a Windows OS deficiency that calling the file dialog causes 3rd party DLLs to be automatically loaded into the calling process. Maybe Chrome should create a separate "File Dialog Handler" process just for the purpose of opening the file picker?
,
Aug 31
Yes moving file dialog operations to a utility process is on our radar. We definitely want people to get their shell extensions back in Chrome. |
||||
►
Sign in to add a comment |
||||
Comment 1 by mathieu....@gmail.com
, Aug 27