Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

groups.google.com

Post reply on HN
Print view View original

201–210 of 450 posts

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

#201

Post by sp332 »

yakult wrote: post #34

1. Any data collection at all deanonymizes the user, cf panopticlick. 2. Frankly even opt-out is not acceptable. I can't recommend any software that peridically asks users for data access, since there exist non-technical users who have a nonzero chance of clicking yes to everything. If they are related to me in some way this compromises my privacy also.

1. Any data collection at all deanonymizes the user, cf panopticlick.

This isn't true. Panopticlick collects a ton of data about your browser that this proposal will not. There has been a lot of research done in this area and we know how to collect anonymous datasets. https://arxiv.org/abs/1407.6981

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

#203

Post by codedokode »

clarkevans wrote: post #94
chimeracoder wrote: post #26

Earlier quoted context omitted.

> 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.

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

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.

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

#204

Post by keeperofdakeys »

Ajedi32 wrote: post #171
keeperofdakeys wrote: post #23

Earlier quoted context omitted.

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.

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

#205

Post by belorn »

kannanvijayan wrote: post #71

I can do a quick summary of what's being proposed and why. I work in the JS team at Mozilla and deal directly with the problems caused by insufficient data. Please note that I'm speaking for myself here, and not on behalf of Mozilla as a whole. Tracking down regressions, crashes, and perf issues without good telemetry about how often it's happening and in what context. Issues that might have otherwise taken a few day…

If user privacy is paramount, then there are multiple ways to lower the privacy incursion that is caused by the data collection.

Only collect top-level domains of Alexa rank 1k. That users are using a highway is less sensitive than a specific street where there only exists 5 homes, and it reassures users that private domain names won't be leaked.

Send the data through Tor. That way you only get the data about the browser site interaction, not userbrowsersite interaction.

And make it opt-in and notify users of the purpose of the data collection. A good model to follow here is Debian installer and popcon. Follow the good practices of data collection in the free software world and do not use dark patterns.

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

#206

Post by joosters »

alexrs95 wrote: post #87

I work at Mozilla, but I'm speaking for myself here, and not on behalf of Mozilla as a whole. For those interested in understand more about this project and why we're doing it, here you can find an introduction of Differential Privacy and what we're trying to do. https://twitter.com/Alexrs95/status/896366072240144385

As a user, I don't want to waste my time learning up on Differential Privacy. Am I really expected to read up on it and prove to myself that the theories work and are safe to use? Why should I take the risk that the mechanism might leak data? The only sensible secure choice is to not allow it. Let users opt-in, don't force them to opt-out.

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

#207

Post by Ajedi32 »

joosters wrote: post #190
Ajedi32 wrote: post #162

Earlier quoted context omitted.

I'm not really sure what your concern is here. Let's assume for a moment that Firefox's implementation of differential privacy in this scenario is completely correct, and that as a result it's completely impossible (even in an information-theoretic sense) to learn anything about any individual user using this data; only about many users in aggregate. In this scenario, how exactly would Firefox's actions here compromi…

Why are they not letting people decide? If it is not harming anyone's privacy, and they make it clear that it isn't, then what is the problem with letting people opt-in to it? Instead, it's telling that they are choosing to force people to opt-out. They know that their users don't want this, but don't care.

Opt-in inevitably results in data being heavily biased in favor of the small minority of users who go out of their way to opt-in. For some stuff that's fine, but for certain types of data you really do need a broad, unbiased sample of users in order for the data to be at all meaningful. (Usually to answer questions like "What percentage of users use x feature?" Or "What level of jank does the average user experience on facebook.com?")

They still _are_ planning to let people decide for themselves whether to participate (via opt-out), they're just using a default that's more likely to result in unbiased sample data.

Again though, what's your actual concern? Provided this feature doesn't compromise anyone's privacy even _if_ its enabled, what's wrong with having it be opt-out?

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

#208

Post by joosters »

moosingin3space wrote: post #172
tjoff wrote: post #135

Earlier quoted context omitted.

What you guys just won't grasp is that: 1. You will absolutely obliterate any trust you have with actions like this. This is important. Because if you continue to ignore this and you will have tons of data but you will be absolutely clueless as to why your product and brand are completely abandoned. 2. This data isn't worth that much to begin with. Here is a crazy idea, try to make a better browser instead.

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?

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

#209

Post by sp332 »

syshum wrote: post #200
sp332 wrote: post #164

Earlier quoted context omitted.

I guess this is offtopic, but what do browser extensions have to do with openness, security, or privacy?

It is a factor in openness, the Browser Extension API as being developed by FF, MS, and W3c is very very limiting far more limiting than the old XUL based model It can be a factor in security both positive and negative as XUL was very powerful and could be abused, but it also was used by some projects to enhance the security of FF or provide other security related functionality that is now no longer possible unless F…

It's limiting at the moment because it's not finished yet. And Firefox in particular has far outpaced any third-party or industry-wide standards in adding new APIs. They've been proactive and responsive in getting feedback from addon developers while designing the APIs. I would say security addons are one of the top priorities. For example here's a blog post by the NoScript developer: https://blog.mozilla.org/addons/2017/08/01/noscripts-migrati... "I feel that Mozilla has the most flexible and dynamically growing browser extensions platform"

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

#210

Post by joosters »

Ajedi32 wrote: post #207
joosters wrote: post #190

Earlier quoted context omitted.

Why are they not letting people decide? If it is not harming anyone's privacy, and they make it clear that it isn't, then what is the problem with letting people opt-in to it? Instead, it's telling that they are choosing to force people to opt-out. They know that their users don't want this, but don't care.

Opt-in inevitably results in data being heavily biased in favor of the small minority of users who go out of their way to opt-in. For some stuff that's fine, but for certain types of data you really do need a broad, unbiased sample of users in order for the data to be at all meaningful. (Usually to answer questions like "What percentage of users use x feature?" Or "What level of jank does the average user experience…

I have no way of knowing how this may or may not compromise my privacy without a deep understanding of the techniques being used. I am meant to trust Mozilla and hope that they haven't overlooked some weakness in the algorithms used. The obvious security choice is to not add this feature in. The 'Provided this feature doesn't compromise anyone's privacy' is a fantasy, because no-one can be sure of that.
Post reply on HN