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 -- 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-K0r0TffkdKDOwsgCFwDQR-x5__usPmEJpu54T9N8Uwfvg%40mail.gmail.com.
