331–340 of 450 posts
With the 300+ upvotes and active discussion still occurring at hour 7 since posting, care to explain how the algorithm has relegated this discussion to the fourth page and is still dropping? Is the much less active, day old posting of a SF author's death more heavily weighted than an inconvenient topic that is important to several more factors of readers?
Earlier quoted context omitted.
Because data collection that is "sufficiently anonymous" _does_ respect privacy. If it's completely impossible to tie the data collected to any one particular user, how does the existence of that data compromise privacy in any way?
We can go into an amazing yet pointless semantical argument of what "privacy" means. But let's look at this from a different perspective: I like your faith. However, if this change goes in, and the capability is there, it will get misused. Because, statistically that's how these things go on this planet+capitalism.
Or are you saying you're worried that they could _start_ collecting non-anonymized data in the future? If so, I don't really get that argument either. People always have the ability to change what they're going to do in the future, Mozilla deciding now not to collect this data wouldn't change that.
Hey Dang, HN mods! With the 300+ upvotes and active discussion still occurring at hour 7 since posting, care to explain how the algorithm has relegated this discussion to the fourth page and is still dropping? Is the much less active, day old posting of a SF author's death more heavily weighted than an inconvenient topic that is important to several more factors of readers?
In my experience, the quickest, most reliable way to contact the mods is via the Contact link in the footer. You might want to try that as well if you're looking for an expedient response.
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…
> I'm not directly involved in this proposal, but I personally think it's necessary, and strikes a reasonable balance between the privacy-for-users and actionable-information-for-developers requirements. I use Firefox and always opt into any telemetry that sends data back to Mozilla. You could say I am a fanboy. I think it is a HORRIBLE idea and Mozilla should scrap it yesterday and never bring it up again. If people…
Earlier quoted context omitted.
> Tracking down regressions, crashes, and perf issues without good telemetry about how often it's happening and in what context. If that's what you're aiming at. Collect the data but keep it local. Install some sort of responsiveness/"problem" monitoring. Ask the user to send data relevant to the problem if a problem occurs. IMHO there is no need to systematically collect user data for that. Or get the data from a ra…
> Or get the data from a random sample of users. You don't need data from everyone. To my amateur ear, that actually sounds like a good compromise to lessen the blow somewhat more. You should suggest it to Mozilla :)
And if I opt-in to data collection, why would it matter to me whether the stats I'm sending are a result of me being selected as part of a random sample or not? Might as well just _always_ send those stats; it doesn't matter to me.
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…
Ok, I get your point. You need the extra debugging information. Now, here's my concern. I DO NOT want compromises. I DO NOT want to balance anything. I DO NOT want this telemetry crud on my browser spewing out my browsing history to anyone, no matter how anonymous you people claim it will be. I just want a decent web browser. What are my options? "Mozilla's way or the highway"? Redirect evil.telemetry.things.mozilla.…
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 bro…
The OP actually discusses a very interesting method for doing exactly that using differential privacy techniques. I personally think that's a very good compromise for this use-case.
Earlier quoted context omitted.
Why would it be addressed before anyone complained? And it was planned as part of the Readability feature, which is very popular and not considered "unnecessary". But FF devs were having a hard time making a good read-it-later UI and decided to use Pocket instead of reinventing the wheel. Edit: To be clear, I think the browser code was always a stub, and the privacy policy was modified before the feature launched as…
My concern is that Mozilla has been on a "Sure, you can provide feedback, but we're gonna do it anyway" streak. Pocket is quite unnecessary, and would be a great candidate for an add-on. I don't know their reasons for bringing it in, but it seems pretty cut and dry that there were a lot of users who didn't want it even after it was cleaned up, and Mozilla ignored them.
Earlier quoted context omitted.
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 g…
If mozilla can't see how utterly insane this is then there is no hope left.