+Dominic Battre <bat...@chromium.org> for feedback. On Wed, Aug 18, 2021 at 5:23 AM PhistucK <phist...@gmail.com> 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 <phist...@gmail.com> 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 <jdragon....@gmail.com> >> 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 <jdrag...@gmail.com> 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 <mike...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Hi Jaeyong, >>>>>>> >>>>>>> On 8/16/21 10:27 AM, Jaeyong Bae wrote: >>>>>>> >>>>>>> >>>>>>> *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. >>>>>>> >>>>>>> <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 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 >>>>>>> <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 blink-dev+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KvjXOrJ5WPoRJ%2BuAKpQ9tyRGJu%3D7vsEkpqgN1d8MRkzw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-sD0HxwiTxt3YwVWkNNFWO3Cf_G-UNSEU8Q7beNEY%3DVA%40mail.gmail.com.
