Provide a means for attenuating time zone data

[gibson042]

(split from #231 at the request of @littledan)

For both testing and security, it should be possible to share with untrusted code a Temporal object that does not leak any information about system knowledge or recency of time zone data because all of its time zone lookups are under author control. In other words, I need the ability to write code such that whether Temporal.Absolute.from("2020-01-01T00:00Z").inTimeZone("America/Sao_Paulo") and Temporal.Absolute.from("2019-12-31T22:00-02:00[America/Sao_Paulo]") reflect Daylight Saving Time on any arbitrary host is up to me, and also such that Temporal.Absolute.from("2019-12-31T22:00-02:00[Mars/Olympus_Mons]") works according to rules that I provide.

One obvious approach would be to always resolve time zones through a property on the primordial initial value of Temporal.TimeZone rather than privileged access to data through internal slots and/or abstract operations, allowing for satisfaction of these use cases through monkey-patching. Another approach would be to go through those private channels, but add a side interface by which the data they access could be manipulated. There are probably other approaches that could work as well.

[kaizhu256]

rather than Temporal.Absolute, can't you share w/ untrusted-code a [utc-based] isostring or number/bigint instead?

[gibson042]

Yes, but that doesn't address use cases calling for e.g. temporal arithmetic.

[kaizhu256]

@gibson042's scenario of message-passing Temporal.Absolute to untrusted-code is not very convincing as having better usability than just using isostrings. can you give better scenarios?

[pipobscure]

The way we conceived it, was that DateTime and Absolute would NOT use abstract operations in inTimeZone but rather would get the intrinsic Temporal.TimeZone and use it to get the TimeZone.

[littledan]

I'd like to understand more about the motivation here, and if anyone has any idea for concretely how they'd like this to work.

@gibson042 You use words like "untrusted" and "privileged". Can you say more about why you see access to timezone data as something which requires a certain level of privilege? I wonder if it is enough that the Temporal object's properties may be overwritten with classes that don't reference the tzdb. This would be analogous to how, for SES, we decided that it would be enough to be able to overwrite the Temporal.getCurrentDateTime() (and similar) methods.

@pipobscure Can you say more about this, or point to some other discussion? I don't understand how that makes any more flexibility, if it's based on the original intrinsic and then, from there, using internal slots. It's hard for me to understand how this could be based purely on dynamic property access.

[gibson042]

The way we conceived it, was that DateTime and Absolute would NOT use abstract operations in inTimeZone but rather would get the intrinsic Temporal.TimeZone and use it to get the TimeZone.

That may or may not satisfy the concern. If use of the intrinsic Temporal.TimeZone entails a direct invocation (e.g. as a constructor), then it is insufficient because author code cannot replace it. If use entails an internal slot lookup, then it is insufficient unless author code can replace the contents via some other interface. But if use entails a runtime-interceptible [[Get]] (e.g. of Temporal.TimeZone.from), then this issue is resolved.

@gibson042 You use words like "untrusted" and "privileged". Can you say more about why you see access to timezone data as something which requires a certain level of privilege?

Because it is a source of nondeterminism that causes the same code to yield different results from identical inputs. In principle, it could be exploited to e.g. detect developer-workstation hosts and help an attack sneak into a "works for me" resolution.

I wonder if it is enough that the Temporal object's properties may be overwritten with classes that don't reference the tzdb. This would be analogous to how, for SES, we decided that it would be enough to be able to overwrite the Temporal.getCurrentDateTime() (and similar) methods.

I don't believe that is enough. In practice, I expect replacing every interface in Temporal that could potentially accept a time zone name anywhere in its input to be so burdensome and so likely to be accidentally incomplete that projects like SES will instead opt to block Temporal completely, as they do for Intl.

if anyone has any idea for concretely how they'd like this to work.

There are some in the issue description.

1. always resolve time zones through a property on the primordial initial value of Temporal.TimeZone

   // assumes that all time zone lookups go through `from`
   // ...including those in the TimeZone constructor
   Temporal.TimeZone.from = hideImplementation(function from( tzName ) {
     tzName = String(tzName);
     if ( tzName == "America/Los_Angeles" ) {
       return staticZone;
     }
     throw new RangeError(`Invalid time zone specified: ${tzName}`);
   });

2. add a side interface by which [data that internal operations access] could be manipulated

   for ( { name } of Temporal.TimeZone.getAll() ) {
     Temporal.TimeZone.add(name, null);
   }
   Temporal.TimeZone.add("America/Los_Angeles", staticZone);

[pipobscure]

I've had this exact conversation with Mark in NY. At the time, he did not seem very concerned about general TimeZone database data being a vector. What he did seem concerned with was that the current system timezone not be exposed.

For that reason, the Temporal.getCurrentTimeZone() function is directly on Temporal and not ever used to default any timezone values. The default for anywhere the timezone parameter could be used but is missing is UTC.

So from that conversation I concluded that this is a non-issue. Of course I invite Mark to comment here. (Will forward thread-link by mail).

[littledan]

cc @erights

[ptomato]

Meeting Jan. 27: We believe monkeypatching any methods to do calculations with the time zone should be sufficient for this purpose.

[littledan]

Closing as this is fixed by #498, as noted in #273 (comment)