[Investigation] Different ways to do System I/O via Intl.*

[caridy]

Preliminar list of potential issues:

• hour12 / hourCycle?
• default locale (e.g.: Intl.DateTimeFormat().resolvedOptions().locale)
• default timezone via resolved object (e.g.: Intl.DateTimeFormat().resolvedOptions().timeZone)

/cc @erights

[littledan]

When you say "System I/O", are you talking about fingerprinting vectors that you can read, or information leaks that you can write to? I see some of these as the former, and none of them as the latter. In particular, I don't see what hour12/hourCycle gives you for fingerprinting.

In my opinion, it'd be worth it to document all the fingerprinting vectors in the spec as such, which the WHATWG HTML spec does as well.

@caridy @erights could you give any more context about what you're looking for in this investigation?

[erights]

Realistically, these are not significant threats to security but are "threats" to virtualizability. Put another way, these are dependencies that should be injectable. In the terminology of https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements these are "behavior sensitive instructions".

Agreed that these particular ones are minor. But we need a comprehensive list. All should be kept separate from computational "instructions" so that they can be virtualized separately; such as on a separate System object.

Date.now is worse, because it provides much finer grain time, enabling meaningful measurement of duration for reading timing channels. It actually is security significant. We now plan to hook it via the Realms API. But this is a desperation move because we do not have a choice about its inclusion in the primordials.

Finer grain time would be even worse. This includes the use of shared memory buffers among concurrent agents. However, there is no unprivileged ability to create an agent. A shared memory buffer that is not actually shared does not provide a timing channel.

[caridy]

To clarify, there are two aspects of this, and I'm not sure if both are relevant:

1. calling Intl.DateTimeFormat().resolvedOptions().timeZone twice in the same app (same realm) might produce a different value (imagine that the user change the system settings in between calls without refreshing the app).

2. virtualizing timeZone in a realm requires polyfilling a bunch of APIs.

It seems to me that both are relevant. But I'm more concern about 1 since that's really the System I/O offender. I will like to someone to clarify if this is actually the case today (I believe it is, but I haven't test it). If that's true, maybe we can reform it in a way that the value is computed once per Realm, but I suspect that such change is going to break few existing apps.

[caridy]

Note to self: I will probably do some research on which browsers are actually updating timezone and co., and how app frameworks are caching instances of DateTimeFormat.

[littledan]

cc @domenic ; this seems to relate to a broader proposal about a System object that Domenic has expressed opinions on elsewhere.

There are a few aspects to this. I think virtualization is one use case, and changing the "current" locale and timezone is another one. They are related and might be solved by a common API, but they could also be solved by different ones.

[domenic]

In general I think a holistic discussion needs to be had about how ES and its hosts should support mocking or injecting of the state of the world. Until now we've done well with the usual language-provided facilities, i.e. the ability to override methods and globals; this is used by libraries such as lolex with large success (~3.7 million downloads per month).

But if we want to as a committee decide that this should be configurable from some central location, such that all scripts (in what scope? a realm? an agent?) see mocked-out values for time and locale values, then we need to have that discussion, and make sure it also gets consensus from stakeholders of embedding APIs like Node and the web.

Until we have that conclusion, I don't think these things should be configurable or injectable.

---

calling Intl.DateTimeFormat().resolvedOptions().timeZone twice in the same app (same realm) might produce a different value (imagine that the user change the system settings in between calls without refreshing the app).

This seems working as intended! It would be really bad if you could not detect time zone changes in this way, I believe, and indeed be a huge bug farm when trying to synchronize with your server.

[sffc]

Related: #210

[sffc]

I don't see any open action items on this issue, so I'm inclined to close it for now.