autocomplete tokens for EID and IMEI

[annevk]

What problem are you trying to solve?

Autofill of the Embedded Identity Document (EID) and International Mobile Equipment Identity (IMEI) in select contexts whereby HTML forms are used.

What solutions exist today?

None.

How would you solve it?

Colleagues and I would like to suggest adding these autocomplete tokens for EID and IMEI:

• device-eid
• device-imei

It's not expected that general purpose user agents support autofill for these identifiers. In fact, we'd recommend against it. The main implication for general purpose user agents is supporting them for the purposes of the IDL-exposed autofill value.

We expect these to be useful in select operating system or trusted application flows whereby the operating system can guarantee the information is shared, provided the user consents, with a trusted party.

Anything else?

Usage might look as follows:

<p><label>EID: <input name=eid inputmode=numeric autocomplete=device-eid></label>
<p><label>IMEI: <input name=imei inputmode=numeric autocomplete=device-imei></label>

@battre @hsinyi @DimiDL @whatwg/forms I'd appreciate your feedback.

[battre]

I cannot speak on behalf of Chrome here. Without a clear usecase I don't see that we would implement autocomplete behavior for these tokens, but my read is that you are not asking for that, only that we reflect the value if JavaScript reads or writes the attribute. That would be a ~2 line change and sounds feasible.

[smaug----]

What are the use cases?

[annevk]

These identifiers are among what's needed for the end user to obtain an eSIM. Appreciate the quick feedback!

[DimiDL]

I'm not in a position to speak for Firefox on this issue. I agree that browsers shouldn't automatically fill in such information for users, and I don't see a need to do so as well. I do think it makes sense for a trusted application to autofill EID or IMEI with the user's consent. After all, manually inputting EID and IMEI isn't straightforward. Besides obtaining an eSIM, are there any other use cases?

[annevk]

HTML Standard change is at #9913 and basic test coverage at web-platform-tests/wpt#42965.

@battre @smaug---- @DimiDL who can speak for Chromium and Gecko in terms of implementer interest here? And to be clear, the ask here is that these tokens are recognized and won't be clashed with in the future, not that they necessarily do anything.

[smaug----]

I don't think we should add these kinds of non-web features to the HTML spec. Sounds like they would be used only by some Apple internal thingie, so the values could be documented elsewhere.

[annevk]

These identifiers are expected to be used by a variety of non-Apple websites. Similar to those websites already consuming these identifiers. It seems better if they do not have to use proprietary identifiers therefore.

Any operating system for an eSIM-supporting device might well end up having to support the same websites in similar setup flows and would want to interoperate with these identifiers I would think.

[smaug----]

Sure, used by non-generic websites, and the feature could be fully used only when one browses them using some non-generic browser. Do we have any other features like this in the platform, where we explicitly reserve identifiers and kind of functionality too to be used only by non-browsers?

[annevk]

There's quite a few <meta> and <link> features for search engines and the like.

[saschanaz]

Just curious, which eSIM providers require IMEI? Airalo didn't require such info, is it common for providers to ask one?

[smaug----]

Are there features for other browser-like applications defined in the spec?

[beverloo]

Hi Anne, from an Android perspective we're supportive of adding these autocomplete tokens. +1 to recommending against supporting it in general purpose user agents: access to MEID and IMEI tokens is restricted on Android.

Two further thoughts:

• It would be good for the IDL-exposed autofill value to only reflect if the tokens can be supported. Asking users to fill in their MEID and IMEI manually requires novel UX.

• That said, such UX is possible and some exists today. Based on that I'd argue that these tokens help to optimise a flow for regular Web content when ran in specifically privileged user agents. It's not clear to me why we would not want to support that, as those, in many ways, are still browsers.

[annevk]

Thanks @beverloo. Overall that sounds workable. We don't currently have the concept of a supported token, but we can add that. The main problem I see is the implications for existing tokens as I doubt all of them are universally supported.

Exposing support would also increase the fingerprinting surface. Usually it probably does so not beyond what exposing the user agent ends up exposing, though for EID and IMEI it would and maybe for others as well (again, hard to see through the implications).

Did you all perhaps think through what it might mean for existing tokens to add this new dimension? (I suppose we could also just add it for EID/IMEI now and leave the rest for "later".)

[beverloo]

I don't think we have to block on adding a concept of a supported token, your concerns are sound and I hadn't considered the impact on fingerprintability. That's probably less of a concern for (M)EID/IMEI specifically, as those, when autofilled, are among the most stable identifiers on a device.

[battre]

Chrome is ok with adding the new attribute values and reflecting them in the IDL-exposed autofill value. We are not planning to support filling these types at the moment.

[annevk]

This issue got discussed during WHATNOT and it seems like Mozilla may be objecting.

Here's why I think it makes sense to define these values in HTML:

• These tokens allow you designate the semantics of two new types we did not have coverage for before. Apart from autofilling this can allow for a variety of applications. HTML has many of these kind of features, such as <blockquote cite>, <meta name=application-name>, etc.
• Websites that want to annotate their fields in this way still want to be valid HTML and it makes sense for valid HTML to be defined in the HTML Standard.
• A general purpose web browser may figure out a way to provide autofill for these values without compromising on end user privacy or security. All the proposed normative text says is that you have to be careful.
• A registry seems like too much overhead and generally the WHATWG tries to avoid registries as they have all sorts of issues.

[annevk]

@smaug---- @saschanaz could you clarify whether Mozilla is objecting to this change or not?

[zcorpan]

@annevk we think this shouldn't be added to the HTML standard. See mozilla/standards-positions#1002 (comment)

[annevk]

@zcorpan it's still not clear from that what you prefer we do instead (although I'm not sure there's still an option to change course at this point in time).

[zcorpan]

You can document this in a separate spec or vendor-specific docs, or add support in Safari.

[annevk]

How does that better serve web developers and implementers than documenting it in the HTML Standard? It also introduces the theoretical risk of clashes.

[zcorpan]

A separate spec for features that are only suitable for OS vendors to implement would make it clearer where you're adding features that increase the coupling between platforms and browser engines.