Cineva a construit o automatizare care pornește VPN-ul când apare o filă incognito și nu funcționează în mod fiabil. Există un motiv structural pentru asta și merită înțeles înainte de a regla automatizarea. Regulile VPN pe aplicație din Android selectează pachete de aplicație, iar incognito este o stare în interiorul unui pachet, așa că regula nu poate distinge cele două. Notificarea se declanșează după ce browserul a început deja să lucreze, așa că chiar și un trigger corect sosește târziu. Parcurge verificările de mai jos în ordine; un eșec la a patra verificare înseamnă că abordarea, nu configurația, trebuie schimbată.

Prima verificare: confirmă ce poate selecta regula pe aplicație

O aplicație VPN Android își construiește tunelul cu liste de aplicații permise sau interzise, iar acele liste iau nume de pachet. Chrome în modul normal și Chrome în modul incognito sunt același pachet, cu același id de utilizator și aceeași permisiune de rețea, așa că o regulă care include sau exclude Chrome se aplică identic ambelor. Platforma nu are o identitate legată de filă cu care să se potrivească.

Asta nu este un defect de ocolit; este granularitatea pe care o oferă API-ul. Dacă cerința ta este ca traficul Chrome să treacă prin tunel și tot restul în afara lui, o regulă pe aplicație exprimă exact asta. Dacă cerința ta este ca doar filele private să treacă prin tunel, iar filele obișnuite să meargă direct, nicio regulă pe aplicație nu poate exprima asta, iar nicio cantitate de logică a notificărilor nu va adăuga un selector pe care platforma nu îl are.

Fii atent la capcana identității pachetului în timpul verificării. O versiune beta sau o compilare a producătorului este un pachet diferit de browserul stabil, așa că o regulă care acoperă unul îl ratează silențios pe celălalt:

adb shell pm list packages | grep -i chrome

A doua verificare: testează dacă triggerul poate fi vreodată suficient de devreme

Un ascultător de notificări observa notificările pe care are voie să le vadă. Observarea nu este interceptare: browserul a rezolvat deja numele și a deschis conexiunea până când există notificarea, și nimic pe acea cale nu așteaptă ca automatizarea ta să se termine. O sarcină care apoi lansează clientul VPN trebuie să aștepte interfața clientului, orice solicitare de consimțământ și handshake-ul tunelului, măsurate în secunde, în timp ce prima cerere este măsurată în milisecunde.

Detectarea în sine este fragilă din al doilea motiv. Textul notificării se schimbă între versiuni și localizări, așa că un model potrivit pentru o versiune nu mai corespunde după o actualizare, iar eșecul este silențios. O notificare lipsă nu este dovada că nu există navigare privată; poate însemna doar că șirul s-a schimbat sau că canalul a fost dezactivat.

Există o versiune legitimă a acestui flux de lucru, și este ordonată, nu reactivă: conectează mai întâi VPN-ul aprobat, confirmă un semnal de pregătire care demonstrează cu adevărat că tunelul transportă trafic, apoi deschide sesiunea incognito prin controalele de browser acceptate și oprește-te dacă verificarea de pregătire eșuează. Asta protejează sesiunea pe care ești pe punctul de a o începe fără a pretinde că o protejezi pe cea deja în curs.

A treia verificare: auditează permisiunea pe care ești pe punctul de a o acorda

Accesul la notificări este o permisiune sensibilă care permite unui serviciu să citească notificările din fiecare aplicație, nu doar din browser. A o acorda unei unelte de automatizare necunoscute pentru a supraveghea o singură stare a browserului este un schimb prost, iar accesul persistă după terminarea experimentului. Atingerile conduse de accesibilitate sunt mai rele: sunt un strat de script peste interfață, nu o interfață de control VPN acceptată, și se strică la orice schimbare de aspect.

Înainte de a acorda ceva, întreabă dacă același rezultat este accesibil cu un mecanism acceptat. Dacă răspunsul este o cerință de politică, de obicei este: platforma poate impune un tunel pentru o aplicație sau un profil fără niciun serviciu care ascultă.

A patra verificare: folosește mereu pornit și blocare când cerința este aplicarea

Dacă browserul nu trebuie să comunice niciodată în afara tunelului, aplicarea aparține setărilor platformei, nu unei macrocomenzi. Android acceptă un VPN mereu pornit cu un mod de blocare care împiedică traficul când tunelul nu este stabilit, iar dispozitivele administrate îl pot primi prin politică. Confirmă ce are dispozitivul acum în loc să presupui:

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

O valoare de aplicație care nu este nulă înseamnă că un pachet este configurat ca mereu pornit, iar o valoare de blocare de 1 înseamnă că conexiunile din afara tunelului sunt blocate. Această pereche este cea care transformă un obicei de efort maxim într-o garanție și elimină complet cursa, deoarece tunelul este stabilit înainte ca traficul aplicației să fie permis.

Două limite merită menționate aici. Profilurile de lucru au propria configurație VPN, așa că o regulă verificată în profilul personal nu spune nimic despre cel de lucru. Și un browser instalat separat, o filă personalizată deschisă de altă aplicație sau un webview din interiorul unei aplicații este un pachet sau context diferit cu propria rutare, așa că verifică pachetul real în loc să presupui că o fereastră cu alt stil este un domeniu separat.

A cincea verificare: scrie fluxul de lucru și testează calea de eșec

Orice ai alege, documentează ordinea și condiția de abandon. Pentru fluxul de confort asta înseamnă: tunel pornit, pregătire dovedită, incognito deschis și oprire dură dacă pregătirea eșuează. Pentru calea de aplicare înseamnă: aplicație mereu pornită configurată, blocare activată și comportamentul așteptat când tunelul nu poate porni deloc, adică niciun trafic în loc de trafic neprotejat.

Apoi testează eșecul, nu doar succesul. Deconectează tunelul în timpul unei sesiuni și observă ce face browserul; blochează procesul aplicației VPN și confirmă că nimic nu se scurge. În final, ține cele două modele de confidențialitate separate în documentația utilizatorului: incognito controlează starea temporară a browserului și nu ascunde traficul față de rețea, în timp ce un VPN transportă trafic, dar nu șterge autentificările sau nimic trimis în sesiunea privată.

Articole similare