SharedArrayBuffer timer to get network timings

[NDevTK]

I think this is separate @terjanq

Demo code: https://glitch.com/edit/#!/jealous-childish-lodge?path=public%2Fmain.js
Demo: https://jealous-childish-lodge.glitch.me/

[terjanq]

I haven't heard of Atomics API 😮 . Maybe we should introduce it in clocks article? What do you think?

One objection I have about this PR is that it adds a significant portion of code snippet to the network timing article that is already one of the longest in the wiki. While we want the snippets to be accurate as possible, the main goal of them is to reflect what we write in plain text into the actual code, or if the snippet is simple enough, accompany it with extensive comments as a replacement.

Instead of writing a working Proof of Concept, I would be leaning more towards presenting the concept and describing it in more depth.

We plan on creating Proof of Concepts in the form of interactive examples in the future which will be focused on making them as accurate as possible, so this amazing job that you are doing should not go to vain. But for the initial iteration I feel like this is a little bit too nuanced.

[NDevTK]

@terjanq I made some changes. do you think https://github.com/cgvwzq/spectre/blob/master/spectre.js#L89 helps with the timer? I dont know what it does.

[terjanq]

I added a few changes in cd746a8 so don't forget to pull before making further changes.

I really like the improvements you did to the sharedArray clock, it is cleaner than it was before, and I also like that you used it with a new technique to showcase how this clock can be used!

[terjanq]

@terjanq I made some changes. do you think https://github.com/cgvwzq/spectre/blob/master/spectre.js#L89 helps with the timer? I dont know what it does.

I am not sure either, but it looks like the spectre attack nuance that clears the memory segments.

[NDevTK]

I tested the difference between performance.now() and sharedArray
The duration difference is higher for the sharedArray clock but both seems to work

[NDevTK]

@terjanq it seems this improves reliability for requests with smaller size differences

async function getDuration2(url) {
    var best = null;
    // Find the lowest duration possible
    for (let i = 0; i < 10; i++) {
        let result = await getDuration(url);
        await new Promise(resolve => (iframe.onload = resolve));
        if (best === null || result < best && result > 0) best = result;
    }
    return best
}
// Or the average
async function getDuration3(url, count = 10) {
    var total = null;
    for (let i = 0; i < count; i++) {
        let result = await getDuration(url);
        await new Promise(resolve => (iframe.onload = resolve));
        total += result;
    }
    return total/count
}

[terjanq]

I added a few suggestions. There will be conflicts when merging to master since I updated the defense tables in the meantime. Also, we should update the defense table for the new attack with Unload Events. I believe the table would look something like:

Unload Events:
SameSite Lax: X^1 (in footnote 1: SameSite Lax could protect against the attack inside an iframe but would not top-level navigations)
Framing Protections: X
COOP: X
Isolation Policies: NIP^2 (in footnote 2: FIP could protect against the attack inside iframes, but wouldn't protect against new windows)

[terjanq]

Suggested change

	{{< hint tip >}}
	Network performance changes may make it harder to derive the transfer size.
	You can do something like the following to get the duration with the best network performance.
	```javascript
	var best = null;
	// Find the lowest duration possible
	for (let i = 0; i < 10; i++) {
	let result = await getDuration(url);
	await new Promise(resolve => (iframe.onload = resolve));
	if (best === null || result < best && result > 0) best = result;
	}
	```
	{{< /hint >}}

I would personally drop this part. This applies to other measurements as well, not only Unload events section.

[NDevTK]

Removed it. could it be moved?

[terjanq]

Potentially yes, but not sure what is the best place yet. Maybe in the future, when (if) we have a section about making the attacks more reliable ?! Very unsure what is the place for it now, and whether it improves the contents significantly

[terjanq]

Merging, will update the defense table later.