On 2026-01-29 (Do.) 09:30, Willy Tarreau wrote:
Hi Aleks,
On Wed, Jan 28, 2026 at 08:14:57PM +0100, Aleksandar Lazic wrote:
Hi.
I thought to see how claude.ai can help HAProxy and ask claude.ai to add the
feature JA4H Fingerprint.
Attached the 3 patches.
What's your opinion on that?
I don't know what is the amount of ai-generated code, but it's rather
clean overall. It should get rid of all the malloc/realloc, which could
be replaced by an on-stack allocation of small arrays, because our
headers are limited to global.tune.max_http_hdr, and a few functions
already use it that way. Same for the cookies: cookies have to be split
per-header anyway in H2 during encoding so their number is also subject
to the same limitation.
Thanks that you have take a look into the code. I was also positiv surprised how
"good" the patches looked.
The memory handling is a good point.
However, I'm having a much higher concern based on the ja4 license:
https://github.com/FoxIO-LLC/ja4/blob/main/License%20FAQ.md
and more specifically that one:
https://github.com/FoxIO-LLC/ja4/blob/main/LICENSE
In short, it says that they've patented all of their JA4+ suite, that
it cannot be easily mixed with GPL code and cannot be used in commercial
products without getting a commercial license from them. So to me this
means that:
- the fact that you implemented it yourself doesn't change the
situation, you're not allowed to choose the license on your own
code that implements their documented technique;
- they've file a patent for stuff that was already being done by many
others before them, and they might even have purposely chosen that
deceptive name "JA4" as a way to dupe users into thinking it was
the next version of JA3, while in fact it could be a patent trap;
- companies proposing code implementing these features (here: your
patch) as part of their commercial offering need to find a way to
get rid of that part or to pay them a fee in order not to risk being
sued. This includes not only companies like my employer who dedicates
a lot of manpower maintaining the whole code opensource and usable
by everyone, but even enterprise distros who could probably have to
carefully handle this case.
- in any case we cannot afford to enable it by default, it must be
an opt-in where the user is conscious of their decision, but this
does inevitably fragment adoption and can make the feature mostly
pointless, since free distros will not want to decide to expose
their users.
Now I don't know what they've filed, nor the amount of prior art (we
even had an HTTP fingerprint extension more than 10 years ago at
haproxytech that was much more complete), nor if anyone is willing
to review their filings and engage into legal battle with them to
demonstrate prior art, but all of this tells me that it's way out
of the technical work we're all interested in and that this solution
smells very bad and should be kept away like radioactive waste until
they change their mind and decide to be opensource friendly.
Many of our users are service providers, and I'm just not willing to
start to put them at risk of being sued just by copy-pasting a config
excerpt from a blog post or even by having it generated by their
favorite AI assistant. I do hope that in 10-20 years from now, since
most of the creations will be done by AI, patent trolls will just
disappear but for now they're still polluting the tech world by
forcing others to stay in the middle age just because they managed
to file trivial concepts first.
Maybe it can be fine to keep this as an external patch. In this case
it would be easier to have it as an independent file, that will be
easier to build (i.e. no patch conflict, and as long as the internal
API doesn't change it still works).
Another option would be for the various projects communities to join
efforts and create a new "standard" (and maybe call it "JA5" in order
to continue with that logic?) that proposes alternatives and likely
better mechanisms to achieve the same purpose.
Uff. Thank you for the detailed explanation.
Just my two cents,
Willy
Regards
Aleks
