Android: VPN per app og Chrome inkognito – hva regelen faktisk dekker

Noen har laget en automatisering som skal slå på VPN når en inkognitofane åpnes, og den er ikke pålitelig. Årsaken er strukturell, og den bør forstås før du finjusterer automatiseringen. Androids regler for VPN per app velger applikasjonspakker, mens inkognito er en tilstand inne i én og samme pakke – regelen klarer derfor ikke å skille dem. Varselet kommer først etter at nettleseren har begynt å jobbe, så selv en korrekt utløser er for sen. Ta kontrollene nedenfor i rekkefølge; feiler den fjerde, er det tilnærmingen og ikke konfigurasjonen som må endres.

Kontroll én: finn ut hva regelen per app kan velge

En Android VPN-app setter opp tunnelen sin ved hjelp av lister over tillatte eller avviste apper, og disse listene tar pakkenavn. Chrome i vanlig modus og Chrome i inkognitomodus er samme pakke, med samme bruker-ID og samme nettverkstillatelse, så en regel som inkluderer eller utelukker Chrome virker likt på begge. Plattformen har ingen identitet knyttet til fanen som den kan sammenligne med.

Dette er ikke en mangel som skal omgås, men det detaljnivået API-et tilbyr. Er kravet ditt at Chrome-trafikk skal gå gjennom tunnelen og alt annet utenfor, beskriver en regel per app dette nøyaktig. Er kravet at bare private faner skal gå gjennom tunnelen mens vanlige faner går direkte, finnes det ingen regel per app som kan uttrykke det, og uansett hvor mye varslingslogikk du legger til, får du ikke en velger som plattformen mangler.

Vær oppmerksom på pakkeidentitetsfellen mens du kontrollerer. En beta eller en leverandørversjon er en annen pakke enn den stabile nettleseren, så en regel som dekker den ene, bommer stille på den andre:

adb shell pm list packages | grep -i chrome

Kontroll to: undersøk om utløseren noen gang kan være tidlig nok

En varsellytter ser varsler den har tillatelse til å se. Å se er ikke å avskjære: nettleseren har allerede slått opp navnet og åpnet forbindelsen når varselet eksisterer, og ingenting i den kjeden venter på at automatiseringen din skal bli ferdig. En oppgave som så starter VPN-klienten, må vente på klientens grensesnitt, en mulig samtykkedialog og tunnelens håndtrykk – målt i sekunder, mens den første forespørselen måles i millisekunder.

Også selve gjenkjenningen er skjør, av en annen grunn. Varselteksten endres mellom versjoner og språk, så et mønster som passer for én utgivelse, slutter å passe etter en oppdatering, og feilen er lydløs. At et varsel mangler, er ikke bevis for at privat nettlesing ikke finnes; det kan like gjerne bety at teksten er endret eller at kanalen er dempet.

Det finnes en fornuftig variant av denne arbeidsflyten, og den er ordnet framfor reaktiv: koble til den godkjente VPN-en først, bekreft et klarsignal som faktisk viser at tunnelen frakter trafikk, åpne så inkognitoøkten via støttede nettleserkontroller, og stopp dersom klarsignalet svikter. Da beskyttes økten du er i ferd med å starte, uten å late som om en allerede pågående økt beskyttes.

Kontroll tre: gå gjennom tillatelsen du er i ferd med å gi

Tilgang til varsler er en følsom tillatelse som gir en tjeneste rett til å lese varsler fra alle apper, ikke bare nettleseren. Å gi den til et ukjent automatiseringsverktøy for å overvåke én enkelt nettlesertilstand er en dårlig handel, og tilgangen består etter at forsøket er avsluttet. Trykk styrt av tilgjengelighetstjenester er enda verre: det er et skriptlag oppå grensesnittet, ikke et støttet grensesnitt for VPN-kontroll, og det knekker ved enhver endring i layouten.

Før du gir noe som helst, spør om samme resultat kan oppnås med en støttet mekanisme. Er svaret at det er et policykrav, er svaret som regel ja: plattformen kan påtvinge en tunnel for en app eller en profil helt uten en lyttende tjeneste.

Kontroll fire: bruk alltid på og blokkering når kravet er håndheving

Dersom nettleseren aldri skal kommunisere utenfor tunnelen, hører håndhevingen hjemme i plattformens innstillinger og ikke i en makro. Android har støtte for alltid på-VPN med en blokkeringsmodus som stopper trafikk når tunnelen ikke er oppe, og administrerte enheter kan få dette via policy. Sjekk hva enheten faktisk har nå, i stedet for å anta:

adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdown

En appverdi som ikke er null, betyr at en pakke er satt til alltid på, og en blokkeringsverdi på 1 betyr at forbindelser utenfor tunnelen er blokkert. Det er denne kombinasjonen som gjør en vane til en garanti, og den fjerner samtidig kappløpet fullstendig, siden tunnelen er oppe før apptrafikk tillates.

To grenser er verdt å nevne. Arbeidsprofiler har sin egen VPN-konfigurasjon, så en regel som er kontrollert i den personlige profilen, sier ingenting om arbeidsprofilen. Og en nettleser som er installert separat, en egendefinert fane åpnet fra en annen app, eller en webview inne i en app, er en annen pakke eller kontekst med egen ruting – kontroller derfor den faktiske pakken i stedet for å anta at et vindu med annet utseende er et eget domene.

Kontroll fem: skriv ned arbeidsflyten og test feilscenarioet

Uansett hva du velger, må rekkefølgen og stoppbetingelsen dokumenteres. For bekvemmelighetsflyten betyr det: tunnel opp, klarsignal bevist, inkognito åpnet, og full stopp dersom klarsignalet svikter. For håndhevingsløpet betyr det: alltid på-app konfigurert, blokkering slått på, og forventet oppførsel når tunnelen ikke kan komme opp i det hele tatt – altså ingen trafikk framfor ubeskyttet trafikk.

Test så feilen, ikke bare suksessen. Koble ned tunnelen midt i en økt og se hva nettleseren gjør; blokker prosessen til VPN-appen og bekreft at ingenting lekker. Til slutt bør de to personvernmodellene holdes atskilt i brukerdokumentasjonen: inkognito styrer en midlertidig tilstand i nettleseren og skjuler ikke trafikk for nettverket, mens en VPN frakter trafikk, men sletter verken innlogginger eller noe som sendes i den private økten.