Fråga:
Hur kommer vissa Android-appar ihåg att det inte är första gången de installeras?
defalt
2016-09-25 20:07:01 UTC
view on stackexchange narkive permalink

Vissa Android-appar kan komma ihåg om de installerades på samma enhet tidigare. Antag att du avinstallerade en app för ett år sedan. Om du installerar samma app igen efter ett år kan den appen känna igen att den installerades tidigare på samma telefon.

Denna teknik används av onlineapplikationer för att permanent förbjuda användare från att någonsin skapa en nytt konto igen om de har förbjudits att använda tjänsten en gång. När sådana användare skapar ett nytt konto genom att installera om programmet senare kan de här apparna upptäcka sin "första gången närvaro" och skicka denna information till servrar så att användaren kan förbjudas igen.

Hur de gör det även efter att ha rensat deras data och avinstallerat dem helt? Det betyder att de håller någon fil någonstans i telefonen, som inte raderas efter avinstallationen. Hur inaktiverar jag den här upptäckten?

Varför vill du ta bort denna information? Har appskapare rättigheter? Jag förväntar mig inte att det här är en populär kommentar, men överväg om du har tagit dig tid och problem med att skapa en app.
@S.Mitchell Today Vissa apputvecklare och stora reklamföretag försöker komma åt onödiga detaljer från oskyldiga användare. Inte bara de vill ha MAC-adress utan de vill också veta ditt wifi-SSID. Google gav dem en bra lektion genom att implementera vilka behörigheter du inte vill ge dem i Android 6. Men annonsörerna stannar inte här, de hittar alltid en sätt att komma runt. Jag vill säkerställa detta integritetssystem.
@S.Mitchell Hej Mitchell. Du kanske bedömer mig fel på grund av min fråga. Nej, jag är inte utestängd från några sociala eller onlinetjänster och inte heller från stackbyte om du tvivlar på det. Men för mig vet att lära. Jag gör inget praktiskt arbete med de svar jag har fått här. Men definitivt hjälper de en att veta hur saker och ting fungerar. Man kan inte skapa anti-hackingsäkerhet om man inte vet hur man hackar. Samma analogi finns här. Om jag inte kan lära mig hur appar fungerar är det ingen mening att jag kan göra en.
@S.Mitchell: "Har appskapare rättigheter?" Egentligen har de det inte på _ min_ telefon. Jag kanske låter dem köra sin kod och lagra deras data på min telefon, men de har inte _rätt_ att göra och jag förbehåller mig rätten att återkalla båda rättigheterna efter eget gottfinnande.
@S.Mitchell Jag skulle uppmuntra svar på alla frågor oavsett varför du tror att de finns. bra att du inte driver den här webbplatsen!
Fem svar:
GiantTree
2016-09-25 20:21:22 UTC
view on stackexchange narkive permalink

Det finns flera sätt att identifiera en unik enhet eller dess användare:

  1. Spara en fil i någon (icke-standard) katalog : Du har redan sagt detta; appar kan ofta skriva till enhetens interna lagring. Den här metoden är enkel, fungerar offline och är inte den enklaste att upptäcka (placera filen i någon systemliknande katalog och ingen kommer att bry sig om att radera den).
  2. Håll koll på en unik enhet ANDROID_ID (unik per ny installation) : den här metoden är enkel men kräver internetåtkomst, åtminstone vid första användningen . Det är inte särskilt påträngande och kvarstår inte vid fabriksåterställning. Det är också unikt per användare. Se den här informationen.
  3. IMEI : Mycket påträngande, oföränderlig men kräver en SIM-kompatibel enhet. IMEI är unikt för varje enhet, kan inte ändras och följer inte användaren, vilket innebär att om du säljer din enhet hälsas den nya ägaren med en skärm som berättar för honom att appen redan fanns i telefonen.
  4. Följ en användares Google-konto : Detta är ungefär detsamma som ANDROID_ID -metoden men kräver uttryckligt tillstånd (Android 6.0+) från användaren för att tillgång. Appar som utnyttjar Google-kontots ekosystem (t.ex. toppresultat och prestationer i spel) kan således följa en specifik användare och få mer information än bara om appen har installerats eller inte.

2 , 3 och 4 kräver en nätverksanslutning och en server på utvecklarens sida.

Jag kan hantera 2,3 & 4: e delen med Xprivacy. Jag ska förfalska var och en av dem. Men den första, det är inte lätt att upptäcka. Finns det ändå jag kan upptäcka denna sårbarhet?
Det är inte en sårbarhet, bara en missbrukad funktion. Liksom applikationer som håller filer i registret. Det finns inte mycket du kan göra förutom att gå igenom alla kataloger på telefonens interna lagring och leta efter misstänkta filer.
Att gå igenom alla kataloger är omöjligt eftersom du aldrig vet vilket filnamn du söker, vad är dess filtillägg, filstorlek. Och även om du hittar en och tar bort den och då inser du att filen inte var den aktuella filen du letade efter kommer du att få en systemkrasch. Jag hoppas om det finns en administratörsapp som kan upptäcka medan filen är kopplad till vilken app.
Lycka till att hitta / göra den här appen. Systemet kan inte krascha på grund av någon saknad fil på det interna lagringsutrymmet. I allmänhet tenderar appar att använda samma ramar som använder samma filer, men som du redan påpekade är dessa filer omöjliga att hitta (inte alltid men för det mesta). Filer som innehåller saker som "id", "användare" eller liknande innehåller ofta ett sådant ID och dessa ID används vanligtvis för reklam.
@S.Mitchell Nej Jag har aldrig förbjudits från några onlinetjänster, webbapplikationer och onlinespel. Men jag tror att att veta om hur systemet fungerar bakom dess gränssnitt är rätt steg för att gå vidare i Android-utveckling.
@user334283 "vet aldrig vilket filnamn du söker". Detta är falskt. Android, som ett Linux-operativsystem, har "strace" -verktyget som kan användas för att hålla reda på alla systemanrop. Så du måste starta din app med "strace" och kontrollera alla systemanrop relaterade till filer på enheten och du kommer att upptäcka alla filer lästa / kontrollerade för att existera av appen. Visst: förmodligen ganska svårt att göra på smarttelefonen men definitivt * möjligt *.
@Bakuriu Thnx för att lägga till detta. Jag kan hitta det relaterade inlägget för strace-kommando för Android på inbyggd webbplats. http://stackoverflow.com/q/12166917/6538535http://stackoverflow.com/q/16247565/6538535
Ett annat sätt: det finns också säkerhetskopieringstjänsten för Android, återställer inte det inställningarna för tidigare installerade appar (åtminstone om den är aktiverad)?
@derobert Android 6 tillåter detta: http://stackoverflow.com/a/36471154/6538535
@Bakuriu: Det är inte svårt alls om du har en rotad telefon och en ssh-server i telefonen. SSHDroid gör det enkelt att installera en som körs som root om möjligt.
Devin Ersoy
2016-09-25 20:21:32 UTC
view on stackexchange narkive permalink

Den är inte ansluten till lagring utan till molnet. Det är så det kommer ihåg även om du raderade dina data. För att stänga av det här, gå till enhetens inställningsapp, tryck på konton google under personlig (tryck på det konto du vill ha om du har flera konton) och stäng sedan av de appar du inte vill synkronisera automatiskt.

Autosynk är inte rotproblemet. Tredjepartsservrar ser till att deras app kan samla in din MAC-adress, IMEI, enhets-ID, reklam-ID och lagra detta på servrar för att upptäcka enheten igen i framtiden. Spoofing dessa detaljer kommer att hålla din integritet, men om en app skriver "registerposter" som i Windows problem kommer att upptäckas.
Neil
2016-09-26 22:33:29 UTC
view on stackexchange narkive permalink

GiantTrees svar täcker det bäst, men det finns en annan punkt att tänka på. Det skulle helt klart vara ett " mörkt mönster " men denna identifiering kan också göras genom fingeravtryck vissa användardata - detta kan ses som en variant vid hans första punkt ("behåll en fil ") men det skulle vara svårare att upptäcka och mindre bekvämt att undvika.

Hur motståndskraftigt detta är beror på den valda informationen. Den mest uppenbara metoden är att titta på kontaktuppgifter och använda någon form av fingeravtryck av detta; ett alternativ kan vara användning av fotostämplar och andra metadata. Uppenbarligen förändras dessa över tid så vilken metod som helst skulle behöva ge ett nära svar efter modifiering (så det skiljer sig från en traditionell hash-funktion). Det finns ingen garanti för att en användare inte bara rensar spårad data, men i många fall föredrar människor att inte göra detta.

Du kanske vill titta på webbläsarens fingeravtryck för att få en känsla av hur detta fungerar, även om det kommer att bli något annorlunda eftersom telefonhårdvara vanligtvis är mer enhetlig än datorhårdvara. Med detta sagt kan tillägget av vissa telefondetaljer hjälpa till att begränsa fingeravtrycket lite.

Där detta tillvägagångssätt bryts ner i synnerhet är om en användare byter telefon och tar deras detaljer med dem till en ny telefon - i det här fallet (om inte telefondetaljer går in i fingeravtrycket) kan den nya telefonen detekteras som redan installerad, som frågan ställdes. Det verkar dock ganska troligt att i ett scenario där en app försöker förbjuda en användare, kan detta faktiskt vara ett önskat resultat (snarare än att förbjuda den specifika telefonen i sig)

Observera: stark> På något sätt säger jag att detta är korrekt eller "bra" som ett sätt att hantera om du skriver appar, men det verkar rimligt att diskutera det eftersom det bara är genom diskussion som människor kommer att ta reda på om de är oroliga tillräckligt för att göra något åt ​​det och vad det kan vara.

David Bennett
2016-09-26 05:05:30 UTC
view on stackexchange narkive permalink

Det finns en SharedPreferences-klass - https://developer.android.com/reference/android/content/SharedPreferences.html - som vissa appar använder för att lagra preferensdata. Dessa data raderas inte när appen avinstalleras. Om appen senare installeras om finns fortfarande några tidigare sparade SharedPreferences-nycklar tillgängliga för den.

"SharedPreferences" raderas faktiskt ** när appen avinstalleras. Det finns sätt för utvecklare att ställa in säkerhetskopior, men som standard tas de bort vid avinstallationen. (Källa: Som utvecklare avinstallerar jag mina appar för att rensa inställningarna. Se även: http://stackoverflow.com/a/9815641/1438733)
computingfreak
2016-10-20 07:12:42 UTC
view on stackexchange narkive permalink

Det finns en annan möjlighet - användning av beständiga kakor med mycket stor "tid att löpa ut". Jag antar att det är så att flera appar från samma utvecklare brukade dela referenser traditionellt, när lagrade referenser via kontofunktionen inte var så öppna / kända för allmänheten.



Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...