Blue Shield Data Breach (Google Ads)
news.blueshieldca.com
news.blueshieldca.com
I see so many medical and government sites that really shouldn't be running third-party trackers. Yet almost every single time I check, they are.
It's negligence/incompetence/reckless, criminally so, in some cases.
Given the inability of almost anyone in our field to build or operate a competently secure system, and the practices that go out of their way to gratuitously make the situation even worse-- we really just need to smack our entire field upside the head, repeatedly, until we stop churning out shit while strutting about how smart we are.
"AI" development tools (i.e., making humans stupider, through the power of plagiarism, to churn more BS at a faster rate) isn't going to solve the root problems of grossly misaligned incentives and culture.
Vague passive voice, FTW.
One way to start to fix the pattern and practice of gross negligence in our field is for Blue Shield CA to get stuck with HIPAA violation fines for each record leaked.
If Blue Shield CA claims they're not competent to know which records were leaked, assume it's all of the records.
0.0.0.0 analytics.google.com
0.0.0.0 google-analytics.com
0.0.0.0 ssl.google-analytics.com
0.0.0.0 www.google-analytics.com
0.0.0.0 www.googletagservices.comBack in the day I ran a giant hosts file for the same reason. I guess dumb OSs didn’t index HOSTS files well (didn’t expect them to be very large?) and it slowed things down noticeably.
Apparently it’s still a thing and the workaround doesn’t work either:
> This is still relevant with Windows 11; adding a 20MB hosts file (to block every known malicious IP) makes a 24-core i7 /w nvme take 4+ hours to boot. Worse, DNS cache is now system-controlled and cannot be stopped. Do not attempt!
https://serverfault.com/questions/322747/can-a-long-etc-host...
It sounds like a fairly minor concern, but I find it quite distasteful that the email subject doesn't indicate that a breach occurred.
Can we coin a term for this weasel-y headline writing?
In this case, health care data covered by HIPAA was sent to a party without a legal contract that extends HIPAA to the receiving party. By law, that's a data breach.
Under some legal definitions, "data breach" includes not just breakdowns of confidentiality, but also of availability and/or integrity. So a company deleting your data by accident would be considered a data breach, even though it's being accessed by fewer parties than intended. This can be important: imagine a bank or credit agency losing some or all of the data about you, this would materially impact your ability to do business in the modern world.
They're lying.
Look at the page source for the announcement of the data breach. Use of both Google Tag Manager and Google Analytics.
<!-- Google tag (gtag.js) -->
<script type="text/javascript" src="/static/js/jquery.cookie.js"></script>
<script async src="https://www.googletagmanager.com/gtag/js?id=G-KTK4E56VDB"></script>
<script>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
var check_site_id = 347;
var social_patterns =
['facebook.com/share','twitter.com/share','linkedin.com/share',
'pinterest.com/share','mailto:?subject'];
Here's Blue Shield's patient portal:
https://www.blueshieldca.com/login
That will redirect. Do a view source on where it goes, and you'll see both Google Tag Manager and Google Analytics code.
(Can't archive that page, unfortunately.)
"...Settings.WebAnalyticsEnabled = 'False';"
is set - thank goodness my medical provider's doing it right. (at least on this portion, I'm not digging through all the code or whatever)
"On February 11, 2025, Blue Shield discovered that, between April 2021 and January 2024, Google Analytics was configured in a way that allowed certain member data to be shared with Google’s advertising product, Google Ads, that likely included protected health information. Google may have used this data to conduct focused ad campaigns back to those individual members. We want to reassure our members that no bad actor was involved, and, to our knowledge, Google has not used the information for any purpose other than these ads or shared the protected information with anyone."
Well, they have inadvertently exposed PHI - this press release literally admits that they did.
In terms of what fines will apply, well, the annual cap for violations is about $2 million per calendar year, but I doubt they'll have to pay even that.
I see two but whatever
EDIT: Most of these places are just feature factories with offshore developers who are very unlikely to raise concerns.
I don't know why you're being downvoted, because this is unfortunately quite accurate. You'd be shocked how often this happens, even for tools they think are totally secure and "HIPAA-compliant".
> EDIT: Most of these places are just feature factories with offshore developers who are very unlikely to raise concerns.
I don't think there's any meaningful difference based on where the developers are located. The developers aren't the ones making the decisions. Usually the issue is that the higher-ups want it, which is why practices can continue even after concerns are raised.
GoodRx, BetterHelp, and dozens of others have received notices that this is an issue. The federal OCR even published a bulletin about this 3 years ago.
You'd think that any one of these would have triggered internal reviews and discovered this issue for all the others, but that's much too high a bar to expect in healthcare.
But no doubt the analytics blurb was stuffed into a generic "top_level_page" generator or whatever. And it happens that the PHI wasn't firewalled by design, and pulled it in by default. Or it was firewalled, but then someone forgot and migrated the "patient_info_page" templates to a generic framework, etc...
Security is really, really hard. And one of the worst responses to a mistake like this is to tut-tut about how obvious a mistake and how easy to avoid it was. Believing that secure software is a matter of "not making mistakes" makes you more likely to write such bugs and not less, because you won't take the time to establish clear boundaries from the start.
If there was no review, that's negligence.
If there was a review, one of the first questions that would be asked is, "what kind of tracking or telemetry do you have"? And there are tools that will scan code and flag things like that for you that large companies normally use.
Similarly, everyone at Blue Shield should know they can be fined outrageous amounts for a systemic HIPAA breach, so the system design and code review processes should make it really difficult to mess this up. Anything else is surprising.
I have been in charge of such systems, and you can do a lot with pretty simple rules, such as: No external scripts can appear on a page containing PHI, with exceptions reluctantly approved by security review for things like performance monitoring (not advertising). Systems that can access PHI are a separate codebase from marketing. The marketing systems don't connect to anything with PHI in it. If anyone feels constrained by these rules, pull in the compliance team and discuss.
In fact it's also possible this came about because a page changed over time and no one re-reviewed that original approval. Imagine for example that they had some un-authenticated pages set up so that people could see what sort of Medicare plans BS offers. Every year, thousands of people flock to the site, drop their zip code in and see what plans are available in their area. So far so good, no PHI (zip + medicare without anything else isn't generally PHI). Then a year later someone gets the bright idea to let you search for which doctors are in or out of network. Again, not PHI for most practical purposes. Yes, it could be enough data to uniquely identify someone and their health conditions, but in practice, it's hardly going to raise any red flags. Next year someone suggests adding the ability to list your medications so that you can see what you out of pocket costs for a plan will be. We're edging up on PHI here, but as long as they're not taking actual personally identifying info like dates of birth or addresses, this probably still isn't getting flagged as a PHI page. Finally the next year someone suggests "wouldn't it be handy if our existing customers could have their medications and providers from the prior year just imported into the search automatically. Well sure it would, so they go ahead and implement it but whoops, pulling that data out of the system also pulled along some internal tracker id that happens to be composed partially of their external "HIPAA safe" analytics ID that gets mapped to the internal tracking ID so they can got analytics attached to your session even before you authenticate. And now that ID is matched up to health information in a way that both creates a unique connection between the health information and an individual and now also links that individual to a specific cross-site google tracking ID. And now you've had a data breach, without ever (intentionally) approving the application of marketing libraries on a PHI containing site. I agree that there should be a lot more safeguards still, but the bug also being in place between 3-4 years suggests to me that it was a lot more subtle than just "don't include `ads.google.js` on the patient's medical history page". It's possible they really are just completely inept and haven't had any audits in 5 years but we won't really know that unless/until someone leaks more details.
Actually no, Blue Shield is the bad actor here.
Why, again, is this necessary at all? What is the rationale for analytics somewhere that deals with private health data?
Offtopic: I wrote a TLDR of this incident here: https://www.uxwizz.com/blog/blue-shield-data-breach-why-self...