
No boundaries for user identities: Web trackers exploit browser login managers - randomwalker
https://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/
======
cm2187
What makes the matter worse is this ridiculous trend that all websites have
adopted of making a two step process, one for login, another page for the
password. I see no good reason to do so, and if the password manager does not
prepopulate the credentials, it forces the user to do many clicks to go
through the process. This is really a moronic design.

~~~
humblebee
This pattern is used for SSO. It doesn't make a lot of sense to request a
password from a user who is using a SSO solution. The issue is the website
needs to do a look up on the username to determine which SSO solution the user
might be using.

There might be a better pattern for this, such as making the determination
through a xhr request when the username field loses focus.

~~~
CydeWeys
Another good thing to do in combination with that is to store the SSO provider
locally (cookie/local storage, whatever). Then simply use that instead of
presenting the two step process -- you can default to the existing server-side
determination if the method stored locally fails.

I don't mind doing the two-step dance _once_ during first login on a new
device, but having to deal with it every time is infuriating and lazy on the
part of the company.

~~~
zanedb
But what if the user needs to login through a different provider?

~~~
CydeWeys
That could easily just be a different link, like the "Forgot password" link,
presented at the main login page. You wouldn't interact with it normally, and
thus it'd never interrupt your typical logon flow, but it'd be there when you
need it.

I'm still not really sure what purpose this two-step login is solving, though,
as typically every time I use an SSO it's by clicking on a button like "Log in
through Facebook" or "Log in through Google", before I'm ever even asked to
enter a username. Why do they need to know the username? They'll know that
when I log in using the SSO provider.

------
iforgotpassword
I never understood this behavior. Opera presto had a dedicated "fill with
saved credentials and submit" button in the toolbar (or ctrl-enter). Problem
avoided. Autofill never made the overall process faster. On the contrary, if I
want to use different credentials I have to manually clear the form first.

~~~
so33
1Password does this also, and I believe LastPass. I too prefer this behavior
to autofill, especially in situations where I have, say, multiple Google
accounts, to the point where the UX tradeoff (introducing extra UI) is totally
worth it.

------
tofflos
Is disabling autofill really a solution for the majority? These publishers are
handing over their users' credentials to a third party. If enough people
disable autofill they will just move the script to the login page and capture
their users' credentials as they are manually typing them in.

The top Polish sites need to clean up their act.

~~~
cpv
Not totally related, but imagine an online banking website with 3rd party
scripts.

------
quantumfoam
For FF users: about:config - set signon.autofillForms to false.

~~~
QAPereo
Would uBlock Origin and uMatrix do the job?

~~~
thg
For uBlock it depends on whether the script is hosted on a blacklisted site.
If it is, the script won't get loaded, but if it isn't, uBlock isn't going to
do anything about it.

uMatrix does prevent this as long as you keep the script blocked. But of
course you're going to be out of luck if you have to allow scripts from the
host that also hosts the script that exfiltrates the data. Sadly, there aren't
really many sites left that function without at least partial JavaScript
execution. Thus, as was mentioned in other comments already, disable auto
pasting for your browser or possibly use a plug-in that disables it for you,
as you can't really rely on uBlock, nor uMatrix, to reliably protect you
against this.

~~~
QAPereo
I see, thanks for the highly informative reply... I’ll definitely disable auto
fill.

------
kevin_b_er
I was using Secure Login for Firefox for a good while, but it died in e10s era
and probably doesn't have the hooks to block this at all in Firefox Quantum.
One of its useful features was to not fill out anything, username/email
included, until I clicked a button.

~~~
Izkata
I haven't upgraded yet, but it sounds like KeePassHelper can do something
similar - I have it listed as "try this replacement" for when I do eventually
upgrade: [https://addons.mozilla.org/en-
US/firefox/addon/keepasshelper...](https://addons.mozilla.org/en-
US/firefox/addon/keepasshelper/)

Seems to require some setup though, and stores passwords outside of Firefox?

~~~
kevin_b_er
Not much of a replacement when I'm fine with firefox's password manager. It
seems plenty secure when a master password is set and thus the passwords are
encrypted at rest.

~~~
thuspoint
> when a master password is set and thus the passwords are encrypted at rest

They are not
[https://bugzilla.mozilla.org/show_bug.cgi?id=1284343](https://bugzilla.mozilla.org/show_bug.cgi?id=1284343)

------
ecesena
I wonder if the parent sites are even aware of this.

If you can get (well, you can) the autofilled email+password, might as well
automatically log the user in.

Edit: it's also interesting to see so many EU sites, where in theory you
should show a disclaimer for cookies, but apparently it's ok to extract email
addresses.

~~~
sjmulder
They aren't allowed to, of course, and the banner is treated like a formality
in an almost cargo cult like fashion.

~~~
chatmasta
The “we use cookies!” banner is ridiculous. I always click “no thanks”
whenever it’s an option, but obviously it changes nothing. That banner is a
great example of useless regulation that accomplishes nothing yet wastes the
time of users and developers.

~~~
toyg
It started as a legitimate complaint about user tracking but it was eventually
lobbied into nothingness. Meaningful legislation would have hit the industry
hard, at a time when IT/web was one of the few sectors holding on in the Great
Crisis, so the EuroParliament got cold feet. They seem to have done a better
job with the GDPR, which really should have come before the cookie stuff
anyway; there is a chance the matter will be reviewed once the GDPR is fully
implemented.

------
inetknght
This just reminded me why disabling autofill is one of the first things I do
when using a new browser.

~~~
dylan604
I've never disabled it directly, mainly because I'm not intimately familiar
with all of the about:config options, but I have always selected the "Never
for this site" whenever that popup presents itself. Deep down, I always
thought it was a bit tin-foil hat on my part, but sounds like it was good
intuition after all.

------
walterbell
Why do browsers autofill non-visible forms?

~~~
gruez
because it's hard to determine whether something is visible. what if it's
offscreen? what if it's partially off screen? what if it's 0% opacity? what if
it's 0.001 opacity? what if it's 1px height/width? what if something is
overlaid on top of it?

~~~
sirmarksalot
Most importantly, the page could easily wait until the login manager fills it
in, and then immediately hide the form.

~~~
walterbell
Can the browser prevent visibility changes to auto-filled forms?

~~~
adamson
I feel like that'd be a terrible user experience on non-malicious sites

------
daddosi
Lets be honest. Browsers and webstandards never gave us the things needed to
build a nice userbase for our little web projects. Persona was a cool
idea/step in the right direction but it came much to late. Everyone is on big
web farms now where they can do many things after suffering though the arcane
form just once.

------
exikyut
From the article:

> _Chrome doesn’t autofill the password field until the user clicks or touches
> anywhere on the page._

When I tried the demo, clicking through to part 2 only autofilled the
username, but when I hit F5 to reload the page it autofilled the password too.

Chrome 63.0.3239.108

~~~
totallynotcool
Using the same version of Chrome on Ubuntu and I cannot recreate this. I have
to click ~somewhere~ on the page before the password is filled, just
refreshing does not cause the issue.

------
paulryanrogers
It would seem the only guaranteed way for a browser to avoid interception of
credentials is to deny JS access to sign-in fields. Even write-only access
risks allowing other scripts access to the key and mouse events.

Am I missing something?

------
totallynotcool
That's part of running 3rd party scripts on your site. I guess the worst part
of this is sniffing auto-fill credentials without user interaction- i.e.
submitting a form- however listener/callback on the submit button could
accomplish the same thing.

Only thing I can think of to thwart auto-fill sniffing is populating the form
with junk data on page load then waiting for the user to enter their access
id/user name before the password field is filled. This "solution" still
doesn't protect the 3rd part script from intercepting the submit button.

------
ivanhoe
For this to be significant you first need a) to register on that site b) to
explicitly logout and clear all the cookies for that domain(otherwise they can
track you anyway). How many people does this? Of course, disabling auto-fill
option is a smart thing to do regardless of this, I'm just saying that this is
not affecting the most of the population.

------
dao-
> Users can install ad blockers or tracking protection extensions to prevent
> tracking by invasive third-party scripts. The domains used to serve the two
> scripts (behavioralengine.com and audienceinsights.net) are blocked by the
> EasyPrivacy blocklist.

Firefox has built-in tracking protection that should block these scripts.
Enable it in about:preferences#privacy.

------
KozmoNau7
Nothing happened, which just makes me even more appreciative of uBlock Origin
in dynamic mode with default-deny on all 3rd-party resources.

I'll still set signon.autofillForms to false, though. For peace of mind.

------
leeoniya
uMatrix

~~~
mr_toad
The article seems to suggest that at least some sites are embedding the script
to avoid same origin policy, which will also bypass uMatrix.

This is equivalent to hosting something like JQuery from your own domain,
instead of using a CDN. As a site owner you have to trust that scripts like
JQuery aren’t going to do bad things.

They could just as send the email addresses (and passwords) directly to third
parties. It’s not clear whether the site owners are witting collaborators in
this or if they don’t know what the scripts are doing.

~~~
leeoniya
there are companies that specifically market as CDNs to advertisers to allow
third-party scripts to appear as first-party. it's nasty shit:

"The company's technology disguises third-party network requests so they
appear to be first-party network requests."

[https://www.theregister.co.uk/2017/08/11/ad_blocker_bypass_c...](https://www.theregister.co.uk/2017/08/11/ad_blocker_bypass_code/)

however, the demo page linked in this thread failed to work for me as uMatrix
blocked an injected 3rd party script

