高分解能な時刻 — High Resolution Time

1.1. 利用事例

この仕様は、 次に挙げる能力を伴う時計を定義して，それに基づいて時刻印を供する ⇒＃ 安定的に単調増加する, 異なる文脈で比較-可能, ~milli秒より細かい分解能にもなり得る ◎ This specification defines a few different capabilities: it provides timestamps based on a stable, monotonic clock, comparable across contexts, with potential sub-millisecond resolution.

処理能の測定において，安定的に単調増加する時計の必要性が問われるのは、 当の測定が無関係な`外的な時計~調整$により歪められ，無用と化す事実があることに起因する。 例えば，［ 文書~navi, 資源の~fetching, ~scriptの実行 ］などに費やされた時間を正確aに測定しようと試みるとき、 単調増加する, かつ分解能が~milli秒より細かい時計が欲される。 ◎ The need for a stable monotonic clock when talking about performance measurements stems from the fact that unrelated clock skew can distort measurements and render them useless. For example, when attempting to accurately measure the elapsed time of navigating to a Document, fetching of resources or execution of script, a monotonically increasing clock with sub-millisecond resolution is desired.

異なる文脈で得られた時刻印を比較することは、 例えば，次のときに本質的になる ⇒＃ `Worker$I と~main~threadの間で作業を同期するとき／ そのような作業を計測して，~event時列線の統一された~viewを作成するとき ◎ Comparing timestamps between contexts is essential e.g. when synchronizing work between a Worker and the main thread or when instrumenting such work in order to create a unified view of the event timeline.

最後に，~milli秒より細かい~timerは、 次に挙げる利用事例の周りで必要になる： ◎ Finally, the need for sub-millisecond timers revolves around the following use-cases:

• ~milli秒より細かい周期で作業を~scheduleする能。 それは、 利用者から可視になるカクつきを避けるため，特に~main~threadで重要になる — そこでの作業は、［ 短い周期で定期的に起きる必要がある，~frameの描画 ］に干渉し得る。 ◎ Ability to schedule work in sub-millisecond intervals. That is particularly important on the main thread, where work can interfere with frame rendering which needs to happen in short and regular intervals, to avoid user-visible jank.
• ~scriptに基づく~animationの~frame~rateを計算するとき、 ~animationが 60 FPS で描画されているかどうか決定するためには，~milli秒より細かい分解能が必要になる。 ~milli秒より細かくなければ、 開発者は 58.8 FPS と 62.5 FPS を区別するのが限界になる（ 1 ~frameあたり前者が 1/58.8 = 約 0.017 秒, 後者は 0.016 秒）。 ◎ When calculating the frame rate of a script-based animation, developers will need sub-millisecond resolution in order to determine if an animation is drawing at 60 FPS. Without sub-millisecond resolution, a developer can only determine if an animation is drawing at 58.8 FPS (1000ms / 16) or 62.5 FPS (1000ms / 17).
• 開発者は，~JS~codeの測定を~~自前で収集するとき（例： `User Timing$cite を利用して）、 自身の関数に対し~milli秒より細かい計時を集めて，退歩を早期に捕えることにも関心があろう。 ◎ When collecting in-the-wild measurements of JS code (e.g. using User-Timing), developers may be interested in gathering sub-milliseconds timing of their functions, to catch regressions early.
• ~animation内の特定の時点に音声を~cueしようと試みるときや, 音声と~animationが完璧に同期するのを確保するためには、 開発者は，時間の~~長さを正確aに測定する必要がある。 ◎ When attempting to cue audio to a specific point in an animation or ensure that the audio and animation are perfectly synchronized, developers will need to accurately measure the amount of time elapsed.

1.2. 例

開発者は、 自身の~app全体にわたり，`時刻~起点$enVが異なる［ `Worker$I や `SharedWorker$I ］からの~eventも含むような時列線~FN を構築したいと望むこともあろう。 `timeOrigin$m 属性の助けを借りて 各~eventの `DOMHighResTimeStamp$I 値を換算すれば、 ~appは，そのような~eventたちを同じ時列線~上に表示できる。 ◎ A developer may wish to construct a timeline of their entire application, including events from Worker or SharedWorker, which have different time origins. To display such events on the same timeline, the application can translate the DOMHighResTimeStamps with the help of the Performance.timeOrigin attribute.

【~FN 時列線（ `timeline^en ） — 生じた~eventをその時刻とともに時系列順に記録するもの （無数の時刻~値からなる並びが成す線）。 】

// ---- worker.js -----------------------------
/* 
`SharedWorker$I 内の~script
◎
Shared worker script
 */
onconnect = function(%e) {
  var %port = %e.ports[0];
  %port.onmessage = function(%e) {
    /* 
~worker内での計時~task
◎
Time execution in worker
 */
    var %task_start = performance.now();
    %result = runSomeWorkerTask();
    var %task_end = performance.now();
  }

  /* 
結果と, および~epochに相対的な時刻【！timestamp】を，別の文脈へ送信する
◎
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 ------------------------
/* 
文書~内での計時~task
◎
Timing tasks in the document
 */
var %task_start = performance.now();
runSomeApplicationTask();
var %task_end = performance.now();

/* 
稼働時の処理能~dataを~uploadするために開発者が供した~method
◎
developer provided method to upload runtime performance data
 */
reportEventToAnalytics({
  'task': 'Some document task',
  'start_time': %task_start,
  'duration': %task_end - %task_start
});

/* 
~workerの時刻印を文書の`時刻~起点$enVに換算する
◎
Translating worker timestamps into document’s time origin
 */
var %worker = new SharedWorker('worker.js');
%worker.port.onmessage = function (%event) {
  var %msg = %event.data;

  /* 
~epochに相対的な時刻【！timestamp】を文書の`時刻~起点$enVに換算する
◎
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.1. 時計

`時計@ （ `clock^en ）は、 時間の経過を追跡する — すなわち、［ ある~algoにて，ある段を実行している時点 ］における時刻を `安全でない現在の時刻@ （ `unsafe current time^en ）として報告できる。 ◎ A clock tracks the passage of time and can report the unsafe current time that an algorithm step is executing.＼

【 “安全でない” と称される理由は、 `§ ~securityの考慮点＠#sec-security$を見よ。 】

時計には，多くの種類がある。 ~web~platformにおける`時計$は，どれも［ 現実世界の時間を成す 1 ~milli秒ごとに，時計~時間を成す 1 ~milli秒を数える ］よう試みるが、 それらは，［ 正確に正しくなれない事例を各自が どう取扱うか ］において相違する。 ◎ There are many kinds of clocks. All clocks on the web platform attempt to count 1 millisecond of clock time per 1 millisecond of real-world time, but they differ in how they handle cases where they can’t be exactly correct.

`時計$は、 `壁~時計@ （ `wall clock^en ）, `単調増加~時計@ （ `monotonic clock^en ） に大別される： ◎ ↓

• `壁~時計の安全でない現在の時刻@ — `壁~時計$から得られる`安全でない現在の時刻$ — は、 常に，アリな限り利用者の［ 時間の観念 ］に近くあろうとする。 ~computerは，ときには［ 時間が早くまたは遅く流れる／ 時間を追跡できなくなる ］ので、 `壁~時計$は，ときどき調整される必要がある — このことは、 `壁~時計の安全でない現在の時刻$は減少し得ること，したがって［ 処理能を測定する／~eventたちの順序を記録する ］用途においては依拠-可能にならないことを意味する。 ◎ The wall clock’s unsafe current time is always as close as possible to a user’s notion of time. Since a computer sometimes runs slow or fast or loses track of time, its wall clock sometimes needs to be adjusted, which means the unsafe current time can decrease, making it unreliable for performance measurement or recording the orders of events.＼

  ~web~platformは、 `壁~時計$を `~JS時刻@ — `ECMA-262$r に定義される`時刻＠~TC39#sec-time-values-and-time-range$ — と共有する。 ◎ The web platform shares a wall clock with [ECMA-262] time.

  【 単に “時刻（ `time^en ）” では汎用に過ぎるので、 この訳では， “~JS時刻” と称することにする。 】

• `単調増加~時計の安全でない現在の時刻@ — `単調増加~時計$から得られる`安全でない現在の時刻$ — は、 決して減少しないので，`外的な時計~調整$により変更され得ない。 `単調増加~時計$は，`~UA$の［ 1 回の実行 ］の中に限り存在するので、［ 互いに異なる実行にて起こるかもしれない~event ］どうしを比較するときには，利用できない。 ◎ The monotonic clock’s unsafe current time never decreases, so it can’t be changed by system clock adjustments. The monotonic clock only exists within a single execution of the user agent, so it can’t be used to compare events that might happen in different executions.

  注記： `単調増加~時計$は，利用者の［ 時間の観念 ］に合致するよう調整し得ないので、 利用者から可視な時間ではなく，測定~用に利用するベキである。 利用者に通信する用途には、 常に壁~時計を利用すること。 ◎ Since the monotonic clock can’t be adjusted to match the user’s notion of time, it should be used for measurement, rather than user-visible times. For any time communication with the user, use the wall clock.

  注記： ~UAは、［ ~browserの各~再起動 ／ 他から隔離された閲覧~session（例：~~私的（ `incognito or similar^en ）閲覧~mode）の各~開始／ 既存の どの設定群~objとも通信し得ない`環境~設定群~obj$を作成する各~回 ］ごとに，新たな［ `単調増加~時計において~Unix~epochを成すものと見積もられる時刻$ ］を選び取れる。 そのため，開発者は、［［ 過去現在未来すべての文脈にわたって単調増加する特質 ］を保持する，絶対的な時刻 ］には，共有される時刻印を利用するベキでない 【すなわち、ある回で`単調増加~時計$から得られた時刻印を他の回に再利用するベキでない】。 実施において，単調増加する特質を適用できる用途は、［ 供された~message法の仕組み — 例： `postMessage(message, options)$m, `BroadcastChannel$I, 等々 — を介して~messageを交換することにより，互いに他へ到達できるような文脈 ］に限られる。 ◎ The user agent can pick a new estimated monotonic time of the Unix epoch when the browser restarts, when it starts an isolated browsing session—e.g. incognito or a similar browsing mode—or when it creates an environment settings object that can’t communicate with any existing settings objects. As a result, developers should not use shared timestamps as absolute time that holds its monotonic properties across all past, present, and future contexts; in practice, the monotonic properties only apply for contexts that can reach each other by exchanging messages via one of the provided messaging mechanisms - e.g. postMessage(message, options), BroadcastChannel, etc.

  注記： ある種の局面においては （例：~UItabが~~背後に回されているとき）、 ~UAは，その文脈においては［ ~callbackを周期的に走らす~~頻度を抑えるよう，~timerを絞ることを — あるいは、まるごと凍結することさえ — 選ぶ ］こともあろう。 そのようにしたときでも、 `単調増加~時計$が返す時刻の分解能や正確aさには影響するベキでない。 ◎ In certain scenarios (e.g. when a tab is backgrounded), the user agent may choose to throttle timers and periodic callbacks run in that context or even freeze them entirely. Any such throttling should not affect the resolution or accuracy of the time returned by the monotonic clock.

2.2. ~momentと所要時間

各`時計$の`安全でない現在の時刻$は、 `安全でない~moment@ （ `unsafe moment^en ）を返す。 `時刻を粗化する$ことは、 これら`安全でない~moment$を `粗化した~moment@ （ `coarsened moment^en ） — 略して`~moment$ — に変換する。 ◎ Each clock’s unsafe current time returns an unsafe moment. Coarsen time converts these unsafe moments to coarsened moments or just moments.＼

注記： ［ `~moment$／`安全でない~moment$ ］は、［ 時間における一点 ］を表現する — それは、 直に数として格納し得ないことを意味する。 実装は、 通例的に，`~moment$を他の何らかの固定的な［ 時間における一点 ］からの`所要時間$として表現することになるが、 仕様は，`~moment$それ自体で処するべきである。 ◎ Moments and unsafe moments represent points in time, which means they can’t be directly stored as numbers. Implementations will usually represent a moment as a duration from some other fixed point in time, but specifications ought to deal in the moments themselves.

【 この仕様の文脈において “`moment^en” に相応しい対訳は， “~~時刻” くらいしか思いつかないが、 それは，すでに `time^en の対訳として利用されている。 “~~時点” とも訳せるが、 それも，至る所で `time^en その他の対訳に利用されている。 （ `time^en は、 通例的に，文脈に依存して［ “~~時間” ／ “~~時刻” ］と訳されるが、 その訳し分けが，この仕様における［ `duration^en ／ `moment^en ］の概念に いくぶん対応する。） 】

異なる時計から得られた［ `安全でない~moment$／`~moment$ ］どうしは、 比較-可能でない。 ◎ Unsafe moments and moments from different clocks are not comparable.

`所要時間@ （ `duration^en ）は、 同じ`時計$から得られた［ ある`~moment$から別の`~moment$まで ］の距離である — ［ すべての`所要時間$が `§ 時計の分解能＠#clock-resolution$における懸念を軽減する ］ことを確保するため、 どちらの`~moment$も`安全でない~moment$にし得ない。 `所要時間$は、［ ~milli秒数, 秒数, 等々 ］で測定される。 すべての`時計$は，同じ~rateで数えるよう試みるので、 `所要時間$に結付けられる`時計$は無い。 ◎ A duration is the distance from one moment to another from the same clock. Neither endpoint can be an unsafe moment so that both durations and differences of durations mitigate the concerns in [§ 9.1 Clock resolution]. Durations are measured in milliseconds, seconds, etc. Since all clocks attempt to count at the same rate, durations don’t have an associated clock,＼

【 この仕様に現れる “相対的な時刻” は、 実質的に，所要時間の同義語と見なせる。 】

ある`時計$ %時計 から得られた`~moment$に対しては、［ ある【%時計 とは同じと限らない】`時計$から得られた 2 個の`~moment$ ］から計算された`所要時間$を加算して， %時計 における別の`~moment$を生産できる。 ◎ and a duration calculated from two moments on one clock can be added to a moment from a second clock, to produce another moment on that second clock.

`所要時間$は、 暗黙的に `DOMHighResTimeStamp$I として利用できる — `所要時間を時刻印に暗黙的に変換する$ことにより。 ◎ Durations can be used implicitly as DOMHighResTimeStamps.＼

3.1. 例

9.1. 時計の分解能

正確aな計時~情報への~accessは、 測定と~schedule法の両~目的において，多くの~appに共通な要件である。 例えば，［ ~animation, 音, その他の~page上の活動 ］を協調して，より良い利用者~体験を供するためには、 高分解能な時間への~accessを要する。 類似に、 開発者は，測定により［ ~codeの決定的な部位における処理能を追跡する, 退歩を検出する, 等々 ］が可能になる。 ◎ Access to accurate timing information, both for measurement and scheduling purposes, is a common requirement for many applications. For example, coordinating animations, sound, and other activity on the page requires access to high-resolution time to provide a good user experience. Similarly, measurement enables developers to track the performance of critical code components, detect regressions, and so on.

しかしながら，その同じ正確aな計時~情報への~accessは、 攻撃者が他では見たり~accessできない~dataを推測して推定するような，悪意的な攻撃~目的にも利用され得る。 例えば，［ ~cache攻撃／ 統計的な指紋収集（ `statistical fingerprinting^en ）／ CPU ~architectureに乗じる攻撃（ `micro-architectural attack^en ） ］は、 悪意的な~web~siteが［ 利用者たちを分別する／ 特定0の利用者を識別する／ 同一-~process内の無関係な利用者~dataを露呈する ］ために［ ~browserや~appから起動される様々な演算による，高分解能な計時~data ］を利用し得る所における，~privacyや~securityの懸念である — さらなる背景0は、 `CACHE-ATTACKS$r, `SPECTRE$r を見よ。 ◎ However, access to the same accurate timing information can sometimes be also used for malicious purposes by an attacker to guess and infer data that they can’t see or access otherwise. For example, cache attacks, statistical fingerprinting and micro-architectural attacks are a privacy and security concern where a malicious web site may use high resolution timing data of various browser or application-initiated operations to differentiate between subset of users, identify a particular user or reveal unrelated but same-process user data - see [CACHE-ATTACKS] and [SPECTRE] for more background.

この仕様は、［ これまで `EpochTimeStamp$I として公開され可用であった~milli秒の分解能 ］よりも正確aな［ より細かい時間~分解能を供する~API ］を定義する。 しかしながら，この新たな~APIがなくとも、 攻撃者は［ ~~反復~実行と統計的な分析を通して，高分解能な見積もりを得する ］ことは可能である。 ◎ This specification defines an API that provides sub-millisecond time resolution, which is more accurate than the previously available millisecond resolution exposed by EpochTimeStamp. However, even without this new API an attacker may be able to obtain high-resolution estimates through repeat execution and statistical analysis.

新たな~APIにより，そのような攻撃の正確度や速度が有意に向上されないことを確保するため、 `DOMHighResTimeStamp$I 型の分解能は，攻撃を防止するに十分な正確aさに抑えるベキである。 ◎ To ensure that the new API does not significantly improve the accuracy or speed of such attacks, the minimum resolution of the DOMHighResTimeStamp type should be inaccurate enough to prevent attacks.

~UAは、 ~architectureや~softwareにおける拘束, その他の考慮点に因り，~privacyや~securityの懸念に取組むために必要yな所では、 `時刻を粗化する$ための処理~modelにおいて %時間~分解能 に設定する値をもっと高くする【すなわち粗化する】ベキである。 ◎ Where necessary, the user agent should set higher resolution values to time resolution in coarsen time’s processing model, to address privacy and security concerns due to architecture or software constraints, or other considerations.

~UAは、 そのような攻撃を軽減するために必要と判断される技法があれば，それを配備してもヨイ。 そのような技法の配備は、 次に挙げるものに基づいて変わり得る ⇒＃ ~browserの~architecture, 利用者の機器, 内容, 内容が非同一-生成元な~dataを悪意的に読取る能, その他の実施~上の考慮点 ◎ In order to mitigate such attacks user agents may deploy any technique they deem necessary. Deployment of those techniques may vary based on the browser’s architecture, the user’s device, the content and its ability to maliciously read cross-origin data, or other practical considerations.

これらの技法には、 次も含まれよう ⇒＃ 分解能の抑制／ ゆらぎを加える／ 濫用を検出して~API~callを絞る ◎ These techniques may include: • Resolution reduction. • Added jitter. • Abuse detection and/or API call throttling.

そのような計時~側からの攻撃を まるごと軽減することは、 実施~上はアリでない。 そのためには，［ すべての演算の実行~時間は［ 機密的な情報の値に基づいて変わることはない ］ようにする ］か［ ~appを［ 時間に関係するあらゆる~~基盤 ］（時計, ~timer, ~counter, 等々）から隔離する ］必要があるが、 どちらも，［［ ~browser／~app ］開発者にとっての複階性 ］および［ ~appの［ 処理能, 応答性 ］に対する負な効果 ］につながることに因り，実用的でない。 ◎ Mitigating such timing side-channel attacks entirely is practically impossible: either all operations would have to execute in a time that does not vary based on the value of any confidential information, or the application would need to be isolated from any time-related primitives (clock, timers, counters, etc). Neither is practical due to the associated complexity for the browser and application developers and the associated negative effects on performance and responsiveness of applications.

注記： 時計の分解能は、 未解決かつ発展途上な事実調査の分野であり，すべての~browserに適用される既存の［ 業界~総意／権威ある推奨 ］は無い。 `課題 #79＠https://github.com/w3c/hr-time/issues/79$ にて，論点を追跡できる。 ◎ Clock resolution is an unsolved and evolving area of research, with no existing industry consensus or definitive set of recommendations that applies to all browsers. To track the discussion, refer to Issue 79.

9.2. 時計の~drift

この仕様は、［ 分解能が~milli秒より細かい`時刻~起点の時刻印$ ］を供する~APIも定義する。 ~APIには［ すべての~browser文脈にわたって共有されなければナラナイ，`単調増加~時計$ ］が要求され，それを~appに公開する。 この時計は，物理的な時刻に縛られる必要はないが、 新たな［ 利用者についての指紋収集- ］~entropyを公開するのを避けるため，`~JS時刻$を基準に設定することが推奨される。 ~JS時刻は，すでに~appにより容易に得される一方で、 新たな論理-時計を公開するのは，新たな情報を供するに等しいので。 ◎ This specification also defines an API that provides sub-millisecond time resolution of the zero time of the time origin, which requires and exposes a monotonic clock to the application, and that must be shared across all the browser contexts. The monotonic clock does not need to be tied to physical time, but is recommended to be set with respect to the [ECMA-262] definition of time to avoid exposing new fingerprint entropy about the user — e.g. this time can already be easily obtained by the application, whereas exposing a new logical clock provides new information.

しかしながら，上述した仕組みの下でも、 `単調増加~時計$は， `時計の~drift＠https://en.wikipedia.org/wiki/Clock_drift$ （ `clock drift^en, “遅れ／進み” ）に関する分解能も供し得る。 今日の~appは、 同じ文脈の中の複数の時点で，［ 従来の時計による時刻印, 単調増加~時計による時刻印 ］を（順に， `Date.now()$c, `now()$m を介して）得てから， それらの間の~drift — 例えば`外的な時計~調整$に因るそれ — を観測できる。 攻撃者はまた、［ `timeOrigin$m 属性により，`単調増加~時計$から報告される`時刻~起点$enV ］と［ 従来の時計により，現在~見積もられる`時刻~起点$enV ］ （すなわち，［ `performance.timeOrigin^c ］と［ `Date.now()^c ~MINUS `performance.now()^c ］との差） とを長時間にわたり比較して， これらの時計どうしの~driftを観測できる~~可能性がある。 ◎ However, even with the above mechanism in place, the monotonic clock may provide additional clock drift resolution. Today, the application can timestamp the time-of-day and monotonic time values (via Date.now() and now()) at multiple points within the same context and observe drift between them—e.g. due to automatic or user clock adjustments. With the timeOrigin attribute, the attacker can also compare the time origin, as reported by the monotonic clock, against the current time-of-day estimate of the time origin (i.e. the difference between performance.timeOrigin and Date.now() - performance.now()) and potentially observe clock drift between these clocks over a longer time period.

【 例えば暗号処理を考える。 その処理の重さ（計算量）に因る CPU 熱は、 `外的な時計~調整$（この事例では `clock skew^en ）をもたらす結果，時計の~driftに反映され得る。 攻撃者は、 いくつかの入力とその計算量との相関関係を分析して，ある程度の情報を推定できるかもしれない。 】

実施においては、 ~appは，同じ時刻~driftを複数回の~naviにわたり観測できる： ~appは、 各~文脈における論理-時刻を記録し， ~client／~server 時刻~同期法の仕組みを利用して、 利用者の時計における変化を推定できる。 類似に，より低い層における仕組み — ~TCP時刻印など — は、 複数回の訪問を要することなく，同じ高分解能な情報を~serverに露呈し得る。 そのようなわけで，この~APIにより供される情報は、 有意な, あるいは以前までは可用でなかった，利用者についての~entropyを公開するベキでない。 ◎ In practice, the same time drift can be observed by an application across multiple navigations: the application can record the logical time in each context and use a client or server time synchronization mechanism to infer changes in the user’s clock. Similarly, lower-layer mechanisms such as TCP timestamps may reveal the same high-resolution information to the server without the need for multiple visits. As such, the information provided by this API should not expose any significant or previously unavailable entropy about the user.