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 On Thu, Aug 26, 2021 at 10:28 PM Dominic Battre <[email protected]> wrote: > 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 > > On Thu, Aug 19, 2021 at 9:13 PM Chris Harrelson <[email protected]> > wrote: > >> +Dominic Battre <[email protected]> for feedback. >> >> On Wed, Aug 18, 2021 at 5:23 AM PhistucK <[email protected]> wrote: >> >>> 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* >>> >>> >>> On Wed, Aug 18, 2021 at 1:19 PM PhistucK <[email protected]> wrote: >>> >>>> 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* >>>> >>>> >>>> On Wed, Aug 18, 2021 at 12:30 PM Jaeyong Bae <[email protected]> >>>> wrote: >>>> >>>>> 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* >>>>>> >>>>>> >>>>>> On Tue, Aug 17, 2021 at 9:01 AM Jaeyong Bae <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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* >>>>>>>> >>>>>>>> On Mon, Aug 16, 2021 at 5:52 PM Mike Taylor <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Jaeyong, >>>>>>>>> >>>>>>>>> On 8/16/21 10:27 AM, Jaeyong Bae wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> *Contact emails *[email protected] >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> <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 >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 [email protected]. >>>>>>>>> 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 >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc31bca8-7b9d-b233-cece-f39f6fc38592%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> >>>>>>> thanks , >>>>>>> Jaeyong >>>>>>> >>>>>> -- >>> 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 [email protected]. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KvjXOrJ5WPoRJ%2BuAKpQ9tyRGJu%3D7vsEkpqgN1d8MRkzw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> > -- > 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 > -- 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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFa1-K0qo9frqoLi5%3DoYeYX%3D%3D_sryy7sLgAnc3MbsZ51JKxpJQ%40mail.gmail.com.
