What do you mean, a URL must not contain PHI? You can't prevent a non-tech minded person from submitting questions about their health to any text field linked to a form with a GET method.

I'd argue that domains are the same- there are tons of domains that clearly indicate what they're about (e.g. stop-drinking.example)

You can argue it all you want. Whoever is storing that is responsible under the Canadian laws criminally. It's probably the same if not worse in other countries (Germany, etc).

@clarkevans But submitting search input via the GET method (e.g. https://www.google.com/search?q=how+to+stop+drinking ) are a common practice in leading search engines.

> What do you mean, a URL must not contain PHI? You can't prevent a non-tech minded person from submitting questions about their health to any text field linked to a form with a GET method.

You can't, but that can't be part of Mozilla's threat model, and it's not relevant here anyway because Mozilla isn't collecting it.

And even if they were, that's not considered PHI legally. You are free to type any information about your own health that you want anywhere; that doesn't make it legally PHI, unless you are providing it to a Covered Entity.

> I'd argue that domains are the same- there are tons of domains that clearly indicate what they're about (e.g. stop-drinking.example)

This information is not legally considered PHI. As for privacy, SNI means that all domains you visit are already visible in transit, even if you are using SSL. Domain names are not considered private.

> This information is not legally considered PHI.

Do you have any sources that go into more detail?

When I've worked on PII in analytics, even TLDs were treated carefully. (obviously not the same from a legal perspective...)

> Do you have any sources that go into more detail? When I've worked on PII in analytics...

PHI is an incredibly well-defined term legally and is not equivalent to PII. Some things that constitute PHI actually wouldn't qualify as PII.

There are a lot of resources that explain HIPAA in great detail; if you want to know the specifics like here, you have to read the bill and the case law itself.

>>You can't, but that can't be part of Mozilla's threat model,

How normal everyday people actually use their product cant be a part of the threat model... Really?

That is scary...

I don't care what the legal definition of PHI is, I am concerned that Mozilla is collecting actual personal health information (if not through URLs, the domain name concern is still valid). And I know that DNS resolution is not necessarily secure from snooping, but having one extra orginazation explicitly collecting this data is more dangerous than not having one extra org collecting it.

As a practical matter, there are lots of applications that use GET for user submitted search data. Since GET requests encode user entered information into the URL and since the URL is typically found in web server logs and other tracking/history mechanisms, it is unwise to use GET for user-submitted data in applications that are concerned with privacy. However, it was not always considered unwise: REST advocates recommend GET when the underlying information representation doesn't change as a side effect of the request. Therefore, one might just as well say that logging of URL query parameters is the technical problem.

That said, when a "breach" has occurred is a legal distinction involving the control of information -- when protected data moves beyond those who have a duty to protect it. Saying that a particular technical approach creates breach is inaccurate.

I think logging is unrelevant here because it can be set up to log POST data too or not to log query string. But the problem with leaking data via referrer exists. Google encrypts (or obfuscates) search query in referrer for example.

A group of URLs tied with the IP accessing them may leak such data. Maybe not in exact violation of the law, but it would allow for a reasonable estimate of the chance of someone at that IP address having some given condition.