Windows 11 laat gebruikers toegang tot camera en microfoon per app instellen

Windows 11 laat gebruikers de toegang tot de camera, microfoon en locatie per Win32-app instellen. Dat blijkt uit een nieuwe Experimental Preview Build. Tot dusver was het alleen mogelijk om de toegang voor alle Win32-programma's wel of niet toe te staan.

De wijziging zit in Windows 11 Insider Experimental Build 26340.9212, bevestigt onder meer Windows Latest. Daarin kunnen gebruikers in de Windows-instellingen onder 'Privacy en beveiliging' de toegangsrechten voor ieder programma afzonderlijk instellen.

Tot dusver kon dit alleen bij apps van de Microsoft Store. Voor andere applicaties, zoals Google Chrome, Microsoft Edge en Discord, konden gebruikers de toestemming alleen voor alle apps tegelijk wijzigen. Het was dus bijvoorbeeld niet mogelijk om wel Discord, maar niet Chrome toestemming te geven om de microfoon te gebruiken.

Daarnaast vraagt Windows in dergelijke apps vooraf om toestemming voor het gebruik van de microfoon, camera of locatie. Veel apps, zoals Google Chrome en Microsoft Edge, hadden zelf al ingebouwde toestemmingsvensters, maar in de Insider Build verschijnt er midden in beeld een standaardpop-up van Windows bij alle Win32-programma's.

Het is niet duidelijk of en wanneer deze aanpassingen beschikbaar komen in de stabiele release van Windows 11. Meestal duurt het maanden voordat functies in het Experimental-kanaal algemeen beschikbaar komen.

Oude toestemmingspagina (links) en nieuwe pagina. Bron: Windows Latest

Reacties (45)

[beerse]

Het gaat hier om win32 applicaties. Dat houdt volgens mij in dat het om 32 bits applicaties gaat. Is microsoft van plan om die 32 bits applicaties te ondersteunen tot er een 128 bits versie van windows uit komt?

In de tijd van 16 v.s. 32 bits applicaties (de overgang van msDos naar msWindowsNT) was het voor de compatibiliteit wel nodig. Maar dat ze die 16 bits omgeving pas hebben afgezworen toen ze over gingen naar 64 bits is misschien een slecht voorbeeld voor de toekomst.

Toegegeven, pas met windows11 hebben ze de 32-bits versie van msWindows pas achter zich gelaten en daarmee de 16-bits mogelijkheden. Maar toch hoop ik dat microsoft de 32-bits runtime omgeving toch snel achter zich laat.

[Blokker_1999]

Win32 is de naam van de api die geintroduceerd is met de komst van NT en later ook in Windows 95 en als expliciet doel te dienen voor 32bit applicaties. Vandaag wordt het ook vaak gebruikt als verzamelnaam voor alle applicaties de gebruik maken van zowel de win32 als de win64 API. Applicaties die nog een pure executable zijn in plaats van dat ze via een moderne tussenlaag zoals .Net werken.

En waarom zou Microsoft de 32bit laag moeten weglaten? Wat win je er mee? En zelfs vandaag zijn er nog mensen die op een 64bit Windows weer met omwegen die 16 bit laag terugbrengen voor oude applicaties te kunnen blijven gebruiken.

[rjmno1]

Klopt dat maakt windows x64 downwards compatible.

En dus nog altijd 32 bit aplicaties ondersteund.

[MrJoery]

Met Win32 worden hier de reguliere EXE & MSI's bedoelt. De apps uit de Windows Store (appx, etc.) konden al per applicatie geblokkeerd worden.

[David14p]

Win32 is volgens mij gewoon de naam van een api en heeft niks met 32 bit te maken.

[Henk Poley]

Precies dat. Het is meer zoiets van, "een bestand openen vraag je zo en zo aan, stop dit nummertje daar in, en de bestandsnaam daar, en roep dan dat we het moeten gaan doen". Dat werkt grotendeels hetzelfde voor 32 en 64 bits app. Hetzelfde nummertje, dezelfde volgorde van gegevens aangeven, het 'roepen' (interrupt) gaat dan alleen op een 32 of 64 bit manier, maar is altijd hetzelfde.

[wiseger]

Zoals anderen al stellen, Win32 is de naam van de API. Oorspronkelijk de 32 bits Windows API maar intussen al heel lang gewoon de Windows API dus 64 bits.

De speciale laag om 32 bits applicaties te kunnen draaien is wow64.

En vergis je niet, in de industrie wordt nog altijd 32 bits gebruikt. Zowel 32 bits applicaties als 32 bits communicatie protocollen. Daar wordt met hele lange termijnen gewerkt waarbij het 'don't fix it if it don't break' gehanteerd wordt.

[recyclebin]

Los van dat win32 slaat op een applicatie API om met Windows te communiceren,

Is microsoft van plan om die 32 bits applicaties te ondersteunen tot er een 128 bits versie van windows uit komt?

Reken er maar niet op dat we snel een conventionele 128-bit CPU of OS hoeven te verwachten. Met 64 bits zou een processor maximaal 16 exabyte aan geheugen kunnen gebruiken.

Ik weet dat ik nu herhaal wat ze vroeger zeiden over 32-bits met 4GB, maar 16EB is zo'n bizar grote hoeveelheid; met de huidige technieken hoe SRAM/DRAM gemaakt wordt, kunnen we dat realistisch gezien niet bereiken.

Daarnaast, als we zoveel geheugen nodig hebben voor Windows en wat applicaties te draaien dan lijkt me dat we eerder de plank mis hebben geslagen met optimalisaties De POST tijdens zullen ook niet lekker snel zijn

[CivLord]

Of applicaties 32/ 64/ 128 bits zijn heeft niet enkel te maken met het aanspreken van geheugen, maar ook met de CPU-instructies.
Met een 128 bit instructieset zou een CPU in één keer een instructie van 128 bit kunnen verwerken, iets wat met bv. een 64 bit instructieset meerdere instructies zou kosten.

[Olaf van der Spek]

Maar toch hoop ik dat microsoft de 32-bits runtime omgeving toch snel achter zich laat.

Want?

[Marctraider]

Allemaal fout. Dit gaat om alle niet Store / UWP related apps, waarvoor dit soort 'permissies' nooit zijn bedacht. Hier heb je normaliter alleen user/elevation permissions (basic uitgelegd)

[Reactie gewijzigd door Marctraider op 19 augustus 2026 23:07]

[rjmno1]

Met die 128 bits versie van windows word onder andere ook door arm ondersteund microsoft is met de laptops daar al klaar mee.

als er nog een 128 bits versie van windows komt op het x86 platform dat weet ik niet.

[Olaf van der Spek]

Er is geen 128 bits versie.

[kdekker]

De 32 in win32 heeft al heel lang geen 1:1 relatie met 32-bit. Meestal wordt daarvoor x86 (32-bit) of x64 (64-bit) voor gebruikt.

Windows zelf is al heel lang 64-bit, maar pas sinds Windows 11 is er geen 32-bit Windows versie meer. In verband met comptibiliteit heeft Microsoft de verwarring best groot gemaakt: C:\Windows\System32 bevat 64-bit executeerbare bestanden (o.a. .exe en.dll), C:\Windows\SysWOW64 juist 32-bit. In de registry zit dat op een soortgelijke manier. En in namen van Windows systeem DLL's zit ook nog wel de *32.dll naam, wat ook niet (meer) op het aantal bitjes slaat.

De term Win32 slaat ook op de 'Win32 API' (wat ook @Blokker_1999 zegt), zeg maar de laag waar tegenaan je programmeert als programmeur (kenners weten dan ook hoe je de term MSDN interpreteert, dat is/was de oude naam voor de documentatie van de Win32 API). Hoe de interactie 32-bit v.s. 64-bit zit gaat hier een beetje te ver, maar onder de motorkap loopt dat via System32 vs SysWOW64, zoals ik hierboven noem.

Overigens is .NET ook afhankelijk van de Win32 API (of op Linux, van die systeem API). Dingen als file operaties, proces beheer lopen via low-level OS routes, wat automatisch op Windows dus Win32 is.

In menselijke termen klinkt 64-bit is meer/beter dan 32-bit. Dat is deels een psychologische truc. De hoofdreden voor overstap naar 64-bit vanuit eindgebruikersperspectief is de mogelijkheid om meer dan 2GB geheugen aan te kunnen spreken (in 32-bit was dat met trucs beperkt mogelijk, maar nooit meer dan 4GB) + bijv. grotere files dan 2GB te kunnen gebruiken. Die extra mogelijkheden komen wel met een prijs, nl. een verwijzing naar geheugen met een 64-bit adres kost 2x zoveel ruimte als voor een 32-bit adres. Dus de extra mogelijkheden komen met een 'prijs'. Doordat de focus nu 100% op 64-bit ligt, Windows zelf ook iets vlotter op direct 64-bit werkt, dan 32-bit op 64-bit Windows (de WOW in SysWOW staat voor (32-bit)Windows-on-(64-bit)Windows en is een compatibilitetieslaag) is de 'prijs' van het extra geheugengebruik van een 64-bit executable t.o.v. een 32-bit executable voor lief genomen. Uit de tijd dat ik actief bezig was met overstap van 32-bit naar 64-bit was het extra geheugengebruik ca 30% (dat is uiteraard applicatie specifiek, afhankelijk hoe geheugenintensief een applicatie is). Een andere praktische reden van overstap op 64-bit is: iedereen doet het, waardoor 3rd party spul geen 32-bit interface meer aanbood (bijv. database leveranciers).

Dat gezegd hebbende: het zijn eigenlijk alleen nog oude apps, waar de leverancier niet meer van bestaat of deze geen tijd/geld (noem het) over heeft om een 64-bit versie te maken, die die oude lagen nog nodig hebben. Maar uitsterven van iets duurt heel lang. Daarom zal Microsoft oude meuk lang laten zitten, omdat verwijderen van code ook een risico op fouten/bugs oplevert. Voor een ontwikkelaar geldt dat oude code alleen weggehaald wordt, als het in de weg zit en je niet al te veel klanten dupeert (dat is nl. je inkomstenbron).

[Reactie gewijzigd door kdekker op 20 augustus 2026 11:50]

[FPSUsername]

Mis ik iets of is dit een andere functie. Dit zit er toch al best lang in? Ik kan op mijn werk laptop al best lang gewoon de mic blokkeren voor Vivaldi, die ik als .exe geïnstalleerd heb.

[Ricco02]

Veel apps, zoals Google Chrome en Microsoft Edge, hadden zelf al ingebouwde toestemmingsvensters

Dit dus. Waarschijnlijk heeft Vivaldi hun eigen ingebouwde toestemmingvenster.

Echter voorkomt dat niet dat Vivaldi alsnog bij jou microfoon kan. Aangezien het nooit op systeemniveau per app geblokkeerd kon worden. Dus technisch kon Vivaldi altijd je microfoon gebruiken. Hun eigen toestemmingvenster voorkomt dat natuurlijk technisch niet.

In de nieuwe functie kan je het nu op systeemniveau (Windows) het per app instellen.

[FPSUsername]

Ah duidelijk. Dan zal dat zo zijn. Mooi dat het zich verder uitbreid tot alle programma's

[faim]

Precies, Vivaldi heeft zelf altijd gewoon toegang tot de microfoon etc, de toestemmingsvensters (alsmede in Edge en Chrome) zijn per website, niet voor de Windows apps zelf.

[LootersV]

“Mis ik iets of is dit een andere functie. Dit zit er toch al best lang in?”

Ik dacht hetzelfde maar ik had me vergist met MacOS

[FPSUsername]

Tja, een mooier OS, maar daar kun je niet de software op draaien die ik nodig heb (en tevens gaan de lampjes bij IT branden als er geen windows gebruikt wordt, systeembeheer is een vak apart). Thuis lekker doen waar je zin in hebt, op werk roeien met de riemen die je krijgt.

[LootersV]

Je kunt elk OS wat er bestaat en dus ook de software draaien op een mac; zie vm ware fusion

[FPSUsername]

Dan draai je het alsnog op windows

Kan ook RDP naar een windows server, komt een beetje op hetzelfde neer.

[ochhanz]

Goede zaak, miste deze functie. Hopelijk komt het daadwerkelijk naar een stabiele versie.

[squareware]

Waarom alleen webcam en microfoon en niet meteen ook allerlei andere rechten aanpassen als instellingen wijzigen, lezen en schrijven van bepaalde mappen, uitgaande internet verbindingen (heeft windows firewall al een beetje) endergelijke... zou wel fijn zijn voor de privacy.

[joezzt]

Ja, en ook bij een muisbeweging vragen of je dat toestaat, wel per app graag dan.

[Deepvault]

Dit is natuurlijk gewoon hetzelfde concept dat Apple al jaren gebruikt. 😏 Microsoft wil al jaren graag op Apple lijken, en dit is weer zo’n mooi voorbeeld.

Maar goed: beter goed gejat dan slecht bedacht. 😉 Als Microsoft het eindelijk fatsoenlijk implementeert voor Win32-apps, is dat alleen maar winst voor de gebruiker.

[dakathefox]

Mooi dat WIndows dat na al die jaren ook eindelijk kan.

[mdenboer]

Alleen hopen dat het ook echt werkt. Voor nu nog te vaak een niet-werkende microfoon. En daar kom je meestal pas achter als het telaat is.

[CriticalHit_NL]

Dat gebeurt vaak als een andere applicatie al je microfoon 'gijzelt' maar in de June 2026 Patch bij Windows 11 zou Microsoft eindelijk na het zoveel jarige bestaan het toestaan de webcam te kunnen gebruiken tegelijkertijd in meerdere applicaties.

[dakathefox]

De keren dat ik in Teams zit en mijn camera of microfoon weer een zetje moet geven zijn inderdaad niet op 1 hand te tellen in een week tijd.

[Davey400]

Precies. Nu GNOME en KDE nog en dan zullen alle veel gebruikte desktops het kunnen.

[crichton]

Wow, wat een nieuws! Wat zijn die Redmond ontwikkelaars toch briljant!

[Davey400]

Precies. Gnome en KDE zullen nu dit trucje bekend is niet zo lang op zich laten wachten voordat ze dit ook kunnen.

[faim]

Ondertussen zit dit al sinds jaar en dag in macOS…

[tfk__66]

Is dit niet gewoon containerized apps?

[Roel1966]

Eerlijk gezegd nooit echt zo naar gekeken omdat ik sowieso alleen de interne microfoon van mijn Logitch webcam gebruik. Die schakel ik altijd via de Logitech software uit en alleen dan gebruik als ik eens een Teams meeting heb of had.

Als een programma dan toch van de webcam of microfoon gebruik wil maken dan werkt dat toch al niet omdat dit uitgeschakeld is in de webcamsoftware. Had er geen zin in om dan bij elk programma dat apart in te moeten gaan stellen.

[Atlantis1995]

En hoe zit dat met updates van bijvoorbeeld LG die geascocieerd worden met drivers en wat daar bij komt?

[HSG]

Raar dat dit nu pas kan.