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

141 views
Skip to first unread message

Jaeyong Bae

unread,
Aug 16, 2021, 10:27:41 AMAug 16
to blink-dev

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

unread,
Aug 16, 2021, 12:52:24 PMAug 16
to Jaeyong Bae, blink-dev
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

unread,
Aug 16, 2021, 4:53:21 PMAug 16
to Mike Taylor, Jaeyong Bae, blink-dev
> 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

unread,
Aug 17, 2021, 4:01:09 AMAug 17
to blink-dev, PhistucK, Jaeyong Bae, blink-dev, mike...@chromium.org
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

unread,
Aug 17, 2021, 5:01:42 AMAug 17
to Jaeyong Bae, blink-dev, mike...@chromium.org
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

unread,
Aug 17, 2021, 1:08:31 PMAug 17
to blink-dev, mike...@chromium.org, blink-dev, 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?

thanks,
Mike


thanks,
Jaeyong 

Jaeyong Bae

unread,
Aug 18, 2021, 7:30:41 AMAug 18
to blink-dev, PhistucK, blink-dev, mike...@chromium.org, 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

unread,
Aug 18, 2021, 8:20:14 AMAug 18
to Jaeyong Bae, blink-dev, mike...@chromium.org
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

unread,
Aug 18, 2021, 8:23:10 AMAug 18
to Jaeyong Bae, blink-dev, mike...@chromium.org
Or publicly, since it is on StackOverflow anyway -

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

PhistucK

Chris Harrelson

unread,
Aug 19, 2021, 3:13:16 PMAug 19
to PhistucK, Dominic Battre, Jaeyong Bae, blink-dev, mike...@chromium.org

Dominic Battre

unread,
Aug 26, 2021, 4:29:26 PMAug 26
to Chris Harrelson, PhistucK, Jaeyong Bae, blink-dev, mike...@chromium.org
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

unread,
Aug 30, 2021, 8:29:50 AMAug 30
to Chris Harrelson, PhistucK, Jaeyong Bae, blink-dev, mike...@chromium.org
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

unread,
Sep 2, 2021, 6:08:03 AMSep 2
to blink-dev, Dominic Battré, PhistucK, Jaeyong Bae, blink-dev, Mike Taylor, Chris Harrelson
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.

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

unread,
Sep 4, 2021, 9:55:42 PMSep 4
to Yoav Weiss, blink-dev, Dominic Battré, PhistucK, Mike Taylor, Chris Harrelson
Yes, currently it is.

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


-- 
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
Reply all
Reply to author
Forward
0 new messages