고해상도 시간

1. 소개

ECMAScript 언어 명세 [ECMA-262]는 Date 객체를 1970년 1월 1일 UTC 이후의 밀리초를 나타내는 시간 값으로 정의합니다. 대부분의 용도에서 이 시간 정의만으로 충분합니다. 이 값들은 1970년 1월 1일 UTC 이후 약 285,616년 범위의 임의의 시점을 밀리초 정밀도로 나타낼 수 있습니다.

실제로 이러한 시간 정의는 시계 드리프트(편차)와 시스템 시계 조정의 영향을 받을 수 있습니다. 시간 값이 항상 단조 증가하지 않거나, 이후 값이 더 작아지거나 동일할 수도 있습니다.

예를 들어 아래 스크립트에서는 계산된 duration 값이 양수, 음수, 혹은 0이 될 수 있습니다:

var mark_start = Date.now();
doTask(); // Some task
var duration = Date.now() - mark_start;

특정 작업의 경우 이 시간 정의만으로는 충분하지 않을 수 있습니다. 그 이유는 아래와 같습니다:

• 안정적이고 단조적인 시계를 제공하지 않으므로 시스템 시계 드리프트의 영향을 받음
• 밀리초 미만의(서브밀리초) 시간 해상도를 제공하지 않음

이 명세서는 Date.now() [ECMA-262] 의 동작 변경을 제안하지 않습니다. 이는 달력상의 현재 값을 구하는 데 실질적으로 유용하고, 오랜 사용의 역사가 있기 때문입니다. DOMHighResTimeStamp 타입, Performance.now() 메서드, 그리고 Performance.timeOrigin 속성 등은 위 문제들을 해결하여 단조적으로 증가하는 서브밀리초 해상도의 시간값을 제공합니다.

서브밀리초 해상도 제공은 본 명세서의 필수 요건이 아닙니다. 구현은 프라이버시/보안상의 이유로 노출하는 타이머 해상도를 제한하여 서브밀리초 타이머를 제공하지 않을 수 있습니다. 서브밀리초 해상도에 의존하는 사용 사례가 있을 경우, 그러한 상황에서 이 요구사항이 충족되지 않을 수 있습니다.

1.1. 사용 사례

본 명세서는 여러 기능을 정의합니다: 안정적이고 단조적인 시계를 기반으로 한 타임스탬프를 제공하고, 컨텍스트 간 비교와 서브밀리초 해상도를 지원할 수 있습니다.

성능 측정에서 안정적 단조 시계가 필요한 이유는, 관련 없는 시계 드리프트로 인해 측정값이 왜곡되어 무용지물이 될 수 있기 때문입니다. 예를 들어, 문서 내비게이션, 리소스 가져오기, 스크립트 실행 경과 시간을 정확하게 측정하려면 단조 증가(혹은 서브밀리초 해상도)가 필요합니다.

컨텍스트 간 타임스탬프 비교는 예를 들어 Worker 와 메인 쓰레드 간 동기화 작업 등 이벤트 타임라인의 통합 뷰를 만들기 위한 계측에서도 필수적입니다.

마지막으로, 서브밀리초 타이머 요구사항은 아래의 사용 사례와 관련됩니다:

• 서브밀리초 간격으로 작업을 스케줄할 필요. 이는 특히 메인 쓰레드에서 프레임 렌더링(사용자에게 보이는 끊김 방지)이 짧고 규칙적인 간격으로 일어나야 하므로 중요합니다.
• 스크립트 기반 애니메이션의 프레임 속도를 계산할 때, 개발자는 애니메이션이 60FPS로 그려지는지를 확인하기 위해 서브밀리초 해상도가 필요합니다. 밀리초 단위로만 보면 58.8FPS(1000ms/16)이나 62.5FPS(1000ms/17)로 구분할 수밖에 없습니다.
• 실제 환경의 JS 코드(예: User-Timing)의 측정값을 수집할 때, 개발자는 함수의 서브밀리초 타이밍을 모아 조기 회귀를 잡고 싶어합니다.
• 애니메이션에서 특정 지점 오디오 큐잉·오디오와 애니메이션 완벽 동기화를 하려면 정확한 경과 시간 측정이 필요합니다.

1.2. 예제

개발자는 워커(Worker 또는 SharedWorker 등) 의 이벤트를 포함한 애플리케이션 전체 타임라인을 만들 수 있습니다. 이들은 서로 다른 time origin을 가질 수 있습니다. 이런 이벤트를 통합 타임라인으로 표시하려면, DOMHighResTimeStamp 값을 Performance.timeOrigin 속성을 이용해 변환하면 됩니다.

// ---- worker.js -----------------------------
// Shared worker script
onconnect = function(e) {
  var port = e.ports[0];
  port.onmessage = function(e) {
    // Time execution in worker
    var task_start = performance.now();
    result = runSomeWorkerTask();
    var task_end = performance.now();
  }

  // Send results and epoch-relative timestamps to another context
  port.postMessage({
    'task': 'Some worker task',
    'start_time': task_start + performance.timeOrigin,
    'end_time': task_end + performance.timeOrigin,
    'result': result
  });
}

// ---- application.js ------------------------
// Timing tasks in the document
var task_start = performance.now();
runSomeApplicationTask();
var task_end = performance.now();

// developer provided method to upload runtime performance data
reportEventToAnalytics({
  'task': 'Some document task',
  'start_time': task_start,
  'duration': task_end - task_start
});

// Translating worker timestamps into document’s time origin
var worker = new SharedWorker('worker.js');
worker.port.onmessage = function (event) {
  var msg = event.data;

  // translate epoch-relative timestamps into document’s time origin
  msg.start_time = msg.start_time - performance.timeOrigin;
  msg.end_time = msg.end_time - performance.timeOrigin;

  reportEventToAnalytics(msg);
}

2. 시간 개념

2.1. 시계

시계는 시간의 경과를 추적하며 알고리즘 단계 실행 중 안전하지 않은 현재 시간 을 보고할 수 있습니다. 다양한 종류의 시계가 있습니다. 웹 플랫폼의 모든 시계는 실제 시간 1 밀리초당 시계 시간 1 밀리초를 세려고 하지만, 정확히 그러지 못하는 경우의 처리 방식에 따라 다릅니다.

단조시계는 사용자의 시간 개념에 맞춰 조정될 수 없으므로 측정 용도로만 사용해야 하며, 사용자가 볼 수 있는 시간에는 사용하지 않아야 한다. 사용자와의 모든 시간 소통에는 벽시계를 사용해야 한다.

사용자 에이전트는 브라우저 재시작, 격리된 브라우징 세션(예: 시크릿 모드 또는 유사 모드) 시작, 혹은 기존 설정 객체와 통신할 수 없는 환경 설정 객체를 생성할 때, 새로운 유닉스 에포크의 단조 예상 시간을 선택할 수 있다. 따라서 개발자는 공유 타임스탬프를 모든 과거, 현재, 미래 컨텍스트에서 단조 특성을 유지하는 절대적인 시간으로 사용해서는 안 되며, 실제로 단조 특성은 서로 메시지를 교환할 수 있는 컨텍스트에만 적용된다 - 예시로 postMessage(message, options), BroadcastChannel 등.

특정 상황(예: 탭이 백그라운드로 전환된 경우)에서는 사용자 에이전트가 해당 컨텍스트 내의 타이머와 주기적 콜백을 느리게 하거나 완전히 동결할 수 있다. 이러한 제한은 단조시계가 반환하는 시간의 해상도나 정확성에는 영향을 미치지 않아야 한다.

2.2. 순간과 기간

각 시계의 안전하지 않은 현재 시간은 안전하지 않은 시점을 반환한다. 시점 간소화는 이러한 안전하지 않은 시점을 간소화된 시점 또는 시점으로 변환한다. 안전하지 않은 시점과 시점은 서로 다른 시계 간에는 비교할 수 없다.

시점과 안전하지 않은 시점은 시간상의 한 지점을 의미하므로, 직접적으로 숫자로 저장될 수 없다. 구현체는 일반적으로 시점을 어떤 고정된 시점으로부터의 지속시간으로 나타내지만, 규격에서는 시점 자체를 다뤄야 한다.

지속시간(duration)은 동일한 시점(moment)들 사이의 거리이며, 같은 시계(clock)에서 측정된다. 두 끝점 모두 안전하지 않은 시점(unsafe moment)이 아니어야 하며, 이렇게 하면 지속시간(duration)과 지속시간 차(difference of durations) 모두 [§ 9.1 시계 해상도]의 문제를 완화할 수 있다. 지속시간은 밀리초, 초 등의 단위로 측정된다. 모든 시계가 같은 속도로 카운트하려고 시도하므로 지속시간은 특정 시계와 연관되지 않으며, 하나의 시계에서 두 시점으로 계산된 지속시간을 두번째 시계의 특정 시점에 더하여 그 두번째 시계의 새로운 시점을 얻을 수 있다.

지속시간 계산 a에서 b까지의 결과는 다음 알고리즘에 따른다:

1. 단언: a는 b와 동일한 시계에 의해 생성되었다.
2. 단언: a와 b는 모두 조정된 순간들이다.
3. a에서 b까지의 시간량을 기간으로 반환한다. 만약 b가 a보다 이전에 왔다면, 이것은 음의 기간이 된다.

지속시간은 암묵적으로 DOMHighResTimeStamp로 사용할 수 있다. 지속시간을 타임스탬프로 암묵 변환하려면, 지속시간 d가 주어졌을 때 d의 밀리초 수를 반환한다.

3. 명세서 작성자를 위한 도구

단일 페이지(단일 환경 설정 객체 컨텍스트 내)에서 시간을 측정하려면 settingsObject의 현재 상대 타임스탬프를 사용한다. 이는 settingsObject의 시간 기준점에서 settingsObject의 현재 단조 시간까지의 지속시간으로 정의된다. 이 값은 지속시간의 암묵적 변환을 통해 DOMHighResTimeStamp로 자바스크립트에 직접 제공될 수 있다.

단일 UA 실행 내에서 시간 기준점이 비교 기준점으로 적합하지 않은 경우, 환경 설정 객체의 시간 기준점 대신 시점을 환경 설정 객체의 현재 단조 시간을 사용해 생성한다. 환경 설정 객체 settingsObject의 현재 단조 시간 은 다음 단계의 결과이다:

1. unsafeMonotonicTime을 단조시계의 안전하지 않은 현재 시간으로 설정한다.
2. 시점 간소화를 unsafeMonotonicTime과 settingsObject의 크로스 오리진 격리 기능으로 호출한 결과값을 반환한다.

모멘트(moment)는 단조 시계에서 생성되며 JavaScript나 HTTP에서 직접적으로 표현될 수 없다. 대신, 그러한 두 모멘트 사이의 지속 시간(duration)을 노출한다.

여러 UA 실행에 걸쳐 시간을 측정하기 위해서는 모멘트를 현재 wall time(현재 보정된 벽시계 시간)을 사용해서 생성하거나(혹은 cross-origin-isolated context에서 더 높은 정밀도가 필요한 경우) environment settings object의 현재 wall time을 사용한다. 현재 보정된 벽시계 시간은 coarsen time을 벽시계(wall clock)의 안전하지 않은 현재 시간(unsafe current time)에 적용한 결과이다.

환경 설정 객체 settingsObject의 현재 벽시계 시간은 다음 단계의 결과이다:

1. unsafeWallTime을 벽시계의 안전하지 않은 현재 시간으로 설정한다.
2. 시점 간소화를 unsafeWallTime과 settingsObject의 크로스 오리진 격리 기능으로 호출한 결과값을 반환한다.

벽시계에서 가져온 모멘트를 사용할 때에는, 사용자가 시계를 앞으로 또는 뒤로 조정하는 상황을 반드시 설계에 반영해야 합니다.

벽시계에서 가져온 모멘트는 자바스크립트에서 유닉스 에포크로부터 그 모멘트까지의 밀리초 수를 Date 생성자에 전달하거나, 유닉스 에포크로부터 그 모멘트까지의 나노초 수를 Temporal.Instant 생성자에 전달하여 표현할 수 있습니다. [Temporal]

컴퓨터 간에 이와 유사한 표현을 전송하는 것은 지양해야 하며, 이는 사용자의 시계 오차(클록 스큐)를 노출시킬 수 있는데, 이것은 추적 벡터가 됩니다. 대신, 단조 시계 모멘트 방식처럼, 두 모멘트 사이의 기간(duration)을 전송하는 접근법을 사용하세요.

3.1. 예제

4. 시간 오리진

유닉스 에포크(Unix epoch)는 벽시계(wall clock)에서 1970년 1월 1일 00:00:00 UTC에 해당하는 모멘트(moment)입니다.

어떤 방식으로든 통신이 가능한 environment settings object 그룹마다 유닉스 에포크의 예상 단조 시계 시각이 존재합니다. 이는 단조 시계(monotonic clock)의 모멘트(moment)로, 그 값은 다음 단계에 따라 초기화됩니다:

1. wall time을 벽시계(wall clock)의 안전하지 않은 현재 시간(unsafe current time)으로 둡니다.
2. monotonic time을 단조 시계(monotonic clock)의 안전하지 않은 현재 시간으로 둡니다.
3. epoch time을 monotonic time - (wall time - 유닉스 에포크) 로 둡니다.
4. 유닉스 에포크의 예상 단조 시계 시각을 coarsen time을 epoch time에 호출한 결과로 초기화합니다.

성능 측정치는 관련된 environment settings object의 초기화 시점 초기에 저장된 모멘트(moment)로부터 지속 시간(duration)을 리포트합니다. 해당 모멘트는 settings object의 time origin에 저장됩니다.

타임 오리진 타임스탬프(get time origin timestamp)를 global object global에 대해 실행하면, 다음 단계가 수행되어 지속 시간(duration)이 반환됩니다:

1. timeOrigin을 global의 relevant settings object의 time origin으로 둡니다.

   Window 컨텍스트에서는 이 값이 네비게이션이 시작된 시점을 나타냅니다. Worker 및 ServiceWorker 컨텐츠에서는 이 값이 워커가 실행된 시점을 나타냅니다. [SERVICE-WORKERS]

2. 유닉스 에포크의 예상 단조 시계 시각에서 timeOrigin까지 지속 시간(duration from)을 반환합니다.

get time origin timestamp가 반환하는 값은 대략적으로 유닉스 에포크 이후 global의 time origin이 발생한 시점에 해당합니다. 이는 Date.now()를 time origin 시점에 실행한 결과와 다를 수 있는데, 전자는 시스템 및 사용자 시계 조정, 시계 오차(skew) 등에 영향을 받지 않는 단조 시계(monotonic clock) 기반으로 기록되기 때문입니다.

current high resolution time 알고리즘은, global object current global을 받아, unsafe shared current time과 current global을 relative high resolution time에 전달한 결과를 반환해야 합니다.

coarsened shared current time 알고리즘은, 선택적 불린 crossOriginIsolatedCapability (기본값: false)를 받아, unsafe shared current time과 crossOriginIsolatedCapability로 coarsen time을 호출한 결과를 반환해야 합니다.

unsafe shared current time 알고리즘은 단조 시계(monotonic clock)의 안전하지 않은 현재 시간(unsafe current time)을 반환해야 합니다.

5. DOMHighResTimeStamp 타입 정의

DOMHighResTimeStamp 타입은 밀리초 단위의 지속 시간(duration) 을 저장하는 데 사용됩니다. 맥락에 따라, 이 타입은 모멘트 를 나타낼 수도 있고, 기준 모멘트 (예: time origin 또는 유닉스 에포크(Unix epoch)) 이후 지속 시간만큼 지난 시점을 나타낼 수도 있습니다.

typedef double DOMHighResTimeStamp;

DOMHighResTimeStamp 는 밀리초 단위의 시간을 측정할 수 있을 만큼 정확하면서도, 타이밍 공격을 방지할 만큼의 충분한 보안성을 가져야 합니다. 추가적인 고려사항은 § 9.1 시계 해상도를 참조하십시오.

DOMHighResTimeStamp 는 double 타입이므로, 오직 에포크 기반 시간—즉 유닉스 에포크로부터 특정 모멘트까지의 밀리초 수—만을 유한한 해상도로 나타낼 수 있습니다. 2023년의 모멘트 기준 해상도는 대략 0.2마이크로초(μs)입니다.

6. EpochTimeStamp 타입 정의

typedef unsigned long long EpochTimeStamp;

EpochTimeStamp 는 유닉스 에포크부터 벽시계의 주어진 시점까지의 윤초를 제외한 정수 밀리초 수를 나타낸다. 이 타입을 사용하는 명세에서는 밀리초 수의 해석 방식을 정의한다.

7. Performance 인터페이스

[Exposed=(Window,Worker)]
interface Performance : EventTarget {
    DOMHighResTimeStamp now();
    readonly attribute DOMHighResTimeStamp timeOrigin;
    [Default] object toJSON();
};

7.1. now() 메서드

now() 메서드는 현재 고해상도 시간에서 this의 관련 글로벌 객체를 전달하여 얻게 되는 밀리초 수(지속시간)를 반드시 반환해야 한다.

같은 시간 기준점을 갖는 Performance 객체에서 now() 메서드를 호출했을 때 반환되는 시간 값은 반드시 동일한 단조시계를 사용해야 한다. 동일한 시간 기준점에 대해 now() 메서드로 얻은 어떤 두 시간 값의 차이는, 시간적으로 먼저 기록된 값이 절대로 음수가 되어서는 안 된다.

7.2. timeOrigin 속성

timeOrigin 속성은 반드시 get time origin timestamp가 this의 관련 글로벌 객체에 대해 반환하는 지속시간의 밀리초 값을 반환해야 한다.

Performance.timeOrigin 값을 얻을 때 반환되는 시간 값은 반드시 단조시계를 사용해야 하며, 이 시계는 시간 기준점들이 공유하며, 기준점은 [ECMA-262]의 시간 정의를 따른다. 추가 사항은 [§ 9 보안 고려사항]

7.3. toJSON() 메서드

toJSON()을 호출하면, [WEBIDL]의 default toJSON steps를 수행해야 합니다.

8. WindowOrWorkerGlobalScope 믹스인에 대한 확장

8.1. performance 속성

performance 속성은 인터페이스 믹스인 WindowOrWorkerGlobalScope 에 정의되어 있으며, global object에서 성능 관련 속성과 메서드에 접근할 수 있도록 합니다.

partial interface mixin WindowOrWorkerGlobalScope {
  [Replaceable] readonly attribute Performance performance;
};

9. 보안 고려사항

9.1. 시계 해상도

정밀한 타이밍 정보 접근(측정 및 예약용)은 많은 앱에서 공통적으로 필요한 기능입니다. 예를 들어, 페이지 내 애니메이션, 사운드 등 다양한 활동에서 고해상도 시간이 필요합니다. 또 측정은 개발자가 중요한 코드의 성능을 추적하고, 회귀를 탐지하는 데도 쓰입니다.

하지만 동일한 정밀 타이밍 정보 접근이 공격자가 보지 못하거나 접근할 수 없는 데이터를 추측·추론하는 데 악의적으로 쓰일 수도 있습니다. 예: 캐시 공격, 통계적 핑거프린팅, 마이크로아키텍처 공격은 프라이버시·보안 위험입니다. 악성 사이트가 다양한 브라우저/앱 동작의 고해상도 시간 정보를 이용해 일부 사용자군을 구분하거나 특정 사용자를 식별, 혹은 관련 없는(동 프로세스) 사용자 데이터를 드러내는 데 활용할 수 있습니다. 자세한 배경은 [CACHE-ATTACKS] 및 [SPECTRE] 참고.

이 명세는 서브밀리초 단위의 고해상도 시간 API를 정의하며 이는 EpochTimeStamp가 노출하는 밀리초 해상도보다 더 정확합니다. 하지만 새로운 API 없이도 공격자는 반복 실행 및 통계 분석을 통해 고해상도 추정값을 얻을 수 있습니다.

새로운 API가 이러한 공격의 정확도·속도를 대폭 개선하지 않도록 하기 위해, DOMHighResTimeStamp 타입의 해상도(precision)는 공격을 방지할 정도로 부정확해야 합니다.

필요하다면, 사용자 에이전트는 아키텍처 또는 소프트웨어 제약이나 기타 고려 사항에 따라 프라이버시 및 보안 문제를 해결하기 위해 시점 간소화 처리 모델에서 time resolution을 더 높은 해상도 값으로 설정해야 한다.

이러한 공격을 차단하기 위해, 사용자 에이전트는 필요하다 생각하는 모든 기법을 채택할 수 있습니다. 구체 적용 방식(구현체·디바이스·컨텐츠, 교차 출처 데이터 접근 가능성, 기타 실제 고려 상항 등)은 브라우저마다 다를 수 있습니다.

구현 기법 예시:

• 해상도 저하(precision reduction)
• Jitter 추가(임의 노이즈 추가)
• 오남용 감지 및/또는 API 호출 제한

타이밍 기반 부채널(side-channel) 공격을 완전히 막기는 현실적으로 불가능합니다: 모든 연산이 어떠한 비밀 데이터 값에도 영향 받지 않는 시간 내에서만 실행되어야 하고, 애플리케이션은 모든 시간 관련 프리미티브(시계, 타이머, 카운터 등)로부터 완전히 격리되어야 하기 때문입니다. 이는 구현 복잡성과 앱 반응성·성능에 부정적 영향을 주므로 현실적이 아닙니다.

9.2. 시계 드리프트(시간 오차)

이 명세는 time origin의 zero time에 대해 밀리초 이하의 시간 해상도를 제공하는 API도 정의하며, 이는 애플리케이션에 단조시계를 요구하고 노출하는데, 반드시 브라우저의 모든 컨텍스트에서 공유되어야 한다. 단조시계는 물리적 시간과 반드시 연결될 필요는 없지만, 새로운 사용자 식별 관련 엔트로피가 노출되는 것을 막기 위해 [ECMA-262]의 시간(time) 정의와 맞추는 것이 권장된다. 예를 들어 이 시간은 이미 애플리케이션에서 쉽게 획득할 수 있으나, 새로운 논리 시계를 노출하면 새로운 정보가 제공될 수 있다.

그러나 위의 방식을 적용하더라도, 단조시계는 추가적인 시계 오차(clock drift) 해상도를 제공할 수 있다. 현재 애플리케이션은 같은 컨텍스트 내에서 여러 지점에서 시간-오브-데이와 단조시계 값을 (Date.now()와 now())으로 타임스탬프화하고, 이 값들 사이의 드리프트(예: 자동 또는 사용자 시계 조정에 따라 발생)를 관찰할 수 있다. timeOrigin 속성을 사용하면, 공격자는 시간 기준점을 단조시계로 측정되는 값과 현재 시간-오브-데이 추정값(시간 기준점에서의 값, 즉 `performance.timeOrigin`과 `Date.now() - performance.now()`의 차이) 사이에서 오랜 시간에 걸친 시계 드리프트를 관찰할 수 있다.

실제로 동일한 시계 드리프트는 애플리케이션이 여러 번 내비게이션을 거치면서도 관찰할 수 있다: 애플리케이션은 각 컨텍스트의 논리 시점을 기록하고, 클라이언트 또는 서버의 시간 동기화 메커니즘을 이용하여 사용자의 시계 변화 추측이 가능하다. 이와 비슷하게, TCP 타임스탬프와 같은 하위 계층 메커니즘 또한 서버에 고해상도 정보를 한 번 방문만으로 제공할 수 있다. 따라서 이 API가 제공하는 정보는 사용자의 엔트로피를 크게 (또는 이전에 획득 불가능했던 엔트로피를) 노출해서는 안 된다.

10. 프라이버시 고려사항

현재 time origin의 정의에서는, Document가 얻는 도착 전 크로스오리진 리다이렉트의 전체 시간이 노출됩니다. 이로 인해 교차 출처 정보가 노출되지만, 이를 성능 지표를 심각하게 해치지 않게 완화하는 방법은 아직 결정되지 않았습니다.

논의의 진행 상황은 Navigation Timing 이슈 160을 참고하세요.

11. 감사의 말

본 작업에 기여해주신 Arvind Jain, Angelos D. Keromytis, Boris Zbarsky, Jason Weber, Karen Anderson, Nat Duca, Philippe Le Hegaret, Ryosuke Niwa, Simha Sethumadhavan, Todd Reifsteck, Tony Gentilcore, Vasileios P. Kemerlis, Yoav Weiss, Yossef Oren께 감사드립니다.