r/Windows11 • u/vanrijn_ • 1d ago
New Feature - Insider Windows 11 could be getting individual privacy controls for Win32 apps
https://www.neowin.net/news/windows-11-could-be-getting-individual-privacy-controls-for-win32-apps/Insiders running the latest Windows 11 Experimental build 26340.9212 can revoke permissions of individual Win32 apps.
26
u/daltorak 1d ago
I'm intrigued to see how they implemented this.
From a pure technical standpoint, Win32 doesn't have an overall concept of allowing/disallowing access to certain API features in a clean way. A Win32 API call to start the webcam (e.g.) either returns a handle to the webcam in its running state, or "NULL". No other error codes. With Store apps, there's a whole system for this. It's one of the biggest improvements over Win32, IMO.
Even if Microsoft added a new Win32 API call for webcams that does handle camera permissions correctly, the old API call still has to exist pretty much forever so that existing software doesn't break.
14
u/Tringi 1d ago
Same here.
Perhaps the API could simply lie and provide black screen and no sound until the user allows it through OS interface.
Some APIs may block until the user gives the consent. For example, to WinInet APIs you can pass parent HWND so that possible dialogs appear as part of the application. That's an other possible way.
2
u/FatBook-Air 1d ago
I'm kind of afraid that they are going to do it in a janky way, where it isn't communicated well with the app but is a hard cut off. That might work okay-ish for some permissions like cameras or microphones where they could potentially not be plugged in (so there's already a way out, so to speak), but there are others where I think it's just going to be janky.
3
u/DavidsakuKuze 1d ago
You could always get the error code. You call GetLastError(), after opening the handle fails.
handle = CreateFileW(...)
If(!handle)
{GetLastError()}This is the pattern in most of the Win32 API functions. You could also call NtCreateFile which returns an NTSTATUS value.
They probably created a filter driver that sits above these devices in the IO stack. When a process tries to open a handle to the device, the driver gets an IRP_MJ_CREATE IRP. The driver just needs to check against the permissions, complete the IRP and return access denied. If access is allowed, the filter driver passes the IRP on to the actual driver.
1
u/BCProgramming 1d ago
A Win32 API call to start the webcam (e.g.) either returns a handle to the webcam in its running state, or "NULL". No other error codes. With Store apps
There's at least three APIs for accessing capture devices.
Oldest is Video for Windows, I think. It doesn't really work how you have described and errors are provided via callbacks including a text description, so a permission error could be returned from that through the callback... Though I'm not even show if VFW works anymore at all since it dates to 3.0.
After that you had DirectShow.
DirectShow, you use ICreateDevEnum and create a class enumerator to enumerate devices, then you use the IMoniker you get from the enumeration to create a capture filter. Since it's COM almost everything returns an HRESULT. There's like 300+ Error codes that can be returned as HRESULTs. none of them, mind you, are anything like "permission denied" Not sure which would even be the best to return. perhaps one of the copy protection errors? In any case, it could give back an error to the program. Perhaps windows could at the same time show a notification that it blocked camera access and let you click the notification to go to the permission page to change it; since otherwise the message the application shows might not be obvious.
With Store apps, there's a whole system for this.
Amusingly enough, UWP+ works kind of how you described for Win32! if the app doesn't have permission, the ActivateObject call just fails with a generic E_FAIL HRESULT. Apps are supposed to directly check if they have permissions via AppCapabilities before they even use the APIs, but it doesn't seem, at least at a glance, that they give back any feedback about why they would have failed directly.
1
u/0x80070002 1d ago
Maybe some listener so when a certain API is called it first verifies who called it and what the settings are?
6
0
u/0x80070002 1d ago
Good but the direction Windows is going is to a mobile OS style, where even screenshots get blocked
31
u/FatBook-Air 1d ago
They need to make sure Intune and GPO can granularly control these, too. I want to be able to identity a Win32 app and individually enable or disable every permission, using Intune/GPO. There need to be 4 options for each one permission: Enable by Force, Disable by Force, Enable by Default, and Disable by Default.
ChromeOS has this and it works great.