크래시 보고

1. 소개

[소개가 여기에 들어감]

1.1. 예제

Reporting-Endpoints: default="https://example.com/reports"

2. 개념

2.1. 크래시

2.2. 메모리 부족

2.3. 응답 없음

3. 크래시 보고

크래시 보고는 브라우저(또는 페이지에 필요한 브라우저 프로세스 중 하나)가 크래시되어 사용자가 페이지를 계속 사용할 수 없었음을 나타낸다. 보안상의 이유로, 브라우저 공급업체가 해석할 수 있는 고유 식별자와, 선택적으로 크래시 이유(예: "oom")를 제외하고는 크래시에 대한 세부 정보가 전달되지 않는다.

크래시 보고는 보고의 한 유형이다.

크래시 보고의 보고 유형은 "crash"이다.

dictionary CrashReportBody : ReportBody {
  DOMString reason;
  DOMString stack;
  boolean is_top_level;
  DocumentVisibilityState visibility_state;
  object crash_report_api;
};

크래시 보고의 body는 JavaScript에서 CrashReportBody로 표현되며, 다음 필드를 포함한다:

• reason: 알려진 경우 발생한 크래시 유형의 더 구체적인 분류이며, 그렇지 않으면 생략된다. 유효한 reason 문자열은 아래에 표시되어 있다.

• stack: 다음 조건이 모두 참인 경우 크래시 당시의 JavaScript 호출 스택을 나타내는 문자열 표현이며, 그렇지 않으면 생략된다:

  • 크래시 reason이 "unresponsive"이다.

  • 크래시된 Document의 include-js-call-stacks-in-crash-reports 정책 값이 true이다.

  • 크래시된 문서에서 호출 스택을 복구할 수 있다.

  stack에 사용되는 문자열 표현은 Error.prototype.stack 속성에서 사용되는 것과 같다.

• is_top_level: 크래시된 Document가 최상위 traversable에 속했는지를 나타내는 boolean이다.

• visibility_state: 웹 플랫폼에 노출되는 DocumentVisibilityState enum과 일치하는 문자열 값 "visible" 또는 "hidden"이며, Document.visibilityState를 통해 노출된다. 이는 크래시된 Document가 호스트되던 시각적 뷰포트가 조금이라도 보였는지, 또는 완전히 가려졌는지를 나타낸다.

• crash_report_api: 크래시된 Document의 CrashReportContext의 backing buffer ID 멤버로 식별되는 사용자 에이전트의 crash report buffers 맵에 있는 메모리 버퍼를 역직렬화하여 얻은 임의의 키/값 데이터로 이루어진 JSON dictionary이다. 이 버퍼는 JSON 형식 문자열로 역직렬화되며, 그 키와 값은 CrashReportBody의 이 any 객체 멤버에 추가된다.

참고: 크래시 보고는 JavaScript에서 관찰할 수 없다. 이를 수신할 페이지는 정의상 그렇게 할 수 없기 때문이다. CrashReportBody의 IDL 설명은 이 명세에서 JSON으로 직렬화 가능한 인터페이스를 제공하기 위해 존재하며, 그 직렬화 결과는 대역 외 보고에 포함될 수 있다.

3.1. 크래시 보고 전달 우선순위

그렇지 않고 default endpoint가 지정되어 있으면, 크래시 보고가 해당 위치로 전달된다.

어느 endpoint도 지정되어 있지 않으면, 크래시 보고는 전달되지 않는다.

Reporting-Endpoints: crash-reporting="https://example.com/reports"

4. CrashReportContext 인터페이스

partial interface Window {
  readonly attribute CrashReportContext crashReport;
};

각 Window 객체에는 연결된 crashReport가 있으며, 이는 CrashReportContext 인스턴스로서 Window와 함께 생성된다.

[Exposed=Window]
interface CrashReportContext {
    Promise<undefined> initialize(unsigned long long length);
    undefined set(DOMString key, DOMString value);
    undefined delete(DOMString key);
};

각 CrashReportContext 객체에는 연결된 internal map이 있으며, 이는 맵으로, 그 키와 값은 모두 DOMString이다.

사용자 에이전트에는 연결된 crash report buffers가 있으며, 이는 맵으로, 그 키는 고유한 내부 값이고, 그 값은 구현 정의 값이다.

참고: internal map은 최종적으로 크래시 보고에 나타날 데이터의 맵 표현이며, 맵 의미 체계를 통해 이 데이터와 인체공학적으로 상호작용하기 위해 존재한다. 그러나 이 명세의 구현, 특히 사이트 격리를 지원하는 구현은 결국 그 전체 내용을 사용자 에이전트의 crash report buffers 맵이 추적하는 backing shared memory buffer로 직렬화할 가능성이 높다. 해당 맵의 값은 웹 프로세스와, 웹 프로세스가 크래시될 때 크래시 보고 전송을 담당하는 OS 프로세스 사이에 걸쳐 있는 메모리 버퍼일 것으로 예상되며, 그 internal map은 더 이상 읽을 수 없게 된다.

각 CrashReportContext 객체에는 연결된 backing buffer ID가 있으며, 이는 null 또는 고유한 내부 값이다. 초기값은 null이다.

각 CrashReportContext 객체에는 연결된 is buffer initialized boolean이 있으며, 초기값은 false이다.

참고: 이 멤버는 this의 backing buffer ID와 연결된 backing memory buffer가 초기화되면 비동기적으로 true로 설정된다.

각 CrashReportContext 객체에는 연결된 unsigned long long buffer length가 있으며, 초기값은 0이다.

참고: 이는 initialize()에서 한 번 할당되며, set() 호출이 internal map을 backing하는 메모리에 쓸 수 있는 최대 바이트 수를 추적한다.

internal map은 개발자에게 CrashReportBody를 통해 제공될 모든 키/값을 보관하는 데 사용된다. 사이트 격리가 있는 브라우저에서는 이 데이터에 쓰는 물리적 프로세스가 이를 읽고 크래시 보고를 보내는 프로세스와 다르다. 따라서 구현은 이 맵을 두 프로세스에 걸쳐 있는 공유 메모리 버퍼로 유지할 것으로 예상된다. Chromium의 이 API 구현은 이렇게 동작한다.

5. Document Policy 통합

사이트 작성자는 일부 보고에 JavaScript 호출 스택 기록을 포함하도록 선택할 수 있다.

이 명세는 이름이 include-js-call-stacks-in-crash-reports인 configuration point를 정의한다. 그 유형은 boolean이고 기본 값은 false이다. 크래시 보고가 활성화된 Document에서 true로 구성되면, 크래시 당시의 JavaScript 호출 스택 문자열 표현이 크래시 보고에 포함된다.

Document-Policy: include-js-call-stacks-in-crash-reports

6. 구현 고려 사항

6.1. 전달

이 명세가 의존하는 프레임워크를 정의하는 [REPORTING]은 많아야 최선 노력 방식의 전달 메커니즘을 제공한다. 크래시 보고의 경우에는 특히 그렇다. 보고할 수 없는 특정 크래시 조건은 아마도 항상 존재할 것이다. 예를 들어, 크래시가 사용자 에이전트의 크래시 모니터링 코드 내에서 발생하거나, 사용자 에이전트를 호스트하는 컴퓨터가 갑자기 존재하지 않게 되는 경우가 그렇다. 그러나 많은 크래시는 현대 브라우저에서 관찰될 수 있으며, 그 직접적인 원인을 추론할 수 있다.

크래시 보고를 구현하는 사용자 에이전트는 해당 문서를 담당하는 프로세스가 크래시되거나 운영 체제에 의해 종료되더라도 계속 동작할 수 있는 방식으로 문서의 크래시를 모니터링하려고 시도해야 한다(SHOULD).

이러한 모니터를 구현하는 방법은 여러 가지가 있으며, 특정 크래시 원인에 대한 신뢰성과 견고성 수준도 다양하다. 이 명세는 그러한 특정 방법을 규정하려고 하지 않는다.

7. 샘플 보고

POST /reports HTTP/1.1
Host: example.com
...
Content-Type: application/reports+json

[{
  "type": "crash",
  "age": 42,
  "url": "https://example.com/",
  "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0",
  "body": {
    "reason": "oom"
  }
}]

8. 보안 고려 사항

대역 외 보고 전반을 둘러싼 보안 고려 사항에 대한 논의는 Reporting API § 8 보안 고려 사항을 참조하라.

이 섹션의 나머지 부분에서는 특히 크래시 보고에 대한 보안 고려 사항을 논의한다.

9. 개인정보 보호 고려 사항

대역 외 보고 전반을 둘러싼 개인정보 보호 고려 사항에 대한 논의는 Reporting API § 9 개인정보 보호 고려 사항을 참조하라.

이 섹션의 나머지 부분에서는 특히 크래시 보고에 대한 개인정보 보호 고려 사항을 논의한다.

9.1. 교차 프로세스 오염