search

tc39 / ecma402

Status, process, and documents for ECMA 402
https://tc39.es/ecma402/
Other
537 stars 105 forks source link

Consider marking DefaultLocale as a fingerprinting vector #110

Open littledan opened 8 years ago

littledan commented 8 years ago

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 commented 8 years ago

default time zone as well?

littledan commented 8 years ago

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

caridy commented 8 years ago

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

bterlson commented 8 years ago

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 commented 8 years ago

Timezone maybe? Not sure it grabs global state elsewhere.

domenic commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

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

leobalter commented 4 years ago

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

sffc commented 4 years ago

Fingerprintable behavior is the implementation-dependent stuff in Annex A plus the default locale.

ryzokuken commented 4 years ago

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?

littledan commented 4 years ago

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.

annevk commented 4 years ago

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.

sffc commented 1 year ago

@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.

sffc commented 5 months ago

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.

annevk commented 5 months ago

Why not make it a host hook if they are meant to be equal?

ryzokuken commented 5 months ago

In Node.js, it might be derived from something else.

In Node.js IIRC, it's derived from the $LANG and $LC_* env vars.

sffc commented 5 months ago

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.

annevk commented 5 months ago

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).