Understood, and thanks for updating the blog post. The discussion in the comments was interesting, and I'd like to clarify a few points. From my side, there never were any doubts about licensing compliance. I picked MIT precisely so that folks can use the implementation without further obligations, I wanted the implementation to be as useful as possible. What startled me was the combination of a for-profit company writing a blog post about a new feature (that will likely further increase profit in the future), using my implementation as the core of the feature (and therefore likely save a bunch of money) and not giving any credit to either the IETF batched tokens draft or the implementation. Anyway, the blog post has been amended now – thanks for that. Case closed.
PS: If you want to go above and beyond, you can spell my last name right in the blog post – it's Robert, not Roberts.
I love that Kagi now uses Privacy Pass, and they look like a cool company in general.
That being said, they essentially took the IETF draft I worked on for a while [1] and also my Rust implementation [2]. They built a thin wrapper [3] around my implementation and now call it "Kagi’s implementation of Privacy Pass".
I think giving me some credit would have been in order. IETF work and work on open-source software is mostly voluntary, unpaid, and often happens outside of working hours. It's not motivating to be treated like that. Kagi, you can do better.
I case you refer to me as the MLS co-author, I'm not directly affiliated with the p2panda project. I think p2panda uses OpenMLS (OSS implementation of the MLS protocol, https://openmls.tech), hence the connection. I did however exchange with this friendly an motivated team!
MLS and blog author here. I've been a proponent of deniability within the MLS WG and there have been quite a few online and offline discussion about it. Personal opinions aside, deniability remains a divisive property. Some people think it is important, many people do not care about it, and a few even think it is harmful. That sets it apart from properties like say confidentiality that is far more appealing to most people. It also remains largely theoretical, in that the lack of deniability hasn't had tangible negative consequences so far (the DKIM case aside, but that doesn't translate 1:1 to messaging).
Deniability is also used as a colloquial term, when there is much more nuance to it (what exactly is deniable? what capabilities does the attacker have? etc.). Finally, deniability in protocols like Signal clearly have limitations and can be circumvented with moderate effort as explained in [1]. So the reason why deniability didn't make it into core MLS is rather banal: there was not enough traction.
That being said, there has been a low key effort to come up with an extension to MLS to introduce some notion of deniability. It is not published yet, but I will probably talk more about it at the upcoming MLS session at IETF117.
Thank you for bringing this up! It appears ghost has this turned on by default, and I turned it off now. Sorry for any inconvenience. For context, we had an internal debate whether we should host the blog ourselves, but ultimately decided to use ghost. It ticked a few boxes, being open-source and run by a non-profit. The fact that it would do outbound link tagging by default really comes as a surprise, so thanks again for bringing it up.
PS: If you want to go above and beyond, you can spell my last name right in the blog post – it's Robert, not Roberts.