설치된 관련 앱 가져오기 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이고, 값이 listmap이며, 그 list에는 설치된 앱들이 들어 있다.

3.2. 설치된 앱

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

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

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

4. 알고리즘

4.1. 설치된 앱 일치시키기

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

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

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

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

    1. relatedAppidinstalledAppid와 같지 않고, relatedAppurlinstalledAppid와 같지 않으면, 계속한다.

    2. minVersionrelatedAppmin_version으로 둔다. 없으면 빈 문자열로 둔다.

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

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

    4. fingerprintsrelatedAppfingerprints로 둔다. 없으면 빈 list로 둔다.

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

      1. installedAppfingerprintsfingerprint포함하지 않으면, null을 반환한다.

    6. installedApprelatedURLsmanifestURL포함하지 않으면, null을 반환한다.

    7. installedApp을 반환한다.

  5. null을 반환한다.

5. API

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

RelatedApplicationWebAppManifest의 제공된 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. manifestmanifestURLmanifest 얻기의 결과로 둔다. 이것이 실패하면, promise를 빈 list해결하고 이 단계를 중단한다.

    2. relatedApplicationsmanifestrelated_applications로 둔다.

    3. 선택적으로:

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

      2. relatedApplicationssizemaxRelatedApps보다 크면, relatedApplicationsmaxRelatedAppssize로 자른다.

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

    4. installedApps를 빈 list로 둔다.

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

      1. matchedApprelatedApplicationmanifestURL과 함께 설치된 앱 일치시키기를 실행한 결과로 둔다.

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

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

        platform

        relatedApplicationplatform

        url

        relatedApplicationurl

        id

        relatedApplicationid

        version

        matchedAppversion

      4. installedAppinstalledApps추가한다.

    6. promiseinstalledApps해결한다.

  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)