Wouldn't an easy solution be to just give a right click function that says "bug on this page"? You get a nice and easy way to the user to report a page and you are non-intrusive. If you're concerned with what pages users visit the most, why not just check Alexa ratings?
Studying how Firefox can collect additional data in a privacy-preserving way
271–280 of 450 posts
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#272Earlier quoted context omitted.
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.
> I'm pretty sure that the idea is to report back random (existing) domains, yes.
Here's a concern that comes up from that implementation option: any outliers from the set of existing domains (which would likely simply be implemented as a list of strings) would immediately be able to be called out as a "True" value, while a single reporting of a domain could reliably called out as a "False" value. Unless, of course, you choose a randomization algorithm which exhibits a very strong clustering trait.
You could also limit reports to those domains which are in the whitelist, but that would voluntarily neuter the reporting; something they seem less-than-eager to do.
Ultimately, it will all come down to the implementation details, which are unlikely to be available until after the opt-in release, and auditable by a remarkably small number of people in the open source community.
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#273Earlier quoted context omitted.
I'd suggest you research the topic of negative and positive liberty. I'm all for a free and open source experience but what about the liberties of content creators? What about my right to as a user to be offered content with the knowledge that I won't and don't want to know its inner workings as long as it's passive non-malicious code?
I will be happy to do so, once consumers and content creators (and specifically the companies they sell rights to) are on a level playing field in terms of legal protections and lobbying powers.
This isn't about the money or power you or I have. This is about freedom to distribute content and the agreement between the user and the creator while you're asking the browser to be the ideological arbiter of this transaction. If you're all for freedom, you should logically see that not including the DRM option is inhibitive of both the user's and the creator's freedoms. As a browser, it should be ideologically agnostic to my downloading of an executable or zip file that goes against freedom, privacy and all that we hold dear and it should still be my right and freedom to download and view as I legally please. The Richard Stallman approach does have its limits.
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#274Earlier quoted context omitted.
I did the same, but used https://error.invalid/ , as that URL is guaranteed to never resolve.
Unfortunately, it is not. https://tools.ietf.org/html/rfc6761#section-6.4 > Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s). It's only SHOULD, not MUST. And in fact, the glibc resolver (and I bet also other major implementation…
> And in fact, the glibc resolver (and I bet also other major implementations) does send such queries to the DNS server.
Using the glibc resolver as baseline is a bad idea, it’s broken beyond hope.
Try resolving http://-emmawatson.tumblr.com/, which is a valid URL under newer standards, and works on all other systems. The Glibc authors refuse to merge patches fixing this, because they disagree with the standard.
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#275Earlier quoted context omitted.
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.
Can you give any examples of sites and URLs that you've missed with opt-in data?
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#276Earlier quoted context omitted.
They did and too few people said yes. On the other hand, everyone complains Firefox is slow. So,few pay, few opt in, and everyone complains.
"They did and too few people said yes." There's the answer. And the response? "Tough shit", we'll take away that choice granularly. For our own good, apparently. Moz has been giving tough shit with caveats for more than a few years now. Perhaps that is why market share is falling?
There is a story about people getting driver's license having a check box to opt-in into being organ donors, and very few said yes. Once the box was changed to opt-out, very few said no :)
The question is are people saying no because they are privacy conscious, or because they don't care. My money is on latter. In general more people care about Firefox being fast than security.
What's a bigger issue for Firefox is deprecating its add-ons. That's going to hurt its marketshare way more than telemetry data.
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#277Earlier quoted context omitted.
I don't know what level of risk this implementation carries with it. Probably more than a performance fix to the JavaScript interpreter, yes, but is it really a significant enough risk to make this feature not worth implementing? Maybe it is, maybe it isn't; I honestly don't know. You just seemed to be arguing that _any_ amount of risk would be too much, which in my view is ridiculous since, as I said, all new featur…
You just seemed to be arguing that _any_ amount of risk would be too much Unfortunately that's exactly the kind of thing I was talking about, extending arguments to ridiculous extremes. I have never said any amount of risk would be too much. In this particular instance, I think the risk and the unknowns are clearly too much.
> In this particular instance, I think the risk and the unknowns are clearly too much.
But why? I don't claim to know enough about RAPPOR to say for sure that the risk _is_ worth it, but it seems a little presumptuous to claim it isn't without knowing _anything_ about the project or Mozilla's proposed use of it.
That's why I assumed you were arguing that _any_ amount of risk would be too much; you didn't include any sort of analysis of the risk/reward in your previous comments, and without knowing the risk the only way to conclude this feature is definitely _not_ worth it would be if you already considered the acceptable level of risk to be zero.
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#278Earlier quoted context omitted.
Because the Pocket feedback I remember was about privacy concerns, and those were addressed.
> those were addressed. source? I never saw anything addressed other than "don't worry about it, it's for your own good"
The code in the browser is a stub. No data gets collected let alone sent anywhere until the user adds a Pocket account. Pocket updated their privacy policy, and they open-sourced the browser integration code. https://venturebeat.com/2015/06/09/mozilla-responds-to-firef...
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#279As someone familiar with differential privacy, and (somewhat less) with privacy generally, here are some suggestions for Mozilla:
1. Run an opt-out SHIELD study to answer the question: "how many people can find an 'opt-out' button?". That's all. You launch this at people with as much notice as you would plan on doing for RAPPOR, and see if you get a 100% response rate. If you do not, then 100% - whatever you get are going to be collateral damage should you launch DP as opt-out, and you need to own up to saying "well !@#$ them".
2. Implement RAPPOR and then do it OPT-IN. Run three levels of telemetry: (i) default: none, (ii) opt-in: RAPPOR, (iii) opt-in: full reports. Make people want to contribute, rather than trying to yank what they (quite clearly) feel is theirs to keep. Explain how their contribution helps, and that opting-in could be a great non-financial way to contribute. If you give a shit about privacy, work the carrot rather than the stick.
3. Name some technical experts you have consulted. Like, on anything about DP. The tweet stream your intern sent out had several historical and technical errors, and it would scare the shit out of me if they were the one doing this.
4. Name the lifetime epsilon you are considering. If it is 0.1, put in plain language that failing to opt out could disadvantage anyone by 10% on any future transaction in their life.
I think the better experiment that is going on here is the trial run of "we would like to take advantage of privacy tech, but we don't know how". I think there are a lot of people who might like to help you on that (not me), and I hope you have learned about how to do it better.
Re: Studying how Firefox can collect additional data in a privacy-preserving way
#280Normally, I would vote for opt-in only, but I think that it could be opt-out for Firefox as long as there are no dark patterns that make it difficult to opt-out. The survival of Firefox is extremely important for the future of the Web.
If it is opt-out, then Mozilla would have to be extremely open about how to opt-out and exactly what is tracked.