Pkg.jl telemetry should be opt-in
discourse.julialang.org
discourse.julialang.org
Services are not free (as in beer) - they always take time, money, and labor to provide. A PkgServer.jl is exactly the kind of thing that has to be sustained somehow.
It's not possible to use a networked service without exchanging some information with that service, which may or may not be useful for the service providers to collect, so that they can provide a better service (Read: make it cost less)
The idea that one should be entitled to use a service, for free, and at the same time ask that the service does not collect any data, or make it opt-in by default, is akin to demanding free beer that people can optionally pay for.
Caveat: My bias is from being a service provider for a packaging endpoint, a security updates endpoint, and a community CI service. Any telemetry data we can get our hands on to help us make informed decisions about what to support, and what to drop support is absolutely invaluable.
As you mentioned, reducing the costs usually amounts to taking something out: this can piss off users, particularly if they were not informed and no discussion took place. An example that comes to mind was the decision by Mozilla to stop supporting the ALSA driver in Firefox based on the telemetry showing little usage.
Ths example also shows that often data are biased and making a decision solely based on data is not ideal: ALSA is (was) the default choice on most GNU/Linux and BSD distributions, where firefox is usually built and distributed by the maintainers with telemetry disabled.
> is akin to demanding free beer that people can optionally pay for.
This is similar to how donations work: with donations you can't force people to give you money but you can be very insistent and it can leave users with a bad taste in their mouth. Also, if you are implying the service providers are entitled to collect all the data they can, I think this must have limitations. Running code on the client side from which the provider only can (directly) benefit should require permission, because you grant users access to server and so should the users grant you access to their machine.
Disabling telemetry by default ended up harming the users of those distributions by making their usage of ALSA invisible. Again, that choice by the distro maintainers isn't something that Mozilla had any control over. Voluntarily withholding telemetry data is similar to abstaining from an election. You dont get to complain about who got elected if you didn't vote, likewise you dont get to complain about lack of support for your use cases if you don't allow upstream projects to know that you have them.
No, it absolutely is not.
Telemetry IS asking their users in a way that scales past putting a random poll in some random forum that only a specific subset of people will ever interact with.
You can have some idealistic view of how feedback should be holistically gathered by “just damn listening to people!”, but this entirely glosses over the specifics of how it will scale and how accurate it will be which is vitally important when you go past 10,000 users.
Telemetry provides unbiased data about the vast majority of users, especially including those not privileged enough to make their needs known (for any one of thousands of reasons) — with the notable exception of various Linux distributions who have decided that they do not wish their users to be represented in the data, and certain power users who simultaneously demand the right not to contribute unbiased data yet seem to feel entitled to have their needs met.
I didn’t know that Firefox disabled ALSA but it doesn’t surprise me at all that it impacted users whose telemetry is disabled for idealistic reasons. Open source is discovering that the economics of free and the burden of long tail support are not compatible goals, and there will be many more pain points in many more open source products along this road. In the past, the squeaky wheel would get the grease; now, sometimes, the car might be converted to a tricycle and the squeaky wheel disposed of as superfluous to the greater good.
Most of the time, I take for granted that this is where the rubber meets the road on their ideals: The distro’s ideals demand that their users not be represented via telemetry, and so their users pay that price in exchange for the ideals they (often unknowingly) signed up for with that distribution. If upstream fails to take them into account as a result, the distro already accepted on behalf of its users that upstream will make decisions that aren’t compatible with their users as a result of disabling telemetry. Idealism is not free of costs.
In my more cynical moments, I wonder if this is because they fear that unbiased data would show that their use cases are in the severe minority (like, 0.0001%), and so feel think there’s a higher chance of having their needs met by withholding telemetry and then banging the outrage drums loudly to make their numbers look larger than life. Game theory suggests it’s a possibility, anyways.
The legal document also clearly indicates that Julia is collecting a very small amount of info, so there's no trickery either.
Moreover, at present, we have no idea how many people use each solver (and on which platform!). Knowing how many people installed which solver
would allow us to prioritize support from our finite developer time.
This would also allow us to lobby the commercial solver developers to provide official support (or $$). To quote one company "We'll want to
provide official support at some point, but it looks like the scales haven't tilted quite yet." It'd be nice to know whether 100, 1000, 10000, or
100000 people per month use their software; that might change their mind.
Finally, if it is opt-in, the vast majority of users will not opt-in. This leaves us no better off than we were before. Opt-out is a good
compromise.
The rest of this discussion devolves into "Everyone else is doing it". The lone dissenter finally gives in to peer pressure.
I remember when using download statistics was enough. Developers still maintained software. No "trade-offs" were needed.
Do you remember applying for grants to fund software? It's tough out there, right now. Harder than it once was - software is more expensive, and funding agencies are more critical.
No download statistics are currently available for Julia packages. That's essentially the issue that the Pkg.jl telemetry is trying to address.
As much as people in the Julia community have dunked on Matlab in the past, at least MathWorks has their business model worked out, people understand the tradeoffs being made, and the dark pattern being used is just closed source software instead of exploiting PII.
They have no special access nor do I see a first order effect that benefits them. Just that the open source Julia ecosystem will benefit and that will feed back into JC's market.
I think it is more likely the majority of users don't care, so do whatever the default is. If the vast majority didn't want telemetry enough to opt out anyway, then there wouldn't be any point in having it at all.
> The truth comes out.
The truth was never hidden. It's all laid out quite plainly here: https://julialang.org/legal/data/.
> If providing usage statistics is something that the Julia developers already know the vast majority of users do not want to do
There are three reasons someone might not opt-in: they don't want to, they don't know about it, or they simply don't care. To ignore the latter two is simply disingenuous.
> The rest of this discussion devolves into "Everyone else is doing it". The lone dissenter finally gives in to peer pressure.
That's certainly not my read of the 200+ post thread.
What are the reasons users do not read the /legal/data page on the Julia website? What are the reasons users do not read 200+ posts from developers debating the use of opt-out telemetry? To ignore such reasons, assuming they exist, would also be disingenuous.
If you put the choice clearly before users and they knowingly, affirmatively choose to submit usage data, then no 200+ post thread is necessary. Instead, the choice is not left to users. It is made by developers, and the fact of the use of opt-out telemetry is found on a webpage that developers know users do not read.
I don’t have a specific concern about the Julia team using my data, but I have general concerns about companies collecting telemetry. Can’t they get a rough estimate of active users by counting unique IP addresses over the past X months which doesn’t require opting people in to telemetry?
Edit: I think I read the link incorrectly. This person is arguing that users should have to actively opt-in, not that they are opted in automatically. They are arguing for a change that would increase privacy, and I need to opt-out in my current installation. I didn’t know I was sending telemetry right now.
> I think this is the crux of the issue: you’re already doing that across the Internet since your IP address is part of many (most?) normal HTTP requests. It’s not perfectly uniquely identifiable, but it’s not so far away from being that and it’s being submitted without even the possibility of opt-out in most cases / for most people.
> So I think the core issue this thread should resolve: would it be better for Julia to just do everything via logging IP addresses? That’s what everyone else in OSS is already doing (seemingly without almost any concerns), so perhaps the problem is just that Julia is talking about how to best do things rather than just doing them? That feels quite perverse to me, but it’s my big fear after reading this thread.
I'm guessing there's an unspoken assumption that given a UUID the server-side would not log IPs. It then comes down to trust that they'd stick to that.
I should probably get back into the Discourse thread to see if I can contribute constructively, but the amount of back and forth between mostly “My freedom!” and “Tū quoque!” [1] in the thread over the weekend – apart from me being far too busy to take the time to summarise it all – has kept me away, although it looks way better over the last few hours. With the little free time I have I would rather work on my Julia code. '^^
Also, I find this whole discussion to be somewhat irrelevant when talking about a service serving up arbitrary code to be executed on your machine: if you don’t trust the server owners, you really shouldn’t be executing the code they serve up.
Other package managers like npm already do this kind of telemetry, and without opt-out option, because they are centralised.
Julia packages are not, there is no central server.
They want to access primitive view of the package usage so they know where the whole ecosystem is, how to prioritise and help with getting funding – as they mention in the thread it's difficult to raise money if you can't present basic userbase numbers.
1) You familiarize yourself with the actual proposal and the improvements that are currently underway and
2) Be kind
A number of people have put in an enormous amount of effort to try and get this right - please remember that they are indeed people.
When the data is available to the community, just like the source code, its a much easier sell.
This comment is not meant to serve as an official policy, just pointing out one of the reasons why we can't delete IP addresses like 1.1.1.1 and 8.8.8.8 do; because the abuse vectors for a server that serves the community large resources is very different from that of a DNS server.
Most of the "abuse" we see is not malicious in nature, but is instead users that have some kind of very poorly-configured autoinstaller on a cluster. In the case of a catastrophic issue like the one mentioned above, we null-routed the IP address, reached out to the abuse contact for that IP, and worked with the user to architect a better system. Everyone is happy now, and we can continue to provide a high quality service for the community without breaking the bank.
If you block their traffic with HTTP 429 Too Many Requests, they can email you instead.
So if follows then that users are right to be concerned and would have every reason to not opt in if they were presented with the choice.
In any case that's why it's important to be transparent about what is sent, and for what purpose and who has access, so people can make informed decisions. Ironically, I think people are jumping on the authors of this particular piece of functionality precisely because they tried to be very transparent.
And, as you say, users trust the developers with access to their systems and data. Deciding unilaterally to sacrifice user privacy to benefit other interests might be seen as a breach of that trust.
An opt-out is the way that makes sense.
User's need to consider the developer perspective. Julia is a product with millions of hours sunk into it. It needs to sustain itself, since it's open source.
I doubt the telemetry is being used for profit anyway, but anything we can do to help Julia is good. "Donations" aren't sustainable and can't fund a large software project.
Also it's not hidden, so I fail to see the issue. If the information is in a legal document and the source code, then you know exactly what's going on. There's no shady business.
But given the landscape of privacy issues, I wouldn't vote for an opt-out telemetry in any of the OS projects I'm involved with.
I want to hammer this rule into everyone regardless of the domain you're working in when it comes to privacy:
- Explicitly ask the user. Respect their privacy. Explain why you would like to collect data, may be show past examples of what you've done with the data and don't deploy dark patterns or default behavior.
It is not that hard. No backlash. No problem at all if you ask the user. Sure, that would lead to less than optimal telemetry for the collecting party but there should not be any way around this. Want more data? Incentivize users, may be give them free subscription for helping out with the beta testing. Give them a discount. Treat data just like a commodity that costs money to obtain responsibly. Right now, everyone is a data-cartel trying to hoard as much as possible.
Why is this so hard to understand? This is opposite of "level-headed". I usually allow PyCharm to collect telemetry, I allow Apple to use Siri requests for improving it. It is because they do this as respectfully as possible without deceiving the user.
That expectation is incorrect if you’ve ever used a package server or pulled packages from some website including Github (for ANY language). HTTP requests do communicate your IP address, and it is standard practice to store them and use them for analytics.
If I download julia binaries from their website, they can collect IP information if the local laws allow it. Once it is in my possession, it is reprehensible to do anything without asking me first.
It’s one thing to collect statistics of downloads on the server side and another thing to profile me. It’s pretty clear to me.
(Not that I think Julia does this)
Let's not forget that despite Apple's otherwise good privacy record, Siri was saving your recordings to be listened to and reviewed by 3rd party contractors without giving you any opportunity to opt out. It was only late last year after their competitors were called out for the same issues that Apple provided an opt-out option.
And given how proactive they were with privacy warnings about donating voicemail transcriptions to improve voicemail accuracy, it was pretty reasonable to think "Surely if they were saving the Siri input recordings and letting people listen to them, they would have warned me about that and asked me if it's OK."
https://www.cnbc.com/2019/10/28/ios-13point2-has-new-siri-pr...
It's possible they still had better privacy protections in place for handling the recordings once they have them on their servers(compared to Amazon and others), but even the contents of voice recordings can be enough to de-anonymize them depending on what you've said.
This is very minimal data that gets sent along with requests that you’re already making to a (user-selectable) package server.
This is just excuses. Usage statistics could be tied to downloads or public source code analysis. No need for tracking.
Most people just don’t care, and will go with the defaults.
Now, I absolutely sympathise with any developers in this situation. But I think the underlying issue is that we lack a good way to give consent and are stuck with awful solutions like opt-out and ridiculous pop-ups. Is there not good work on this out there or are we forever going to have to endure sub-optimal solutions?
A: “Recently I have been thinking about personal responsibility.”
B: “Why so?”
A: “I believe there is a strong correlation between a sense of personal responsibility and success later in life.”
C: “That is interesting, I think I read a study about this once. Here is a link!”
<the discussion goes on for some time>
B: “Myself, I learned about personal responsibility – in particular financial – when I as a child ran my own little business. What I did was to deliver apples and later fruit for a small fee to the neighbourhood on my bike when I was about twelve. It did not make me rich of course, just enough to buy a video game in the end. But I do think it gave me solid experience in life. Later on in high school I started designing local webpages.”
D: “Hi! I am D, I am head of research at Foobar Corp and we have a new apple breed: http://foo.bar/baz It is the best apple on the market: crisp, juicy, and perfect for pies! Let me know if we can help!”
A, B, and C: “Eh?!”
Now, you are perfectly in your right to disagree. But I think D is being a dick here and inserting themselves blatantly solely to attract attention to their product and adding nothing to the discussion or the community as a whole – possible because D has signed up for some god awful “business intelligence” tool that just scans various websites for mentions of “apples” so that they can insert a generic, re-usable message.
Regardless, I will not monitor this conversation further as I feel we are at this point deviating far far from the topic of this “dead” thread. If you still feel the need to discuss this matter, feel free to dig up my e-mail on my personal website. Trust me, I am fairly easy to locate with my username and a keyword or two from my profile – or just look at the about page using the link to the tool I mentioned earlier in this conversation.
Now if your goal was to collect personalized data in order to get targeted ad revenue...
That is precisely what the logged IP addresses are used for (an example: nginx access logs), and is one of the reasons why we would much rather use a random number generated by the client machine than an IP address; because the bits themselves have no meaning, unlike IP addresses.
As mentioned in the linked thread, NumFocus has worked with a legal team that specializes in this type of law, this plan is all in compliance with the GDPR.
[1] https://gdpr-info.eu/recitals/no-49/ (The actual GDPR text regarding security concerns) [2] https://blogs.akamai.com/2018/08/dispelling-the-myths-surrou... (Akamai legal team confirming that this interpretation of logging IP addresses for security purposes is valid) [3] https://law.stackexchange.com/a/28609 (Stack exchange post pointing out that even more exceptions exist beyond just security)
'The goal is to answer the question “How many Julia users are there?”'
This is a commercial concern, nothing to do with security, and to my understanding at least, is not a valid reason for collecting PII. There doesn't appear to be a security argument for collecting this data without consent.