Intent to Remove: -internal-autofill-previewed and -internal-autofill-selected

[Jaeyong Bae]

Contact emails
jdrag...@gmail.com

Summary
Remove pseudo classes :-internal-autofill-previewed and :-internal-autofill-selected.
Un-expose these two classes and make them available for UA stylesheets only.

Each class represents:
:-internal-autofill-previewed class - fields are filled when hovering over an autofill suggestion
:-internal-autofill-selected - fields are filled with a selected autofill suggestion

Motivation
Although being -internal-prefixed pseudo classes, these two pseudo classes have erroneously been exposed for author use. It can be used by a side channel to extract information from autofill before the user decides to disclose it to the website. Those pseudo classes should be only allowed in UA sheets. -internal prefix is used means that we did not intend to expose in the first place. So, there are no :-webkit-* versions of those.

Interoperability and Compatibility Risk
Edge: Not supported
Firefox: Not supported
Safari: Not supported

Alternative implementation suggestion for web developers
The default styling does not get overridden in preview state and selected state.
Only can use :-webkit-autofill pseudo-classes for autofilled state (matched input elements which have been autofilled by user agent).

Usage information from UseCounter
There is no estimated data from UseCounter.

Entry on the feature dashboard
https://chromestatus.com/feature/5778154275733504

[Mike Taylor]

Hi Jaeyong,

<thinking outloud>

Do we think its worth adding one? Or perhaps looking for usage in HTTPArchive as a proxy? I suspect fallout from removing this feature would be pretty minimal - designs might look different in some cases, so perhaps side-channel concerns are overriding here. Not sure if outreach would even be worthwhile, were we to find a popular site or library using this, since there's no recommended alternative.

</thinking outloud>

Entry on the feature dashboard
https://chromestatus.com/feature/5778154275733504

Is there a crbug where interested folks can follow along?

thanks,
Mike

[PhistucK]

> It can be used by a side channel to extract information from autofill before the user decides to disclose it to the website.

Does "information" mean actual data (credentials)? Or is the fact that something was autofilled also bad to be exposed (because it basically means the user probably has an account on that website)?

(I ask because there are other ways to find out about the latter)

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc31bca8-7b9d-b233-cece-f39f6fc38592%40chromium.org.

[Jaeyong Bae]

Hello, PhistucK 

> It can be used by a side channel to extract information from autofill before the user decides to disclose it to the website.

Does "information" mean actual data (credentials)? Or is the fact that something was autofilled also bad to be exposed (because it basically means the user probably has an account on that website)?

(I ask because there are other ways to find out about the latter)

What I meant was the latter. I wonder the other way is common.

 

☆Phistuc

thanks ,
Jaeyong

[PhistucK]

Even if the other ways are uncommon, they will probably get picked up once this is gone.

I am aware of one way that is not being misused - a React-and-Redux-Form-based website had to find out whether autofill happened because otherwise the login submit button remains disabled and the user had to delete one of the autofilled values and re-enter it.

☆PhistucK

[Jaeyong Bae]

Hello, Mike,
 

I also wonder if it's worth adding one as there is no alternative at this time.
It seems like a decision will need to be made depending on the severity of the side-channel concerns.

 

Entry on the feature dashboard
https://chromestatus.com/feature/5778154275733504

Is there a crbug where interested folks can follow along?

Here it is.
https://bugs.chromium.org/p/chromium/issues/detail?id=951476
 

thanks,
Mike

thanks,
Jaeyong 

[Jaeyong Bae]

Even if the other ways are uncommon, they will probably get picked up once this is gone.

I am aware of one way that is not being misused - a React-and-Redux-Form-based website had to find out whether autofill happened because otherwise the login submit button remains disabled and the user had to delete one of the autofilled values and re-enter it.

PhistucK@: Thank you for a detailed description.

After removing these I think it's necessary to block the side channel what you said.

WDYT?

[PhistucK]

Sure, if that is a concern, of course...

Not feeling so comfortable to shoot myself in the foot, but I will share the way privately.

☆PhistucK

[PhistucK]

Or publicly, since it is on StackOverflow anyway -

https://stackoverflow.com/a/41530164

How do you suggest websites that have a disabled login submit button to re-enable it after autofill, though?

☆PhistucK

[Chris Harrelson]

+Dominic Battre for feedback.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KvjXOrJ5WPoRJ%2BuAKpQ9tyRGJu%3D7vsEkpqgN1d8MRkzw%40mail.gmail.com.

[Dominic Battre]

Hi.

Thanks for CCing me. Sorry for the delay. Just returned from vacation.

Thanks for sharing these usecases. I acknowledge the value of exposing the preview state. I will discuss this with some folks on the team and respond here.

Best regards,

Dominic

-- 

Google Germany GmbH - Erika-Mann-Str. 33 - 80636 München - Germany

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[Dominic Battre]

Hi.

I had a chance to look into this a bit more.

This came up in the context of the "Intent to Implement and Ship: :autofill pseudo-class". During a code review, I asked to for a cleanup and removal of -internal-autofill-previewed. I learned that :-webkit-autofill is sensitive to both autofill and preview and I acknowledge the use cases.

I would like to withdraw my request to remove "-internal-autofill-previewed". We'll look into different ways to address the concerns of using this as a side-channel to extract information from autofill before the user decides to disclose it to the website.

Best regards,

Dominic

[Yoav Weiss]

Jaeyong Bae - Should we consider this intent withdrawn?

+Dominic Battre for feedback.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KvjXOrJ5WPoRJ%2BuAKpQ9tyRGJu%3D7vsEkpqgN1d8MRkzw%40mail.gmail.com.

-- 

Google Germany GmbH - Erika-Mann-Str. 33 - 80636 München - Germany

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[Romederful]

Yes, currently it is.

2021년 9월 2일 (목) 오후 7:08, Yoav Weiss <yoav...@chromium.org>님이 작성:

+Dominic Battre for feedback.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KvjXOrJ5WPoRJ%2BuAKpQ9tyRGJu%3D7vsEkpqgN1d8MRkzw%40mail.gmail.com.

-- 

Google Germany GmbH - Erika-Mann-Str. 33 - 80636 München - Germany

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado