Long Tasks API

1.1. 用例

const %observer = new PerformanceObserver(function(%list) {
    for (const %entry of %list.getEntries()) {
        /* 
長い~task通知を処理する：解析と監視~用に報告する…
◎
Process long task notifications: report back for analytics and monitoring ...
 */
    }
});
/* 
これまで, および未来における長い~taskの通知~用に，観測器を登録する
◎
Register observer for previous and future long task notifications.
 */
%observer.observe({type: "longtask", buffered: true});
/* 
以降，長い~script実行が生じたときは、
観測器にて `longtask^l ~entryが~queueされ，受信されるようになる。
◎
Long script execution after this will result in queueing and receiving "longtask" entries in the observer.
 */

3.1. `PerformanceLongTaskTiming^I ~interface

[`Exposed$=Window]
interface `PerformanceLongTaskTiming@I : `PerformanceEntry$I {
    /* 
`PerformanceEntry$I の~memberを多重定義する：
◎
Overloading PerformanceEntry
 */
    readonly attribute `DOMHighResTimeStamp$I `startTime$m1;
    readonly attribute `DOMHighResTimeStamp$I `duration$m1;
    readonly attribute `DOMString$ `name$m1;
    readonly attribute `DOMString$ `entryType$m1;

    readonly attribute `FrozenArray$<`TaskAttributionTiming$I> `attribution$m;
    [`Default$] `object$ `toJSON@m1();
};

`PerformanceLongTaskTiming$I の各種 属性の値は、 `長い~taskを報告する$処理~modelにて設定される。 それらがどう設定されるかについて，規範的でない要約を以下に供する： ◎ The values of the attributes of a PerformanceLongTaskTiming are set in the processing model in § 4.1 Report long tasks. The following provides an informative summary of how they will be set.

• `name@m1 【！`name$m】 属性の取得子は、［ 当の長い~taskが出自にしているのは、 どの`閲覧~文脈$の中の~event~loop`~task$か ］に応じて，次に挙げるいずれかの文字列を返すことになる： ◎ The name attribute’s getter will return one of the following strings:

  `unknown@l

  ~UAが`~event~loop$の外側で遂行した作業 ◎ The long task originated from work that the user agent performed outside of the event loop.

  `self@l

  この`閲覧~文脈$。 ◎ The long task originated from an event loop task within this browsing context.

  `same-origin-ancestor@l

  `同一-生成元$に属する`先祖~navigable$。 ◎ The long task originated from an event loop task within a same-origin ancestor navigable.

  `same-origin-descendant@l

  `同一-生成元$に属する`子孫~閲覧~文脈$。 ◎ The long task originated from an event loop task within a same-origin descendant browsing context.

  `same-origin@l

  `同一-生成元$に属するが，先祖でも子孫でもない`閲覧~文脈$。 ◎ The long task originated from an event loop task within a same-origin browsing context that is not an ancestor or descendant.

  `cross-origin-ancestor@l

  `同一-生成元$に属さない`先祖~navigable$。 ◎ The long task originated from an event loop task within a cross-origin ancestor navigable.

  `cross-origin-descendant@l

  `同一-生成元$に属さない`子孫~閲覧~文脈$。 ◎ The long task originated from an event loop task within a cross-origin descendant browsing context.

  `cross-origin-unreachable@l

  `同一-生成元$に属さない, かつ先祖でも子孫でもない`閲覧~文脈$。 ◎ The long task originated from an event loop task within a cross-origin browsing context that is not an ancestor or descendant.

  `multiple-contexts@l

  ~event~loop`~task$のうち，複数の`閲覧~文脈$を孕んでいるもの。 ◎ The long task originated from an event loop task involving multiple browsing contexts.

  注記： これらの名前には、 一貫性に欠くものがある — `-unreachable^l, `-contexts^l 接尾辞など。 これらの名前は、 後方-互換性の理由から保たれる。 ◎ Note: There are some inconsistencies across these names, such as the "-unreachable" and the "-contexts" suffixes. These names are kept for backward compatibility reasons.

• `entryType@m1 属性の取得子は、 `longtask^l を返す。 ◎ The entryType attribute’s getter step is to return "longtask".
• `startTime@m1 属性の取得子は、 当の~taskが開始された時点を表す `DOMHighResTimeStamp$I 値を返す。 ◎ The startTime attribute’s getter step is to return a DOMHighResTimeStamp of when the task started.
• `duration@m1 属性の取得子は、 当の~taskの開始から終了までに経過した時間を粒度 1ms で表す `DOMHighResTimeStamp$I 値を返す。 ◎ The duration attribute’s getter step is to return a DOMHighResTimeStamp equal to the elapsed time between the start and end of task, with a 1 ms granularity.
• `attribution@m 属性の取得子は、 一連の `TaskAttributionTiming$I ~entryからなる凍結d配列を返す。 ◎ The attribution attribute’s getter will return a frozen array of TaskAttributionTiming entries.

3.2. `TaskAttributionTiming^I ~interface

[`Exposed$=Window]
interface `TaskAttributionTiming@I : `PerformanceEntry$I {
    /* 
`PerformanceEntry$I の~memberを多重定義する：
◎
Overloading PerformanceEntry
 */
    readonly attribute `DOMHighResTimeStamp$I `startTime$m1;
    readonly attribute `DOMHighResTimeStamp$I `duration$m1;
    readonly attribute `DOMString$ `name$m1;
    readonly attribute `DOMString$ `entryType$m1;

    readonly attribute `DOMString$ `containerType$m;
    readonly attribute `DOMString$ `containerSrc$m;
    readonly attribute `DOMString$ `containerId$m;
    readonly attribute `DOMString$ `containerName$m;
    [`Default$] `object$ `toJSON@m1();
};

`TaskAttributionTiming$I の各種~属性の値は、 `長い~taskを報告する$処理~modelにて設定される。 それらがどう設定されるかについて，規範的でない要約を以下に供する： ◎ The values of the attributes of a TaskAttributionTiming are set in the processing model in § 4.1 Report long tasks. The following provides an informative summary of how they will be set.

• `name@m1 属性の取得子は、 常に `unknown^l を返す。 ◎ The name attribute’s getter will always return "unknown".
• `entryType@m1 属性の取得子は、 常に `taskattribution^l を返す。 ◎ The entryType attribute’s getter will always return "taskattribution".
• `startTime@m1 属性の取得子は、 常に 0 を返す。 ◎ The startTime attribute’s getter will always return 0.
• `duration@m1 属性の取得子は、 常に 0 を返す。 ◎ The duration attribute’s getter will always return 0.
• `containerType@m 属性の取得子は、 `元凶~閲覧~文脈~容器$の型を返す — `iframe^l, `embed^l, `object^l など。 `元凶~閲覧~文脈~容器$は一つも見出されない場合、 `window^l を返すことになる。 ◎ The containerType attribute’s getter will return the type of the culprit browsing context container, such as "iframe", "embed", or "object". If no single culprit browsing context container is found, it will return "window".
• `containerName@m 属性の取得子は、 `元凶~閲覧~文脈~容器$の `name^a 内容~属性の値を返す。 `元凶~閲覧~文脈~容器$は一つも見出されない場合、 空~文字列を返すことになる。 ◎ The containerName attribute’s getter will return the value of the container’s name content attribute. If no single culprit browsing context container is found, it will return the empty string.
• `containerId@m 属性の取得子は、 `元凶~閲覧~文脈~容器$の `id^a 内容~属性の値を返す。 `元凶~閲覧~文脈~容器$は一つも見出されない場合、 空~文字列を返すことになる。 ◎ The containerId attribute’s getter will return the value of the container’s id content attribute. If no single culprit browsing context container is found, it will return the empty string.
• `containerSrc@m 属性の取得子は、 `元凶~閲覧~文脈~容器$の `src^a 内容~属性の値を返す。 `元凶~閲覧~文脈~容器$は一つも見出されない場合、 空~文字列を返すことになる。 ◎ The containerSrc attribute’s getter will return the value of the container’s src content attribute. If no single culprit browsing context container is found, it will return the empty string.

3.3. 元凶を指すもの

`長い~task$は、 異なる種別の作業（~script, ~layout, ~style等々など）を孕み得る。 また、 異なる`閲覧~文脈$の中で実行されることもあれば，大域的な資質を備えるものにもなり得る — ［ `~agent~cluster$ ／ `閲覧~文脈~group集合$ ］全体にわたる長い~garbage収集など。 ◎ A long task can involve different types of work (such as script, layout, style etc), and it could be executed within different browsing contexts, or it could be global in nature such as a long garbage collection that spans the entire agent cluster or browsing context group set.

したがって，`帰属$が指すものには少数の側面fがある： ◎ Thus attribution has a couple of facets:

• 当の長い~taskの生成元や`元凶~閲覧~文脈~容器$の［ 全体の中での所在 ］ — これは、 `極小な元凶~帰属@ （ `minimal culprit attribution^en ）と称され， `name$m ~fieldにて捕捉される。 ◎ Pointing to the origin of the long task and/or the overall location of the culprit browsing context: this is referred to as minimal culprit attribution and is captured in the name field.
• `長い~task$が孕む作業の種別, およびそれに結付けられた`元凶~閲覧~文脈~容器$ — これは、 `PerformanceLongTaskTiming$I の `attribution$m ~field内の各 `TaskAttributionTiming$I ~objにて捕捉される。 ◎ Pointing to the type of work involved in the long task, and its associated culprit browsing context container: this is captured in TaskAttributionTiming objects in the attribution field of PerformanceLongTaskTiming.

したがって， `PerformanceLongTaskTiming$I 上の［ `name$m, `attribution$m ］~fieldの組は、 長い~taskの~~原因がどこにあるか~~実像を~~描く。 この情報を送達するときには、 ~Webの同一-生成元~施策を固守するモノトスル。 ◎ Therefore, name and attribution fields on PerformanceLongTaskTiming together paint the picture for where the blame rests for a long task. When delivering this information the Web’s same-origin policy must be adhered to.

これらの~fieldは~~相関する — どう関係するかの概観を次に与える： ◎ These fields are not independent. The following gives an overview of how they are related:

4.1. 長い~taskを報告する

5.1. 何が観測器に公開されるのか？

~top-level~pageの中にある すべての観測器 （すなわち，~pageと~main~frame内のすべての~iframe） は、 長い~taskが在ることについて通知を受信することになる。 それは、 当の~taskの［ 開始~時刻, 所要時間, 元凶~frameへの~pointer ］を公開する （所要時間は粒度 1ms で）。 この情報は、 今日においてすでに， `setTimeout()^m を利用して より高-分解能に観測できる 【それは、閾値 50ms により制限されない】 。 攻撃者は、［ ~page上のすべてを~clearしてから，非同一-生成元に属する脆弱な資源を追加することで、 `setTimeout()^m からの遅延が，その資源により生じることを確保する ］ことにより，これを行える。 【元凶とは】異なる~page（~UItabや~UIwindow）内の観測器は、 ~UAの~architectureを問わず，通知【において`帰属$】を受信するベキでない。 ◎ All observers within the top level page (i.e. all iframes in the page and the main frame) will receive notifications about presence of long tasks. We expose the start time of the task, its duration (with 1 ms granularity), and a pointer to the culprit frame. This information can already be observed today, and with higher resolution, using setTimeout. An attacker can do this by clearing everything else on the page and adding the vulnerable cross-origin resource to ensure that delays from the setTimeout are caused by that resource. Observers in other different pages (tabs or windows) should not receive notifications, regardless of the architecture of the user agent.

非同一-生成元に何が公開されるかに関する規則： ◎ Cross origin rules for what is exposed:

• 非同一-生成元に属する観測器は、 元凶が在る方向を知り得る — 例： 当の元凶は深く入子にされた~iframeである場合、 それを~hostしている~pageは，自身と元凶の合間にある最初の非同一-生成元を知れる。 ◎ Cross-origin observers may see the direction of the culprit e.g if the culprit is a deeply nested iframe, then the host page can see the first cross-origin between itself and the culprit.
• 逆に，元凶の方が~top-level~pageである場合、 深く埋込まれた~iframeは，［ 非同一-生成元に属する先祖~内で，ある長い~taskが生じたこと ］を知れるが，それについての情報は受信しない。 ◎ Conversely, if the culprit is the top level page, then a deeply embedded iframe can see that a longtask occurrred in its cross-origin ancestor but does not receive any information about it.

5.2. 考慮される攻撃~局面

考慮される計時~攻撃として，次が挙げられる： ◎ The following are the timing attacks considered:

• 伝統的な計時~攻撃 ⇒ 外部~資源の読込nにかかる時間を利用して，私的~dataの~sizeを露呈する。 一例として、 ある展示における隠された絵図の個数, ~usernameは妥当かどうか, 等々。 `例＠http://crypto.stanford.edu/%7edabo/papers/webtiming.pdf$ を見よ。 ◎ Traditional timing attacks: using external resource load time to reveal the size of private data. For instance the number of hidden pictures in a gallery, whether username is valid, etc. See an example.
• ~side-channel計時~攻撃 ⇒ ［ 動画~構文解析／ ~script構文解析／ ~app~cache読取n【この特能は~HTMLから廃された】／ `Cache$I ~API（~sw） ］の利用度に関する時間を利用して、 利用者を一意に識別するか, 利用者の［ 年齢, 性別, 所在, 関心事, 等々 ］が成す~profileを作成する。 `一例として＠https://tom.vg/papers/timing-attacks_ccs2015.pdf$， ~social~network内の ある~permalink用の~pageからの状態s更新は、 一定の対象層（例： 20 代の女性）に制限-【するように公開-】され得る。 その~permalink~pageの~file~sizeは、 利用者は当の対象層に属するかどうか決定するために利用され得る。 【対象層に属さないならば、当の~pageを読込まないので，時間がかからない。】 ◎ Side-channel timing attacks: using time for video parsing, script parsing, App Cache reads or Cache API (service workers) usage to uniquely identify a user, or to create a profile of the user’s age, gender, location, and interests etc. For instance, status updates from a social network can be limited to certain demographic (eg. females of age 20-30) the file size of the permalink page can be used to determine whether the user is in the target demographic.

これらの局面は、［ 50ms 閾値, 非同一-生成元に関する境界 ］の組みで取組まれる。 すなわち、 信用されない非同一-生成元に属する観測器には，~taskの種別や追加的な帰属は示されない。 ◎ These scenarios are addressed by the 50ms threshold AND respecting cross-origin boundary i.e. not showing task type or additional attribution to untrusted cross origin observers.