# RFC: Proposal for estimating unique Julia clients without tracking

**URL:** <https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027>\
**Category:** General Usage\
**Tags:** statistics, pkg, cryptography, rfc\
**Created:** [July 9, 2026, 9:07am UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027 "2026-07-09T09:07:34Z")\
**Posts on this page:** 9\
**Page:** 4

<div class="post-metadata">

**Author:** ![Antipath1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/antipath1/32/221404_2.png) [@Antipath1](https://discourse.julialang.org/u/Antipath1)\
**Post date:** [August 9, 2026, 1:18pm UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/61 "2026-08-09T13:18:11Z")

</div>

Thank you for this official moderator clarification. Having the project’s governance standards explicitly placed on the record is incredibly helpful.

In your assessment of whether this environment is “toxic,” I notice you selectively focused only on the terms “insane” and “antisocial.” You conveniently omitted the parts of the comment that equated standard FOSS privacy principles with the ideals responsible for “shadow banking,” or the labeling of dissenting users as “foil hat extremists.” If project leadership considers _that_ to be “nuanced pushback” rather than bad-faith hyperbole, the bar for civil discourse is functionally nonexistent.

Furthermore, pointing to the quote, _“Julia is better when there are all kinds of people, including people with stupid political and social ideas,”_ and framing it as a genuine “invitation to remain” is a remarkable misread of a very basic rhetorical device. Tacking a hollow welcome onto a litany of personal insults is a standard tactic used to deliver hostility while maintaining plausible deniability. For a community moderator to endorse that tactic as proof of a welcoming environment is deeply revealing.

I do not need to argue this any further. By officially ruling that this behavior is acceptable, and even endorsing it, the moderation team has perfectly validated the core premise of my departure.

Thank you for making the reality of this community’s governance undeniable. I yield the remainder of my time.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [August 9, 2026, 2:59pm UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/62 "2026-08-09T14:59:15Z")

</div>

Since you’re replying to [my deleted post](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/59) (which I might as well undelete, since the damage is done), I must clarify that **I am not a moderator.** I have absolutely no influence on the moderation or governance of this site. As far as I can tell, no moderator has officially commented on whether any behavior in this thread is acceptable – although you might, and obviously do, take the lack of a moderator response as a response in itself.

If I was a moderator (which I really wouldn’t want to be), I don’t know if or how I would have asked @jakobnissen to more finely thread the needle between calling out a set of bad and harmful ideas, and giving personal insult to people that subscribe to some subset of those ideas. But I do agree that we should try to avoid to cross the line to “character impugnment”. Whatever ideas you personally hold probably do not make you a bad person, or someone who shouldn’t have a place in this community.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [August 9, 2026, 8:16pm UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/63 "2026-08-09T20:16:25Z")

</div>

> [@foobar\_lv2](#):
>
> > [@StefanKarpinski](#):
> >
> > @foobar_lv2, I feel like that addresses the bulk of your request bundle fingerprinting concern. Does it?
> 
> Yes! I think this is a much better version of sharding!

Good! I’m very happy to hear that. I was pleased to realize that it was a very simple change to the protocol.

> [@](#):
>
> I honestly would store individual records for ~3 days, for incident response, and then start deleting / bucketing.

We keep raw logs with IP addresses and everything else for 31 days for incident response, but it goes into a completely unrelated S3 bucket that the longer term log aggregation system never touches. So we can start bucketing right away.

> [@](#):
>
> Initially tell the server “nope, I’m opted out of download statistics collection”. Simplest implementation.

No header sent is equivalent to “opted out” so you can just do nothing.

> [@](#):
>
> Maybe also tell the registry that you are ajt instead of [Pkg.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/Pkg)?

That would be appreciated, just so we can know that from the logs. We could potentially add a header for it if that’s helpful.

> [@](#):
>
> You can simplify the protocol in some ways: For example, you could just skip the zero-knowledge-proof that the server’s RSA keys are “good”, i.e. don’t have a privacy-destroying backdoor. This is of course not ideal, but you can practically rely on all the Pkg users to keep the servers honest, i.e. spot backdoored RSA keys. I’m pretty sure that people from Pkg, discourse, and @StefanKarpinski will be happy to help you on that.

This is fine, of course, but it’s also designed so that the client portion is very simple to implement. And I would be happy to help. Pretty sure an LLM can do it pretty well too, especially given an existing implementation and thorough spec to base it on.

> [@](#):
>
> But the general protocol / idea is widely applicable: Approximately count individual users of a resource in a way that makes reasonable effort to preserve user privacy, with data embedded in http headers, and good mitigations against both malicious servers and malicious clients. This wants to be an RFC-style protocol with a variety of implementations in different languages (C, C#, javascript, java, with julia bindings for pkg and zig bindings for ajt).
> 
> First doing that for Pkg in a very hand-rolled fashion, and gaining experience, makes sense.

That would be very cool and I’d love to see this help open source projects everywhere gain better insight into their usage statistics while preserving people’s privacy.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [August 9, 2026, 10:37pm UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/64 "2026-08-09T22:37:59Z")

</div>

> [@Antipath1](#):
>
> Beyond the personal attacks, this stance makes the implicit financial expectations around this telemetry PR completely explicit. It argues that because JuliaHub subsidizes package infrastructure (“€100k / year”), users are “beyond entitled” if they expect privacy while consuming those resources.

> [@Antipath1](#):
>
> Thank you for this official moderator clarification. Having the project’s governance standards explicitly placed on the record is incredibly helpful.

It’s unfortunate that you keep misrepresenting what’s happening to make it sound sinister. “ **JuliaHub** is doing this” — when, in fact, as has been stated many times, JuliaHub has nothing to do with this and doesn’t benefit in any way, nor receive special access to any data. “ **Moderators** have officially endorsed this position” — when, in fact, the statement wasn’t made by a moderator. Some of the statements in this thread have been spicier than they ought, but I think that observation goes both ways.

If you have objections, ok, but please make them based on reality rather than based on fabrications. It undermines the position you’re putting forward to keep insisting on arguing from false premises.

> [@Antipath1](#):
>
> I do not share the viewpoint that expecting my local machine to remain private is “antisocial,” nor do I agree that I owe JuliaHub my data in exchange for using an open-source package manager.

Again, I think this misrepresents reality — it asserts that something bad is being proposed that doesn’t match what’s being proposed, and then argues from that misrepresentation. I asked the following question on the pull request [a month ago](https://github.com/JuliaLang/Pkg.jl/pull/4722#issuecomment-4967859615) in response to a similar post and got no response:

> [@StefanKarpinski](#):
>
> Assume that we implement all of the protections that are being discussed on the discourse thread (timestamp coarsening, removal of IP hashes, etc.). Suppose you are a user who does not know about this option and does not opt out of it. How would unknowingly leaving this turned on violate your privacy? Concretely. Real question. Please lay out the actual privacy issue that this causes.

So I’ll give it another try here: what, concretely, is the way in which this makes anyone’s local machine less private? Violating individual privacy is precisely what the protocol bends over backwards to avoid.

Is there some way that you believe the protocol fails to preserve individual privacy? If that’s the case, I’d very much like to know what it is. I think I’ve demonstrated that I very much _welcome_ that sort of objection and am extremely willing to address any such issue. That’s precisely what the back and forth with @foobar_lv2 has been about, and it has led to several concrete improvements.

Is the objection that you don’t trust the review process and believe that there might be a flaw in the protocol that simply hasn’t been discovered yet? I have proposed that we can implement the client side but wait to implement the server side until the protocol passes peer review. Of course, that doesn’t guarantee lack of flaws either. However, if a flaw is discovered at some point in the future, we would immediately turn off the server side and remove this from future clients.

If the issue isn’t actually about these things then it doesn’t seem to be about individual privacy at all. If not, then what is the issue? Do you object to the Julia community having aggregate user data at all? That’s not really about individual privacy then, but it could be an objection. I’m really just trying to understand waht the actual issue is here.

---

<div class="post-metadata">

**Author:** ![anon28281882](https://avatars.discourse-cdn.com/v4/letter/a/7ab992/32.png) [@anon28281882](https://discourse.julialang.org/u/anon28281882)\
**Post date:** [August 10, 2026, 12:13am UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/65 "2026-08-10T00:13:09Z")

</div>

I skimmed through the Executive Summary. I don’t like it, but I don’t like anything that collects data about me in any form, and I am generally opposed to any forms of gamification particularly in my private life.

However, if you and @foobar_lv2 are saying that it is bulletproof, and will remain so for years, if not decades, and that it will help individual researchers make a living, then I’m perfectly fine with it. Especially that the option for the opt-out is included.

On a separate note, to be honest, I am skeptical that this will significantly advance the development of the language or achieve the promoted goals. In my opinion, this approach is unlikely to disrupt established Silicon Valley technologies such as Python and C++. However, I might be very wrong.

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [August 10, 2026, 10:20am UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/66 "2026-08-10T10:20:02Z")

</div>

Proposal for moderation @StefanKarpinski (since it’s “your” thread) and @mbauman (as the resident moderator) :

Let’s split this topic. One thread for technical considerations, that ideally leads to an implementation of HLL-RSA user counting to be merged as a PR, initially disabled by default (this makes the actual data pretty worthless).

A second separate PR and thread / discussion / community consultation for whether HLL-RSA counting should be enabled per default, i.e. switching from opt-in to opt-out, that tries to build rough consensus for that.

It is anyways good development hygiene to have separate commits / PRs for “support feature X, gated behind feature-flag” and “enable feature X by default”.

Most political considerations and forum flamewars go to the second thread. First thread gets ruthlessly moderated / redirected to the second thread.

> [@StefanKarpinski](#):
>
> I’d love to see this help open source projects everywhere gain better insight into their usage statistics while preserving people’s privacy.

You’re thinking too small.

If I want reader statistics for my blog, then your proposal is a good way to do this. There is a not insignificant population who (A) wants statistics on resource-using clients, aka readers, and (B) hates cookie-banners, and (C) cares about their user’s privacy, and (D) also cares about the general politics of user privacy.

That would require a small javascript implementation of the client-side protocol, putting the key-material (i.e. the user’s statistical-tracking-identity) into localStorage.

In a perfect world, the necessary machinery would be part of web-browsers, such that users don’t need to trust the javascript library (this won’t ever happen).

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [August 10, 2026, 10:41am UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/67 "2026-08-10T10:41:08Z")

</div>

> [@foobar\_lv2](#):
>
> You’re thinking too small.
> 
> If I want reader statistics for my blog, then your proposal is a good way to do this. There is a not insignificant population who (A) wants statistics on resource-using clients, aka readers, and (B) hates cookie-banners, and (C) cares about their user’s privacy, and (D) also cares about the general politics of user privacy.
> 
> That would require a small javascript implementation of the client-side protocol, putting the key-material (i.e. the user’s statistical-tracking-identity) into localStorage.
> 
> In a perfect world, the necessary machinery would be part of web-browsers, such that users don’t need to trust the javascript library (this won’t ever happen).

Wow, I didn’t think of this. That could actually be quite impactful.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [August 10, 2026, 6:08pm UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/68 "2026-08-10T18:08:03Z")

</div>

> [@foobar\_lv2](#):
>
> Proposal for moderation @StefanKarpinski (since it’s “your” thread) and @mbauman (as the resident moderator) :
> 
> Let’s split this topic. One thread for technical considerations, that ideally leads to an implementation of HLL-RSA user counting to be merged as a PR, initially disabled by default (this makes the actual data pretty worthless).
> 
> A second separate PR and thread / discussion / community consultation for whether HLL-RSA counting should be enabled per default, i.e. switching from opt-in to opt-out, that tries to build rough consensus for that.
> 
> It is anyways good development hygiene to have separate commits / PRs for “support feature X, gated behind feature-flag” and “enable feature X by default”.
> 
> Most political considerations and forum flamewars go to the second thread. First thread gets ruthlessly moderated / redirected to the second thread.

While there have indeed been three or four concrete discussion threads (technicalities, opt-out-vs-opt-in, philosophies of privacy in general, and motivations here in specific), I don’t think a topic split makes sense nor do I think any are really off-topic. In fact, the motivation of the split, to have a place for a “forum flamewar” is misplaced: we do strive to avoid flamewars here. If anything the technical discussion makes most sense on GitHub itself.

The big challenge here, though, is that this topic _explicitly wants for_ larger community feedback on the topic, and that feedback has included ideological concerns. Our community is large enough to have widely diverging views on the ideology, including quite strongly-held contradictory ones, and that’s ok! That’s precisely why we strive to avoid ideological flamewars; they become exclusionary fast and nobody is changing their mind on the internet here anyhow.

---

<div class="post-metadata">

**Author:** ![kapple](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kapple/32/218915_2.png) [@kapple](https://discourse.julialang.org/u/kapple)\
**Post date:** [September 3, 2026, 3:26am UTC](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027/69 "2026-09-03T03:26:28Z")

</div>

> [@mbauman](#):
>
> nobody is changing their mind on the internet here anyhow.

To provide a small tangent as someone lurking this discussion (and many others), I would make a rough observation that this statement is true for a majority of the vocally loud opinionated individuals.

For others like me who aren’t experts in these spaces and learn a lot from witnessing discussions among others, it helps me form/update/change my opinion. Which I have done many times over the years of being a part of the Julia community.

In general I would love for there to be more discussions on various topics that I am not informed enough to ask well-formed questions/initiate such discussions.

In short, thank you to everyone (emphasis on “everyone”) contributing to this discussion. Following the spirit of @mbauman’s response: The open voices of opinion help in seeing the multiple sides of various arguments and experiences. The only blanket improvement most (if not everyone) needs in their communication is to deal in good faith and give each other the benefit of the doubt more often, lest we have to shut down some voices due to inflammatory communication which, sadly, blocks everyone else from being able to empathise with them.

[Previous page](https://discourse.julialang.org/t/rfc-proposal-for-estimating-unique-julia-clients-without-tracking/138027.md?page=3)