I noticed the same for my bank too. Wrote a blog post complaining about it and got a call from them. Essentially their argument was that "we have a confidentiality agreement with Google and that is sufficient to ensure that your data won't be compromised."

So glad I have uBlock Origin.

I might be wrong but I think Ublock origin does not block google analytics, atleast with default settings. I have installed ghostery for that. Will check and confirm.

It does if you load the Ublock - Privacy list. However I can't tell you whether it's enabled by default.

It does block Google Analytics by default.

kaiser permanente (doctor) has not only google analytics but doubleclick links on their online health services. Even the pages to communicate with your doctor or view test results. kp.org

I complained about this (and blocked everything), but at one point they required I accept an onerous terms of service to continue to use the site. So I requested they delete my account. Well, apparently they cannot delete an account, only inactivate it. They didn't do that and I still

California DMV has not only google analytics, but will log you into google when you use their site. dmv.ca.gov

It is hard to mindfully resist.

Doubleclick, just means they're running ad campaigns on Google, targeting pages on kp.org. It's standard practice for health insurers' websites, like kp.org.

Is that supposed to make it okay?

I personally have no problem with this. I’ve worked in this space in health care and understanding how these metrics are used.

It’s no different than running Webtrends on a website. Companies want to know how people interact with sites and the methods as to how they arrive.

This is where GDPR would help. They wouldn't be able to keep your account and personal info.

Google Analytics does not transmit page content like your account balance. It can see that you viewed the account balance url but knows nothing about what is displayed.

There are however other trackers that could send such information if they are not configured correctly.

What it does or what it does not is of no consequence to me. What it could do is what matters because I don't have the time to check whether or not someone at Google or some US agency decided that they want to know. The easy solution is to make sure that it can't happen, which is to stop using GA tags on logged in parts of the website.

They would need to remove GA from all pages on the same origin. JavaScript in any page can perform an AJAX request to read HTML, and those requests will send cookies.

So I am supposed to check the script Google sends me every time I access the page that this script does not now (only in an A/B test! Only in beta! It was a human error!) send all the page content to Google as well? Ridiculous.

Nothing to see here folks, it's just 'meta-data' .. move along.

[edit: /s]

I experienced the same thing on one of my credit card account management interface.

I have been using ublock + configured my router as DNS server using https://github.com/StevenBlack/hosts/

The DNS server has the advantage of filtering for the mobile devices on WiFi as well, which is a nice plus.

Imagine how much money you'd be able to syphon if you could access the javascript that serves these pages!

You can't get at the $ but you can get at the individual transaction data. They really should not have third party js on banking and medical sites, especially not for logged in users.

Are you absolutely sure about this (would love a reference)? Letting another party running code removes at least many layers of defence. I would not trust a bank which is doing that it's just a sign of gross incompetence.

2FA should at least in theory stop them from doing that. But if the script rewrites the page then maybe there are interesting ways around that.

Third party code within your banking website has access to anything you can do from the UI.

That includes siphoning money from your account.

I have a hardware token and a chipcard to stop that from happening, still, there may be some way to do it that I'm not aware of. One way I can think of is to display one set of destination details for a transfer to the user and use another for the actual transfer.

The hardware token I use shows amount and recipient. At least you could notice.

From my banks web site? Effectively zero. Nothing will happen unless you validate the transactions using two factor authentication (user id + code app/single use paper code)

(In my experience all bank web sites work like above here in Finland)

One possible attack is to change the details of a transaction before the page post it. To the user it would appear as she's transferring money to Bob, but it'd go to Eve.

My bank has two-factor using some special applet thingy on my phone (not a regular app, it's tied into the SIM card somehow). It shows me the details (amount and destination account) which I have to confirm using my password (in combination with a key from the SIM).

Much more difficult to circumvent, assuming the user pays attention...

Then, the malicious script can just pop up an official looking dialog box with a message saying that they are 'testing' the confirmation system, and please accept/agree to the next sms/alert from the app.

Having direct control of the user interface is very powerful.

Of course one has to have a minimum of awareness for any protection mechanism to work.

Eve should be among the known receivers though, which is a world of slow (~72hours to add an IBAN to my list for instance).

There are banks that try to make it faster though, with MFA, though the MFA system is usually SMS.

The banks I've used in Canada allow you to send transfers (uip to $3000) to other domestic bank accounts without reautenticating. Fortunately, they don't seem to use any third-party JavaScript.

Nothing. That is not how online banking works. At all. Payments need validation, check and balances (quite literally) at multiple stages before any money changes hands.

Really depends on how secure your bank is, because a lot of major banking trojans work in a very similar way : injecting JavaScript in your webpage.

Nut they can sure tell if you’re worth mugging...