ecma402
ecma402 copied to clipboard
tc39
Consider marking DefaultLocale as a fingerprinting vector
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 Yeah, that too; guess this affects ECMA 262 as well. @bterlson @caridy @allenwb How do you think we should go about this?
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.
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.
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.
Probably a time-boxed topic for upcoming meetings to try to achieve consensus on this.
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
Fingerprintable behavior is the implementation-dependent stuff in Annex A plus the default locale.
Do we have a way to do this in ecmarkup yet? I don't think so. Should I just improvise in the meantime with a emu-note?
You can use HTML and CSS in ecmarkup. See how "normative optional" works in ECMA-402. If it reaches more common use, we can look at upstreaming it into ecmarkup.
Note that on the platform side we now have a single point for features that can be used for fingerprinting and tracking to point to: https://infra.spec.whatwg.org/#privacy. Bikeshed also supports this.
@ben-allen has been doing a lot of work in this space. The ILD behavior in the spec should be defined as derived from the user agent. See #588.
My suggestion here is to add a (normative note?) that says that DefaultLocale is "derived from" navigator.languages in environments that have such a thing. In Node.js, it might be derived from something else. I would be happy resolving this issue with a pull request of that nature.
Also, just to clarify:
Fingerprintable behavior is the implementation-dependent stuff in Annex A...
This part should be resolved by #588 / #780.
In Node.js, it might be derived from something else.
In Node.js IIRC, it's derived from the $LANG and $LC_* env vars.
Why not make it a host hook if they are meant to be equal?
They aren't equal. For example, I set my Accept-Language to ['eu', 'en-US'], but my DefaultLocale is en-US because Chrome does not support eu.
I see. I think a host hook would still be appropriate though and then hosts can determine whether they should be equal or not (and which can be overridden by end users and how).