KR20160077104A - 모바일 앱 사용예의 규제되지 않은 수집을 제어하기 - Google Patents

Abstract

기술이 모바일 컴퓨팅 디바이스에서 실행되는 모바일 앱에 의해 동작 추적을 제어하기 위해 제공된다. 프로파일들의 세트는 개인 정보 관리자에 의해 관리되고, 각 프로파일은 상기 모바일 컴퓨팅 디바이스에서 다른 분리된 실행 환경을 나타내고 연관된 실행 환경에서 실행될 때 애플리케이션을 지배하는(governing) 개인 정보 규칙들의 세트를 정의한다. 앱을 시작하기 이전에, 앱의 사용자는, 개인 정보 관리자에 의해, 프로파일들의 세트로부터 앱에 대한 프로파일을 선택하도록 유도된다. 다음으로 개인 정보 관리자는 모바일 컴퓨팅 디바이스에서 앱의 실행 동안에 선택된 프로파일과 연관된 개인 정보 규칙들의 세트를 적용한다.

Description

모바일 앱 사용예의 규제되지 않은 수집을 제어하기{CONTROLLING UNREGULATED AGGREGATION OF MOBILE APP USAGE}

본 출원은 2014년 10월 24일자 미국 출원 제14/522,618호의 우선권을 주장하고 2013년 10월 25일자 미국 가출원 제61/895,611호의 이익을 요청한다. 상기 출원들의 전체 내용들은 본원에 병합된다. 본 출원의 전체 개시는 참조로 본 명세서에 병합된다.

본 개시는 모바일 애플리케이션들의 동작 추적을 제어하는 기술에 관한 것이다.

스마트폰 애플리케이션들은 우리의 일상 생활과 기업들에서 점점 더 중요하고 인기를 끌고 있다. 2013년에만, 모바일 앱 다운로드들은 전 세계적으로 1000억을 돌파하고 전체 앱 사용예는 115% 증가했다. 사용자는 스마트폰에 매일 평균 2.5 시간을 소비하고 있고, 그 80%가 모바일 앱 내에서 소비되고 있다. 스마트폰들에서 모바일 앱들의 인기는, 모바일 앱들을 사용자의 인구 통계(demographics), 관심 사항(interests) 및 위치와 같은 기타 개인 정보를 수집하는 매력적인 채널로 만들고 있다.

악의적인 자(앱 또는 앱 내에 제3자)가 엑세스하지 말아야 할 정보에 엑세스하는 것을 중지하는 방법에 대한 많은 연구들이 있었다. 이러한 이전의 시도들과 독립적으로, 본 개시는, 사용자의 동의 또는 알림없이 -세션 또는 앱들을 통해- 사용자의 개인 정보를 은밀하게 링크하고 수집하는 호기심을 가진 자에 의해 부여되는 개인 정보 위협에 초점을 맞추고 있다. 현재 스마트폰 생태계에 호기심을 가진 자는 다음과 같다:

● 모바일 애플리케이션들. 예를 들어, 사용자는 CNN이나 뉴욕 타임즈와 같은 동일한 뉴스 앱을 사용하여 정치 뉴스와 종교적인 기사들을 좇는다. 사용자의 정치적, 종교적 관심 사항들을 수집하여, 앱은 그에게 "The END Of Anti-Gay Religious Rhetoric in Politics"와 같은 개인화된 뉴스 콘텐츠를 제공할 수 있다 그러나, 사용자가 자신이 무엇을 읽는지에 대한 민감한 경우, 그는 다른 주제들에 대해 자신의 관심 사항들을 통해 이러한 유형의 불필요한 상관 관계를 원치 않을 수 있다.

● 광고 대행사. 예를 들어, 사용자는 두개의 광고 탑재 앱들을 다운로드하고 자신의 연령을 제1앱에 공개하고 자신의 성별을 제2앱에 공개한다. 그러나, 이 앱들은 동일한 광고 라이브러리를 포함하기 때문에, 광고 대행사는 연령과 성별을 사용자와 링크하고 그에게 타겟 광고를 보낼 수 있다. 사용자에게, 다른 한편으로는,이 비밀 수집에 대한 알림이 없다.

● 네트워크 스니퍼들. 최근 언론에 널리 홍보된 바와 같이, 이러한 NSA와 GCHQ와 같은 정부 기관은, 종종 네트워크 트래픽을 스니핑하고 스마트폰 앱과 광고 라이브러리에 의해 유출된 개인 정보를 수집하여 공공 감시를 실시하고 있다. 최근의 연구는, 유사한 스니퍼(similar sniffer)는 정치적 전망과 성적 지향과 같은 상단의 상세한 개인의 관심 사항들(interests)이 추출될 수 있는 모바일 트래픽의 50 %까지 '스니핑'된 사용자에 기인할 수 있다는 것을 보여준다.

이러한 위협의 심각도(severity)나 출현율(prevalence)은 스마트폰 생태계에서 각 사용자의 앱 사용예들(usages)에서 비링크가능성(unlinkability)의 부족에 뿌리를 두고 있다. 장치 식별자, 소프트웨어 쿠키들, IP들, 로컬 및 외부 스토리지들이 제공하는 일관성의 다양한 수준을 이용하여, 사용자의 선택 및 승인(또는 불허)과 상관없이, 공격자는 동일한 사용자의 앱 사용예들을 쉽게 상관 관계를 찾고 분리된 것으로 가정할 수 있는 정보들(supposed-to-be Isolated islands of information)을 포괄적인 사용자 프로파일에 수집할 수 있다.

그러나, 사용자의 관점에서, 기능적으로(functionally)- 의존하는 앱 사용예들만은 링키될 수 있어야 한다. 예를 들어, GTalk에서, 동일한 로그인에서 앱 사용예들은 링키될 수 있어서 일관성있는 메시징 서비스를 제공할 수 있다. 앵그리 버드에서, 동일한 앱의 사용예는 링키될 수 있어서 사용자가 자신이 이전에 중지된 위치에서 다시 시작할 수 있다. 반면, 명시적 로그인을 적용하지 않거나 일관된 장기 '기억'을 요구하지 않는, 빙(Bing)이나 위키백과(Wikipedia)와 같은 가장 빈번한 질의 유사 앱들(most query-like apps)에서, 앱 사용예들은 기본적으로 익명이어야 한다.

이러한 통찰력을 바탕으로, 모바일 앱, 광고 대행사 및 네트워크 스니퍼를 포함하지만 제한되지 않는 다양한 호기심을 가진 제3자들에 의해 규제되지 않는 수집을 선택할 수 있는 실제 프레임 워크가 제공된다. 아래에서 이 프레임 워크를 마스크(MASK)로 지칭한다. 특히, 마스크(MASK)는 앱 사용예들에서 다른 수준의 비링크 가능성을 제공하는 일련의 전용 실행 모드들을 유도한다. 각 앱의 호출시, 사용자는 자신의 기능적 필요에 따라, (앱의 시작부터 종료까지) 현재 앱 세션에 다음 모드 중 하나를 적용할 수 있다:

● 식별 모드(Identifiable Mode): 사용자가, 명시적인 실제 식별자로 이 앱을 실행함. 동일한 로그인을 공유하는 앱 세션들은 링키될 수 있다.

● 가명 모드(Pseudonymous Mode) : 사용자가, 자신의 현재 활동에 대한 영구 스토리지(일치하는 로컬 상태)에 의존함. 동일한 앱 내 앱 세션들은 링키될 수 있다.

● 익명 모드(Anonymous Mode) : 사용자가, 어떤 영구적인 흔적을 남기지 않고 상태 비지속적으로(statelessly) 현재 세션을 실행함. 앱의 용도는 기본적으로 비링키될 수 있다.

네트워크 스니퍼 및/또는 광고 대행사 모두에 의해 수집된 앱의 사용예들은 직접 또는 간접적으로, 모바일 앱으로부터 온다. 상기 실행 모드들을 적용함으로써, 마스크(MASK)는 이러한 앱 사용예들을 각종 식별 정보들에 대한 분리된 런타임 환경(isolated runtime environment)과 각각 연관된 비링키될 수 있는 프로파일들(unlinkable profiles)로 분할한다. 특히, 마스크(MASK)는 IMEI 번호와 같은 익명 장치 ID, 계정 정보와 같은 노출 개인 식별자들(stripped personal identifiers), 노출 개인 식별자들(stripped personal identifiers) 및 분리된 영구 스토리지로 분리된 런타임 환경을 생성한다. 비링키될 것으로 예상되는 앱의 사용예들은 자신의 비링크 가능성을 보장하기 위해 다른 런타임 환경에 할당된다. 식별 모드에서, 영구 런타임 환경이 적용된다. 가명 모드에서, 마스크(MASK)는, IP 및 위치와 같은 가명 식별자들(quasi-identifiers)의 영향을 완화하여, 사용자가, 집, 사무소, 여행중에 사용할 수 있는 다중 콘텍스트-기반 런타입 환경들(multiple context-based runtime environments)을 유지할 수 있게 한다. 익명 모드에서, 앱이 호출될 때마다, 새로운 런타임 환경이 적용된다.

이 섹션은 종래 기술에 필수적이지 않은 본 발명과 연관된 배경 기술을 제공한다.

이 섹션은 본 개시의 일반적인 요약을 제공하고, 본 개시의 특징들 모두 또는 전 범위의 포괄적인 내용은 아니다.

기술이 모바일 컴퓨팅 디바이스에서 실행되는 모바일 앱에 의해 동작 추적을 제어하기 위해 제공된다. 프로파일들의 세트는 개인 정보 관리자에 의해 관리되고, 각 프로파일은 상기 모바일 컴퓨팅 디바이스에서 다른 분리된 실행 환경을 나타내고 연관된 실행 환경에서 실행될 때 애플리케이션을 지배하는(governing) 개인 정보 규칙들의 세트를 정의한다. 앱을 시작하기 이전에, 앱의 사용자는, 개인 정보 관리자에 의해, 프로파일들의 세트로부터 앱에 대한 프로파일을 선택하도록 유도된다. 다음으로 개인 정보 관리자는 모바일 컴퓨팅 디바이스에서 앱의 실행 동안에 선택된 프로파일과 연관된 개인 정보 규칙들의 세트를 적용한다.

일 측면에서, 개인 정보 관리자는, 프로파일이 식별 프로파일(identifiable profile), 가명 프로파일(pseudonymous profile) 및 익명 프로파일(pseudonymous profile)로 이루어진 군에서 선택될 때, 선택된 프로파일에 따라 소정의 앱에 대한 실행 환경을 생성하고 관리한다. 사용자로부터 입력을 수신한 것에 대한 응답으로, 결정은 소정의 애플리케이션에 대한 실행 환경의 존재에 따라 개인 정보 관리자에 의해 되고, 가능하다면 소정의 애플리케이션에 대한 실행 환경은 개인 정보 관리자에 의해 생성된다.

익명의 프로파일이 소정의 애플리케이션을 위해 선택될 때, 개인 정보 관리자에 의해, 소정의 애플리케이션의 세션의 완료시 소정의 애플리케이션에 대한 실행 환경이 파괴된다. 식별 프로파일이 소정의 애플리케이션을 위해 선택될 때 개인 정보 관리자에 의해, 소정의 애플리케이션의 세션을 통해 소정의 애플리케이션에 대한 실행 환경이 유지된다. 가명의 프로파일이 소정의 애플리케이션을 위해 선택될 때, 개인 정보 관리자에 의해, 실행 환경을 파괴하라는 명시적 코멘트가 수신될 때까지 소정의 애플리케이션의 세션을 통해 소정의 애플리케이션에 대한 실행 환경이 유지된다.

콘텍스트 엔진은 모바일 컴퓨팅 디바이스에 대한 컨텍스트 데이터를 결정하고, 사용자가 프로파일을 지시하도록 유도하는 경우에 가명 프로파일들의 그룹으로부터 특정 가명 프로파일을 추천하며, 특정 가명 프로파일은 콘텍스트 데이터에 기반하여 선택된다.

다른 측면에서, 인터셉터는, 개인 정보 관리자에 의해, 선택된 프로파일과 연관된 개인 정보 규칙들의 세트에 따라 구성되고, 소정의 앱의 실행 환경에서 인 시작된다(launching). 동작에서, 인터셉터는 모바일 컴퓨팅 디바이스의 운영 시스템(operating system)에 의해 제공되는 시스템 서비스들에 대한 소정의 애플리케이션에 의해 만들어진 요청들(requests)을 모니터링하고; 소정의 애플리케이션의 사용자에 대한 식별 정보를 제공하는 요청을 식별하고; 식별 요청들에 대한 응답들에 포함된 식별 정보를 익명화한다(anonymize).

또 다른 측면에서, 인터셉터는 소정의 애플리케이션에 의해 만들어진 파일 시스템 동작들을 인터셉트하고(intercept), 파일 시스템 동작들을 소정의 애플리케이션에 대한 실행 환경과 연관된 임시 데이터 스토리지(transient data store)로 리디렉션한다(redirect).

추가적인 적용 가능성(further areas of applicability)은 본 명세서에 제공된 상세한 설명으로부터 명백해질 것이다. 요약서의 상세하고 구체적인 예시들은 설명의 목적을 위한 것이며, 본 개시의 범위를 제한하기 위한 것이 아니다.

첨부된 도면들은 오로지 선택된 실시예들의 설명을 위한 것이고, 모든 가능한 실시예들을 위한 것이 아니며, 본 개시의 범위를 제한하기 위한 것이 아니다.
도 1은 다양한 호기심을 가진 제3자들에 의해 다른 앱 세션들에서 사용예가 어떻게 모으고, 수집되고 파급되는지를 도시하는 도면이다;
2는 분리된 런타임 환경이 다른 모바일 앱 사용예 패턴들을 위해 다른 모바일 애플리케이션의 실행 모드들에서 유지되는지를 도시하는 도면이다;
도 3은 프로세스 간 통신을 인터셉트하는 기술을 도시하는 도면이다;
4는 모바일 앱에 의해 사용되는 영구 스토리지를 분리하는 기술을 도시하는 도면이다;
도 5는 개인 정보 관리자의 구현 예를 도시하는 흐름도이다;
도 6a-6c는 개인 정보 관리자에 의해 사용되는 사용자 인터페이스들의 예들이다;
도 7은, 각 카테고리 기반(per-category basis)으로 자신의 사용예 패턴에 따라 앱들의 분해(breakdown of apps)를 도시 한 그래프이다;
도 8a-8c는 다른 개인 정보 실행 모드에서 실행될 때 세 가지 모바일 앱에 대한 수집될 수 있는 앱 사용예를 도시한 그래프들이다;
도 9a-9c는 세 가지 대표적인 광고 및 분석 대행사들이 수집할 수 있는 앱 사용예를 도시한 그래프들이다; 및
도 10은 글로벌 네트워크 스니퍼에 의해 수집된 수집될 수 있는 앱 사용예를 도시한 그래프이다;
해당 도면 번호들(corresponding reference numerals)은 도면들의 여러 뷰들(views)에 걸쳐 대응되는 부분들(corresponding parts)을 나타낸다.

이하 예시적인 실시예들은 첨부된 도면들을 참조하여 보다 완벽하게 설명될 것이다.

현재 모바일 생태계에서, 관심과 호기심 많은 제3자(interested/curious party)는 사용자의 동의 또는 알림없이 시간에 따른 동일한 사용자의 앱 사용예들을 은밀하게 링크하고 수집할 수 있고, 이것은 앱 사용예들의 규제되지 않은 수집으로 지칭될 수 있다. 이러한 수집은, 공격자가 항상 동일한 사용자의 앱 사용예를 통해 일정 수준의 일관성(a certain level of consistency)을 관찰할 수 있기 때문에, 가능하다. 이러한 일관성은 예를 들어, 일관된 사용자 ID를 앱에 의해 보내지는 HTTP 요청들에서 삽입하여 명시적으로 달성되거나 시간에 따라 동일한 영구적 스토리지를 사용하므로 암시적으로 달성될 수 있다.

세개의 주요한 공격자들-모바일 앱, 광고 대행사 및 네트워크 스니퍼-에 의한 앱 사용예의 규제되지 않은 수집은 아래에서 소개된다.

스마트폰 앱들은 주로 개인화를 위해 사용자의 앱 사용예들을 수집한다. 시간에 따른 앱 사용예들을 추적하고 이들을 도메인-특정 마이닝/학습 알고리즘들에 공급하므로, 스마트폰 앱들은 사용자들의 니즈나 취향을 만족할 수 있는 맞춤형 콘텐츠들, 예를 들어 개인화된 뉴스, 음악, 레스토랑 등을 전달할 수 있다. 그러나, 사용자들은, 자신의 앱 사용예들이 (겉으로는) 양성 목적으로 수집되는 경우에도 호기심을 가지거나 보수적(conservative)이다-사용자는, 자신의 개인화가 확실히 유용하다고 발견한 경우에만 예를 들어 로그인에 의해, 앱에 일관된 식별을 제공한다.

그러나, 사용자가 (로그인하여) 명시적 동의를 하지 않는 경우에도 앱들은 여전히 동일한 사용자들의 사용예들을 식별하고 수집한다. 사실상, 오직 사용자 추적의 목적으로 하는 경우에, 덜 신뢰할 수도 있지만, 모바일 앱들은 로그인을 시행하는 것보다 휠씬 쉽고 간단한 옵션들을 가지고 있다. 예를 들어, 스마트폰 앱은, 서버 상에서 원격으로 사용자 앱 사용예들을 수집하거나, 디바이스에 일관되고 영구적인 스토리지를 이용하여 로컬에서 동일한 목적을 달성하여 일관된 사용자 식별로 IMEI과 안드로이드 ID와 같은 디바이스 ID들 또는 시스템 ID들을 사용할 수 있다.

타겟 광고를 사용하려면, 광고 대행사는 사용자마다 앱 사용예들, 특히 개인적인 관심이나, 성별, 수입, 위치 등과 같은 앱 사용에들에 개시되는 인구 통계를 수집하는데 관심이 있다. 특히, 앱 개발자들은 자신의 광고 대행사들-광고 라이브러리들-의 클라이언트들을 자신의 스마트폰 앱들에 포함하고 자신의 라이브러리에 의해 요청되는 민감한 정보를 사전에(proactively) 공급한다.

또한, 광고 라이브러리는 그 호스트 앱과 동일한 권한을 공유하기 때문에, 광고 라이브러리는 그 자신에 대한 개인 정보를 엑세스 및 모을 수 있다. 동일한 사용자의 정보를 식별 및 수집하기 위해, 제3자 라이브러리들은 사용자 식별자들을 그들이 백 엔드 서버에 보내는 트래픽에 삽입한다. 이러한 사용자 식별자는 디바이스/시스템 ID 또는 로컬 쿠키의 해시 값일 수 있다. 이러한 광고 대행자들은, 그들이 동일한 라이브러리를 운반하는 다중 앱들을 통해 사용예 행동들을 수집할 수 있기 때문에, 스마트폰 앱들보다 더욱 위험할 수 있다.

전술한 제3자들과 달리, 네트워크 스니퍼는 자신의 사용자 디바이스로부터 직접 정보를 수집할 수 없으며 단지 원시 네트워크 트래픽(raw network traffic)으로부터 정보를 추출할 수 있다. 또한, 스니퍼의 관점에서, 네트워크 트래픽이 정말 지저분하게 될 수 있다: 일부는 직접 실제 디바이스 ID로 마스킹되고, 일부는 해시 값들로 태그되고, 일부는 단지 앱-특정 ID(크레이그리스트 사용자 ID(craigslist user ID)와 같은)을 삽입하고, 반면에 다른 일부는 암호화되어 완전히 무용할 수 있다. 그러나, MOSAIC이 IP의 상대적 일관성을 이용하므로 보여주는 바와 같이, 그것은 동일한 사용자를 나타내는 다른 ID들을 결합할 수 있다. 이러한 방법으로, 심지어 다르며 외견상 무관한 사용자 ID들로 마스킹된 트래픽도 수집될 수 있다. 최근에 공개된 바와 같이, 유사한 기술은 공공 감시를 위해 정부 기관(예를 들어, 미국 NSA와 GCHQ)에 의해 사용된다.

요약하면, 이 제3자들이 정보 수집 및 집계의 범위가 증가하고 클라이언트 측(모바일 디바이스)에서 제어가 감소하고 있다. 게다가, 이들은 독립된 당사자들이 아니라 통합된 공격자의 부하 직원처럼 동작한다. 이 제3자들 사이의 정보 흐름이 도 1에 도시되어 있다.

이 공격자들은 대부분 정직하지만 호기심을 많이 가졌다. 즉, 공격자는 시스템이 허가하는 사용자 정보를 수집할 수 있지만 사용자에 대한 부가적인(개인적인) 정보를 추론하기 위해 이와 같이 수집된 정보를 임의로 수집하고 분석할 수 있다. 다시 말해 악성 공격자가, 엑세스되지 않은 정보를 모으기 위해, 기존 시스템을 전복하거나 관통하는 것으로 간주되지 않는다. 이 공격자 모델은 문헌에 널리 발표된 액세스 - 제어 관련 보안 문제 대신, 규제되지 않은 수집의 개인 정보 문제에 초점을 맞추고 있다.

규제되지 않은 수집의 위협은 모바일 앱 생태계에서 널리 유행되고 더욱 심각해지고 있다. 다음과 같은 근본적인 문제는 실제 설정에서 이 개인 정보 위협을 완화하기 위해 해결되어야 한다.

무료 앱들은 전체 다운로드의 91 %로 모바일 앱 스토어들을 지배하고, 앱 개발자는 이 무료 앱들로 수익을 창출하기 위해 광고 라이브러리를 포함한다. 따라서, 스마트폰 앱은 광고 대행사와 동일한 재정적 이해 관계를 공유하고, 따라서 신뢰할 수 없다. 사실, 스마트폰 앱들은 의도적으로 광고 대행사와 결탁하고 그들에게 광고 라이브러리를 스스로 알 수 없는 연령이나 성별과 같은 사용자의 인구 통계를 공급한다. 다시 말해, 그 인기가 높은 앱 개발자의 활동에 의존하는 OS 공급 업체들은 앱 개발자의 재정적 이해관계에 저해할 수 있는 개인 정보 강화 기능을 추가하기를 꺼려한다. 그래서, 확장된 OS 수준의 수정을 요구하는 것은 자신의 실제 값어치를 떨어뜨릴 수 있다.

사용자가 일반적으로 쿠키를 사용하여 식별되고 추적되는 웹의 경우와 달리, 스마트폰 앱들은 더 많은 선택들이 있다. 다수의 디바이스 및 시스템 ID들(심지어 이들의 일부는 액세스할 권한을 필요로 하지 않는다)에 의해 제공되는 일관성을 악용하여, 그들은 모두 일관되고 지속적으로 앱 사용자들을 추적할 수 있다. 앱들이 자신의 영구 스토리지를 통해 임의적으로 제어할 수 있기 때문에, 그들은 심지어 ID의 모든 유형을 필요로 하지 않는 사용자의 정보를 로컬로 수집을 허용할 수 있다.

사용자는 자신의 명시적 동의없이 자신의 앱 사용예의 링크를 허용하지 않아 개인 정보 보호를 할 수 있지만, 자신의 앱 사용예는 그가 원하는 (앱) 기능들을 달성하기 위해 링크해야 할 수 있다. 대부분의 애플리케이션들이 비 저장하도록 설계된 웹과 달리, 모바일 앱에 대한 클라이언트 측 솔루션은 앱의 원래 기능을 손상 할 가능성이 높다. 따라서, 클라이언트 측 솔류션은 개인 정보와 기능 사이의 유용한 트레이드 오프를 해야 한다. 이러한 근본적인 문제는 실제적인 솔루션이 사용할 수 있는 툴들이나 기술들의 설정을 상당히 감소시키고, 실제적인 설정에서 대부분의 기존 제안들을 효과가 없게 만든다.

마스크(MASK)의 설계의 기본적인 아이디어는 서로 간에 기본적으로 비링크로 유지하는 반면에 기능적으로 서로 의존하는 앱 사용예들만 링크되는 것을 허용하는 것이다. 이것은 현재 세션에서 앱 사용예들이 수집될 수 있는지와 어느 범위에서 수집될 수 있지는 앱 사용자가 명시적으로 동의한 개인 정보 실행 모드들의 세트들을 도입하므로 달성될 수 있다. 개인 실행 모드는 앱이 실제로 어떻게 사용되는지에 대한 관찰에 기초하여 도입되었다. 특히, 앱 사용예 패턴들은 앱 기능에서 요구되는 링크가능성(linkability)의 수준에 따라 먼저 분류되고 다음으로 이 앱 사용예 패턴들에 따라 다른 개인 실행 모드들을 도입한다.

마스크(MASK)에서, 사용자의 앱의 사용예의 기본 단위는 사용자 특정 기능을 달성하기 위해 사용자와 앱 사이 지속적인 활성의 일련의 상호 작용을 나타내는 세션이다. 안드로이드에서 이것은 일반적으로 생성과 파괴에 대한 함수 콜들의 호출들들 사이의 활동들(the activities between the invocations of function calls onCreate and on Destroy)에 대응한다. 세션의 지속 기간은 몇 초에서 몇 분에 이르기까지 상대적으로 짧다. 따라서, 단일 세션의 개인적인 정보는 매우 제한될 수 있으며, 따라서, 다른 제3자는 동일한 사용자의 다른 세션을 링크하고 수집하는 것이 어렵다(devoted).

마스크(MASK)는 다른 세션들에서 앱 사용예들이 링크될 수 있는지와 어느 범위에서 링크될 수 있는지에 따라 사용예 패턴들을 분류한다. 아래 소개되는 세가지 앱 사용예 패턴들-비지속(stateless), 일정 기간(durative) 및 독점(exclusive)-은 런타임 환경에서 일관성의 수준을 증가할 앱의 기능적인 니즈를 특징화한다.

비지속 패턴에서, 하나의 세션에서 사용자 활동은 다른 세션들의 상태나 정보에 크게 의존하지 않는다. 크게 의존하지 않으므로, 앱은, 이전 세션들로부터 어떤 정보없이, 선택적인 개인화 특성들을 감소하는 범위에서 주요 기능을 제공할 수 있다. 넓은 스펙트럼의 앱들은 이 패턴에 맞다.

가능한 옵션 맞춤 기능을 감소시키는 비용으로, 이전 세션에서 어떤 정보없이 주요 기능을 제공할 수 있다. 위키 백과나 옙프와 같은 유사 질의 앱들(querylike apps), 뉴욕 타임즈와 CNN와 같은 대부분의 뉴스 미디어 앱들, 두들 점프(Doodle Jumps)나 플래피 버드(Flappy Bird)와 같은 단순한 게임을 포함하는 넓은 스펙트럼의 앱들이 이 패턴에 맞다.

일정 기간 패턴에서, 사용자는 자신의 현재 활동을 수행하기 위해 지속적인 상태들과 앱의 장기 '기억'을 필요로 하지만, 자신의 실제 식별을 공개할 필요가 없다. 이 패턴은 노트-유지 앱들, 음악 플레이어, 북&잡지, 스토리 라인을 갖거나 (앵그리 버드 등과 같이) 비잠금될 필요가 있는 수준의 복잡한 게임들에 맞다.

독점 패턴에서, 사용자는 사용자 이름 또는 계정 ID와 같은 명시적으로 사용자 ID로 앱을 실행해야 하고, 동반된 개인 정보 보호 위험을 감수할 의사가 있어야한다. 이것은 페이스북이나 트위터와 같은 대부분의 소셜 앱들 뿐만 아니라 WhatApp, 야후 메신저 등을 포함하는 통신 앱들을 커버한다. 앱이 이 패턴에 맞으면, 대응하는 사용예들은 동일한 앱의 모든 세션에 걸쳐 링크될 수 있고 링크되어야 한다.

동일한 앱은 다른 사용예 패턴들로 실행될 수 있고 어떤 것을 결정하느냐는 사용자에게 달려 있다.

예시를 위해, 기본 시나리오는 현대의 모바일 OS, 예로써 안드로이드에서 제공된다. 앱은, 일반적으로 허가가 필요한 IMEI 또는 MAC와 같은 디바이스 ID들을 통하거나 모두 허가가 필요없는 SERIAL 번호나 안드로이드 ID와 같은 시스템 ID들을 통해 사용자를 추적할 수 있다. 앱이나 광고 라이브러리가 원하는 경우, 항상 쿠키를 자신의 로컬 스토리지로 내보내거나, 더욱 지속적으로 외부 스토리지로 내보낼 수 있다. 앱의 런타임에서 이러한 지속적인 앵커들이 공격자들이 앱들이나 세션들을 통해 사용예를 링크하고 수집하는 것을 허용한다. 그러나 사용자 관점에서, 이러한 링크가능성은 대부분의 앱 기능들에 대해 너무 강력하다.

비지속적으로 실행되는 앱들에 대해, 링크가능성은, 각 세션이 본질적으로 다른 것들과 독립적이기 때문에 가장 약한 형태에서 조차도 필요없다. 일정 기간 실행되는 앱들에 대해, 링크가능성은 동일한 앱의 사용예들(일부, 반드시 전부일 필요없음)에서만 필요하다-예를 들어 사용자가 동일한 앱을 사용하는 두개의 독립된 앨범들을 유지하기 바랄 수 있다. 독점적으로 실행되는 앱들에서 조차도 부가적인 개인 정보 문제들이 있다. 사용자가 로그인으로 앱을 실행할 때에, 이 앱 사용예들은 앱 내에 또는 동일한 로그인을 사용하는 대부분의 앱들 사이에서 링크될 수 있어야 한다. 아래 표 1은 이상적인 경우와 실제 사이 차이에 대한 개요를 제공한다.

[표 1]

비지속 패턴과 일정 기간 패턴은 앱 기능(링크가능성)과 개인 정보(비링크가능성) 사이 트레이드 오프에서 두 극단들을 나타낸다. 앱의 런타임 동안에 세션마다 또는 앱마다 분리를 제공하는 것이 트레이드 오프들을 달성할 수 있다. 그러나 일정 기간 사용예 패턴은 동일한 앱의 분리된 프로파일들이 하나의 디바이스에 적용할 수 있는 부가적인 요구를 갖는다. 이 방법에서, 앱의 사용예들은 각 프로파일 내에서 세션 설정(set-of-sessions)으로만 링크될 수 있다.

프로파일의 관리를 용이하게하기 위해, 마스크(MASK)는 콘텍스트 정보를 개인 정보 인에이블러(privacy enabler)로 사용한다: 위치, 시각, 네트워크 연결성 등과 같은 콘텍스트들의 다른 조합들은 다른 앱 시나리오들을 나타낼 수 있고 사용자 행동의 자연스러운 세그먼트로 사용될 수 있다. 예를 들어, 사용자는 밤에 집에서 오락 뉴스를 읽을 가능성이 높지만, 아침에 사무실에서 전문 기사를 읽을 수도 있다. 두개의 콘텍스트-기반 애플리케이션 시나리오들-집, 밤; 사무실, 아침-은 사용자의 오락 및 전문 관심 분야들을 구분할 뿐만 아니라, 상황-인지 커스터마이제이션(context-aware customization)의 가능성을 허용한다. 이러한 관찰에 기초하여, 마스크(MASK)는 콘텍스트-기반 프로파일들을 도입하고, 따라서 사용자가 다른 콘텍스트들에 따라 동일한 앱의 다중 분리된 인스턴스들(multiple isolated instances)을 유지할 수 있다.

링크가능성에 대한 사용자의 요구 사항을 이해하여, 사용자가 명시적 동의를 주는 직관적인 방법이 제공된다. 구체적으로, 마스크(MASK)는 개인 실행 모드들의 세트를 도입한다. 사용자가 앱을 시작할 때마다, 그는, 암시적으로 자신의 앱 사용예를 수집할 수 있는지 여부와 어느 범위 내에서 수집할수 있는지를 지정하여, 현재 세션에 적용할 모드를 선택할 수 있다.

예시적인 실시예로, 마스크(MASK)는 개인 실행 모드들의 세 가지 유형을 제공한다-식별 가능, 가명, 익명. 이들은 앞에서 정의한 세 사용예 패턴들에 매핑되고 사용자의 앱 사용예의 비링크 가능성의 증가 수준을 제공된다. 일반 사용자는 도메인-특정 알림없이, 몇 가지 간단한 규칙에 따르므로 이 결정을 내릴 수 있다. 특히, 앱이 실행을 시작하고 사용자가 원할 때:

● 앱이 자신의 진정한 식별들 중 하나를 사용할 때, 그는 식별 모드를 선택해야 한다. 동일한 로그인 하에서 모든 앱의 사용예들이 링크 가능한 것으로 가정하면, 마스크(MASK)는 관련이 없는 앱에서 수집를 허용하지 않는 경우에 비타협적 개인 서비스들(uncompromised personal services)을 제공할 수 있다.

● 이전에 저장된 상태들을 유지하거나 사용할 때, 그는 가명의 모드를 적용해야 한다. 이 모드에서, 사용자는 다중적인 상황 기반 프로파일들을 유지할 수 있고 동일한 프로파일에서 앱 사용예들만이 링크될 수 있다.

● 어떤 추적(trace)을 남기지 않고 이 앱을 실행할 때, 그는 익명 모드를 적용해야 한다. 각 세션이 독립적으로 처리되고 앱 용도가 현재 세션 내에서 제한된다.

실행 모드들의 다른 유형은 또한 본 개시에 의해 고려된다.

도 2는 마스크(MASK)의 설계에 대한 개요를 제공한다. 그 합리성이 앱 사용예 패턴들의 일반적인 개념에 뿌리를 두고 있기 때문에 이 설계는 특정 모바일 OS나 플랫폼에 제한되지 않는다. 마스크(MASK)의 구현의 다른 선택들은 성능, 강건성이나 실용성과 같은 다른 측면들에 중점을 둔다.

여기서 광고 대행사와 협력의 플랫폼 수준의 지원과 같은 다른 제3자에 어떤 비현실적인 의존성 또는 가정을 필요로 하지 않는, 구현 효율적 사용이 제시된다. 이것은, (1)고려하는 개인 정보 위협이 유행하고 긴급하게 처리될 필요가 있고 사용자가 바로 탈퇴하는 선택을 부여해야 하고, (2) 앞에서 설명한 바와 같이, 현재 모바일 앱 생태계에서 다른 제3자들 사이의 혼합된 장점이 존재하고 그 중 하나를 중요시하는 것(counting on)은 솔루션의 실용성을 저하시킬 수 있다. 이 원리에 의해 안내될 때, 마스크(MASK)의 클라이언트 측 프로토타입은, 예를 들어 안드로이드 상에서 사용자 수준에서 설명된다. 특정 기준이 안드로이드에 적용할 수 있는 기술을 특별히 참조할 때, 쉽게 동일하거나 유사한 기술들이 다른 운영 시스템에 적용될 수 있음을 쉽게 알 수 있다.

전술한 개인 실행 모드를 활성화하기 위해, 분리된 실행 환경이 제공된다. 실용성이 증명된 구현에서 우선 순위가 있고 사용자들이 맞춤 ROM(custom ROM)을 사용하거나 개인 정보 보호를 위해서 전적으로 자신들의 디바이스를 루트할 가능성이 낮기 때문에, 사용자-수준의 샌드 박스 구현(user-level sandbox implementation )이 사용된다.

이 일 구현 예에서, 동적 링크 프로세스는 프로그램 커스터마이제이션을 지원하기 위해 이용될 수 있다. 임의의 동적 링크 실행은 글로벌 옵셋 테이블(global offset table(GOT))로 알려진, 외부 함수 심볼들 및 대응하는 메모리 어드레스 사이의 맵핑을 유지한다. GOT의 엔트리들을 재작성함으로써, 외부 함수 심볼들에 대한 액세스는 사용자 - 특정 함수로 리디렉션할 수 있다. 이것은 사용자 수준에서 라이브러리 호출을 인터셉트하고 보안 및 개인 정보 기능들을 제공하는 것을 가능하게 한다.

이 사용자 수준의 기술은 두가지 목표들을 달성하기 위해 채택된다: 시스템 서비스와 앱들 사이의 프로세스 간 통신(inter-process communications(IPC))를 인터셉트하여 서버 측에서 수집할 수 있는 개인적이고 디바이스 식별 정보를 제거하는 것; 및 분리된 샌드박스 마다 스토리지를 제공하여 로컬(온 디바이스) 수집을 중단함.

도 3은 인터셉트 매카니즘의 개요를 제공한다. 운영 시스템에 의해 제공되는 앱(31) 및 서비스 시스템들(32) 간의 통신들은 인터셉터(33)에 의해 모니터링된다. 더욱 구체적으로, 요청은 앱(31)에 의해 범용의 통신 채널들을 통해 이루어진다. 이 요청은 인터셉터(33)에 의해 인터셉트되고 검사된다. 사용자를 식별하는 데 사용할 수 있는 정보에 대한 요청들은 인터셉트(33)에 의해 기록된다. 그 응답들에 포함되는 임의의 식별 정보는 이번에 앱(31)에 보내지기 전에 인터셉터에 의해 익명화된다. 이런 방법으로, 이러한 식별 정보는 앱(31)에 엑세스될 수 없고 따라서 서버 측에서 수집하기 위해 사용될 수 없다.

다음 설명을 위해, 인터셉터(33)는 다음과 같이 안드로이드 환경에서 구현될 수 있다. IPC는, 앱이 다른 프로세스들과 상호작용하고 정보를 교환할 수 있는 안드로이드에서 유일하게 지원되는 매카니즘이다. 인텐트들(intents)을 사용한 명시적인 통신이나 높은 수준의 API들을 사용한 시스템 서비스들로부터 정보를 획득하는 등의 암시적 통신은 이 IPC 매카니즘에 의해 지원된다. 앱이 얻을 수 있는 개인과 디바이스 식별 정보를 제거하기 위해 인터셉터는 앱과 다른 제3자들 사이 어떤 IPC들을 인터셉트하고 이해하고 식별할 수 있을 필요가 있다. 이것은 몇 가지 기술적인 문제를 제공하고 IPC가 안드로이드에서 작동하는 방법의 좋은 이해를 요구한다.

안드로이드에서, IPC의 설계, 바인더는 개념적으로 하나의 프로세스가 다른 프로세스 루틴을 호출할 수 있는 경량의 RPC 메커니즘이다. 그것은 두개의 컴포넌트들로 구성되어 있다: 사용자 공간에서 공유 라이브러리 libbinder.so 및 커넬 공간에서 바인더 드라이버. 이들은 bionic libc call ioctl을 통하여 바인더 프로토콜에 따라 서로 통신한다. 이러한 텐트 등 모든 높은 수준의 객체들은, 컨테이너 객체(Parcel)로 포장된 다음에 바이트 배열로 바인더 프로토콜을 통해 전송된다. libbinder.so에서 ioctl 함수 콜을 인터셉트함으로써, 인터셉터는 임의의 사용자-수준의 제어를 실행할 수 있다. 특히, libbinder.so의 GOT는 덮어 써져 ioctl 함수는 다음 래퍼 함수(wrapper function)로 리디렉션된다.

이 래퍼는 모두 수신 및 발신 통신을 인터셉트할 수 있고, 이들은 모두 목표를 달성하기 위해 필수적이다. 발신 트래픽을 인터셉트하는 것은 우리에게 이 앱이 무슨 요청을 전송하는지 알려주는 반면, 수신 트래픽을 인터셉트하는 것은 우리에게 리턴된 결과들을 변경할 수 있게 한다.

이 인터셉트 메커니즘의 상에서, 제어는 앱 내 또는 앱 간 통신뿐만 아니라 시스템 컴포넌트들과 앱의 상호 작용을 통해 부과될 수 있다. 여기서 안드로이드에서 식별 정보를 중앙 시스템 서비스에 의해 관리되기 때문에 초점은 후자의 경우이다. 표 2는 예시적인 실시예가 익명화화는 식별자들와 인터셉트가 필요한 대응하는 시스템 서비스들의 리스트를 요약한다.

[표 2]

예시적인 식별자는 운영 체제 (예를 들어, 안드로이드 ID)에 의해 할당된 식별자, 네트워크 인터페이스(예를 들어, MAC 어드레스)에 할당된 식별자, 버라이존이나 스프린트에 의해 할당된 가입자 식별자와 같은 통신 서비스 공급자와 연관된 식별자, 모바일 컴퓨팅 장치에 대한 식별자를 포함한다. 그것은 가장 일반적으로 사용되는 ID를 포함하지만, 모든 잠재적 식별 정보의 완벽한 리스트이지 않을 수 있다. 그러나, 연관된 기술적 토대는 다른 식별자를 포함하기에 충분히 일반적이다.

SERIAL 번호를 익명화하려고 할 때 몇 가지 추가 문제가 발생했다. 다른 ID를 달리, SERIAL 번호는 클래스 안드로이드에서 정적 변수로 내보내진다. 운영 체제는 샌드 박스가 시작 훨씬 전에 시스템 서비스에 의해 초기화된다. 마스크(MASK)는 같은 패키지 구조 하에서 동일한 이름의 변수를 선언함으로써 이 문제를 해결한다. 안드로이드의 최적화 덕분에, SERIAL 번호에 대한 모든 참조는 컴파일 시간 동안 우리의 섀도우 변수에 정적으로 다시 작성된다.

이 사용자의 앱 사용예의 로컬 수집을 방지하고, 또한 소프트웨어 쿠키의 일관성을 제거하기 때문에 각각의 샌드 박스에 대한 영구 스토리지를 분리하는 것이 필요하다. 도 4는 분리 방법의 개요를 제공한다. 앱(31)에 대한 분리된 실행 환경을 생성하는 동안, 이하에서 추가로 설명한 바와 같이 개인 정보 관리자(36)는 섀도우 디렉토리(37)를 생성한다. 앱에 의해 만들어진 파일 시스템 동작은 섀도우 디렉토리를 대응하는 앱-특정 디렉토리에서 리디렉션될 수 있다.

안드로이드는 영구 스토리지에 대한 다음과 같은 옵션을 제공한다: 공유 환경 설정(shared preferences); 내부 스토리지; 외부 스토리지 및 SQLite 데이터베이스. 이러한 스토리지 옵션 모두가 open, stat, MKDIR, chmod 등과 같은 Bionic Libc에 의해 제공되는 파일 시스템 프리미티브들 상에서 구축된다. 이러한 프리미티브들을 인터셉트하거나 대응하는 입력 파라미터들을 수정함으로써, 인터셉터 (33)는 앱의 파일 시스템과 상호 작용을 통해 임의의 컨트롤을 수행할 수 있다. 특히, 인터셉터(33)는 파일 시스템 동작들을 인터셉트하고 이들을 적용 가능한 섀도우 디렉토리들(37)로 리디렉션한다. 주어진 세션 동안, 섀도우 디렉토리(37)는 앱(31)에 액세스를 유지한다. 세션이 완료되면, 섀도우 디렉토리(37)는 앱(31)에 대한 실행 환경과 함께 파괴되고, 따라서, 컴퓨팅 디바이스의 앱에 의한 로컬 수집을 방지한다.

각 샌드 박스의 수명주기는 개인 정보 관리자에 의해 중앙에서 제어된다. 개인 정보 관리자는 각 샌드 박스에 대한 메타 파일을 유지하고, 각 샌드 박스는 샌드 박스-특정 파라미터들, 지정된 섀도우 디렉토리들에 대한 경로, 영구 식별자의 익명화된 값들 및 콘텍스트-기반 샌드 박스인 경우 연관된 콘텍스트 정보를 포함한다.

도 5는 샌드 박스는 개인 정보 관리자에 의해 생성하는 방법을 추가로 보여준다. 첫째, 모바일 앱의 사용자는 모바일 앱에 대한 실행 모드(또는 프로파일)가 시작되는 것을 지시하는 것을 51 단계에서 프롬프트된다. 예시적인 실시예에서, 사용자 인터페이스는 앱의 시작 활동(the launcher activity of the app)이 시작되기 직전에 표시되고 앱의 모든 다른 컴퍼넌트들로부터 분리된 독립된 프로세스로서 수행된다. 프롬프트에 대한 응답으로, 입력은 모바일 앱의 사용자로부터 개인 정보 관리자에 의해 52 단게에서 수신되고, 이 입력은 사용자에 의해 선택된 프로파일을 지시한다.

도 6a 내지 도 6c는 개인 정보 관리자에 의해 사용될 예시적인 사용자 인터페이스를 도시한다. 예시적인 실시예에서, 실행 모드는 식별 모드, 가명 모드 및 익명 모드로 이루어진 그룹으로부터 선택된다. 식별 모드와 익명 모드는 약간의 관리 오버 헤드가 발생하고 사용자는 단순히 이 두 가지 모드 중 하나를 클릭할 수 있다. 그러나, 익명 모드에서, 사용자는 동일한 디바이스에서 다중 프로파일들을 유지하기 쉽다. 예를 들어, 사용자는 직장에서 하나의 프로파일과 집에서 다른 프로파일을 사용하는 것을 선호할 수 있다. 이 경우에, 콘텍스트 정보는 인에블러가 다중 프로파일들을 관리하는 것을 돕도록 사용될 수 있다. 일부 실시예들에서, 스위치는 런타임에서 컨텍스트 엔진을 ON / OFF하기 위해 제공된다. 컨텍스트 스위치가 켜져있을 때, 콘텍스트 관리자는 자동으로 기존의 컨텍스트-기반의 프로파일들을 현재 컨텍스트와 매칭하고 어떤 프로파일이 가장 적합한지 추천한다. 도 6b에서, 두 번째 가명의 프로파일은 "Y"로 나타낸 바와 같이, 개인 정보 관리자에 의해 권장되고 있다.

익명의 프로파일을 생성할 때 사용자는 도 6c에서 볼 수 있듯이 현재 컨텍스트를 선택하라고 프롬프트된다. 이러한 방법으로, 사용자는 콘텍스트 정보의 그룹을 새로운 프로파일과 연관하고 컨텍스트 엔진에 의해 제공되는 자동 관리에 사용할 수 있다. 예시적 컨텍스트 정보는 다음을 포함할 수 있다 :

● 시간 : 밤 또는 낮;

● 위치 : (100m 내) 현재 위치;

● 활동 : 아직도, 산책 또는 운전;

● 와이파이 : 와이파이 액세스 포인트;

● 셀룰러 : true 또는 false

● 밝기 : 밝음 또는 어두움;

● 주변 : 조용함 또는 시끄러움.

또한, 콘텍스트 정보는 사용자의 앱 용도의 자연스러운 세그먼트(natural segmentation)로 사용할 수 있다. 예를 들어, 카메라 앱을 사용하는 경우, 집, 직장 또는 여행에 대해 다른 프로파일들을 유지하는 것은 사진들을 다른 카테고리들로 구분하는 것을 도울 수 있고 또한 콘텍스트-특정 커스터마이제이션(예를 들어, 플래시를 켜거나 특정 렌즈 설정을 사용할지 여부)을 허용한다. 다른 유형들의 콘텍스트 정보는 본 개시의 보다 넓은 양태에 속하는 것으로 쉽게 이해된다.

상기 콘텍스트-연관된 기능들을 지원하기 위해, 마스크(MASK)는 독립적 안드로이드 서비스로 구현될 수 있는 컨텍스트 엔진을 통합한다. 컨텍스트 엔진은, UI가 팝-업한 후 및 사용자가 명시적으로 컨텍스트 스위치를 켤 때에만 참여하기(engage) 시작한다. 컨텍스트 엔진에 의해 패치된 콘텍스트 정보는 기존의 컨텍스트-기반 정보와 매칭하거나 새로운 콘텍스트-기반 프로파일을 정의하는 데 사용된다. 콘텍스트 정보는, 사용자가 프로파일을 선택할 때까지 주기적으로(예를 들어, 매 초) 업데이트된다.

예시적인 실시예에서, 마스크(MASK)는 컨텍스트 정보를 이용하여 자동화의 특정 수준을 제공하지만, 사용자가 마스크(MASK)를 사용하는 것을 강제하지 않는다는 것을 유의해야 한다. 사용자는 항상 컨텍스트 엔진을 끄고 향상된 제어를 달성하기 위해 수동으로 이러한 앱-수준 프로파일들을 관리할 수 있다. 다른 실시예에서, 개인 정보 관리자는 자동으로 현재 컨텍스트와 매칭하는 가명의 프로파일을 구현하고, 모바일 앱 시작시에 사용자에 의해 명시적으로 선택을 포기한다.

도 5를 계속해서 참조하면, 개인 정보 관리자는, 앱의 실행 환경이 이미 사용자로부터 프로파일 선택을 수신하는 응답이 존재하는지 여부를 53 단계에서 결정한다. 애플리케이션이 아직 존재하지 않으면 실행 환경은 54 단계에서 생성된다. 실행 환경을 생성하기 위해, 개인 정보 관리자는 샌드 박스-특정 메타 파일을 생성하고 앱 섀도우 디렉토리를 예를 들어 로컬 스토리지 및/또는 SD 카드에 할당한다. 앱의 초기 상태들에 필요한 자원은 섀도우 디렉토리에 복사된다. 샌드 박스가 파괴 될 때, 개인 정보 관리자는 해당 메타 파일을 삭제하고 섀도우 디렉토리를 포함하는 샌드 박스에 지정된 로컬 스토리지를 삭제한다.

더욱 구체적으로는, 실행 환경의 생성은 프로파일 선택에 의존한다. 예를 들어, 익명의 프로파일이 주어진 어플리케이션에 대해 선택될 때, 예를 들어, 새로운 실행 환경은 주어진 애플리케이션의 각 세션에 대해 생성된다. 주어진 앱의 세션이 완료되면 그 후에 주어진 앱의 실행 환경이 개인 정보 관리자에 의해 파괴된다. 식별 가능한 프로파일은 주어진 어플리케이션에 대해 선택되면, 소정의 애플리케이션의 실행 환경은, 애플리케이션이 각각의 세션에 대해 동일한 실행 환경에서 실행되도록, 주어진 애플리케이션의 세션을 통해 개인 정보 관리자에 의해 유지된다. 익명의 프로파일이 주어진 어플리케이션을 선택하면, 소정의 애플리케이션의 실행 환경은 사용자로부터 수신된 실행 환경을 파괴하기 위해 명시적 명령까지 주어진 애플리케이션의 세션을 통해 개인 정보 관리자에 의해 유지된다. 즉, 사용자는 새로운 실행 환경을 생성하거나 기존 실행 환경을 재사용할지 여부를 선택할 수 있다.

다음으로, 개인 정보 관리자는, 55 단계에서 실행 환경에서 앱에 대한 인터셉트를 활성화한다. 인터셉터는 프로파일 선택에 의존하여 다르게 동작하도록 개인 정보 관리자에 의해 구성된다. 익명 프로파일에서, 인터셉터는 임의로 생성된 데이터로 모든 식별한 정보를 익명화할 뿐만 아니라 파일 시스템 동작들을 현재 세션의 마지막에 파과된 임시 데이터 스토리지로 리다이렉트한다. 식별 가능한 프로파일에 대해, 인터셉터는 어떤 식별한 정보를 익명화하지 않고 앱에 파일 시스템 동작들을 리다이렉트하지 않고, 그렇지 않으면 앱을 간섭하지 않도록(interfere with the app) 구성된다. 가명 프로파일에 대해, 인터셉터는 이 특정 프로파일에 고유한 식별자를 가지고 식별한 정보를 익명화하고 파일 시스템 동작들을 이 특정 프로파일에 고유한 임시 데이터 스토리지로 리다이렉트한다. 따라서, 가명 프로파일에서, 앱들은 동일한 프로파일 내에 링크되고 프로파일들을 통해 링크되지 않는다.

마지막으로, 애플리케이션은 실행 환경에서 56 단계에서 시작된다. 실행 동안, 인터셉터는 전술한 방식으로 시스템의 서비스에 대한 애플리케이션뿐만 아니라 파일 시스템 동작에 의한 요청을 모니터링한다. 애플리케이션의 세션이 완료한 후, 개인 정보 매니저는 실행 환경에 대한 제어를 재개하고 앱의 지정 실행 모드에 따라 환경을 유지하거나 파괴하는 적절한 조치를 취한다. 관련된 조치들만이 도 5와 관련하여 논의되었지만, 다른 소프트웨어-구현 지시는 개인 정보 매니저의 전반적인 동작을 제어하고 관리하기 위해 요구될 수 있음을 이해해야 한다.

하나의 프로세스만을 가진 앱에서, 샌드 박스에서 실행은 간단하다; 그러나 여러 프로세스들을 가진 앱에서, 샌드 박스에서 실행은 복잡할 수 있다. 각각의 실행 환경은 프로세스마다의 샌드 박스로 구현되고 안드로이드가 앱이 여러 프로세스들을 호스팅할 수 있기 때문에, 다른 프로세스들이 일치하지 않는 런타임 환경으로 실행하는 경우, 앱이 충돌한다. 따라서, 각각의 실행 환경은 멀티-프로세스 지원을 갖추고 있다. 앱 프로세스가 시작될 때마다, 개인 정보 관리자는 먼저 샌드 박스가 이미 이 앱에 대해 생성되었는지 (예를 들어, 이 앱의 로컬 스토리지에서 잠금 파일을 유지하여) 여부를 알려준다. 그렇다면, 새로운 프로세스가 기존 샌드 박스에 조인하고 동일한 런타임 환경을 공유할 것이다.

다음으로, 기술은 앱 패키지 파일(application package file(APK)) 재작성기를 사용하여 앱에 샌드 박스 컴포넌트를 끊김없이 병합하는 방법을 제시한다. 특히, apktool은 안드로이드 APK를, 샌드 박스 컴포넌드를 포함하는, 인간-판독 가능한 smali 코드들에 디컴파일하는 데 사용되고, 파일들을 실행 가능한 APK에 재컴파일하는 데 사용된다. 이것은 다음과 같은 두 가지 기술적인 문제를 도입한다.

먼저, APK 재작성기는 어떤 샌드 박스 구성 요소가 실행하기 전에 초기화되는 것을 확인할 필요가 있다. 이것은 글로벌 애플리케이션 상태를 유지하기 위해 안드로이드에 의해 제공되는 애플리케이션 베이스 클래스를 이용함으로써 달성된다. 이 베이스 클래스의 좋은 특성은 앱의 프로세스를 초기화되는 첫 번째 사용자-제어 컴포넌트라는 것이다. APK 재작성기는 앱의 기존 코드들을 통과하고(go throguh) 애플리케이션 베이스 클래스가 이미 존재하는지 여부를 검사한다. 베이스 클래스가 존재하면 기존의 애플리케이션 베이스가 수정되고, 그렇지 않으면 애플리케이션 베이스가 직접 삽입된다. 샌드 박스 초기화 로직이 애플리케이션 베이스 클래스의 정적 코드 섹션에 프로그래밍되고 실행하는 첫번째인 것이 보장된다.

둘째, 앱에 통합된 모든 UL 엘리먼트들은 범용 고유 id로 참조되고 res/values/ids.xml 및 res/values/public.sml 하에서 인덱스된다. 새로운 엘리머트들을 기존 앱에 통합하기 위해, APK 재작성기가 빈 슬롯을 자동으로 추적하고 기존의 ID들 내에서 할당한다. 또한, APK 재작성기는, UI가 완성된 후(after the US cuts in line)에 제어가 앱에 반환되는 것을 보장할 필요가 있다. 그것은 매니페스트 파일(manifest file)을 통과하고, 앱 시작 활동(the app launcher activity)을 식별하고 통계적으로 시작 활동에 대한 초기화 로직을 OnDestroy 함수들에 작성하여 작동할 수 있다. 마지막으로, APK 재작성기는 앱이 호스트하는 프로세서들의 리스트를 얻을 수 있도록 매니페스트 파일을 파싱한다. 이 멀티 프로세스 앱의 경우, 이 정보는 여러 프로세스에 대한 마스크(MASK)의 지원을 활성화하기 위해 개인 정보 관리자의 smali 코드에 하드 코딩된다.

마스크(MASK)는 성능 오버 헤드의 두 가지 유형을 초래한다: 샌드 박스가 생성되고, 파괴되고 실행될 때; 및 애플리케이션 런타입 동안, 앱이 사용자 선택의 샌드 박스에서 실행을 시작한 후에 샌드 박스의 관리 상으로. 샌드 박스 관리의 오버 헤드는 마스크(MASK) 및 타이머들로 테스트 앱을 인스트루먼트에 의해 측정된다. 선택된 샌드 박스 관리 태스크들을 수행하고 이 타이머의 출력을 기록한다.

[표 3a]

표 3a의 결과가 보여지는 바와 같이, 샌드 박스 관리에서 가장 시간이 많이 걸리는 액션들은 UI를 로딩하고 샌드 박스를 실행하는 것으로, 각각 수백 밀리 초가 걸린다. 그러나, 이 액션들은 세션 중에 한 번만 발생하기 때문에 샌드 박스 관리에 누적 오버 헤드는 여전히 마이너(작음)하다.

마스크(MASK)가 프로세스 간 통신(IPC) 및 파일 시스템 동작을 인터셉트할 때 앱 런타임에서 오버 헤드는 마스크(MASK)의 사용자 - 수준 샌드 박스 컴포넌트로부터 유래한다. 파일 시스템 동작을 리디렉션하여 발생하는 오버 헤드를 측정하기 위해, 벤치 마크 앱(benchmark app) AndroBench는 안드로이드 디바이스들에서 스토리지 성능 측정을 위해 설계되도록 선택되었다. AndroBench에 포함되는 테스트 벤치들(test benches) 외에, 두개 이상의 테스트들이 파일의 생성 및 삭제 성능을 측정하였다. 각각의 테스트 벤치는 10번 마스크(MASK)를 활성화 및 비활성화로 실행된다. IPC들의 인터셉트로 인한 오버 헤드를 평가하기 위해, IPC들의 필터링 및 재포맷 각각에 의해 발생하는 오버 헤드를 측정하는 두 개의 테스트 벤치를 포함하는, 합성된 벤치 마크가 사용되었다. IPC 필터링은, 우리가 흥미를 가진 IPC들, 예를 들어 디바이스 ID를 얻기(such as getting device ID)를 우리가 흥미를 갖지 않는 IPC들, 예를 들어 위치 업데이트들을 얻기(such as getting location updates,)와 구별하는 반면에, IPC 재포맷은 낮은 수준 이진 시퀀스를 높은 수준의 객체들에 재구성하고 해당 영구 식별자들을 수정한다. IPC 필터링은 앱 및 다른 제3자들 사이의 IPC에 오버 헤드가 발생하는 반면에, IPC의 재포맷 오버헤드는 개인 또는 디바이스 식별 정보를 앱에 반환하는 IPC들에 대해서만 발생된다.

[표 3b]

TPS: 초당 트랜잭션들(Transactions Per Second)

애플리케이션 런타임 오버 헤드에 결과가 표 3b에 요약되어 있다. 발생하는 유일한 오버 헤드가 앱의 원래 스토리지에 경로를 샌드 박스의 섀도우 스토리지에 경로로 변환하는 것이 때문에 파일 시스템 동작들의 성능 저하는 마이너하다. 이 변환은 파일 시스템들에 비효하여 매우 가볍다. 그것은 또한 IPC 필터링 오버 헤드는 무시할 수 있음을 발견하고, 마스크(MASK)가 가장 "관심 없는" IPC 콜들의 성능에 영향을 주지 않는다는 것을 의미한다. 대조적으로,바이트 어레이를 높은 수준 객체들, 예를 들어 자바 오브젝트들로 파싱하는 것이 비싸기 때문에, IPC 재포맷 오버 헤드가 의미가 있다(이상 37 %). 그러나 모든 IPC들을 단지 매우 작은 부분을 재포맷하기 때문에- 단지 이들이 영구 식별자를 반환함- 전체적인 성능 저하는 무시해도 된다.

마스크(MASK)가 용도 패턴들(독점, 일정 기간 또는 비지속 패턴들)에 따라 서로 다른 모바일 애플리케이션에 다른 개인 실행 모드를 적용하여, 증가된 수준의 개인 정보 보장을 제공한다. 여기서, 구글 플레이에서 상위 200개의 무료 앱이 연구되었고, 도 10에 도시된 바와 같이 각 앱들에 가장 맞는 앱 사용예 패턴에 따라 분리되고 다음으로 그 숫자를 각 기능적 카테고리로 나누었다. 요약하면, 앱들의 29 %는 비지속적(stateless)이고 43 %가 일정 기간(durative)이고 25 %는 독점적(exclusive)이다. 마스크(MASK)는, 파일 탐색기, 안티 바이러스 소프트웨어 등 시스템 용도를 위해 설계된 앱들을 제외하고 모든 앱의 97 %에 적용될 수 있다. 이들 앱들을 기능적으로 샌드 박스하는 것은 그들의 기능들을 위반하고 예상치 못한 결과 또는 심지어 충돌을 야기할 수 있다. 또한, 카테고리마다의 분리(the per-category breakdown)로부터, 마스크(MASK)가 게임, 독서 및 정보 조회에 사용되는 앱들에 보다 잘 작동하나, 사회적, 금융 및 통신에 사용되는 앱들로 도움이 되는 것은 아니다.

다른 개인 정보 강화 패러다임처럼, 실제로 개인 정보의 개선을 정량적으로 보여주기 위해 도전하고 있다. 다른 공격자들은 매우 다른 방식들로 수집된 정보를 결합하고, 처리하고 사용할 수 있고; 어떤 마스크(MASK)가 '개인 정보'의 관점에서 실제로 제공하느냐 하는 것은, 예를 들어 공격자들은 어떤 종류 정보에 흥미를 가지고 있는지와 사용자가 이 정보에 대해 얼마나 민감하는지와 같은 특정 콘텍스트에 의존한다. 따라서, 개인 정보 강화에 대한 일반적인 주장을 하는 대신에, 이 평가는 다른 시나리오에서 앱 세션을 링크하거나 해제하는데 마스크(MASK)의 효과를 제공한다. 구체적으로 마스크(MASK)가 적용되는 경우에 수집될 수 있는 앱 사용예(세션, POI들 등)가 얼마나 감소될 수 있느냐를 보여준다.

이 상세한 앱 사용예 및 6 개월 이상 33개의 스마트폰 사용자들의 위치 추적을 포함하는 LiveLab 데이터 세트를 연구하였다. 추적들에서 상위 30개의 비시스템 앱이 평가를 위해 선택되었다. 마스크(MASK)의 개인 실행 모드의 효과를 기대할 수고 확실하기 때문에, 우리는 상위의 현실 세계의 추적들에 마스크(MASK)의 기대되는 효과들을 놓고 마스크(MASK)가 야생에서 다양한 제3자에 의한 규제되지 않은 수집을 얼마나 감소하는지 조사할 수 있다.

모바일 앱은 전문 기능을 제공하고 도메인- 특정 사용자 프로파일에 관심이 있다. 여기에, 세 가지의 대표 모바일 앱 및 스레드 시나리오를 연구하였다

● 구글 지도 : POI들(point of interests)을 수집하는데 관심이 있는 지도 서비스

● 유튜브 : 사용자가 열람하는 비디오 콘텐츠를 수집하는데 관심이 있는 온라인 비디오 앱((YouTube에 소요되는 시간에 비례)

● 옐프 : 검색 질의들을 수집하는데 관심이 있는 식당 추천 앱(그 수는 앱 세션의 수에 비례)

구글 지도는 각 사용자의 위치 정보에 대해 액세스를 하며, 따라서 각 사용자의 관심 지점(POI들)을 수집할 수 있다. 그러므로, 적어도 세 개의 세션의 특정 위치에서 사용자를 관찰하는 경우, 공격자는 POI를 사용자에 연결할 수 있다고 가정한다. (어떤 보호없이) 기본 시나리오에서 구글 지도는 각 사용자에게 평균 27개의 POI들을 연결할 수 있다.

다음으로, 마스크(MASK)가 적용되는 경우를 고려한다. 사용자가 식별 모드를 적용하면, 앱 사용예는 동일한 앱와 링크될 수 있고, 따라서 마스크(MASK)는 기본 시나리오에 비교하여 추가적인 이점을 제공하지 못한다. 사용자가 다중 컨텍스트-기반의 프로파일들로 가명 모드를 적용하며 앱의 사용예들은 동일한 프로파일 내에서만 링크될 수 있다. 예를 들어, 각 사용자가 세 가지 콘텍스트 기반 프로파일들(평일 낮, 평일 밤과 주말)를 유지하는 것으로 가정하면, 공격자는 평균 15개의 POI들을 각 사용자에 링크할 수 있을 뿐이다. 사용자가 익명 모드를 적용하면, 앱 사용예는 하나의 세션 내에서만 링크될 수 있다: 하나의 앱 세션의 정보는, 공격자가 사용자의 POI에 대한 추측을 하기에 너무 적기 때문에, 수집 가능한 앱 사용예(POI들)는 0으로 떨어진다. 도 8a은 사용자가 다른 실행 모드들을 구글 지도에 적용할 때 수집 가능한 앱 사용예(POI들)의 CCDF를 보여준다.

구글 지도의 경우와 유사하게, 유튜브 및 옐프에 대한 마스크(MASK)의 효과가 연구되었다. 유튜브에 대해 앱 사용예가 비디오를 시청하는 데 소요되는 시간에 비례한다고 가정한다; 옐프에 대해, 앱의 사용예는 사용자가 옐프를 여는 횟수에 비례하는 것으로 가정한다. 평균적으로, 세 가지 간단한 프로파일들(평일 낮, 평일 야간, 주말)은 유튜브에 대해 45 %와 옐프에 대한 44 %로 수집할 수 있는 앱 사용예를 줄일 수 있다; 가명 모드에서 진행되는 평균의 감소는 85 % 및 84 %만큼 높을 수 있다. 도 8b 및 8c는 각각 유튜브와 옐프에 대해 다른 실행 모드에서 수집할 수 있는 앱 사용예들의 분포를 제공한다.

도시된 바와 같이, 다른 개인 실행 모드가 다른 수준의 보호를 가져온다. 한 사용자는 유튜브에 의한 개인화된 추천을 좋아하고 항상 로그인을 유지하고 싶어 할 수 있다; 다른 사용자가 이러한 추천을 싫어하고 히려 익명으로 이 서비스를 사용할 수 있다. 다음 평가로, 사용자들이 개인 정보에 민감한 것으로 가정한다: 이들은, 이 앱의 핵심 기능을 훼손하지 않는 한 항상된 개인 정보를 제공하는 실행 모드를 항상 적용한다.

광고 대행사는 사용자의 관심 분야 및 인구 통계의 다양한 스펙트럼에 관심이 있고, 동일한 광고 라이브러리를 공유하는 앱들을 통해 앱 사용예들을 수집할 수 있다. 여기서, 그들은 유사한 방식으로 사용자를 추적하고 그들이 수집하는 앱 사용예는 그들이 추적하는 앱 세션들의 수에 비례한다고 가정한다. 여기, 세 가지 대표적인 광고 및 분석 기관 대행사들-(평가를 위해 선택한 30개의 앱들 중) 9개, 10개 및 6개의 모바일 앱들에 포함되는 Flurry, Millennial and InMobi-을 연구했다.

도 9는 마스크(MASK)가 적용되기 전후의 수집 가능한 앱 세션들의 분포를 나타낸다. 마스크(MASK)에서 평균 감소는 Flurry에 대해 69 %, Millennial 에 대해 47 %와 InMobi에 대한 36 %이다. 이것은 서로 기능적으로 의존하지 않는 앱 사용예를 링크하지 않는 개인 정보 보호의 이익을 의미한다. 도 9c에 주의하는 바와 같이, 상위 소수의 사용자의 수집 가능한 앱의 용도예들은 마스크(MASK)가 적용되는 후 약간 줄일 수 있다. 이것은 다음과 같은 이유 때문이다: 1)사용자들이 집중적으로 하나의 앱을 사용함 (InMobi이 수집할 수 있는 세션의 90 % 이상이 동일한 앱으로부터 옮), 2)이 앱이 사용자에게 로그인을 강요함. 이것은 마스크(MASK)가 이 앱 세션들을 추가로 링크하지 않는 것을 불가능하게 만든다. 이 평가에서 이러한 킬러 애플리케이션의 예는 WordsWithFirends이다- 그것은 여러 추적 라이브러리들을 포함하고 사용자들이 그들의 진짜 식별을 노출하도록 강제한다.

이 네트워크 스니퍼에 대해, 공격자는 MOSAIC(Mosaic)와 유사한 방법론을 채용하고있는 것으로 가정한다: 그것은 동일한 사용자의 ID들을 연관하고(correlate) 그 기능을 향상시키기 위해, 셀룰러 IP의 시간적 일관성을 이용할 수 있다. 단순화하기 위해, 네트워크 스니퍼는 IP, 앱 특정 ID 및 광고 네트워크 ID를 관찰할 수 있는 것으로 가정한다.

도 10은 기본 시나리오에서, 네트워크 스니퍼는, 짧은 기간(예를 들어, 60초) 내에서 동일한 IP로 노출되는 ID들를 연관하여 대부분(85%)의 암호화되지 않은 앱 세션들을 식별 및 링크할 수 있다. 그러나, 이 기술은 마스크(MASK) 하에서 훨씬 덜 강력하다. 공격자들이 어떤 거짓-양성없이(without any False-Positives) ID들을 연관시킬 수 가정하더라도 마스크(MASK)가 네트워크 스니퍼에 대항한 평균 감소는 69 %이다. 이것은 마스크(MASK) 하에서, 앱 사용예들은 훨씬 세분화된 조각으로 분해되고 IP가 제공하는 일관성이 대부분을 링크하기에 충분히 강하지 않기 때문입니다.

예시적인 실시예는, 악의적인 자에 대한 정보의 액세스 제어를 강제하는 대신에, 정직하지만 호기심 많은 공격자들에 의한 규제되지 않는 수집의 개인 정보 위협에 대응하기 위해 설계되었습니다. 따라서, 무결성, 특히 사용자 수준 구현은, 공격자가 모바일 OS를 침투하거나 우회하면 훼손될 수 있다. 그러나, 마스크(MASK)는 이러한 제한들을 제고하기 위해 커널의 일부 또는 안드로이드 맞춤 ROM(Android custom ROM)으로 구현될 수 있다는 것을 구상한다.

이러한 IP 또는 위치와 같은 다른 가명 식별자들(quasi-identifiers)은, 동일한 사용자의 앱 사용예를 링크하는데 사용될 수 있다. 그러나, 마스크(MASK)에서 설명된 명시적 식별자들(explicit identifiers)에 비해, 이들은 훨씬 덜 일관되고 신뢰할 수 있다. 따라서, 이들은 일반적으로 추가적인 거짓-양성의 비용에서 추적 범위를 증가하기 위해 명시적인 식별자를 함께 사용하고 있다. 그러나, 마스크(MASK)가 사용자의 앱 사용예들을 흩어지고 분리된 조각들(scattered and isolated pieces)로 세그먼트한 후, 가명 식별자들은 도움이 되지 않을 수 있다. 위 평가에 나타낸 바와 같이, 네트워크 스니퍼는 IP의 일관성을 악용하려고 할 때조차, 마스크(MASK)는 수집 가능한 앱 사용예들을 충분히 줄일 수 있다.

모바일 사용자들의 개인 정보를 개선하기 위해 설계하지만, 마스크(MASK)는 앱 개발자의 이익을 침해하는데 악용될 수 있는 자체 부작용이 있다. 사용자 프로파일을 제외하고, 최종 사용자의 식별은 또한 저작권 보호와 같은 다른 목적을 위해 요구된다. 일부 유료 앱은 일정 기간 동안 무료 평가판 사용을 위해 배포된다. 지속적으로 무료 평가판 앱을 활용하지 못하도록 하기 위해, 앱 개발자는 무료 평가판을 이미 경합한 사용자들을 식별하고 추적할 필요가 있다. 영구 식별자들 및 시스템 파라미터들을 익명화하는 능력이 주어졌으므로, 마스크(MASK)는 확인 프로세스를 생략할 수 있다.

여기에 기재된 기술들은 하나 이상의 프로세서에 의해 실행되는 하나 이상의 컴퓨터 프로그램에 의해 구현될 수 있다. 상기 컴퓨터 프로그램은 비일시적 컴퓨터 판독 가능 매체(non-transitory tangible computer readable medium)에 저장된 프로세서- 실행 가능 명령을 포함한다. 또한 컴퓨터 프로그램은 저장된 데이터를 포함할 수 있다. 비 일시적인 유형의 컴퓨터 판독 가능한 매체의 비제한적인 예들은 비휘발성 메모리, 자기 스토리지 및 광학 스토리지이다.

상기 설명의 일부분은 알고리즘이나 정보에 대한 동작들의 심볼 표현(symbolic representations)의 관점에서 본 명세서에 기재된 기술을 제시한다. 이 알고리즘 설명들과 표현은 가장 효과적으로 다른 당업자에게 작업의 실체를 전달하기 위해 데이터 처리 분야의 당업자에 의해 사용되는 수단이다. 기능적 또는 논리적으로 설명되었지만 이 동작은 컴퓨터 프로그램에 의해 구현되는 것으로 이해된다. 더욱이, 일반성의 상실하지 않고 모듈로서 동작들의 이러한 배치들을 언급하거나 기능적 명칭을 언급하는 것이 시간으로 편리하다는 것이 입증되었다. 주어진 모듈 내에서 동작들의 그룹이 제한되지 않고, 동작들이 여러 개의 모듈 사이에 공유되거나 하나의 모듈로 결합될 수 있다고 이해된다.

구체적으로 상기 논의로부터 명백하게 구체적으로 반대로 기술되지 않는 한, 명세서를 통해 "처리"또는 "연산" 또는 "계산" 또는 "결정" 또는 "표시" 등과 같은 용어들을 사용하는 논의들은 컴퓨터 시스템 또는 컴퓨터 시스템 메모리 또는 레지스터 또는 다른 이러한 정보 저장 장치, 전송 또는 디스플레이 장치 내에서 물리적 (전자적) 물량으로서 표현된 데이터를 조작하고 변환하는, 유사한 전자 제어 유닛의 액션 및 프로세스들을 의미하는 것으로 이해된다.

설명된 기술들의 특정 측면들은 알고리즘의 형태로 본 명세서에 기재된 프로세스 단계들 및 지시들을 포함한다. 전술한 공정들 및 지시들은 소프트웨어, 펌웨어 또는 하드웨어로 구현될 수 있고, 소프트웨어에서 구현되는 경우에 다운로드되어 상주하거나 실시간 네트워크 운영 시스템에 의해 사용되는 다른 플랫폼으로부터 동작될 수 있음을 주목해야 한다.

또한 본 개시는 본 명세서에서 동작들을 수행하는 장치에 관한 것이다. 이 장치는 필요한 목적을 위해 특별히 구성되거나, 또는 선택적으로 활성화되거나 컴퓨터에 의해 액세스 될 수 있는 컴퓨터 판독 가능 매체에 저장된 컴퓨터 프로그램에 의해 재구성될 수 있는 컨트롤러를 포함할 수 있다. 이러한 컴퓨터 프로그램은 그 자체로 실체적인 컴퓨터 판독 가능한 저장 매체, 제한되지 않고 예를 들어, 플로피 디스크를 포함하는 어떤 형태의 디스크, 광 디스크, CD-ROM, 자기-광학 디스크, 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), EPROM, EEPROM, 자기 또는 광 카드, 주문형 집적 회로 (ASIC), 또는 전자 지시를 저장하기에 적합한 기타 유형의 매체에 저장될 수 있다. 또한, 본 명세서에서 참조된 컴퓨터는 단일 프로세서를 포함하거나 증가된 컴퓨팅 능력을 위한 다중 프로세서 설계를 채용한 아키텍처일 수 있다.

본 명세서에 제시된 알고리즘들 및 동작들은 본질적으로 임의의 특정 컴퓨터 또는 다른 장치에 연관된 것이 아니다. 다양한 전자 제어 유닛은 본 명세서의 교시에 따른 프로그램과 함께 사용될 수 있으며, 또는 요구된 방법 단계들을 수행하도록 보다 특화된 장치를 구성하는 것이 편리하다는 것을 증명할 수 있다. 이러한 다양한 시스템에 필요한 구조는 상응하는 변경과 함께 당업자에게 명백할 것이다. 또한, 본 개시는 임의의 특정 프로그래밍 언어를 참조하여 설명되지 않는다. 다양한 프로그래밍 언어가 본 명세서에서 설명된 본 개시의 교시를 구현하는데 사용될 수도 있다.

전술한 실시예들에 대한 설명은, 예시와 설명의 목적으로써 제공된 것이다. 발명을 고갈시키거나(exhaustive) 제한시킬 목적이 아니다. 특정 실시예의 개개의 구성요소들 또는 형상들(features)은 일반적으로 특정 실시예로 제한되지 않지만, 적용되는 경우, 구체적으로 도시되거나 설명되지 않았더라도, 선택된 실시예에 교환가능하거나 사용가능하다. 또한 많은 방식으로 변경될 수 있다. 이러한 변경들(variations)은 본 발명에서 이탈된 것으로 간주되지 않고, 모든 그러한 수정사항들(modifications)은 발명의 범위 이내에 포함되는 것이다.

Claims (18)

1. 개인 정보 관리자에 의해, 각각 상기 모바일 컴퓨팅 디바이스에서 다른 분리된 실행 환경을 나타내고 연관된 실행 환경에서 실행될 때 애플리케이션을 지배하는(governing) 개인 정보 규칙들의 세트를 정의하는 프로파일들의 세트들을 관리하는 단계;
   상기 개인 정보 관리자에 의해, 사용자가 상기 모바일 컴퓨팅 디바이스에서 실행 환경에서 소정의 애플리케이션(a given of an application)의 실행 이전에 상기 소정의 어플리케이션에 대한 프로파일을 지시하도록 유도하는 단계;
   상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션의 사용자로부터, 상기 프로파일들의 세트로부터 선택된 프로파일을 지시하는, 입력을 수신하는 단계; 및
   상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션의 실행 동안에 선택된 프로파일과 연관된 상기 개인 정보 규칙들의 세트를 상기 소정의 애플리케이션에 적용하는 단계를 포함하며, 상기 개인 정보 관리자는 상기 모바일 컴퓨팅 디바이스의 프로세서에 의해 실행되는 컴퓨터 판독 가능한 명령들에 의해 구현되는,모바일 컴퓨팅 디바이스에서 실행되는 애플리케이션들에 의해 동작 추적을 제어하는 방법.
2. 제 1 항에 있어서,
   상기 개인 정보 관리자에 의해, 선택된 프로파일과 연관된 상기 개인 정보 규칙들의 세트에 따라 인터셉터를 구성하는 단계 및
   상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션의 실행 환경에서 상기 인터셉터를 시작하는(launching) 단계를 추가로 포함하는 방법.
3. 제 1 항에 있어서,
   상기 프로파일은 식별 프로파일(identifiable profile), 가명 프로파일(pseudonymous profile) 및 익명 프로파일(anonymous profile)로 이루어진 군에서 선택된 방법.
4. 제 3 항에 있어서,
   상기 개인 정보 관리자에 의해, 상기 익명의 프로파일이 상기 소정의 애플리케이션을 위해 선택되고 상기 소정의 애플리케이션의 세션의 완료시, 상기 소정의 애플리케이션에 대한 실행 환경을 파괴하는 단계를 추가로 포함하는 방법.
5. 제 3 항에 있어서,
   상기 개인 정보 관리자에 의해, 상기 식별 프로파일이 상기 소정의 애플리케이션을 위해 선택될 때 상기 소정의 애플리케이션의 세션을 통해 상기 소정의 애플리케이션에 대한 실행 환경을 유지하는 단계를 추가로 포함하는 방법.
6. 제 3 항에 있어서,
   상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션의 세션을 통해 상기 소정의 애플리케이션에 대한 실행 환경을 유지하는 단계 및 상기 가명의 프로파일이 상기 소정의 애플리케이션을 위해 선택될 때 상기 소정의 애플리케이션의 사용자로부터 명시적 코멘트에 대한 응답으로 상기 소정의 애플리케이션에 대한 실행 환경을 파괴하는 단계를 추가로 포함하는 방법.
7. 제 3 항에 있어서,
   콘텍스트 엔진에 의해, 상기 모바일 컴퓨팅 디바이스에 대한 컨텍스트 데이터를 결정하는 단계; 및
   상기 콘텍스트 엔진에 의해, 상기 사용자가 프로파일을 지시하도록 유도하는 경우에 가명 프로파일들의 그룹으로부터 특정 가명 프로파일을 추천하는 단계를 추가로 포함하는 방법.
8. 제 3 항에 있어서,
   콘텍스트 엔진에 의해, 상기 모바일 컴퓨팅 디바이스에 대한 컨텍스트 데이터를 결정하는 단계;
   상기 콘텍스트 엔진에 의해, 상기 콘텍스트 데이터에 기반하여 가명 프로파일들의 그룹으로부터 특정 가명 프로파일을 선택하는 단계; 및
   상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션의 실행 동안 상기 특정 가명 프로파일과 연관된 개인 정보 규칙들의 세트를 적용하는 단계를 추가로 포함하는 방법.
9. 개인 정보 관리자에 의해, 각각 상기 모바일 컴퓨팅 디바이스에서 다른 분리된 실행 환경을 나타내고 연관된 실행 환경에서 실행될 때 애플리케이션을 지배하는(governing) 개인 정보 규칙들의 세트를 정의하는 프로파일들의 세트들을 관리하는 단계;
   상기 개인 정보 관리자에 의해, 사용자가 상기 모바일 컴퓨팅 디바이스에서 소정의 애플리케이션(a given of an application)의 실행 이전에 상기 소정의 어플리케이션에 대한 프로파일을 지시하도록 유도하는 단계;
   상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션의 사용자로부터, 프로파일들의 세트로부터 선택된 프로파일을 지시하는, 입력을 수신하는 단계; 및
   상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션의 실행 환경에서 인터셉터를 시작하는 단계;
   상기 인터셉터에 의해, 상기 모바일 컴퓨팅 디바이스의 운영 시스템(operating system)에 의해 제공되는 시스템 서비스들에 대한 상기 소정의 애플리케이션에 의해 만들어진 요청들(requests)을 모니터링하는 단계;
   상기 인터셉터에 의해, 상기 소정의 애플리케이션의 사용자에 대한 식별 정보를 제공하는 요청을 식별하는 단계; 및
   상기 인터셉터에 의해, 식별 요청들에 대한 응답들에 포함된 식별 정보를 익명화하는(anonymizing) 단계를 포함하며, 상기 개인 정보 관리자 및 상기 인터셉터는 상기 모바일 컴퓨팅 디바이스의 프로세서에 의해 실행되는 컴퓨터 판독 가능한 명령들에 의해 구현되는, 모바일 컴퓨팅 디바이스에서 실행되는 애플리케이션들에 의해 동작 추적을 제어하는 방법.
10. 제 9 항에 있어서,
    상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션에 대한 실행 환경의 존재를 결정하는 단계로, 상기 결정은 상기 사용자로부터 입력을 수신한 것에 대한 응답으로 발생함; 및
    상기 개인 정보 관리자에 의해, 상기 선택된 프로파일에 따라 상기 소정의 애플리케이션에 대한 실행 환경을 생성하는 단계를 추가로 포함하며, 상기 생성은 상기 소정의 애플리케이션에 대한 실행 환경이 부존재하다(non-existent)는 결정에 대한 응답으로 발생하는 방법.
11. 제 10 항에 있어서,
    상기 선택된 프로파일에 대해 상기 연관된 실행 환경에서 상기 소정의 애플리케이션의 실행을 시작하는 단계를 추가로 포함하는 방법.
12. 제 9 항에 있어서,
    상기 인터셉터에 의해, 상시 소정의 애플리케이션에 의해 만들어진 파일 시스템 동작들을 인터셉트하는(intercepting) 단계; 및
    상기 파일 시스템 동작들을 상기 소정의 애플리케이션에 대한 실행 환경과 연관된 임시 데이터 스토리지(transient data store)로 리디렉션하는(redirecting) 단계를 추가로 포함하는 방법.
13. 제 9 항에 있어서,
    상기 프로파일은 식별 프로파일(identifiable profile), 가명 프로파일(pseudonymous profile) 및 익명 프로파일(anonymous profile)로 이루어진 군에서 선택된 방법.
14. 제 13 항에 있어서,
    상기 개인 정보 관리자에 의해, 상기 익명의 프로파일이 상기 소정의 애플리케이션을 위해 선택되고 상기 소정의 애플리케이션의 세션의 완료시, 상기 소정의 애플리케이션에 대한 실행 환경을 파괴하는 단계를 추가로 포함하는 방법.
15. 제 13 항에 있어서,
    상기 개인 정보 관리자에 의해, 상기 식별 프로파일이 상기 소정의 애플리케이션을 위해 선택될 때 상기 소정의 애플리케이션의 세션을 통해 상기 소정의 애플리케이션에 대한 실행 환경을 유지하는 단계를 추가로 포함하는 방법.
16. 제 13 항에 있어서,
    상기 개인 정보 관리자에 의해, 상기 소정의 애플리케이션의 세션을 통해 상기 소정의 애플리케이션에 대한 실행 환경을 유지하는 단계 및 상기 가명의 프로파일이 상기 소정의 애플리케이션을 위해 선택될 때 상기 소정의 애플리케이션의 사용자로부터 명시적 코멘트에 대한 응답으로 상기 소정의 애플리케이션에 대한 실행 환경을 파괴하는 단계를 추가로 포함하는 방법.
17. 제 9 항에 있어서,
    상기 소정의 애플리케이션의 사용자에 대한 식별 정보는, 상기 운영 시스템에 의해 할당된 식별자, 네트워크 인터페이스에 의해 할당된 식별자, 통신 서비스 공급자와 연관된 식별자 및 상기 모바일 컴퓨팅 디바이스에 대한 식별자를 포함하는 방법.
18. 제 9 항에 있어서,
    상기 시스템 요청들을 모니터링하는 단계는 상기 운영 시스템에 의해 지원되는 프로세서간 통신 방법들을 질의하는 단계를 추가로 포함하는 방법.

Images