Consider marking DefaultLocale as a fingerprinting vector

[littledan]

HTML marks fingerprinting vectors with a big fingerprint icon. Should we do the same with DefaultLocale in ECMA 402? This applies to #106 even more.

(Side note: How does DefaultLocale relate to navigator.locale? Should they be specified somewhere to be equal? Are they in current browsers?)

cc @domenic @foolip @annevk

[zbraniecki]

default time zone as well?

[littledan]

@zbraniecki Yeah, that too; guess this affects ECMA 262 as well. @bterlson @caridy @allenwb How do you think we should go about this?

[caridy]

I don't know! This is mostly a question for @bterlson I think.

[bterlson]

What is an explicit fingerprint vector in 262 (aside from implementation-specific details like stack depth, implementation bugs, etc.)?

Anyway I don't have much of an opinion here - find something that works for 402 and I can adopt for 262 as needed. If it seems like something that you want markup for in ecmarkup it can be added later.

[annevk]

Timezone maybe? Not sure it grabs global state elsewhere.

[domenic]

If the spec talks about stack depth then marking that up would indeed be nice. But yeah, that and some timezone stuff is all I can think of in 262.

[allenwb]

It seems to me that the concept of "fingerprinting" and reasons for concern about it are things that are specific to the browser platform. Other platforms might have other concepts that they think are worthy of flagging as a concern.

The platform independent Ecma specifications don't seem like the right place to try to capture such an open-ended set of platform-specific concerns. To me, it makes most sense for each platform to address such concerns in that platform's specifications.

Does, the HTML spec have a section about integration of ECMA-262 and ECMA-402 into the browser platform? Does HTML require that its JavaScript implementations also support ECMA-402? Perhaps it should. Such a section also seems like the place where the relationship between DefaultLocale and navigator.local could be addressed.

More generally, some of the recent ECMA-402 discussion about tightening some of the current implementation flexibility might be better handled in such an ECMAScript hosting section of the the HTML spec. There is no reason at all why the web platform can't impose additional requirements upon "implementation-dependent" features of ECMA-402 (or ECMA-262). This has the advantage that it preserves implementation flexibility for other platforms that might have constraints or requirements that differ from the browser platform.

[caridy]

Probably a time-boxed topic for upcoming meetings to try to achieve consensus on this.

[leobalter]

In the TC39 TG-2 (ECMA-402) Meeting of today we decided to add a paragraph (or similar) to Annex A saying that Implementation Dependent Behavior might be fingerprintable