Mac-appen din gir mikrofontilgang — og glemmer den ved hver oppstart

Her er en feil som får deg til å tvile på dine egne øyne. Du installerer GeekBye, den ber om mikrofontilgang, du klikker Allow, og transkribering virker. Flott. Du avslutter, åpner den på nytt neste morgen — og den ber om mikrofontilgang igjen. Du går for å sjekke Systeminnstillinger → Personvern og sikkerhet → Mikrofon for å fikse det manuelt, og GeekBye er ikke engang på listen. Ikke nektet. Ikke tillatt. Bare fraværende, som om den aldri hadde spurt.

Hver enkelt bit så riktig ut. Forespørselen var ekte. Tillatelsen virket der og da. Appen var korrekt signert og notarisert med de riktige bruksstrengene. Og likevel fordampet tillatelsen ved hver oppstart. GeekBye v2.0.6 fikset det — og rotårsaken er en av de mest lumske tingene macOS gjør for å beskytte deg.

Funksjonen som gjemte appen for seg selv

Synderen er macOS App Translocation, en Gatekeeper-sikkerhetsfunksjon. Når du laster ned en app og kjører den rett fra DMG-en eller fra ~/Downloads-mappen din — hvor som helst der den fortsatt er i "karantene" — kjører macOS den faktisk ikke fra der du ser den. Den kopierer den transparent til en tilfeldig, skrivebeskyttet sti dypt under /private/var/folders/.../AppTranslocation/… og kjører den kopien. Det er et godt forsvar: det hindrer en ondsinnet nedlasting i å tukle med filer ved siden av seg selv.

Men her oppstår kollisjonen. macOS' tillatelsessystem (TCC — det som holder styr på hvem som kan bruke mikrofonen, kameraet og skjermen din) identifiserer en app etter sti og kodeidentitet. Når appen er translokert, er den stien tilfeldig og midlertidig. Så når du gir mikrofontilgang, registrerer macOS pliktoppfyllende tillatelsen — mot en sti som ikke vil eksistere ved neste oppstart. Åpne appen på nytt, macOS translokerer den til en annen tilfeldig sti, ser en app den ikke har noen oppføring av, og spør igjen. Og fordi den spøkelsesstien aldri er et stabilt sted, får appen aldri en permanent rad i Systeminnstillinger → Mikrofon.

Appen ga tillatelse til et spøkelse.

Dette er også grunnen til at bare noen folk ble rammet. Hvis kopien din av GeekBye allerede lå i /Applications — fordi du dro den dit, eller fordi den havnet der via automatisk oppdatering — er det ingen karantene, ingen translokering, en stabil sti, og alt bevares perfekt. Feilen var usynlig for oss og for alle som var forbi sin første installasjon, som er akkurat den typen feil som overlever lengst.

Løsningen: gi appen et ekte hjem

Siden hele problemet er en ustabil sti, er løsningen å få appen over på en stabil en. v2.0.6 oppdager når GeekBye kjører translokert (eller bare kjører utenfor /Applications) og tilbyr en "Move to Applications" (flytt til Programmer) med ett trykk — ved hjelp av macOS-relokeringskallet som kopierer pakken inn i /Applications og starter den på nytt derfra. Fra det øyeblikket har appen en fast identitet: mikrofontillatelsen sitter, skjermopptaket sitter, og GeekBye dukker endelig opp i Systeminnstillinger der du forventer det.

Forespørselen er høflig med det. Den tilbyr Move to Applications (flytt til Programmer), Not Now (ikke nå) og Don't Ask Again (ikke spør igjen) — og den husker det siste valget, slik at appen aldri maser på noen som har en bevisst grunn til å kjøre den fra et annet sted. Avgjørelsen om hvorvidt forespørselen i det hele tatt skal vises, er isolert i små, rene funksjoner (er dette bygget translokert? er det utenfor /Applications? undertrykte brukeren det?) slik at logikken kan enhetstestes uten å måtte starte et ekte notarisert bygg på et ekte karantenevolum.

Den samme utgivelsen forenklet også selve tillatelsesopplevelsen. GeekBye pleide å åpne et egendefinert, spesiallaget tillatelsesvindu i appen — noen hundre linjer med UI som forsøkte å gjenskape noe operativsystemet allerede gjør godt. v2.0.6 slettet det og lente seg på den native macOS-tillatelsesforespørselen, støttet av et stille, ikke-blokkerende banner som bare vises når en påkrevd tillatelse faktisk mangler. Mindre kode, og en atferd brukerne allerede kjenner igjen fordi alle andre Mac-apper fungerer på samme måte.

Delen jeg er mest stolt av: vi beviste det før vi trodde det

Det hadde vært lett å gjette på translokering og skipe en fiks. I stedet skipet utgivelsen en oppstartsdiagnostikk først: ved oppstart rapporterer GeekBye nå sin egen kjørbare sti og om den er translokert, om den er inne i /Applications, og gjeldende status for mikrofon- og skjermtillatelse. Den telemetrien gjorde en plausibel teori til en bekreftet en — produksjonsdata viste at de berørte øktene faktisk kjørte fra translokerte stier utenfor /Applications, akkurat som forutsagt.

Den rekkefølgen betyr noe. "Forespørselen dukker opp, men tillatelsen sitter ikke" har flere mulige forklaringer — et signeringsproblem, en manglende bruksstreng, et rettighetsproblem, en TCC-databaserirkverk. Vi utelukket årsakene på API-nivå (forespørselsstien var påviselig korrekt), og lot deretter data fra virkeligheten peke på identitets-/stilaget i stedet for å skipe en håpefull fiks og håpe supporthenvendelsene stanset.

Tre ting denne feilen lærer oss

1. En tillatelse som spør, men ikke vil bevares, er et identitets-problem, ikke et API-problem. Hvis forespørselskoden er riktig og tillatelsen likevel forsvinner, slutt å skrive om forespørselen. Spør hvilken sti og kodeidentitet operativsystemet knytter tillatelsen til — og om den identiteten er stabil på tvers av oppstarter.
2. Skip diagnostikken sammen med (eller før) fiksen. Noen få felt — hvor kjører jeg fra, hva er tillatelsesstatusen min — gjorde et kvalifisert gjett til en verifisert rotårsak og fortalte oss nøyaktig hvilke brukere som var berørt. Instrumenter grensesnittet du mistenker før du lapper det.
3. Feilene som skjuler seg for utviklere, er de som kjører i "feil" miljø. Vår levde i /Applications på hver eneste utviklermaskin, så feilen var strukturelt usynlig for oss mens den rammet førstegangsbrukere. Når en rapport ikke lar seg reprodusere, er det første spørsmålet hva som er annerledes med hvor den kjører, ikke om brukeren tar feil.

GeekBye v2.0.6 skipet relokeringsforespørselen og diagnostikken sammen. For den bredere pålitelighetsbuen dette inngår i, se hva en versjon 2 faktisk krever (v2.0.0) og hvorfor skjermopptak fanger feil skjerm (v2.0.10) — en annen feil som bare dukket opp i et bestemt miljø. For utgivelsen med de små detaljene ved siden av, rolig programvare: flimmerfiksen og svar-modus-brikken (v2.0.3 + v2.0.5).