Yksilöllisten tunnisteiden parhaat käytännöt

Tässä asiakirjassa annetaan ohjeita sopivien tunnisteiden valitsemiseksi sovelluksellesi käyttötapauksen mukaan.

Yleistä Androidin käyttöoikeuksista on kohdassa Käyttöoikeuksien yleiskatsaus. Erityisiä parhaita käytäntöjä Androidin käyttöoikeuksien kanssa työskentelyyn on kohdassa Sovelluksen käyttöoikeuksien parhaat käytännöt.

Parhaat käytännöt Android-tunnisteiden kanssa työskentelyyn

Työskennellessäsi Android-tunnisteiden kanssa noudata seuraavia parhaita käytäntöjä:

1. Välttele laitteistotunnisteiden käyttöä. Useimmissa käyttötapauksissa voit välttää laitteistotunnisteiden, kuten SSAID:n (Android ID), käyttämistä rajoittamatta vaadittua toiminnallisuutta.

   Android 10 (API-taso 29) lisää rajoituksia ei-pysäytettäville tunnisteille,joihin kuuluvat sekä IMEI- että sarjanumero. Sovelluksesi on oltava laitteen tai profiilin omistajasovellus, sillä on oltava operaattorin erityisoikeudet tai sillä on oltava READ_PRIVILEGED_PHONE_STATE-oikeudet, jotta voit käyttää näitä tunnisteita.

2. Käytä mainostunnusta vain käyttäjäprofiilien tai mainosten käyttötapauksissa. Kun käytät mainostunnusta,noudata aina käyttäjien valintoja koskien mainostenseurantaa. Varmista myös, ettei tunnusta voida yhdistää henkilökohtaisesti tunnistettaviin tietoihin (PII), ja vältä mainostunnuksen nollausten silloittamista.

3. Käytä Firebase-asennustunnusta (FID) tai yksityisesti tallennettua GUID-tunnusta aina, kun se on mahdollista kaikissa muissa käyttötapauksissa paitsi maksupetosten estämisessä ja puhelinpalvelussa. Suurimmassa osassa muita kuin mainoskäyttötapauksia FID:n tai GUID:n pitäisi riittää.

4. Käytä käyttötapaukseesi sopivia API:ita yksityisyysriskin minimoimiseksi. Käytä DRM API:ta arvokkaan sisällön suojaamiseen ja SafetyNet API:ta väärinkäytön suojaamiseen. SafetyNet API:t ovat helpoin tapa määrittää, onko laite aito ilman yksityisyysriskiä.

Tämän oppaan muissa osissa käsitellään näitä sääntöjä tarkemmin Android-sovellusten kehittämisen yhteydessä.

Työskentele mainostunnisteiden kanssa

Mainostunnus on käyttäjän palautettavissa oleva tunniste, ja se soveltuu mainoskäyttötapauksiin. On kuitenkin joitain keskeisiä seikkoja, jotka on pidettävä mielessä, kun käytät tätäID:

Kunnioita aina käyttäjän aikomusta nollata mainostunniste.Älä silloita käyttäjän nollauksia käyttämällä toista tunnistetta tai sormenjälkeä linkittääseuraavat mainostunnisteet yhteen ilman käyttäjän suostumusta. Google Play Developer ContentPolicy toteaa seuraavaa:

”…jos uusi mainostunniste nollataan, uutta mainostunnistetta ei saa yhdistää aiempaan mainostunnisteeseen tai aiemmasta mainostunnisteesta johdettuihin tietoihin ilman käyttäjän nimenomaista suostumusta.”

Kunnioita aina siihen liittyvää Henkilökohtaisten mainosten lippua. Mainostunnukset ovatmääritettävissä siten, että käyttäjät voivat rajoittaa tunnukseen liittyvän seurannan määrää. Käytä aina AdvertisingIdClient.Info.isLimitAdTrackingEnabled()menetelmää varmistaaksesi, ettet kierrä käyttäjien toiveita. GooglePlay Developer ContentPolicy toteaa seuraavaa:

”…sinun on noudatettava käyttäjän ’Kieltäydy kiinnostuksen perusteella tapahtuvasta mainonnasta’ tai’Kieltäydy mainosten personoinnista’ -asetusta”. Jos käyttäjä on ottanut tämän asetuksen käyttöön,et saa käyttää mainostunnusta käyttäjäprofiilien luomiseen mainostarkoituksiin tai käyttäjien kohdentamiseen personoidulla mainonnalla.Sallittuja toimintoja ovat muun muassa kontekstisidonnainen mainonta, frekvenssin rajaaminen, konversioseuranta, raportointi sekä tietoturva- ja petostentunnistus.”

Ota huoli käyttämiesi SDK:iden tietosuojakäytännöistä tai tietoturvakäytännöistä, jotka liittyvät mainostunnuksen käyttöön.Jos esimerkiksi annat true:n Google Analytics SDK:n enableAdvertisingIdCollection()-menetelmään, varmista, että olet tutustunut kaikkiin sovellettaviin Analytics SDK:n käytäntöihin ja noudatat niitä.

Ole myös tietoinen siitä, että Google Play Developer ContentPolicy edellyttää, että mainostunnusta ”ei saa yhdistää henkilökohtaisesti tunnistettaviin tietoihin tai liittää mihinkään pysyvään laitetunnisteeseen (esimerkiksi SSAID, MAC-osoite, IMEI jne.),).”

Esimerkkinä oletetaan, että haluat kerätä tietoja, joilla täytetään tietokantataulukot, joissa on seuraavat sarakkeet:

Tässä esimerkissä, ad_id-sarake voitaisiin yhdistää PII-tietoihin account_idsarakkeen kautta molemmissa taulukoissa, mikä rikkoisi Google Playn DeveloperContent Policy -käytäntöä, jos et saa käyttäjiltäsi nimenomaista lupaa.

Muista, että mainostajan tunnuksen ja PII:n väliset yhteydet eivät aina ole yksiselitteisiä. On mahdollista, että ”kvasitunnisteet” esiintyvät sekä PII- että mainostajan tunnisteen avaimilla varustetuissa taulukoissa, mikä aiheuttaa myös ongelmia. Oletetaan esimerkiksi, että muutetaanTAULUKKO-01 ja TAULUKKO-02 seuraavasti:

Tässä tapauksessa, riittävän harvinaisilla klikkaustapahtumilla on edelleen mahdollista yhdistää mainostajan tunnus TABLE-01 ja TABLE-02:n sisältämä PII käyttämällä tapahtuman aikaleimaa ja laitemallia.

Vaikka usein on vaikea taata, ettei tietokokonaisuudessa ole tällaisia kvasitunnisteita, voit estää ilmeisimmät liitosriskit yleistämällä ainutkertaiset tiedot mahdollisuuksien mukaan. Edellisessä esimerkissä tämä tarkoittaisi aikaleiman tarkkuuden vähentämistä siten, että useita saman mallin laitteita esiintyy jokaisessa aikaleimassa.

Muut ratkaisut ovat seuraavat:

• Ei suunnitella taulukoita, jotka nimenomaisesti yhdistävät PII:n ja mainostunnukset. Yllä olevassa ensimmäisessä esimerkissä tämä tarkoittaisi sitä, että account_id-saraketta ei sisällytetä TABLE-01:een.

• Segregoimalla ja valvomalla pääsynvalvontaluetteloita käyttäjille tai rooleille, joilla on pääsy sekä mainostunnuksen avaintietoihin että PII:iin.Valvomalla ja auditoimalla tiukasti kykyä päästä käsiksi molempiin lähteisiin samanaikaisesti (esimerkiksi tekemällä taulukoiden välisiä yhdistämisiä (join)) vähennät mainostunnuksen ja PII:n välisen assosiaation riskiä. Yleisesti ottaen pääsyn valvominen tarkoittaa seuraavaa:

  1. Pitäkää mainostajan tunnuksen avaintiedon ja PII:n pääsynvalvontaluettelot (ACL:t) yhdistettyinä, jotta minimoidaan niiden henkilöiden tai roolien määrä, jotka ovat molemmissaACL:issä.
  2. Valmistakaa pääsyn kirjaaminen ja auditointi, jotta voitte havaita ja hallita kaikkia poikkeuksia tästä säännöstä.

Lisätietoja vastuullisesta työskentelystä mainostunnusten kanssa onAdvertisingIdClient API-viitteessä.

Työskentely FID:ien ja GUID:ien kanssa

Yksinkertaisin ratkaisu laitteessa toimivan sovelluksen yksilöimiseen on Firebase-asennustunnuksen (FID) käyttäminen, ja tätä suositellaankin suurimmassa osassa muita kuin mainoksia sisältävistä käyttökäytön tapauksista. Ainoastaan sovelluksen instanssi, jota varten se on varattu, voi käyttää tätä tunnusta, ja se on (suhteellisen) helposti palautettavissa, koska se säilyy vain niin kauan kuin sovellus on asennettu.

Tuloksena FID-tunnukset tarjoavat paremmat yksityisyysominaisuudet verrattuna ei-palautettaviin, laitekohtaisiin laitteistotunnuksiin. Lisätietoja on firebase.installationsAPI-referenssissä.

Tapauksissa, joissa FID ei ole käytännöllinen, voit myös käyttää mukautettuja globaalisti uniikkeja tunnuksia (GUID) sovelluksen yksilöimiseen. Yksinkertaisintapa tähän on luoda oma GUID-tunnuksesi seuraavan koodin avulla:

var uniqueID = UUID.randomUUID().toString()

String uniqueID = UUID.randomUUID().toString();

Koska tunniste on globaalisti yksilöivä, sitä voidaan käyttää tietynapp-instanssin tunnistamiseen. Välttääksesi ongelmat, jotka liittyvät tunnisteen linkittämiseen eri sovellusten välillä,tallenna GUID-tunnisteet sisäiseen tallennustilaan ulkoisen (jaetun) tallennustilan sijasta. Lisätietoja on Tietojen ja tiedostojen tallennusYleiskatsaussivulla.

Ei saa käyttää MAC-osoitteita

MAC-osoitteet ovat globaalisti yksilöllisiä, eivät ole käyttäjän palautettavissa ja kestävät tehdasasetusten palautuksen. Näistä syistä käyttäjän yksityisyyden suojaamiseksi Android-versiossa 6 ja uudemmissa versioissa pääsy MAC-osoitteisiin on rajoitettu järjestelmäsovelluksiin. Kolmannen osapuolen sovellukset eivät pääse niihin käsiksi.

MAC-osoitteiden saatavuus muuttuu Android 11:ssä

Android 11:n ja uudempien versioiden sovelluksissa MAC-osoitteiden satunnaistaminen Passpoint-verkoissa on Passpoint-profiilikohtaista, ja se luo ainutlaatuisen MAC-osoitteen seuraavien kenttien perusteella:

• Fully-qualified domain name (FQDN)
• Realm
• Credential, joka perustuu Passpoint-profiilissa käytettyyn credentialiin:
  • User credential: Käyttäjän nimi
  • Certificate credential: cert ja cert type
  • SIM credential: EAP type and IMSI

Lisäksi ei-oikeutetut sovellukset eivät pääse käsiksi laitteen MAC-osoitteeseen; vainverkkoliitännät, joilla on IP-osoite, näkyvät. Tämä vaikuttaagetifaddrs()jaNetworkInterface.getHardwareAddress()metodeihin sekä RTM_GETLINK Netlink-viestien lähettämiseen.

Seuraavassa on luettelo tavoista, joilla tämä muutos vaikuttaa sovelluksiin:

• NetworkInterface.getHardwareAddress() palauttaa nollan jokaiselle rajapinnalle.
• Asovellukset eivät voi käyttää bind()-toimintoa NETLINK_ROUTE-socketilla.
• Komento ip ei palauta tietoa rajapinnoista.
• Sovellukset eivät voi lähettää RTM_GETLINK-viestejä.

Huomaa, että useimpien kehittäjien tulisi käyttää mieluummin ConnectivityManager:n korkeamman tason API:ita kuin alemman tason API:ita, kuten NetworkInterface,getifaddrs(),tai Netlink-socketeita. Esimerkiksi sovellus, joka tarvitsee ajantasaista tietoa nykyisistä reiteistä, voi saada nämä tiedot kuuntelemalla verkon muutoksia käyttämällä ConnectivityManager.registerNetworkCallback()ja kutsumalla verkon siihen liittyvääLinkProperties.getRoutes().

Tunnuksen ominaisuudet

Android-käyttöjärjestelmä tarjoaa useita tunnuksia, joilla on erilaiset käyttäytymisominaisuudet.Se, mitä tunnusta sinun kannattaa käyttää, riippuu siitä, miten seuraavat ominaisuudet toimivat käyttötapauksesi kanssa. Näihin ominaisuuksiin liittyy kuitenkin myös yksityisyysvaikutuksia, joten on tärkeää ymmärtää, miten nämä ominaisuudet ovat vuorovaikutuksessa toistensa kanssa.

Tunnuksen laajuus

Tunnuksen laajuus selittää, mitkä järjestelmät voivat käyttää tunnusta. Android-tunnisteen laajuutta on yleensä kolmea eri makua:

• Yksittäinen sovellus:
• Sovellusryhmä: Tunnus on sovelluksen sisäinen, eivätkä muut sovellukset pääse siihen käsiksi.
• Laite: Tunnus on kaikkien laitteeseen asennettujen sovellusten käytettävissä.

Mitä laajempi tunnisteelle annettu soveltamisala on, sitä suurempi on riski, että sitä käytetään jäljitystarkoituksiin. Kääntäen, jos tunnisteeseen pääsee käsiksi vain yksi sovellusinstanssi, sitä ei voida käyttää laitteen jäljittämiseen eri sovellusten tapahtumissa.

Tunnisteen palautettavuus ja pysyvyys

Tunnisteen palautettavuus ja pysyvyys määrittelevät tunnisteen käyttöiän ja selittävät, miten se voidaan nollata. Yleisiä nollauslaukaisimia ovat: sovelluksen sisäiset nollaukset, nollaukset järjestelmäasetusten kautta, nollaukset käynnistyksen yhteydessä ja nollaukset asennuksen yhteydessä. Android-tunnisteilla voi olla vaihteleva elinikä, mutta elinikä liittyy yleensä siihen, miten tunniste nollataan:

• Session-only: Uutta tunnusta käytetään aina, kun käyttäjä käynnistää sovelluksen uudelleen.
• Asennuksen palautus:
• FDR-reset: Uutta ID:tä käytetään joka kerta, kun käyttäjä nollaa laitteen tehtaalla.
• FDR-persistent: Tunnus säilyy tehdasasetusten palautuksen jälkeenkin.

Resetattavuus antaa käyttäjille mahdollisuuden luoda uuden tunnuksen, joka on irrallaan kaikista olemassa olevista profiilitiedoista. Mitä pidempään ja luotettavammin tunniste säilyy, esimerkiksi tehdasasetusten palautuksen jälkeen, sitä suurempi on riski, että käyttäjä joutuu pitkäaikaisen seurannan kohteeksi. Jos tunniste nollataan sovelluksen uudelleenasennuksen yhteydessä, tämä vähentää pysyvyyttä ja tarjoaa keinon, jolla tunniste voidaan nollata, vaikka käyttäjän ei olisi mahdollista nollata sitä nimenomaisesti sovelluksesta tai järjestelmäasetuksista.

Yksilukuisuus

Yksilukuisuus määrittää törmäyksien todennäköisyyden eli sen, että identtisiä tunnisteita on olemassa siihen liittyvässä laajuudessa. Korkeimmalla tasolla globaalisti ainutkertaisella tunnisteella ei koskaan ole törmäyksiä, ei edes muissa laitteissa tai sovelluksissa.Muussa tapauksessa ainutkertaisuuden taso riippuu tunnisteen entropiasta ja sen luomiseen käytetystä satunnaislähteestä. Esimerkiksi törmäyksen mahdollisuus on paljon suurempi satunnaistunnisteille, jotka on kylvetty asennuksen kalenteripäivämäärällä (kuten 2019-03-01), kuin tunnisteille, jotka on kylvetty asennuksen Unixtimestamp-tileimalla (kuten 1551414181).

Käyttäjätilien tunnisteiden voidaan yleisesti ottaen katsoa olevan ainutlaatuisia. Toisin sanoen jokaisellalaite/tili -yhdistelmällä on yksilöllinen tunnus. Toisaalta, mitä vähemmän yksilöllinen tunniste on populaation sisällä, sitä suurempi on yksityisyyden suoja, koska siitä on vähemmän hyötyä yksittäisen käyttäjän jäljittämisessä.

Yhteensopivuuden suojaus ja kiistämättömyys

Voit käyttää tunnusta, jota on vaikea väärentää tai toistaa, todistaaksesi, että siihen liitetyllä laitteella tai tilillä on tiettyjä ominaisuuksia. Voit esimerkiksi todistaa, että laite ei ole roskapostittajan käyttämä virtuaalilaite.Vaikeasti väärennettävät tunnisteet tarjoavat myös kiistämättömyyden. Jos laite allekirjoittaa viestin salaisella avaimella, on vaikea väittää, että viesti on jonkun toisen laitteen lähettämä. Kiistämättömyys voi olla käyttäjän haluama ominaisuus, esimerkiksi maksun todentamisessa, tai se voi olla ei-toivottu ominaisuus, esimerkiksi silloin, kun hän lähettää viestin, jota hän katuu.

Yleiset käyttötapaukset ja sopiva tunniste

Tässä osiossa esitellään vaihtoehtoja laitteistotunnisteiden, kuten IMEI-tunnisteen, käytölle. Laitetunnisteiden käyttöä ei suositella, koska käyttäjä ei voi nollata niitä, ja ne on sidottu laitteeseen. Monissa tapauksissa riittää sovelluskohtainen tunniste.

Track signed-out user preferences

Tässä tapauksessa tallennat laitekohtaisen tilan palvelinpuolelle ilman käyttäjätiliä.

Use: FID tai GUID

Miksi tämä suositus?

Tietojen säilyttämistä uudelleenasennusten kautta ei suositella, koska käyttäjät saattavat haluta nollata asetuksiaan asentamalla sovelluksen uudelleen.

Seuraa kuitattuja käyttäjäasetuksia sovellusten välillä, joilla on sama allekirjoitusavain

Seuraa kuitattuja käyttäjäasetuksia saman allekirjoitusavaimen omaavien sovellusten välillä

Seuraa kuitattuja käyttäjäasetuksia sovellusten välillä saman allekirjoittajaavaimen omaavien sovellusten välillä

Suorita kuitattuja käyttäjäasetuksia saman allekirjoitusavaimen omaavien sovellusten välillä.

Käyttö: SSAID

Miksi tämä suositus?

Android 8.0:ssa (API-taso 26) ja uudemmissa versioissa SSAID tarjoaa tunnisteen, joka on yhteinen saman kehittäjän allekirjoitusavaimella allekirjoitettujen sovellusten välillä. Sen avulla voit jakaa tilaa näiden sovellusten välillä ilman, että käyttäjän on kirjauduttava tilille.

Track-out user behavior

Tässä tapauksessa olet luonut käyttäjän profiilin, joka perustuu hänen käyttäytymiseensä eri sovelluksissa/istunnoissa samalla laitteella.

Use:

Miksi tämä suositus?

Mainostunnuksen käyttö on pakollista mainonnan käyttötapauksissa GooglePlay Developer ContentPolicy:n mukaan, koska käyttäjä voi nollata sen.

Luoda kuitattuja tai anonyymejä käyttäjäanalyysejä

Tässä tapauksessa mittaat käyttötilastoja ja -analyysejä kuitattuja tai anonyymejä käyttäjiä varten.

Käyttökohde: FID tai GUID, jos FID ei riitä

Miksi tämä suositus?

FID tai GUID on rajattu sovellukseen, joka luo sen, mikä estää tunnisteen käytön käyttäjien seuraamiseen eri sovelluksissa. Se on myös helposti palautettavissa, koska käyttäjä voi tyhjentää sovelluksen tiedot tai asentaa sovelluksen uudelleen. FID:ien ja GUID:ien luomisprosessi on suoraviivainen:

• FID:n hakeminen: Katso Firebasen asennusopas.

• GUID:n luominen: Toteuta sovelluksessasi logiikka seuraavan koodinpätkän mukaisesti:

  Kotlin

  val uniqueID: String = UUID.randomUUID().toString()

  Java

  String uniqueID = UUID.randomUUID().toString();

Ole tietoinen siitä, että jos olet kertonut käyttäjälle, että keräämäsi tiedot ovatanonyymejä, sinun on varmistettava, ettet yhdistä tunnustaPII:hen tai muihin tunnisteisiin, jotka voidaan yhdistää PII:hen.

Voit käyttää myös Google Analytics for MobileApps -palvelua, joka tarjoaa ratkaisun sovelluskohtaiseen analytiikkaan.

Track signed-out user conversions

Tässä tapauksessa seuraat konversioita havaitaksesi, onko markkinointistrategiasi onnistunut.

Käyttö:

Miksi tämä suositus?

Tämä on mainoksiin liittyvä käyttötapaus, joka saattaa vaatia tunnuksen, joka on käytettävissä eri sovelluksissa, joten mainostunnuksen käyttäminen on tarkoituksenmukaisin ratkaisu.

Käsittele useita asennuksia eri laitteissa

Käsittele useita asennuksia eri laitteissa

Tässä tapauksessa sinun on tunnistettava sovelluksen oikea instanssi, kun se on asennettu useaan laitteeseen samalle käyttäjälle.

Käyttökohde: FID tai GUID

Miksi tämä suositus?

FID on suunniteltu nimenomaan tätä tarkoitusta varten; sen soveltamisala on rajattu sovellukseen, joten sitä ei voida käyttää käyttäjien jäljittämiseen eri sovelluksissa, ja se nollataan sovelluksen uudelleenasennuksen yhteydessä. Niissä harvoissa tapauksissa, joissa FID ei riitä, voit käyttää myös GUID-tunnusta.

Toimintojen yhdistäminen mobiilipalvelutilauksiin

Tässä tapauksessa sovelluksen toiminnot on yhdistettävä tiettyihin laitteen mobiilipalvelutilauksiin. Sinulla voi esimerkiksi olla vaatimus määrittää pääsy tiettyihin sovelluksen premium-ominaisuuksiin laitteen SIM-kortin kautta tehtyjen mobiilipalvelutilausten perusteella.

Käytä: Subscription IDAPI tunnistaa laitteessa käytetyt SIM-kortit.

Subscription ID tarjoaa indeksiarvon (alkaen 1) laitteessa käytettyjen asennettujen SIM-korttien (mukaan lukien fyysiset ja elektroniset kortit) yksilöllistä tunnistamista varten. Tämän ID:n avulla sovelluksesi voi yhdistää toimintonsa tietyn SIM-kortin erilaisiin tilaustietoihin. Tämä arvo pysyy vakaana tietylle SIM-kortille, ellei laitetta palauteta tehdasasetuksiin. Voi kuitenkin olla tapauksia, joissa samalla SIM-kortilla on eri tilaustunnus eri laitteissa tai eri SIM-kortilla on sama tunnus eri laitteissa.Jos tilaustunnus ei ole riittävän yksilöllinen, suositellaan tilaustunnuksen ketjuttamista SSAID:n kanssa.

Miksi tämä suositus?

Jotkut sovellukset saattavat tällä hetkellä käyttää ICCID:tä tähän tarkoitukseen. Koska ICC-tunnus on globaalisti yksilöllinen ja sitä ei voi palauttaa, pääsy on rajoitettu sovelluksiin, joilla on READ_PRIVILEGED_PHONE_STATElupa, Android 10:stä lähtien. Android 11:stä alkaen Google rajoitti ICCID:n käyttöä edelleen getIccId()API:n kautta sovelluksen kohde-API-tasosta riippumatta. Asianomaisten sovellusten tulisi siirtyä käyttämään sen sijaan Subscription ID:tä.

Anti-fraud: Ilmaisen sisällön rajoitusten toimeenpano ja Sybil-hyökkäysten havaitseminen

Tässä tapauksessa halutaan rajoittaa ilmaisen sisällön, kuten artikkelien, määrää, jonka käyttäjä voi nähdä laitteella.

Käyttö: FID tai GUID. Android 8.0:ssa (API-taso 26) ja uudemmissa versioissa SSAID on myös vaihtoehto, koska se on rajattu sovelluksen allekirjoitusavaimeen.

Miksi tämä suositus?

GUID:n tai FID:n käyttäminen pakottaa käyttäjän asentamaan sovelluksen uudelleen sisällönrajoitusten kiertämiseksi, mikä on riittävä taakka estämään useimpia ihmisiä. Jos tämä ei ole riittävä suojaus, Android tarjoaa DRMAPI:n, jolla voidaan rajoittaa pääsyä sisältöön, sisältää APK-kohtaisen tunnisteen, Widevine ID:n.

Palveluntarjoajan toiminnallisuus

Tässä tapauksessa sovelluksesi on vuorovaikutuksessa laitteen puhelin- ja tekstiviestintoiminnallisuuden kanssa käyttäen palveluntarjoajan tiliä.

Käyttö: IMEI, IMSI ja Line1

Miksi tämä suositus?

Laitteistotunnisteiden käyttäminen on hyväksyttävää, jos se on tarpeen operaattoriin liittyvässä toiminnallisuudessa. Voit esimerkiksi käyttää näitä tunnisteita vaihtaaksesi matkapuhelinoperaattoreiden tai SIM-paikkojen välillä tai toimittaaksesi tekstiviestejä IP:n kautta (Line1:n osalta) – SIM-pohjaiset käyttäjätilit. Käyttäjälaitteiden tietojen hakemiseen palvelinpuolen puolelta suositellaan kuitenkin käyttämään tilikirjautumista, jos sovellukset eivät ole oikeutettuja. Yksi syy tähän on se, että Android 6.0:ssa (API-taso 23) ja sitä uudemmissa versioissa näitä tunnisteita voidaan käyttää vain ajonaikaisen käyttöoikeuden kautta. Käyttäjät saattavat kytkeä tämän luvan pois päältä, joten sovelluksesi tulisi käsitellä nämä poikkeukset hienovaraisesti.

Väärinkäytösten havaitseminen: Tässä tapauksessa yrität havaita useita väärennettyjä laitteita, jotka hyökkäävät backend-palvelujesi kimppuun.

Käyttö: SafetyNet API

Miksi tämä suositus?

Tunniste yksinään ei juurikaan kerro, että laite on aito. Voit varmistaa, että pyyntö tulee aidolta Android-laitteelta – toisin kuin emulaattorilta tai muulta toista laitetta väärentävältä koodilta – käyttämällä SafetyNet API:nattest()menetelmää pyynnön esittävän laitteen eheyden tarkistamiseksi. Lisätietoja on SafetyNet API:n dokumentaatiossa.

Petosten ja väärinkäytösten havaitseminen: Varastettujen, arvokkaiden tunnistetietojen havaitseminen

Tässä tapauksessa yritetään havaita, käytetäänkö yhtä laitetta useaan kertaan arvokkailla, varastetuilla tunnistetiedoilla, esimerkiksi vilpillisten maksujen suorittamiseen.

Käyttö: Petostentorjunta vaatii luonteensa vuoksi suojattuja signaaleja, jotka voivat muuttua ajan mittaan ja ovat siksi tämän asiakirjan soveltamisalan ulkopuolella. Huomaa kuitenkin, että laitteistotunnisteet, kuten IMEI ja IMSI, voidaan helposti muuttaa juurtuneissa tai emuloitavissa laitteissa, joten ne eivät ole luotettavia indikaattoreita petoksista.