Din Mac-app beviljar mikrofonåtkomst — och glömmer den sedan vid varje start

Här är en bugg som får dig att tvivla på dina egna ögon. Du installerar GeekBye, den ber om mikrofonåtkomst, du klickar på Tillåt, och transkriberingen fungerar. Perfekt. Du avslutar, öppnar den igen nästa morgon — och den ber om mikrofonåtkomst igen. Du går för att kolla Systeminställningar → Integritet och säkerhet → Mikrofon för att fixa det manuellt, och GeekBye finns inte ens med i listan. Inte nekad. Inte tillåten. Bara frånvarande, som om den aldrig frågade.

Varje enskild pusselbit såg korrekt ut. Dialogen var äkta. Behörigheten fungerade i stunden. Appen var korrekt signerad och notariserad med rätt användningssträngar. Och ändå avdunstade behörigheten vid varje start. GeekBye v2.0.6 fixade det — och grundorsaken är en av de mest lömska saker macOS gör för att skydda dig.

Funktionen som gömde appen för sig själv

Boven är macOS App Translocation, en säkerhetsfunktion i Gatekeeper. När du laddar ner en app och kör den direkt från DMG:n eller från din ~/Downloads-mapp — var som helst där den fortfarande är i "karantän" — kör macOS den faktiskt inte från platsen du ser. Den kopierar den transparent till en slumpmässig, skrivskyddad sökväg djupt under /private/var/folders/.../AppTranslocation/… och kör den kopian. Det är ett bra försvar: det hindrar en skadlig nedladdning från att manipulera filer bredvid sig själv.

Men här uppstår kollisionen. macOS behörighetssystem (TCC — det som håller reda på vem som får använda din mikrofon, kamera, skärm) identifierar en app utifrån dess sökväg och kodidentitet. När appen translokeras är den sökvägen slumpmässig och tillfällig. Så när du beviljar mikrofonåtkomst registrerar macOS lydigt behörigheten — mot en sökväg som inte kommer att finnas vid nästa start. Öppna appen igen, macOS translokerar den till en annan slumpmässig sökväg, ser en app den inte har någon uppgift om, och frågar på nytt. Och eftersom den där fantomsökvägen aldrig är en stabil plats, tjänar appen aldrig in en permanent rad i Systeminställningar → Mikrofon.

Appen beviljade behörighet till ett spöke.

Det är också därför bara vissa drabbades. Om din kopia av GeekBye redan låg i /Applications — för att du drog dit den, eller för att den hamnade där via autouppdatering — finns ingen karantän, ingen translocation, en stabil sökväg, och allt bevaras perfekt. Buggen var osynlig för oss och för alla som kommit förbi sin första installation, vilket är precis den sortens bugg som överlever längst.

Fixen: ge appen ett riktigt hem

Eftersom hela problemet är en instabil sökväg, är fixen att få appen till en stabil sådan. v2.0.6 upptäcker när GeekBye körs translokerat (eller bara körs utanför /Applications) och erbjuder ett klick på "Move to Applications" (Flytta till Program) — med hjälp av det macOS-relokeringsanrop som kopierar paketet till /Applications och startar om det därifrån. Från och med då har appen en fast identitet: mikrofonbehörigheten sitter kvar, skärminspelningen sitter kvar, och GeekBye dyker äntligen upp i Systeminställningar där du skulle förvänta dig det.

Dialogen är artig med det. Den erbjuder Move to Applications (Flytta till Program), Not Now (Inte nu) och Don't Ask Again (Fråga inte igen) — och den minns det senaste valet, så att appen aldrig tjatar på någon som har en medveten anledning att köra den från en annan plats. Beslutet om huruvida dialogen ens ska visas är isolerat i små, rena funktioner (är den här byggen translokerad? körs den utanför /Applications? har användaren stängt av den?) så att logiken enhetstestas utan att behöva starta en riktig notariserad bygge på en riktig volym i karantän.

Samma release förenklade också själva behörighetsupplevelsen. GeekBye brukade poppa upp ett eget, skräddarsytt behörighetsfönster i appen — några hundra rader gränssnitt som försökte återskapa något som operativsystemet redan gör bra. v2.0.6 tog bort det och lutade sig mot den inbyggda macOS-behörighetsdialogen, uppbackad av en tyst, icke-blockerande banner som bara dyker upp när en nödvändig behörighet faktiskt saknas. Mindre kod, och ett beteende användarna redan känner igen eftersom alla andra Mac-appar fungerar likadant.

Det jag är stoltast över: vi bevisade det innan vi trodde på det

Det hade varit lätt att gissa translocation och skeppa en fix. Istället skeppade releasen en startdiagnostik först: vid start rapporterar GeekBye nu sin egen sökväg till den körbara filen och huruvida den är translokerad, huruvida den ligger inuti /Applications, samt aktuell status för mikrofon- och skärmbehörighet. Den telemetrin förvandlade en trolig teori till en bekräftad — produktionsdata visade att de drabbade sessionerna faktiskt kördes från translokerade sökvägar utanför /Applications, precis som förutspått.

Den ordningen spelar roll. "Dialogen dyker upp men behörigheten sitter inte kvar" har flera möjliga förklaringar — ett signeringsproblem, en saknad användningssträng, ett rättighetsproblem, en egenhet i TCC-databasen. Vi uteslöt orsakerna på API-nivå (begäranvägen var bevisligen korrekt), och lät sedan verkliga data peka mot identitets-/sökvägslagret istället för att skeppa en hoppfull fix och hoppas att supportärendena skulle upphöra.

Tre saker den här buggen lär oss

1. En behörighet som frågar men inte bevaras är ett identitetsproblem, inte ett API-problem. Om begärankoden är korrekt och behörigheten ändå försvinner, sluta skriva om begäran. Fråga vilken sökväg och kodidentitet operativsystemet binder behörigheten till — och huruvida den identiteten är stabil mellan starter.
2. Skeppa diagnostiken med (eller före) fixen. Ett par fält — var körs jag ifrån, vad är min behörighetsstatus — förvandlade en kvalificerad gissning till en verifierad grundorsak och berättade exakt vilka användare som var drabbade. Instrumentera den gräns du misstänker innan du lappar den.
3. De buggar som gömmer sig för utvecklare är de som körs i "fel" miljö. Vår låg i /Applications på varje utvecklarmaskin, så buggen var strukturellt osynlig för oss samtidigt som den drabbade förstagångsanvändare. När en rapport inte går att återskapa är den första frågan vad som är annorlunda med var den körs, inte har användaren fel.

GeekBye v2.0.6 skeppade relokeringsdialogen och diagnostiken tillsammans. För den bredare tillförlitlighetsbågen detta ingår i, se vad en version 2 faktiskt kräver (v2.0.0) och varför skärminspelning fångar fel skärm (v2.0.10) — en annan bugg som bara dök upp i en specifik miljö. För releasen med de små detaljerna intill, lugn mjukvara: flimmerfixen och läges-chippet för svarsläge (v2.0.3 + v2.0.5).