> 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.
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.
I was initially surprised to see several customers from .gov or medical corporations using my self-hosted analytics platform (I never considered those customer types before), but it makes a lot of sense. I think many of them actually run the platforms locally, and I think all companies that deal with private data (e.g. medical, banks, insurance) should be legally forced to not send any data to third parties, unless the customers explicitly agree to that (or the law forces them to do so).
> We understand receiving a notice such as this can create concern, and we regret that member personal information may have been shared without authorization.
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.
Back 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!
That sounds like the result of an "accidentally quadratic" or worse algorithm. Interesting that they didn't bother to fix it after all these years; perhaps they knew what those with large HOSTS files were using them for, and (especially now with Win11) were against it.
I block ads and trackers in my browser. But I had that turned off for Blue Shield's website because it is very broken in lots of ways. One way it's broken is it fails if you run an ad blocker. Not sure if blocking Google's surveillance is the problem or some other ad blocker rule.
I have 133 occurrences of google in my host file.(and I'm not even saying that's enough) Those five you listed are a good start, but you can do better. There are a lot of services available to update your host file.
There should be legal penalties for companies whose negligence leads to data breaches. Consumers really have no recourse here and even CCPA and HIPAA fines are exceedingly rare.
I'm sure those affected will get a 3.00 check and the lawyers bringing suit will make a chunk of change. (curious if this will lead to a suit or what the laws are around that (e.g. can this be class action or will only known affected individuals be allowed to seek redress?)
It depends on the jurisdiction and law, but a "data breach" is when data is accessed by a party who is not authorized, or who should not be authorized. It's not just hackers. Sending data to the wrong recipient is a form of data breach. Under some definitions, sending data to the intended recipient without appropriate safeguard is a form of data breach.
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 almost certainly are entirely different tech stacks, and likely not even developed by the same organizations. If you poke around in the source a bit you can find clear evidence that the news site is probably developed by a third party PR firm, who wouldn't typically have anything to do with a patient portal.
"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."
Putting a third party analytics tool on a page containing PHI is an incredibly dangerous thing to do. It’s really surprising the developers could get that through a security review.
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.
It's only surprising when you phrase it like that. Real bugs are interactions. I mean, sure, if you're asked to review a pull request like "patient_info: Use google to track MRI data", it's a no brainer.
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.
This is sort of like saying it's easy to crash an airplane so you shouldn't be surprised when somebody flies one into the ground. Everyone involved with aircraft knows crashes are bad and there are multiple layers of design and training to prevent it.
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.
The statement seems to imply that it was one of these "external scripts...reluctantly approved...for...performance monitoring". Specifically google analytics. But google is an all consuming vacuum for information, and presumably defaults to sharing data between your analytics account and your ads account. And in today's modern software dev world where everything is dependent on everything, that's exactly the sort of setting that could get accidentally imported somewhere where it wasn't supposed to.
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.
Thing is, that's exactly what security and privacy reviews are for.
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.
As someone who has worked in this field, I'm not. Marketing is generally exempt from massive legal review as they hand wave away "We don't deal with HIPPA data" and developers just wanting marketing to go away, dropped the Javascript block into files that were used for a ton of products including HIPAA containing ones.
EDIT: Most of these places are just feature factories with offshore developers who are very unlikely to raise concerns.
> As someone who has worked in this field, I'm not. Marketing is generally exempt from massive legal review as they hand wave away "We don't deal with HIPPA data" and developers just wanting marketing to go away, dropped the Javascript block into files that were used for a ton of products including HIPAA containing ones.
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.
I worked at an org that give Google Tag Manager access to marketing, effectively as means of bypassing engineering to try whatever spyslime of the month they could paste into a box.
I'm sure Google doesn't want customers doing this dumb stuff. So I'd also expect by this point they would be automatically profiling the incoming data to throw up warnings and safe guards. Maybe there is a perverse incentive where doing that only increases their liability in these situations.
> I wonder what, if any, HIPAA fines will apply to Blue Shield if they're found to have inadvertently exposed PHI.
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.
This can happen to anyone, and not only that, once you decide to send data to thrid-parties, you no longer have control of this data, and those third-parties themselves might accidentally leak the data. Who would then be to blame if you sent the data to someone that didn't respect the privacy regulations? Because the customer only had a contract directly with you, and only shared data with your company.
I guess that's what they mean by the "This site requires Javascript in order to function properly" banner I get at the top. The article is readable without JS anyway.
This statement is using lots of passive voice to try and deflect and confuse.
Blue Shield configured GA to send data they weren't supposed to. GA may have automatically used that data to do the things GA does. No human at Google would have ever interacted with this data, chosen how it was used, known it was there, or really given a shit (besides the risk of liability and not wanting customers to be dumb and do exactly this).
Of course they voluntarily handed it to Google knowing what Google does. But Google is not a good actor either. Just because "they do this to any data they get their hands on" doesn't make it right.
> 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.
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.
I was initially surprised to see several customers from .gov or medical corporations using my self-hosted analytics platform (I never considered those customer types before), but it makes a lot of sense. I think many of them actually run the platforms locally, and I think all companies that deal with private data (e.g. medical, banks, insurance) should be legally forced to not send any data to third parties, unless the customers explicitly agree to that (or the law forces them to do so).
Gotta love the passive voice used, too.
How do we report this?
> We understand receiving a notice such as this can create concern, and we regret that member personal information may have been shared without authorization.
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.
I've seen this sort of wording called "exonerative tense" when describing police conduct.
This is a good reminder to add these to your HOSTS file if you don't already have them blocked (which I have done for over 2 decades now):
You’ve unlocked a memory:
Back 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...
That sounds like the result of an "accidentally quadratic" or worse algorithm. Interesting that they didn't bother to fix it after all these years; perhaps they knew what those with large HOSTS files were using them for, and (especially now with Win11) were against it.
I block ads and trackers in my browser. But I had that turned off for Blue Shield's website because it is very broken in lots of ways. One way it's broken is it fails if you run an ad blocker. Not sure if blocking Google's surveillance is the problem or some other ad blocker rule.
I have 133 occurrences of google in my host file.(and I'm not even saying that's enough) Those five you listed are a good start, but you can do better. There are a lot of services available to update your host file.
The email subject for this notification was "Blue Shield of California Privacy Notification."
It sounds like a fairly minor concern, but I find it quite distasteful that the email subject doesn't indicate that a breach occurred.
the hope is people delete it because it's just a "privacy notification"
Related pet peeve: if the price of something goes down, it's a price drop, but when it goes up, it's a price change.
Can we coin a term for this weasel-y headline writing?
There should be legal penalties for companies whose negligence leads to data breaches. Consumers really have no recourse here and even CCPA and HIPAA fines are exceedingly rare.
I'm sure those affected will get a 3.00 check and the lawyers bringing suit will make a chunk of change. (curious if this will lead to a suit or what the laws are around that (e.g. can this be class action or will only known affected individuals be allowed to seek redress?)
This isn't a "data breach" is it? Blue Shield shared data with GA that they were not supposed to right?
It depends on the jurisdiction and law, but a "data breach" is when data is accessed by a party who is not authorized, or who should not be authorized. It's not just hackers. Sending data to the wrong recipient is a form of data breach. Under some definitions, sending data to the intended recipient without appropriate safeguard is a form of data breach.
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.
Well it is a data breach. Self inflicted, sure, but still a breach.
"Blue Shield severed the connection between Google Analytics and Google Ads on its websites in January 2024."
They're lying.
Look at the page source for the announcement of the data breach. Use of both Google Tag Manager and Google Analytics.
... ...I'm pretty sure you can use Google analytics without sending the data to Google Ads? I'm not sure why they would lie about correcting the issue.
Went to look at my provider's service portal to see if there was any google analytics. Nothing showed when searching google, but...
"...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)
Their News subdomain stack might be completely different than their patient portals.
They almost certainly are entirely different tech stacks, and likely not even developed by the same organizations. If you poke around in the source a bit you can find clear evidence that the news site is probably developed by a third party PR firm, who wouldn't typically have anything to do with a patient portal.
No, that excuse does not correspond to reality.
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.)
Saved copy of page, in case it is changed: https://archive.is/GB8Ty
Disappointing behavior to say the least.
"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."
Putting a third party analytics tool on a page containing PHI is an incredibly dangerous thing to do. It’s really surprising the developers could get that through a security review.
Kaiser was hit with a class action for exactly the same issue last year: https://news.bloomberglaw.com/litigation/patients-advance-ka...
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.
Good. Hope Blue Shield gets the same treatment but they'll just pass the costs to their customers
It's only surprising when you phrase it like that. Real bugs are interactions. I mean, sure, if you're asked to review a pull request like "patient_info: Use google to track MRI data", it's a no brainer.
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.
This is sort of like saying it's easy to crash an airplane so you shouldn't be surprised when somebody flies one into the ground. Everyone involved with aircraft knows crashes are bad and there are multiple layers of design and training to prevent it.
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.
The statement seems to imply that it was one of these "external scripts...reluctantly approved...for...performance monitoring". Specifically google analytics. But google is an all consuming vacuum for information, and presumably defaults to sharing data between your analytics account and your ads account. And in today's modern software dev world where everything is dependent on everything, that's exactly the sort of setting that could get accidentally imported somewhere where it wasn't supposed to.
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.
Thing is, that's exactly what security and privacy reviews are for.
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.
I would turn that around to be an inference that there was no effective security review....
As someone who has worked in this field, I'm not. Marketing is generally exempt from massive legal review as they hand wave away "We don't deal with HIPPA data" and developers just wanting marketing to go away, dropped the Javascript block into files that were used for a ton of products including HIPAA containing ones.
EDIT: Most of these places are just feature factories with offshore developers who are very unlikely to raise concerns.
> As someone who has worked in this field, I'm not. Marketing is generally exempt from massive legal review as they hand wave away "We don't deal with HIPPA data" and developers just wanting marketing to go away, dropped the Javascript block into files that were used for a ton of products including HIPAA containing ones.
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.
I worked at an org that give Google Tag Manager access to marketing, effectively as means of bypassing engineering to try whatever spyslime of the month they could paste into a box.
What security review?
"No bad actor was involved"
I see two but whatever
I'm sure Google doesn't want customers doing this dumb stuff. So I'd also expect by this point they would be automatically profiling the incoming data to throw up warnings and safe guards. Maybe there is a perverse incentive where doing that only increases their liability in these situations.
I wonder what, if any, HIPAA fines will apply to Blue Shield if they're found to have inadvertently exposed PHI.
https://www.hipaajournal.com/hipaa-violation-fines/
> I wonder what, if any, HIPAA fines will apply to Blue Shield if they're found to have inadvertently exposed PHI.
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.
> that no bad actor was involved
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?
This can happen to anyone, and not only that, once you decide to send data to thrid-parties, you no longer have control of this data, and those third-parties themselves might accidentally leak the data. Who would then be to blame if you sent the data to someone that didn't respect the privacy regulations? Because the customer only had a contract directly with you, and only shared data with your company.
Offtopic: I wrote a TLDR of this incident here: https://www.uxwizz.com/blog/blue-shield-data-breach-why-self...
Are you fucking kidding me? You get interrupted reading this shit by a pop up asking you for your information?
I guess that's what they mean by the "This site requires Javascript in order to function properly" banner I get at the top. The article is readable without JS anyway.
[flagged]
This statement is using lots of passive voice to try and deflect and confuse.
Blue Shield configured GA to send data they weren't supposed to. GA may have automatically used that data to do the things GA does. No human at Google would have ever interacted with this data, chosen how it was used, known it was there, or really given a shit (besides the risk of liability and not wanting customers to be dumb and do exactly this).
In this case, the "Bad Actor" was Blue Shield, for designing their system to send PII / PHI to places it should never have gone.
Of course they voluntarily handed it to Google knowing what Google does. But Google is not a good actor either. Just because "they do this to any data they get their hands on" doesn't make it right.