VPN-a aplikaĵo petas kontaktojn kaj alireblecon: kion permesi

La instalilo petas unue retan aliron, poste kontaktojn, alireblecon kaj instaladon de atestilo. Nur la unua peto apartenas al la tasko. La vera decido kuŝas sur la dua ekrano.

Juĝu ĉiun peton laŭ funkcio, kiun vi elektis, sur la platformo, kiun vi uzas. Neniu universala permeslisto kovras ĉiun VPN-produkton, kaj longa listo mem pruvas nenion.

La sola permeso, kiun la tasko vere bezonas

Android petas la uzanton aprobi VPN-servon per sistema dialogo antaŭ ol komenciĝas iu ajn tunelo, kaj la servo de la aplikaĵo deklaras BIND_VPN_SERVICE, por ke la sistemo povu ligiĝi al ĝi. Operacie la aplikaĵo faras la enkursigan laboron. Konsento venas de la persono, kiu tenas la aparaton, en dialogo nomanta la aplikaĵon, kaj malfari ĝin poste estas subtenata ago.

La platformoj de Apple esprimas la saman ideon per reta etendaĵo kaj instalaprobo anstataŭ permesa ekrano. Windows uzas pelilon de virtuala adaptilo kaj privilegian demandon. Du formoj, unu signifo: ĉi tiu programo rajtas trakti pakaĵojn. Nenio en tiu rajtigo kovras legadon de via adresaro aŭ eldonon de propra atestila aŭtoritato.

Plia aliro estas aparta permeso kun apartaj efikoj. Enkursiga kliento, kiu volas ĝin, bezonas propran kialon.

Kie la pliaj petoj bezonas propran rakonton

Alirebleca servo povas legi ekranan enhavon kaj agi anstataŭ vi, kio estas multe preter enkursigo. Aparata administrado povas trudi ŝlosilajn politikojn kaj forigi datumojn. Radika atestilo instalita de la uzanto lasas iun ajn kun la kongrua ŝlosilo legi trafikon, kiun TLS alie protektus.

Iu ajn el tiuj povas esti laŭleĝa. Produktoj por administrataj aparatoj kaj gepatra kontrolo eble bezonas politikajn povojn, kaj subtena ilo eble bezonas alireblecon por gvidi vin tra la agordoj.

La postulo estas spurebleco: la peto montras al nomita funkcio, kaj tiu funkcio videblas en la produkto, kiun vi instalas. Kontakta peto sen kontakta ekrano havas nenion por klarigi. Ankaŭ la argumento pri ĉifrado ne aplikeblas, ĉar protektado de pakaĵoj diras nenion pri tio, kiuj estas viaj amikoj. Laŭleĝa produkto tamen povas peti tro multe per enpakita biblioteko, kaj tio estas difekto raportenda, ne krimo denuncenda.

Notu la peton kaj la funkcion, al kiu ĝi rilatas, poste decidu. Tiu noto ankaŭ estas tio, kion vi montras al subteno, kiam funkcio rompiĝas post rifuzo.

Legi la peton en la aparato

La butika listo priskribas intencon, dum la instalita pako priskribas realon. Demandin al la paka administranto, kio estis deklarita kaj kio donita, antaŭ ol vi aprobos ion alian. La paro plej gravas, kiam listo kaj manifesto malkongruas.

Du demandoj kovras la plejparton:

adb shell dumpsys package com.example.vpn | grep -E "requested permissions|install permissions" -A 30
adb shell cmd appops get com.example.vpn

La unua listigas deklaritajn kontraŭ donitajn permesojn, kaj ĝuste tiu komparo malkaŝas tro larĝan manifeston. La dua montras funkciojn de la aplikaĵo dum ruliĝo, inkluzive specialajn alirojn, kiuj neniam aperas kiel ordinaraj permesoj. Kie programistaj iloj mankas, legu la samajn faktojn el la agordaj ekranoj de la platformo.

Tiuj ekranoj daŭras minuton kaj bezonas nenian programaron. Alirebleco, aparata administrado kaj atestila konservejo ĉiu listigas la aplikaĵojn kun la permeso.

Decidi, poste limigi la damaĝon

Donu la retan rajtigon al kliento, kiun vi elektis, kaj traktu ĉiun plian peton kiel propran decidon. Rifuzu la petojn sen kongrua funkcio, poste vidu, kio rompiĝas. Enkursiga kliento, kiu malsukcesas kiam kontakta aliro rifuziĝas, neniam petis kontaktojn anstataŭ vi.

Malfaro de unu permeso kutime malŝaltas unu solan funkcion sen malinstali la aplikaĵon aŭ disŝiri ĉiun profilon. Rekonektu poste kaj konfirmu, ke la tunelo ankoraŭ konstruiĝas.

Apartigu la du demandojn, kiujn peto emas kunfandi: kion ĉi tiu programo rajtas fari en la aparato, kaj kion ĝia funkciiganto faras kun la trafiko post kiam la tunelo staras. La unua respondiĝas ĉi tie. La dua bezonas konservan politikon, kaj neniu dialogo havigas ĝin.