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. 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. Just my two cents, Willy
