They don't plan on collecting URLs, just (eTLD+1). The only real issue I can see here are users who have registered their own domain under an eTLD, and have it set to their home page.

eTLD: https://en.wikipedia.org/wiki/Public_Suffix_List

> The only real issue I can see here are users who have registered their own domain under an eTLD

Doesn't the differential privacy system described above prevent even that from being an issue?

I'm not sure if they're planning on collecting every homepage domain here, or just asking something like "Is your homepage domain in the list of top 1000 domains?". In the former case, just having the domain listed could leak information. In the latter case, I can't see any issues.

It's more like: "Is your homepage google.com? Flip a coin, if it's heads tell me the truth, otherwise flip another coin and answer yes if it's heads or no if it's tails." (A bit simplified, but that's the general idea behind differential privacy.)

They're not planning to send full URLs, only domains. Also, the system described is resistant to attacks even if the data is captured (SSL leaks). I don't have enough statistical knowledge to understand how that works, though.

My concern is that it relies on differential privacy, or privacy through deniability. Which seems like a poor fit when it comes down to submitting URLs visited, unless they plan on submitting fake URLs when the "coin flip" comes up as tails twice in a row?

Not to mention, people will tend to visit the same websites repeatedly. The entire premise of DP is that the real data will stand out from the noise, creating a compelling picture of what an individual visits on the web. How will that aggregate data be anonymized, when it is reported with (a minimum of) an IP?

In short, this still requires a lot of trust in Mozilla, even with the DP algorithm, to not do the wrong thing with the dataset. And, in my eyes, making this opt-out and not opt-in already compromises that trust.

That’s still personalized data.

Mozilla has been violating even the minimal legal standards in the EU for years, and no one cares.

It’s insanity that an organization promoting its products with privacy doesn’t even meet the minimal legal standards. We’re seeing Google Analytics tracking in parts of the browser ("Get new Addons" page, for example), without even the legally required cookie warning.

EU law is clear on this, as soon as you store any data, do any tracking, connect to any third party, or transmit anything for analytics, you have get opt-in.

do_I_have_very_bad_medical_condition.com

Wouldn't that still leak health information? Less overall, but if any is bad, this still isn't acceptable.

Sure, except that with differential privacy, say 5% of telemetry reports would be marked as visiting do_I_have_very_bad_medical_condition.com anyway – regardless of whether they actually did.

What if a person visits 10 domains all indicating the same thing?

5%^10. Very very unlikely. Sounds very similar to "guilty beyond all reasonable doubt".

> URLs may contain Protected Health and other Identifying Information

A URL must not contain PHI. If it does, a breach has already occurred.

And Firefox is only collecting the domain names, it looks like.

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.