설치된 관련 앱 가져오기 API

초안 커뮤니티 그룹 보고서,

이 버전:
https://wicg.github.io/get-installed-related-apps/spec/
이슈 추적:
GitHub
명세 내 인라인
편집자:
(Google)

초록

설치된 관련 앱 가져오기 API는 현재 기기에 관련 앱이 설치되어 있는지를 웹 앱이 감지할 수 있게 해 준다.

이 문서의 상태

이 명세는 웹 플랫폼 인큐베이터 커뮤니티 그룹에서 발행하였다. 이는 W3C 표준이 아니며 W3C 표준화 절차에 올라 있는 것도 아니다. W3C 커뮤니티 기여자 라이선스 계약(CLA)에 따라 제한적인 옵트아웃 및 기타 조건이 적용됨에 유의하라. W3C 커뮤니티 및 비즈니스 그룹에 대해 더 알아보기.

1. 소개

웹의 기능이 성장함에 따라, 웹 앱의 기능은 대응하는 네이티브 앱의 기능과 맞먹기 시작한다. 사용자가 웹 앱과 대응하는 네이티브 앱을 같은 기기에 모두 설치해 두는 상황은 더 흔해질 것이며, 이러한 앱들의 기능 집합은 수렴하게 될 것이다.

웹사이트가 네이티브 앱이든 웹 앱이든 앱이 설치되어 있는지를 감지할 수 있게 하는 것은 중요하다. 이를 통해 다른 앱에서 제공되어야 하는 기능을 비활성화할 수 있다.

1.1. 예제

const installedApps = await navigator.getInstalledRelatedApps();
const nativeApp = installedApps.find(app => app.id === 'com.example.myapp');

if (nativeApp && doesVersionSendPushMessages(nativeApp.version)) {
  // 푸시 메시지 전송을 처리하는 설치된 네이티브 앱이 있다.
  // 아무것도 할 필요가 없다.
  return;
}

// 푸시 구독을 생성한다.

위 예제에서 doesVersionSendPushMessages는 개발자가 정의한 함수이다.

2. 프라이버시 고려사항

이 API는 보안 최상위 컨텍스트에서만 활성화된다. 이를 통해 웹사이트가 위조될 수 없으며, 사이트와 애플리케이션 간의 연관이 유효함을 보장한다.

웹 앱과 그 대응 앱 간의 연관은 양방향이다. 즉, 웹 앱은 관련 앱과의 연관을 선언해야 하며, 관련 앱 역시 웹 앱과의 연관을 선언해야 한다. 이는 악의적인 웹사이트가 사용자를 핑거프린팅하고 설치된 애플리케이션 목록을 얻는 것을 방지한다.

사용자 에이전트는 핑거프린팅을 제한하기 위해 일치시킬 관련 애플리케이션의 수를 제한할 수 있다.

사용자 에이전트는 예를 들어 Chrome의 시크릿 모드나 Firefox의 사생활 보호 브라우징과 같은 프라이버시 보호 모드에서 실행 중일 때 설치된 애플리케이션을 반환해서는 안 된다.

3. 인프라스트럭처

3.1. 플랫폼

platform은 같은 클래스의 애플리케이션들을 함께 묶는 OS별 개념이다. 이는 USVString으로 표현된다.

OS에는 설치된 앱이 있다. 이는 키가 platform이고, 값이 list인 map이며, 그 list에는 설치된 앱들이 들어 있다.

3.2. 설치된 앱

설치된 앱은 사용자의 기기에 설치된 애플리케이션을 나타낸다.

설치된 앱은 다음으로 구성된다.

설치된 앱은 또한 연관된 platform을 가진다.

4. 알고리즘

4.1. 설치된 앱 일치시키기

relatedApp (ExternalApplicationResource) 및 manifestURL (URL)에 대해 설치된 앱을 일치시키려면, 다음 단계를 실행한다.
  1. platform을 relatedApp의 platform으로 둔다.

  2. 설치된 앱[platform]이 존재하지 않으면, null을 반환한다.

  3. installedApps를 설치된 앱[platform]으로 둔다.

  4. installedApps의 각 installedApp에 대해 반복한다.

    1. relatedApp의 id가 installedApp의 id와 같지 않고, relatedApp의 url도 installedApp의 id와 같지 않으면, 계속한다.

    2. minVersion을 relatedApp의 min_version으로 둔다. 없으면 빈 문자열로 둔다.

    3. minVersion이 빈 문자열이 아니고 minVersion이 installedApp의 version보다 크면, null을 반환한다.

      참고: `greater`는 애플리케이션 버전을 순서화하기 위한 플랫폼별 개념이다. 반드시 사전식 순서일 필요는 없다.

    4. fingerprints를 relatedApp의 fingerprints로 둔다. 없으면 빈 list로 둔다.

    5. fingerprints의 각 fingerprint에 대해 반복한다.

      1. installedApp의 fingerprints가 fingerprint를 포함하지 않으면, null을 반환한다.

    6. installedApp의 relatedURLs가 manifestURL을 포함하지 않으면, null을 반환한다.

    7. installedApp을 반환한다.

  5. null을 반환한다.

5. API

dictionary RelatedApplication {
    required USVString platform;
    USVString url;
    DOMString id;
    USVString version;
};

각 RelatedApplication은 WebAppManifest의 제공된 ExternalApplicationResource들과 일치된 설치된 앱을 나타낸다.

5.2. Navigator에 대한 확장

[Exposed=Window]
partial interface Navigator {
  [SecureContext] Promise<sequence<RelatedApplication>> getInstalledRelatedApps();
};
getInstalledRelatedApps() 메서드는 호출되면 다음 단계를 실행한다.
  1. relevantBrowsingContext를 컨텍스트 객체의 관련 설정 객체의 책임 있는 브라우징 컨텍스트로 둔다.

  2. relevantBrowsingContext가 최상위 브라우징 컨텍스트가 아니면, InvalidStateError DOMException으로 거부된 promise를 반환한다.

    이 제한을 제거해야 하는가? (#11)

  3. promise를 새 promise로 둔다.

  4. 다음 단계를 병렬로 실행한다.

    1. manifest 및 manifestURL을 manifest 얻기의 결과로 둔다. 이것이 실패하면, promise를 빈 list로 해결하고 이 단계를 중단한다.

    2. relatedApplications를 manifest의 related_applications로 둔다.

    3. 선택적으로:

      1. maxRelatedApps를 사용자 에이전트가 결정한 수로 둔다.

      2. relatedApplications의 size가 maxRelatedApps보다 크면, relatedApplications를 maxRelatedApps의 size로 자른다.

      참고: 이는 웹사이트가 얼마나 많은 네이티브 애플리케이션이 설치되어 있는지를 알 수 있는지를 제한한다. 매번 같은 ExternalApplicationResource들이 반환되도록 하려면 추가 항목은 잘라내야 한다.

    4. installedApps를 빈 list로 둔다.

    5. relatedApplications의 각 relatedApplication에 대해 반복한다.

      1. matchedApp을 relatedApplication 및 manifestURL과 함께 설치된 앱 일치시키기를 실행한 결과로 둔다.

      2. matchedApp이 null이면, 계속한다.

      3. installedApp를 다음을 가진 새 RelatedApplication으로 둔다.

        platform

        relatedApplication의 platform

        url

        relatedApplication의 url

        id

        relatedApplication의 id

        version

        matchedApp의 version

      4. installedApp를 installedApps에 추가한다.

    6. promise를 installedApps로 해결한다.

  5. promise를 반환한다.

적합성

문서 규약

적합성 요구사항은 서술적 단언과 RFC 2119 용어의 조합으로 표현된다. 이 문서의 규범적 부분에서 핵심어 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”은 RFC 2119에 설명된 대로 해석해야 한다. 다만, 가독성을 위해 이 명세에서는 이러한 단어들이 모두 대문자로 나타나지는 않는다.

명시적으로 비규범이라고 표시된 절, 예제, 참고를 제외하고 이 명세의 모든 텍스트는 규범적이다. [RFC2119]

이 명세의 예제는 “for example”이라는 말로 도입되거나 다음과 같이 class="example"을 사용하여 규범적 텍스트와 구분된다.

이것은 정보성 예제의 예이다.

정보성 참고는 “Note”라는 단어로 시작하며 다음과 같이 class="note"를 사용하여 규범적 텍스트와 구분된다.

참고: 이것은 정보성 참고이다.

적합한 알고리즘

알고리즘의 일부로 명령형으로 표현된 요구사항 예컨대 "strip any leading space characters" 또는 "return false and abort these steps"는 해당 알고리즘을 도입할 때 사용된 핵심어 ("must", "should", "may" 등)의 의미로 해석해야 한다.

알고리즘 또는 특정 단계로 표현된 적합성 요구사항은 최종 결과가 동등하기만 하다면 어떤 방식으로도 구현할 수 있다. 특히 이 명세에서 정의한 알고리즘은 이해하기 쉽도록 의도된 것이며 성능이 좋도록 의도된 것은 아니다. 구현자는 최적화할 것이 권장된다.

색인

이 명세에서 정의한 용어

참조로 정의된 용어

참고 문헌

규범적 참고 문헌

[APPMANIFEST]
Marcos Caceres; et al. 웹 애플리케이션 매니페스트. 2021년 3월 5일. WD. URL: https://www.w3.org/TR/appmanifest/
[DOM]
Anne van Kesteren. DOM 표준. 현행 표준. URL: https://dom.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML 표준. 현행 표준. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra 표준. 현행 표준. URL: https://infra.spec.whatwg.org/
[RFC2119]
S. Bradner. 요구 수준을 나타내기 위해 RFC에서 사용하는 핵심어. 1997년 3월. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[URL]
Anne van Kesteren. URL 표준. 현행 표준. URL: https://url.spec.whatwg.org/
[WebIDL]
Boris Zbarsky. Web IDL. 2016년 12월 15일. ED. URL: https://heycam.github.io/webidl/

IDL 색인

dictionary RelatedApplication {
    required USVString platform;
    USVString url;
    DOMString id;
    USVString version;
};

[Exposed=Window]
partial interface Navigator {
  [SecureContext] Promise<sequence<RelatedApplication>> getInstalledRelatedApps();
};

이슈 색인

이 제한을 제거해야 하는가? (#11) ↵