
Mixpanel analytics accidentally slurped up passwords - tareqak
https://techcrunch.com/2018/02/05/mixpanel-passwords/?q=1
======
tekkk
One more reason to use adblocker. The beauty of 3rd party scripts running on
your website, hijacking people's passwords like it's no big deal.

I've used Mixpanel as a developer and also been disturbed how they combine
analytics data with the user profiles creating really detailed profiles what
they do on their website. Even that wouldn't be such a big deal if it was
obvious to the user but really there is no law stopping companies from doing
it. I hope GDPR will clear this thing out in the future and companies can't
operate without user's direct consent and opt-in becomes the standard instead
of opt-out.

~~~
ryanwaggoner
That seems crazy to me. It should be illegal for a website to track what you
do on that site? We’re not talking about tracking activity across many sites,
and you don’t need a third-party tool to do this at all. If it were illegal, a
huge number of sites wouldn’t even function without fundamentally changing the
way they work. You know that the HN database has records of all your votes,
comments, etc, right?

I get the outrage at being tracked by third parties across the web, but that’s
different from making it illegal for any website to track any of your activity
_on their site_.

~~~
kangoo1707
How would startups gather BI information then?

~~~
tzahola
Not my problem.

------
RoboTeddy
Looks like Mixpanel is handling this well: they deleted the data, notified
affected customers, and then are making sure it can't happen again. +1 for
admitting responsibility instead of deflecting or minimizing.

~~~
spenvo
Ok, they took responsibility... But they took about a month to notify clients
via email and didn't notify the public until Techcrunch inquired for the
purposes of writing this article. So -1 for not being upfront with end users
and clients.

~~~
ajeet_dhaliwal
Take away a few more for not noticing the problem for nine months.

~~~
snissn
Would be a good move to put together a common password list and regularly
check their data against it.

------
BuildTheRobots
Call me thick and naive if you will, but how does an advert manage to hoover
up all typed inputs on a page including (somehow accidentally) passwords.

Isn't the underlying problem with the web browser that allows this, or are
browsers just fundamentally broken when it comes to protecting users?

~~~
TeMPOraL
Analytics analyze. They read data. Mixpanel decided to read more than they
should, and they unintentionally slurped some passwords.

The core technical problem is that scripts can read data. But that's kind of
their job. "Solving" that would require to reduce the functionality of
webpages.

The core social problem is that people include third-party analytics and
advertisements. Solving that would require to destroy the entire adtech
industry.

I'm all for the latter solution.

~~~
bluesign
Where you will draw the line, then main ad industries will start to serve ads
as 1st party as custom subdomains.

There is no way to win this fight except regulations and oversight

~~~
chopin
In this case, they can be made fully responsible. You'd better vet the
Javascript you're going to deliver.

------
nvr219
Always do ublock origin + privacy badger (and pi hole when you're at home)

~~~
bonestamp2
uMatrix is well worth the time it takes to use too. It shows you a matrix of
exactly what each site is requesting. I've become so much more aware of what
is happening on websites since installing the plugin about a year ago.

The great thing is that it's so quick and easy to enable/disable/customize
too. For example, I've identified two scripts that block websites from loading
when it doesn't get loaded... so I allow those to load on every website -- no
ads, but the site still loads.

Mixpanel is blocked by default in the blacklist that I subscribe to.

~~~
faitswulff
Are those two scripts widespread or specific to a site? And if they're quite
widespread, would you be able to share how to identify them?

~~~
bonestamp2
Just saw one a few minutes ago. It's actually not even the script you need to
allow, it's just an XHR request to adiode.com. I can't remember the other one,
I'll report back here when I see it again (usually every couple days).

I saw the adiode.com one on [https://www.merriam-
webster.com](https://www.merriam-webster.com) if you want to have a look for
yourself.

~~~
TeMPOraL
You mean the "Something interfered with this website loading" fake error
screen? Yeah, that "something" is their bloody script. Bastards.

I hit that one pretty much every other day somewhere; I wonder, how did it
spread so quickly? It must be linked to by some popular ad network or
analytics package.

~~~
bonestamp2
Yup. So if you allow the script to make that XHR request then it thinks the ad
blocker is off and it will show the page but not the ads.

------
NicoJuicy
A lot of people talk here about GDPR, but does anyone know how to "handle"
this in my ecommerce?

I haven't found any indication on how to do it "legally" or a small "howto".
I'm also not interested in an IBM solution that would cost me 10 times my
earnings

~~~
jmickey
In essence the GDPR requires you to be accountable about all personal data you
collect and use in your daily operations.

Compiling a list of all personal data currently located in your systems and
making sure you have a legal basis for each item, goes a long way towards
compliance (though of course this is not all you need to do)

~~~
NicoJuicy
So, let's say:

\- WooCommerce on url xxx: phone number, email,name & address. Google
Analytics & facebook Pixel. Requirement for e-commerce fullfillment and
analysing website performance / ad performance.

\- Mailchimp : email and name, when accepting WooCommerce "Terms and
conditions" n°2. Requirement for recurring ecommerce updates/changes of new
products.

\- OpenERP: ( invoicing - local network) - Firstname, lastname, address,
email, phone, orders. Requirement for invoicing

Somehow i can't believe that would be sufficient.

~~~
jmickey
It can get tricky. Analysing web performance is not a direct requirement to
fulfill orders, so you would need an explicit opt-in from your customers that
lets them agree to their personal data being used in this way.

With Mailchimp you probably need to let your customers separately opt into
their e-mail being used for marketing purposes, as again that use is not
strictly required to fulfil their order.

Same with any other information - your customers need to be aware of all the
ways you will use their data. If any uses are not covered by a legal
agreement, there needs to be an option to opt-in.

~~~
NicoJuicy
Analysing performance is a requirement for more sales.

------
btown
> We immediately began investigating further and learned that the behavior the
> customer was observing was due to a change to the React JavaScript library
> made in March 2017. This change placed copies of the values of hidden and
> password fields into the input elements’ attributes, which Autotrack then
> inadvertently received. Upon investigating further, we realized that,
> because of the way we had implemented Autotrack when it launched in August
> 2016, this could happen in other scenarios where browser plugins (such as
> the 1Password password manager) and website frameworks place sensitive data
> into form element attributes.

Here's the commit in question: [https://github.com/mixpanel/mixpanel-
js/commit/98a1845c5c55f...](https://github.com/mixpanel/mixpanel-
js/commit/98a1845c5c55f8b362847517860cc97c35f1c08e) \- as referenced here:
[https://github.com/mixpanel/mixpanel-
js/issues/164](https://github.com/mixpanel/mixpanel-js/issues/164) .

The meat of it is that the check of the type of the <input> node to ensure
it's not "password" or "hidden," now wraps the iteration over attributes as
well as inclusion of the value.

That heuristic, though, is far from perfect: see, for instance,
[https://www.troyhunt.com/bypassing-browser-security-
warnings...](https://www.troyhunt.com/bypassing-browser-security-warnings-
with-pseudo-password-fields/) . And even if you're not doing something funky
like that, you're not out of the woods. For instance, it's highly likely that
a site collecting "secret answers" in plaintext input fields (for password
resets) would leak that information to Mixpanel if Autotrack were turned on.
This commit does nothing to change that scenario. And while Autotrack is now
opt-in, it can be done entirely by a business team with zero interactions with
engineering, if (for example) a tag management solution is set up: see
[https://mixpanel.com/blog/2015/03/27/community-tip-
implement...](https://mixpanel.com/blog/2015/03/27/community-tip-implementing-
mixpanel-via-google-tag-manager/) and [https://help.mixpanel.com/hc/en-
us/articles/115004613366-Wha...](https://help.mixpanel.com/hc/en-
us/articles/115004613366-What-is-Autotrack-and-how-do-I-get-started-using-it-)

SaaS analytics companies, especially those able to slurp up everything into a
managed data lake and provide perfect retroactive analysis capabilities,
provide a great experience compared to self-hosted solutions, but it's
inevitable that you'll end up giving them more information than you'd
originally planned. For many businesses, that's the right decision, but it
should be one made with eyes wide open.

------
colmvp
On a side note, Mixpanel used to host conferences but stopped after 2014.
Anyone know why?

