Live data from Hacker News

Studying how Firefox can collect additional data in a privacy-preserving way

groups.google.com

251–260 of 450 posts

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#251

The single largest advantage of Firefox over other browsers is that despite all odds and occasional missteps they managed to respect users' desire for complete privacy. For Firefox we want to better understand how people use our product to improve their experience. Sure thing. But the fact that they are unhappy that some (many?) people are opting-out from the data collection is merely a sign that they don't want to u…

> No phoning home. No telemetry, no data collection. No "light" version of the same, no "privacy-respecting" what-have-you. No means No. Nada. Zilch. Try and shovel any of that down people's throats and the idea of Firefox as a user's browser will die. https://github.com/mozilla/addons-frontend/issues/2785 And now this :-( I have been using Firefox since before it was called that. I develop my apps in it, even though…

Also, Firefox has been adding things like Pocket while removing simple options that have been part of Firefox since the beginning claiming that it should be part of an add-on (like the option to disable javascript) and they are also adding privacy invasive options like "Block dangerous and deceptive content"... Firefox is still my favorite but that can always change...

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#252
post #141

Earlier quoted context omitted.

> Currently we can collect this data when the user opts in, but we don't have a way to collect unbiased data, without explicit consent (opt-out). That to me suggests the problem isn't that too many people are opting-out, it's that not enough people are opting-in.

Clearly those users that dont choose to opt in are wrong, and mozilla needs to make this choice for them... This trend towards parentalism in software, especially software that is supposed to be user driven is frankly a steaming pile of garbage. If you have any shred of pretense of being pro-privacy and pro-user dont do this mozilla.

It's more that a lot of people really don't care one way or another, and will neither go out of their way to opt-in or opt-out.

Additionally, it's not that Mozilla just disregards user privacy here: differential privacy being used would mean that no user has to reveal their private information, but looking at all the data in aggregate would still allow Mozilla to gain useful information on how to make Firefox better.

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#253

Earlier quoted context omitted.

This is getting off-topic, but it's interesting. I think I have the exact opposite take on things from you :) A program written by a developer and used by a user is a relationship between that developer and the user. I just work on the platform that allows that relationship to exist. I feel it's overstepping our boundaries as platform providers to say "we're not going to make this platform faster for you because we t…

Why not think about the program you are working on as a program that is built to support the open standards that enable people to communicate and concentrate on performance within these standards? If someone wrote a bad performing non standard compliant code the program should throw an error. Making bad code run faster is overstepping the boundaries.

But we're not making "bad code" run faster. We're making code run faster. The original counterpoint was that we shouldn't be, because improving the performance just gives leeway for bad programmers to use it as a crutch.

We don't prioritize bad code for optimization. See usage of 'with' in Javascript. We don't actively try to make it worse, but whenever a decision is presented which regresses 'with' performance for gains somewhere else, it'll probably be taken because we don't care about 'with' running fast.

But the example I mentioned: histograms of max GC pause times on a particular website. Or particularly bad janks, or long amounts of time spent in JS which might be the result of poor JS execution..

None of these optimize "bad code". They're just standard platform performance optimizations that help all programs. That will include "bad" programs as well.

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#254
post #45

Earlier quoted context omitted.

As you may have read in the feedback request, Mozilla is proposing to use differential privacy – differential is very different from tracking. For more information, see https://en.wikipedia.org/wiki/Differential_privacy for instance.

So, I read that, and already see two problems. One - DP provides privacy by deniability. How does that apply to URLs (or even just domains)? For a domain to show up, I have to have visited it (unless Firefox will report back random domains). Two - DP is only really private over a small data set per individual. If DP were enabled for even two days, you could get a very accurate picture of the sites I visit, since a ma…

One: I'm pretty sure that the idea is to report back random (existing) domains, yes.

Two: That's an interesting question. You'd need to ask it to someone with more domain knowledge than me.

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#255
I tried to be unbiased in the submission title and it's probably late enough that this will be buried, but here are some my thoughts:

> They don't plan on collecting URLs, just (eTLD+1).

This is true as of right now, but can change at any time in the future. From the post:

> What we plan to do now is run an opt-out SHIELD study [6] to validate our implementation of RAPPOR. This study will collect the value for users’ home page (eTLD+1) for a randomly selected group of our release population

This test consists of collecting domains, indeed, but that doesn't say anything about what will happen in the future.

> Note: "planning" means "reaching out for feedback about".

Planning means planning. Today they're reaching for feedback, and the plans might change or not.

> Hello, Redditors...

This is my fault, I suppose, for posting the link here :). Many of the angry comments are uninformed, but the users, educated or not, are stakeholders here and Mozilla should be prepared for the fallout. There have been situations in the past (Pocket, Google Analytics) where well-formulated feedback from users was raedily dismissed.

> One recurring ask from the Firefox product teams is the ability to collect more sensitive data, like top sites users visit and how features perform on specific sites. Currently we can collect this data when the user opts in [...].

Does anyone know what this is about? Telemetry? Because I will disable it if so.

> Allow Firefox to install and run studies

This is from the Nightly settings page but is pointing to https://support.mozilla.org/en-US/kb/shield, which doesn't exist (yet?). For anyone interested, there's a wiki page about them https://wiki.mozilla.org/Firefox/Shield/Shield_Studies.

> What we plan to do now is run an opt-out SHIELD study [6] to validate our implementation of RAPPOR.

This still sounds bad enough to forever poison "SHIELD" for me. It's also terribly named because it doesn't "protect" anyone.

> No telemetry, no data collection.

Without telemetry it would be almost impossible for the developers to figure out what works or not, and what's fast or not in Firefox. There's a whole spectrum here from "no telemetry" to "creepy". Please don't ignore this.

> Now they are killing Privacy.

Please try to get informed. A Mozilla employee in this thread (alexrs95) posted a series of tweets about what's being proposed: https://twitter.com/Alexrs95/status/896366072240144385. It's short enough, so please read at least that before complaining.

> What's your favorite open-source browser?

Firefox :).

> I've removed all URLs from about:config and replaced them with localhost (search for "http"). This should help with privacy-related issues as long as no API endpoint is hardcoded.

Beware of SHIELD, as Mozilla may still have the ability to push extensions to the browser.

> He said there are math theorem to prove that it's sufficiently anonymize.

I've not dug deep enough into the RAPPOR paper, but they do consider in passing the possibility of an attacker that has access to all of the collected data (think https://en.wikipedia.org/wiki/National_security_letter).

> Everyone else

Please be kind.

EDIT: Looks like this post might have been pushed back from the front page by a moderator. I'm not sure I'm fine with that.

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#256

Earlier quoted context omitted.

This data will be used in the pursuit of #2. As it turns out, a lack of understanding of what users are doing with their browsers is an obstacle to making a better browser. Performance issues in complex systems often only show up in production, and that's what Mozilla is trying to collect this data to fix.

Why is opt-in data not sufficient? Why can't Mozilla take the top-N sites and test them out for themselves?

We're already doing that. Experience shows that this is not sufficient to accurately catch regressions.

Also, just because a site is part of the top-N doesn't mean that it's part of the top-N for Firefox users.

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#257
post #52

Earlier quoted context omitted.

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)

> 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 ab…

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.

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#258

Earlier quoted context omitted.

There are a couple different reasons crash reports aren't sufficient: 1. Crash reports only report crashes. We need also want to see perf issues like GC and paint jank, etc. 2. Crash reports don't sample the general population, so statistically the information is less useful. If we get a perf issue, it's very important to know whether that issue is suffered by 10% of the users in general pop, or 0.5% of users in gene…

> Lastly, crash reports are sort of a boolean filter - you only get the people that crash. The things I'd like to know to help in my development are things like "what is the histogram of max GC pause times on docs.google.com". Getting that info requires a good random sampling of the population, not just those who exhibit problems. PLEASE do not go down this road. Look where "optimizing" video card drivers has led the…

Making optimizations based on telemetry from real world sites doesn't mean you're optimizing for that one site only, like a video driver including hacks for a specific game. For example, shifting an array in Firefox used to be O(n) vs. O(1) in the competition [1]. Improving these sort of code paths benefits the entire web, even if the performance issue is discovered and profiled on docs.google.com.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1348772

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#259
post #131

Earlier quoted context omitted.

I think the core disagreement here is not ideological per se, but on premises. I agree with the motivation of not collecting any data. That said, I don't feel that we have a choice but to compromise. If we don't build a better browser, then the other browsers will win by default, which means you lose all those privacy and security motivations anyway. This is not some gleeful romp down the yellow brick road of data co…

What are we attempting to "win". Again I go back to my statement of compromising princibles in the name of market share I have used FF since Ver 1.0 for a few reasons the top ones being it is Open Source, it has always been the most privacy and security focused browser, and were strong advocates of Open Standards that where inter-operable on ALL platforms with out vendor lock in FF is still open source.... the rest t…

> What are we attempting to "win". Again I go back to my statement of compromising princibles in the name of market share

I don't see it as an either-or, but rather a balance to strike. A perfectly private browser with no marketshare doesn't help users. A completely compromised browser with 100% marketshare doesn't help users either.

Re: Studying how Firefox can collect additional data in a privacy-preserving way

#260
I am surprised that there is such a fundamental misunderstanding of differential privacy on the Hacker News crowd.

Meeting the standard of true differential privacy is one of the strongest known unconditional privacy guarantees. It will prevent Mozilla from being able to answer any user specific questions. For example, they might have an accurate count of how many people visit Google.com (say 60% of their user base), but they will be mathematically unable to point to exactly which 60% visited the site.

Differential privacy in the RAPPOR implementation is peer reviewed and well understood. We can also review the actual code that ships in Firefox, which is a big plus over the Chrome implementation. There are some caveats -- what epsilon are they setting, are they adding an appropriate amount of noise, how do they protect against repeated queries, etc. but all of these can and will be reviewed by the differential privacy community.

I am not affiliated with Mozilla or Google, though I do work in the field of differential privacy. On mobile now, but I am happy to provide links or answer questions to people who might have any when I am back at a laptop.

Post reply on HN