이 문서 에서 는 사용 사례 에 따라 앱 에 적합 한 식별자 를 선택 하 는 방법 을 설명 합니다 . 
 Android 권한 과 관련 된 일반 적 인 내용 은 권한 개요 를 참조 하 세요 . Android 권한 을 사용 하 기 위한 구체 적 인 권장 사항 은 앱 권한 권장 사항 을 참조 하 세요 . 
 Android 식별자 사용 권장 사항 
 Android 식별자 를 사용 할 때 다음 권장 사항 을 따르 세요 . 
 # 1 : 하드웨어 식별자 사용 을 피 합니다 . 대부분 의 사용 사례 에서 는 필수 기능 을 제한 하 지 않 고 SSAID ( Android ID ) 및 IMEI 와 같 은 하드웨어 식별자 를 사용 하 지 않 을 수 있 습니다 . 
 # 2 : 사용 자 프로필 이나 광고 사용 사례 에 는 광고 ID 만 사용 합니다 . 광고 ID 를 사용 할 때 는 항상 광고 추적 과 관련 하 여 사용 자 의 선택 을 존중 합니다 . 또한 식별자 를 PII ( 개인 식별 정보 ) 에 연결 해서 는 안 되 며 광고 ID 재 설정 연결 을 피해야 합니다 . 
 # 3 : 결제 사기 예방 및 전화 통신 을 제외 한 기타 모든 사용 사례 에 는 가능 한 경우 항상 인 스턴스 ID 또는 비 공개 로 저장 된 GUID 를 사용 합니다 . 대부분 광고 이외 의 사용 사례 에 는 인 스턴스 ID 나 GUID 만 으로 충분 합니다 . 
 # 4 : 사용 사례 에 적합 한 API 를 사용 하 여 개인 정보 보호 의 위험 을 최소 화 합니다 . 가치 가 높 은 콘텐츠 보호 에 는 DRM API 를 , 악용 방지 에 는 SafetyNet API 를 사용 하 세요 . SafetyNet API 는 개인 정보 보호 의 위험 을 초래 하 지 않 고 기기 의 진위 여부 를 확인 할 수 있 는 가장 쉬운 방법 입니다 . 
 이 가이드 의 나머지 섹션 에서 는 Android 앱 개발 과 관련 하 여 권한 사용 규칙 을 자세히 설명 합니다 . 
 Android 8 . 0 이상 의 식별자 
 MAC 주소 는 전역 적 으로 고유 하 며 , 사용 자 가 재 설정 할 수 없 고 , 초기 화 후 에 도 유지 됩니다 . 이런 이유 로 사용 자 식별 을 위해 MAC 주소 를 사용 하 는 것 은 대개 어떠 한 형태 라도 권장 되 지 않 습니다 . Android 6 . 0 ( API 레벨 23 ) 이상 에서 로컬 기기 의 MAC 주소 ( 예 : Wi - Fi 및 블루투스 ) 는 타사 API 를 통해 사용 할 수 없 습니다 . WifiInfo . getMacAddress ( ) 메 서드 와 BluetoothAdapter . getDefaultAdapter ( ) . getAddress ( ) 메서 드 모두 02 : 00 : 00 : 00 : 00 : 00 을 반환 합니다 . 
 또한 블루투스 와 Wi - Fi 검색 을 통해 사용 가능 한 근처 외부 기기 의 MAC 주소 에 액세스 하 려면 다음 권한 이 있 어야 합니다 . 
 메 서드 / 속성 
 WifiManager . getScanResults ( ) ACCESS _ FINE _ LOCATION 또는 ACCESS _ COARSE _ LOCATION 
 BluetoothDevice . ACTION _ FOUND ACCESS _ FINE _ LOCATION 또는 ACCESS _ COARSE _ LOCATION 
 BluetoothLeScanner . startScan ( ScanCallback ) ACCESS _ FINE _ LOCATION 또는 ACCESS _ COARSE _ LOCATION 
 광고 ID 사용 
 광고 ID 는 사용 자 가 재 설정 할 수 있 는 식별자 로 광고 사용 사례 에 적합 하 지만 , 이 ID 를 사용 할 때 몇 가지 염두 에 둬야 할 중요 한 사항 이 있 습니다 . 
 광고 ID 를 재 설정 할 때 는 항상 사용 자 의 의도 를 존중 합니다 . 사용자 의 동의 없이 이후 의 광고 ID 를 서로 연결 하 는 데 다른 식별자 나 지문 을 사용 하 여 사용 자 재 설정 을 연결 하 면 안 됩니다 . Google Play 개발자 콘텐츠 정책 에 다음 과 같이 명시 되 어 있 습니다 . 
 '... 재 설정 시 사용 자 의 명시 적 인 동의 없이 새 광고 식별자 를 기존 광고 식별자 또는 기존 광고 식별자 에서 파생 된 데이터 에 연결 하 면 안 됩니다 . ' 
 연결 된 개인 맞춤 광고 플래그 를 항상 존중 합니다 . 광고 ID 는 사용 자 가 이 ID 와 관련 된 추적 의 수준 을 제한 할 수 있 다는 점 에서 구성 이 가능 합니다 . 항상 AdvertisingIdClient . Info . isLimitAdTrackingEnabled ( ) 메서 드 를 사용 해 사용 자 의 요구 사항 을 회피 하 지 않 도록 해야 합니다 . Google Play 개발자 콘텐츠 정책 에 다음 과 같이 명시 되 어 있 습니다 . 
 '... 사용 자 의 ' 관심 기반 광고 선택 해제 ' 또는 ' 광고 맞춤 설정 선택 해제 ' 설정 도 준 수 해야 합니다 . 사용자 가 이 설정 을 사용 하 는 경우 광고 식별자 를 사용 하 여 광고 목적 으로 사용 자 프로필 을 만들 거나 맞춤 광고 로 사용 자 를 타 겟 팅 하 면 안 됩니다 . 허용 되 는 작업 에 는 문맥 광고 , 게재 빈도 설정 , 전환 추적 , 보 고 및 보안 , 사기 감지 등 이 있 습니다 . ' 
 광고 ID 사용 과 관련 하 여 사용 하 는 SDK 와 연결 된 개인 정보 보호 또는 보안 정책 에 유의 합니다 . 예 를 들 어 Google 애널리 틱 스 SDK 의 e n a b leAdvertisingIdCollection ( ) 메서 드 에 true 를 전달 하 는 경우 해당 하 는 모든 애널리 틱 스 SDK 정책 을 검토 하 고 준 수 해야 합니다 . 
 또한 Google Play 개발자 콘텐츠 정책 에 따라 광고 ID 는 ' 개인 식별 정보 에 연결 되 거나 영구 기기 식별자 ( 예 : SSAID , MAC 주소 , IMEI , 등 ) 에 연결 되 면 안 됩니다 . ' 
 한 가지 예 로 , 다음 과 같 은 열 의 데이터베이스 테이블 을 채우 기 위해 정보 를 수집 한다고 가정 해 보 겠 습니다 . 
 이 예 에서 ad _ id 열 은 두 테이블 의 account _ id 열 을 통해 PII 에 연결 될 수 있 는데 , 이 경우 사용 자 에게 명시 적 인 권한 을 받 지 않 았 다면 Google Play 개발자 콘텐츠 정책 에 위배 됩니다 . 
 광고주 ID 와 PII 간 링크 가 항상 이렇게 명확 하 지 는 않 습니다 . PII 와 광고 ID 키 테이블 에 ' 유사 식별자 ' 가 나타날 수 있 으며 이 로 인해 문제 가 발생 하 기 도 합니다 . 예 를 들 어 TABLE - 01 과 TABLE - 02 를 다음 과 같이 변경 한다고 가정 해 보 겠 습니다 . 
 이 경우 클릭 이벤트 가 거의 없 어도 여전히 이벤트 와 기기 모델 의 타임스탬프 를 사용 하 여 TABLE - 01 광고주 ID 와 TABLE - 02 에 포함 된 PII 간 에 연결 할 수 있 습니다 . 
 데이터 세트 에 이러 한 유사 식별자 가 없 다고 보장 하 기 어려운 경우 가 많 지만 , 가능 한 경우 고유 데이터 를 일반 화 하 면 연결 과 관련 된 가장 명확 한 위험 을 방지 할 수 있 습니다 . 이 경우 위 예 에서 는 타임스탬프 의 정확도 가 낮 아 져서 모든 타임스탬프 에 동일 한 모델 을 가진 기기 가 여러 대 나타납니다 . 
 그 외 에 다음 과 같 은 해결 방법 이 있 습니다 . 
 PII 와 광고 ID 를 명시 적 으로 연결 하 는 테이블 을 설계 하 면 안 됩니다 . 이 를 위해 위 의 첫 번 째 예 에서 는 account _ id 열 을 TABLE - 01 에 포함 하 지 않 았 습니다 . 
 광고 ID 키 데이터 와 PII 에 모두 액세스 하 는 사용자 나 역할 의 액세스 제어 목록 ( ACL ) 을 분리 하 고 모니터링 합니다 . 두 소스 에 동시 에 액세스 하 는 기능 ( 예 : 테이블 간 연결 ) 을 엄격히 제어 하 고 감사 하 여 광고 ID 와 PII 간 의 연결 위험 을 줄입니다 . 일반 적 으로 다음 작업 을 하 여 액세스 를 제어 합니다 . 
 광고주 ID 키 데이터 와 PII 의 액세스 제어 목록 ( ACL ) 을 분리 해서 유지 하 여 두 ACL 에 있 는 개인 이나 역할 의 수 를 최소 화 합니다 . 
 이 규칙 의 예외 를 감지 하 고 관리 하 기 위한 액세스 로 깅 및 감사 를 구현 합니다 . 
 광고 ID 를 반응 형 으로 사용 하 는 방법 에 관한 자세 한 내용 은 AdvertisingIdClient API 참조 를 확인 하 세요 . 
 인 스턴스 ID 와 GUID 사용 
 기기 에서 실행 중 인 앱 인 스턴스 를 식별 하 는 가장 단순 한 방법 은 인 스턴스 ID 를 사용 하 는 것 입니다 . 이것 은 광고 이외 의 대다수 사용 사례 에 권장 되 는 해결 방법 입니다 . 인 스턴스 ID 가 프로비저닝 되 었 던 앱 인 스턴스 만 이 식별자 에 액세스 할 수 있 으며 , 인 스턴스 ID 는 앱 이 설치 되 어 있 는 동안 만 지속 되 므로 비교 적 쉽 게 재 설정 할 수 있 습니다 . 
 따라서 인 스턴스 ID 는 재 설정 할 수 없 는 기기 범위 의 하드웨어 ID 보다 더 나 은 개인 정보 보호 속성 을 제공 합니다 . 자세 한 내용 은 FirebaseInstanceId API 참조 를 확인 하 세요 . 
 인 스턴스 ID 가 실용 적 이 지 않 은 경우 맞춤 GUID ( Globally - Unique ID ) 를 사용 해 앱 인 스턴스 를 고유 하 게 식별 할 수 도 있 습니다 . 이 를 위한 가장 간단 한 방법 은 다음 코드 로 나 만 의 GUID 를 생성 하 는 것 입니다 . 
 이 식별자 는 전역 적 으로 고유 하 므로 특정 앱 인 스턴스 를 식별 하 는 데 사용 될 수 있 습니다 . 여러 앱 간 식별자 연결 과 관련 된 문제 를 방지 하 려면 GUID 를 외부 ( 공유 ) 저 장소 가 아닌 내부 저 장소 에 저장 하 세요 . 자세 한 내용 은 데이터 및 파일 저 장소 개요 페이지 를 참조 하 세요 . 
 식별자 특성 
 Android OS 에서 는 동작 특성 이 다양 한 여러 ID 를 제공 합니다 . 사용 해야 하 는 ID 는 다음 특성 이 사용 사례 에서 어떻게 작동 하 는지 에 따라 다릅니다 . 또한 이러 한 특성 은 개인 정보 보호 와 도 관련 되 어 있 으므로 이 특성 이 서로 상호 작용 하 는 방식 을 이해 하 는 것 이 중요 합니다 . 
 식별자 범위 는 어떤 시스템 이 식별자 에 액세스 할 수 있 는지 를 나타냅니다 . 일반 적 으로 Android 식별자 범위 는 다음 세 가지 로 구분 됩니다 . 
 단일 앱 : ID 가 앱 내 부용 이 며 다른 앱 에서 는 액세스 할 수 없 습니다 . 
 앱 그룹 : 사전 정의 된 관련 앱 그룹 에서 ID 에 액세스 할 수 있 습니다 . 
 기기 : 기기 에 설치 된 모든 앱 에서 ID 에 액세스 할 수 있 습니다 . 
 식별자 에 부여 된 범위 가 넓 을수록 추적 용도 로 사용 되 는 식별자 의 위험 이 더 커집니다 . 반 대로 앱 인 스턴스 한 개 만 식별자 에 액세스 할 수 있 는 경우 다른 앱 에서 여러 트랜잭션 간 에 기기 를 추적 할 때 는 이 식별자 를 사용 할 수 없 습니다 . 
 재 설정 가능 성 및 지속 성 
 재 설정 가능 성 및 지속 성 은 식별자 의 수명 을 정의 하 고 식별자 를 재 설정 할 수 있 는 방법 을 나타냅니다 . 일반 적 인 재 설정 트리 거로 는 인 앱 재 설정 , 시스템 설정 을 통한 재 설정 , 시작 시 재 설정 , 설치 시 재 설정 등 이 있 습니다 . Android 식별자 의 수명 은 다양 할 수 있 지만 대개 ID 가 재 설정 되 는 방법 과 관련 이 있 습니다 . 
 세션 전용 : 사용 자 가 앱 을 다시 시작 할 때 마다 새 ID 가 사용 됩니다 . 
 설치 재 설정 : 사용 자 가 앱 을 제거 하 고 다시 설치 할 때 마다 새 ID 가 사용 됩니다 . 
 FDR 재 설정 : 사용 자 가 기기 를 초기 화 할 때 마다 새 ID 가 사용 됩니다 . 
 FDR 지속 : 초기 화 후 에 도 ID 가 유지 됩니다 . 
 사용자 는 재 설정 가능 성 을 통해 기존 프로필 정보 와 연결 이 끊 긴 새로운 ID 를 만들 수 있 습니다 . 식별자 가 더 오래 안정 적 으로 지속 될수록 ( 예 : 초기 화 후 에 도 유지 되 는 식별자 ) 사용 자 가 장기 적 으로 추적 될 수 있 는 위험 이 더 커집니다 . 앱 을 다시 설치 할 때 식별자 가 재 설정 되 면 지속 성 이 줄어들 고 , 앱 이나 시스템 설정 내 에 ID 를 재 설정 할 수 있 는 명확 한 사용자 컨트롤 이 없 는 경우 에 도 ID 를 재 설정 할 수 있 는 수단 이 제공 됩니다 . 
 고유 성 은 충돌 가능 성 , 즉 관련 범위 내 에 동일 한 식별자 가 존재 할 가능 성 을 나타냅니다 . 고유 성 이 가장 높 은 수준 에서 는 GUID ( Globally Unique Identifier ) 충돌 이 발생 하 지 않 으며 다른 기기 나 앱 에서 도 마찬가지 입니다 . 그렇 지 않 으면 고유 성 수준 은 식별자 의 엔트로피 와 고유 성 을 생성 하 는 데 사용 된 임의 성 의 소스 에 따라 다릅니다 . 예 를 들 어 설치 시 Unix 타임스탬프 ( 예 : 1551414181 ) 로 생성 된 식별자 보다 설치 날짜 ( 예 : 2019 - 03 - 01 ) 로 생성 된 임의 의 식별자 가 충돌 할 가능 성 이 훨씬 높 습니다 . 
 일반 적 으로 사용 자 계정 식별자 는 고유 하 다고 간주 될 수 있 습니다 . 즉 , 각 기기 / 계정 조합 에 는 고유 한 ID 가 있 습니다 . 반 대로 모집단 내 에서 식별자 의 고유 성 이 낮 을수록 개별 사용 자 추적 에 유용 하 지 않 으므로 개인 정보 보호 수준 이 높 아 집니다 . 
 무결 성 보호 및 부인 방지 ( non - repudiability ) 
 위장 하 거나 다시 재생 하 기 어려운 식별자 를 사용 해 관련 기기 나 계정 에 특정 속성 이 있 음 을 증명 할 수 있 습니다 . 예 를 들 어 기기 가 스팸 발송자 가 사용 하 는 가상 기기 가 아님 을 증명 할 수 있 습니다 . 위장 이 어려운 식별자 는 부인 방지 기능 도 제공 합니다 . 기기 에서 비밀 키로 메시지 에 서명 하 는 경우 다른 사용자 의 기기 에서 메시지 를 전송 했 다고 주장 하 기 어렵 습니다 . 부인 방지 기능 은 어떤 사용자 에게 는 필요 할 수 있 으며 ( 예 : 결제 인증 시 ) 어떤 사용자 에게 는 원치 않 는 특성 일 수 있 습니다 ( 예 : 메시지 를 보내 고 나 서 후회 하 는 경우 ) . 
 일반 적 인 사용 사례 및 사용 하 기 적합 한 식별자 
 이 섹션 에서 는 IMEI 와 같 은 하드웨어 ID 사용 에 관한 대안 을 제공 합니다 . 하드웨어 ID 를 사용 하 면 사용 자 가 ID 를 재 설정 할 수 없 으며 ID 범위 가 기기 로 제한 되 므로 사용 하 지 않 는 것 이 좋 습니다 . 대부분 의 경우 앱 범위 식별자 로 충분 합니다 . 
 로그아웃 한 사용 자 환경 설정 추적 
 사용 자 계정 없이 서버 에 기기 당 상태 를 저장 하 고 있 는 경우 입니다 . 
 사용 : 인 스턴스 ID 또는 GUID 
 권장 이유 
 사용 자 가 앱 을 다시 설치 하 여 환경 설정 을 재 설정 하 는 것 을 원할 수 도 있 으므로 재 설치 후 에 도 정보 가 지속 되 는 것 은 권장 되 지 않 습니다 . 
 동일 한 서명 키 가 있 는 앱 간 에 로그아웃 한 사용 자 환경 설정 추적 
 서버 에 기기 당 상태 가 저장 되 며 동일 한 기기 에 동일 한 키 로 서명 된 서로 다른 앱 간 에 이 상태 를 전송 하 고 있 는 경우 입니다 . 
 사용 : SSAID 
 Android 8 . 0 ( API 레벨 26 ) 이상 에서 SSAID 는 동일 한 개발자 서명 키로 서명 된 앱 간 에 공통 된 식별자 를 제공 합니다 . 따라서 사용 자 가 계정 에 로그인 하 지 않 아도 이러 한 앱 간 에 상태 를 공유 할 수 있 습니다 . 
 로그아웃 한 사용자 행동 추적 
 동일 한 기기 에서 서로 다른 앱 / 세션 간 에 사용 자 행동 을 기반 으로 사용 자 프로필 을 만든 경우 입니다 . 
 사용 : 광고 ID 
 사용 자 가 ID 를 재 설정 할 수 있 으므로 Google Play 개발자 콘텐츠 정책 에 따라 광고 사용 사례 에 는 광고 ID 를 사용 해야 합니다 . 
 로그아웃 한 사용 자 또는 익명 의 사용 자 분석 생성 
 로그아웃 한 사용 자 또는 익명 의 사용자 의 사용 통계 와 분석 을 측정 하 고 있 는 경우 입니다 . 
 사용 : 인 스턴스 ID 또는 GUID ( 인 스턴스 ID 가 충분 하 지 않 은 경우 ) 
 인 스턴스 ID 또는 GUID 는 생성 되 는 앱 으로 범위 가 지정 되 므로 여러 앱 간 에 사용 자 를 추적 하 는 데 식별자 가 사용 되 는 것 을 방지 합니다 . 또한 사용 자 가 앱 데이터 를 삭제 하 거나 앱 을 다시 설치 하 여 쉽 게 재 설정 할 수 있 습니다 . 인 스턴스 ID 와 GUID 는 다음 과 같이 간단히 만들 수 있 습니다 . 
 인 스턴스 ID 만들 기 : Firebase 클라우드 메시징 가이드 를 참조 하 세요 . 
 GUID 만들 기 : 다음 코드 스니 펫 에서 와 같이 앱 에 로직 을 구현 합니다 . 
 수집 하 는 데이터 가 익명 이 라고 사용 자 에게 말 한 경우 PII 에 연결 되 었 을 수 있 는 다른 식별자 또는 PII 에 식별자 를 연결 하 지 않 아야 합니다 . 
 또한 앱 별 분석 을 위한 해결 방법 을 제공 하 는 모바일 앱 용 Google 애널리 틱 스 를 사용 할 수 도 있 습니다 . 
 로그아웃 한 사용자 전환 추적 
 마케팅 전략 의 성공 여부 를 알아내 기 위해 전환 을 추적 하 고 있 는 경우 입니다 . 
 광고 관련 사용 사례 로 , 다양 한 앱 에서 사용 가능 한 ID 가 필요 할 수 있 으므로 광고 ID 를 사용 하 는 것 이 가장 적절 한 해결 방법 입니다 . 
 다양 한 기기 에서 여러 설치 처리 
 동일 한 사용 자 를 위해 여러 기기 에 앱 을 설치 할 때 앱 의 올바른 인 스턴스 를 식별 해야 하 는 경우 입니다 . 
 인 스턴스 ID 는 명확히 이 용도 로 설계 되 었 습니다 . ID 범위 가 앱 으로 제한 되 므로 서로 다른 앱 간 의 사용 자 추적 에 사용 될 수 없 으며 앱 을 다시 설치 하 면 재 설정 됩니다 . 드물 지만 인 스턴스 ID 가 충분 하 지 않 은 경우 GUID 를 사용 할 수 도 있 습니다 . 
 사 기 예방 : 무료 콘텐츠 제한 시행 / Sybil 공격 감지 
 사용 자 가 기기 에서 볼 수 있 는 기사 와 같 은 무료 콘텐츠 수 를 제한 하 려는 경우 입니다 . 
 사용 : 인 스턴스 ID 또는 GUID . Android 8 . 0 ( API 레벨 26 ) 이상 에서 는 SSAID 의 범위 가 앱 서명 키로 지정 되 므로 SSAID 도 사용 할 수 있 습니다 . 
 GUID 또는 인 스턴스 ID 를 사용 하 는 경우 사용 자 가 콘텐츠 제한 을 우회 하 려면 앱 을 다시 설치 해야 하 므로 , 이러 한 부담 으로 인해 대부분 의 사람 들 이 우회 를 포기 합니다 . 이 ID 사용 으로 충분히 보호 되 지 않 는 경우 Android 는 콘텐츠 에 대한 액세스 를 제한 하 는 데 사용 할 수 있 는 DRM API 를 제공 하 며 , 여기 에 는 APK 당 식별 자 인 Widevine ID 가 포함 됩니다 . 
 이동 통신사 기능 
 앱 에서 이동 통신사 계정 을 사용 해 기기 의 전화 및 문자 기능 과 상호 작용 하 고 있 는 경우 입니다 . 
 사용 : IMEI , IMSI , Line 1 
 이 동 통신사 관련 기능 에 필요 한 경우 하드웨어 식별자 를 활용 할 수 있 습니다 . 예 를 들 어 이러 한 식별자 를 사용 해 이동 통신사 또는 SIM 슬롯 간 을 전환 하 거나 IP ( Line 1 의 경우 ) - SIM 기반 사용 자 계정 을 통해 SMS 메시지 를 전송 할 수 있 습니다 . 하지만 권한 이 설정 되 지 않 은 앱 의 경우 계정 로그인 을 사용 해 서버 의 사용 자 기기 정보 를 검색 하 는 것 이 좋 습니다 . 이러 한 이유 중 하나 는 Android 6 . 0 ( API 레벨 23 ) 이상 에서 는 런타임 권한 을 통해서 만 이 식별자 를 사용 할 수 있 다는 점 입니다 . 사용자 가 이 권한 을 해제 할 수 있 으므로 앱 에서 이러 한 예외 를 매끄럽 게 처리 해야 합니다 . 
 악용 감지 : 봇 과 DDoS 공격 식별 
 백 엔드 서비스 를 공격 하 는 여러 가짜 기기 를 감지 하 려는 경우 입니다 . 
 사용 : SafetyNet API 
 격리 된 식별자 는 기기 의 진위 여부 를 나타내 기 어렵 습니다 . 요청 하 는 기기 의 무결 성 을 확인 할 수 있 는 SafetyNet API 의 attest ( ) 메서 드 를 사용 하 면 에뮬레이터 나 다른 기기 로 위장 하 는 다른 코드 가 아닌 진짜 Android 기기 에서 오 는 요청 인지 확인 할 수 있 습니다 . 자세 한 내용 은 SafetyNet API 문서 를 참조 하 세요 . 
 사 기 및 악용 감지 : 가치 가 높 은 도난 당한 사용자 인증 정보 감지 
 기기 한 대 가 가치 가 높 은 도난 당한 사용자 인증 정보 로 여러 번 사용 되 고 있 는지 ( 예 : 사기 결제 ) 감지 하 려는 경우 입니다 . 
 사용 : 특성 상 사기 를 방지 하 려면 시간 이 지남 에 따라 변경 할 수 있 는 독점 신호 가 필요 하 며 , 이 내용 은 이 문서 의 범위 를 벗어납니다 . 그러나 IMEI 및 IMSI 와 같 은 하드웨어 식별자 는 루팅 된 기기 나 에뮬 레이트 된 기기 에서 쉽 게 수정 할 수 있 으므로 신뢰 할 수 있 는 사기 지표 는 아닙니다 .