TL;DR
- Fra næste år vil Android blokere installationen af apps fra ubekræftede udviklere, en politik, der påvirker både Play Butik og sideloadede apps.
- Det nye system kræver, at Android tjekker, om en udvikler er verificeret, hvilket i nogle tilfælde vil kræve en aktiv internetforbindelse under installationen.
- Hobbyist-udviklere kan få en gratis konto, men vil stå over for strenge distributionsbegrænsninger, hvilket kræver, at de manuelt autoriserer hver enhed, der installerer deres app.
Tilbage i august udsendte Google en meddelelse, der chokerede Android-entusiaster og privatlivsforkæmpere: Fra næste år vil Android blokere installationen af apps fra ubekræftede udviklere. Dette gælder ikke kun apps i Play Butik, men også apps distribueret uden for den, hvilket vækker bekymring for, at Google ønsker at dræbe sideloading. Efter et par ugers tavshed tog Google endelig fat på disse bekymringer og insisterede på, at sideloading er kommet for at blive. Virksomheden delte også nye detaljer om, hvordan dets udviklerbekræftelseskrav vil blive håndhævet, herunder at Android i nogle tilfælde vil kræve en aktiv netværksforbindelse for at sideloade apps.
Sidste måned så vi beviser i Android SDK, der tyder på, at udviklerbekræftelse kunne mislykkes, når en netværksforbindelse ikke er tilgængelig. Vi kunne ikke bekræfte denne adfærd på det tidspunkt, da Androids udviklerbekræftelseskrav endnu ikke var trådt i kraft. I denne uge bekræftede Google dog, at dette vil være tilfældet. Udover sit blogindlæg, der erklærer, at "sideloading er grundlæggende for Android", offentliggjorde Google også en video, der forklarer begrundelsen bag verifikationskravene, og hvordan det vil blive implementeret næste år. Jeg granskede videoen for at lære så meget som muligt om disse kommende ændringer, så du ikke behøver det.
Se også:Mærker køles muligvis af satellitfunktioner, og det er dårlige nyheder for billigere Androids
Vil du ikke gå glip af det bedste fra Android Authority?
Hvordan Android vil bekræfte apps
Når du forsøger at installere en Android-app, udfører operativsystemet allerede en række kontroller, før installationen kan gå igennem. Disse kontroller sikrer, at en app med det samme applikations-id (dvs. pakkenavn) ikke allerede er installeret, at den ikke er bygget til en ekstremt gammel version af operativsystemet, og vigtigst af alt, at den ikke er blevet markeret som malware af Google Play Protect.
Google tager nu et ekstra skridt til denne proces. Virksomheden har indbygget en krog i installationsflowet, hvilket kræver, at enhver app, der installeres for første gang, skal gennemgå verifikation. På installationstidspunktet vil Android kommunikere med en "betroet enhed" på enheden kaldet Android Developer Verifier. Denne nye, forudindlæste systemtjeneste bestemmer, om appens udvikler er blevet bekræftet, om der er opstået problemer under verificeringen, og endelig hvilken installationspolitik, der skal håndhæves.
Mishaal Rahman / Android Authority
For at afgøre, om en apps udvikler er blevet bekræftet, skal Android Developer Verifier-tjenesten kontrollere, at pakken og nøglen, der blev brugt til at signere den, er blevet sendt til Google. Det er umuligt at opretholde en omfattende database på enheden med sådanne pakke- og tastekombinationer, især da så mange nye Android-apps dukker op hver uge. Dette er grunden til, at Google siger, at din telefon har brug for en netværksforbindelse for at bekræfte apps, dog kun i "worst case scenario." Virksomheden planlægger at få Developer Verifier-tjenesten til at opretholde en cache over de mest populære apps, den allerede har verificeret, så de kan installeres uden en netværksforbindelse.
Desuden siger Google, at det arbejder på en løsning til app-butikker til at omgå yderligere netværksopkald. App-butikker kan videregive det, der kaldes et "pre-auth token" - en "kryptografisk verificerbar klat", der er forbundet med den pakke, de vil installere. Dette gør det muligt for en apps udvikler at blive verificeret uden yderligere netværksopkald til Googles backend.
Den anden kvartalsvise udgivelse af Android 16, dvs. Android 16 QPR2, vil være den første version af Android, der naturligt understøtter disse ændringer. Bekræftelsespolitikkerne vil dog ikke blive håndhævet, når opdateringen rulles ud i december, da Google stadig arbejder på implementeringen og indsamling af metrics. Ændringerne vil blive backporteret til ældre versioner af Android gennem Google Play Protect, selvom Google siger, at der kan være nogle små forskelle, fordi denne metode udnytter en eksisterende app i stedet for den nye, indbyggede verifikationstjeneste, der er indbygget i operativsystemet.
Aamir Siddiqui / Android Authority
Hvordan Androids bekræftelseskrav vil påvirke studerende og hobbyfolk
Da Google først annoncerede sine nye udviklerbekræftelseskrav, nævnte det, at det ville oprette en "separat type Android Developer Console-konto" til hobbyudviklere og studerende, en der ville have "færre verifikationskrav" og en dispensation for registreringsgebyret på $25 USD. Ved første øjekast ser det ud til, at det ville løse behovene hos indie-udviklere, der distribuerer deres apps gratis på steder som GitHub eller F-Droid, men der er en stor fangst.
Udviklere, der registrerer sig hos Google som studerende eller hobbyist, vil stå over for alvorlige restriktioner for appdistribution, nemlig en begrænsning på antallet af enheder, der kan installere deres apps. For at håndhæve dette skal enhver bruger, der ønsker at installere software fra disse udviklere, først hente en unik identifikator fra deres enhed. Udvikleren skal derefter indtaste denne identifikator i Android Developer Console for at godkende den specifikke enhed til installation.
Dette to-vejs håndtryk mellem brugere og udviklere var bevidst designet til at begrænse distributionen. Google siger, at elev-/hobbyistkonti kun er for udviklere, der ønsker at dele en APK med et begrænset sæt kendte personer, ikke for dem, der ønsker at distribuere deres apps bredt. Udviklere, der tilmelder sig som studerende eller hobbyist, men senere beslutter sig for, at de vil have et bredere publikum, vil have mulighed for at konvertere deres konto, så de ikke for evigt vil sidde fast med begrænset distribution.
Disse begrænsninger giver mening i sammenhæng med Googles overordnede mål. At tillade ubegrænset distribution for studerende/hobbyistkonti ville skabe et smuthul for dårlige skuespillere at udnytte, så ved at begrænse deres rækkevidde afskrækker Google ondsindede udviklere fra at misbruge denne kontotype.
Hvordan Google vil forhindre dårlige skuespillere i at unddrage sig bekræftelse
Når vi taler om dårlige skuespillere, siger Google, at det har designet sit system til at fange og forhindre dem i at bestå verifikationen. For det første vil udviklere ikke kun være i stand til at kræve ejerskab over enhver eksisterende pakke. For at bevise ejerskab skal de vise, at de kan signere apps ved hjælp af den samme nøgle som den app, de gør krav på. Dette kræver ikke deling af private nøgler med Google, så virksomheden selv opnår ingen signeringsrettigheder. Google siger, at dets eneste mål er at forhindre dårlige skuespillere i at distribuere skadelige apps, såsom malware. Derfor vil det ikke lægge andre politiske begrænsninger på udviklere, såsom at begrænse de navne og ikoner, de kan bruge til deres apps.
Et skærmbillede af Android Developer Console
Udviklere, der bliver fanget i at distribuere malware, vil have begrænsninger på deres konti. I en uspecificeret periode vil alle apps, der ejes af disse udviklere, blive blokeret fra installation på brugerens enheder. Dette gælder for enhver udvikler, hvis konto er forbundet med malwaredistribution, selvom den pågældende udvikler ikke er malware-forfatteren. Malware-forfattere forsøger ofte at købe eksisterende udviklerkonti ud for at udnytte dem til distribution; Google siger, at udviklere i sidste ende er ansvarlige for alt, der offentliggøres under deres konto, hvilket retfærdiggør enhver handling, der tages imod dem.
En anden teknik, som malware-forfattere bruger til at omgå verifikation, er identitetsbedrageri. Google siger, at det har noget "hemmelig sauce" - teknikker, der gør det muligt at identificere, hvornår udviklere lyver om deres identitet. Virksomheden har teams, der udfører verifikation og er trænet i at identificere falske indsendelser, selv dem, der er genereret ved hjælp af AI-værktøjer. Derudover vil behovet for at få et DUNS-nummer afholde mange dårlige skuespillere fra at ansøge om en organisationskonto.
Hvad med privatliv, F-Droid og virksomhedsbrug?
I sin video adresserede Google adskillige bekymringer, som brugere rejste efter meddelelsen. Hvad angår privatlivets fred, anerkendte Google, at der eksisterer legitime årsager til udviklerens anonymitet, såsom når man distribuerer apps til dissidenter. Det er grunden til, at virksomheden erklærede, at den ikke vil dele udvikleroplysninger offentligt (selvom den især ikke forpligtede sig til at tilbageholde disse oplysninger fra regeringer). Uanset hvad insisterer Google på, at status quo skal ændres og hævder, at udviklerens anonymitet udgør risici for brugerne, som den ikke længere kan overse.
Selvom Google ikke direkte adresserede bekymringer om, at dets politikker vil dræbe uafhængige app-butikker som F-Droid, nævnte det en lille sølvbeklædning. Virksomheden sagde, at det i sjældne scenarier vil tillade duplikering af pakkenavn. For eksempel, hvis en app i Play Butik deler et pakkenavn med en app fra en anden kilde, men har færre installationer, vil Google arbejde sammen med udviklerne om en løsning, som kan kræve, at Play Butik-udvikleren ændrer deres apps pakkenavn.
Desværre er det usandsynligt, at denne udskæring vil hjælpe mange udviklere på F-Droid. Problemet stammer fra, hvordan F-Droid distribuerer apps: dets team kompilerer kildekode leveret af udviklere og signerer derefter appsene selv. Denne praksis skaber ofte to modstridende versioner af en app - en fra F-Droid og en fra den originale udvikler - der begge bruger det samme pakkenavn.
For at forhindre flere udviklere i at kræve ejerskab af den samme pakke, vil Google give fortrinsret til den udvikler, hvis version har størstedelen af kendte installationer. For mange apps på F-Droid betyder det, at dets team reelt ville blive ejeren, selvom de ikke er de originale udviklere. De oprindelige skabere ville derefter blive tvunget til at ændre deres pakkenavn for at distribuere deres app andre steder. Dette resultat er uønsket og overtræder F-Droids kernefilosofi, hvilket forklarer dens stærke modstand mod Googles nye politikker.
Endelig vil Google gøre nogle undtagelser for virksomheder. En app, der er installeret via virksomhedsadministrationsværktøjer på en administreret enhed, kan installeres, selvom dens udvikler ikke er registreret. Denne udelukkelse eksisterer, fordi administrerede enheder har en ansvarlig tredjepart – en it-administrator – med ansvar for sikkerheden. Desværre siger Google, at enheder, der distribuerer apps til offline-enheder, selv skal bestemme, hvordan de skal håndtere bekræftelsesanmodninger, såsom ved at oprette forbindelse til internettet med jævne mellemrum.
Der er stadig mange spørgsmål om Androids nye udviklerbekræftelseskrav, herunder hvilke metoder der vil omgå det. Vi ved allerede, at ADB-installation fungerer, men det er uklart, om det vil udvides til løsninger som Shizuku, som giver mulighed for at udføre ADB-kommandoer ved hjælp af shell-privilegier. Der er stadig lang tid, før Google håndhæver sine nye politikker, så detaljer kan ændre sig, og nye oplysninger kan dukke op. Hvis vi lærer noget nyt, vil vi sørge for at give dig besked - så følg os for at holde dig opdateret!
Tak fordi du er en del af vores fællesskab. Læs vores kommentarpolitik, før du poster.
