Honestly, I think what TFA calls "Kagi’s implementation of Privacy Pass" is the integration of the feature into their server and clients, not the RFC (which they acknowledge), or the protocol implementation.
Indeed, this is the intended interpretation of "Kagi's implementation of Privacy Pass" - we're talking about building out the server infrastructure, the UX, the browser extensions, the mobile applications, the Orion browser integration, the support and documentation, the Tor service, etc. The cryptography is obviously an extremely important piece, but it is far from the only piece.
As other commenters have noted, the code in question is MIT licensed [1] and we're pulling it in as a standard dependency [2], it's not like we've gone out of our way to obscure its origin. The MIT license does not require us to do anything more.
That said, I can understand the author wanting more visible attribution, and that's very reasonable, we'll add a blurb to the blog post acknowledging his contribution to Kagi's deployment of Privacy Pass.
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.
Exactly this. As a British English speaker that works a lot with the US it was an early learning.
In British English a "scheme" has no negative connotations. It's commonly used in all kinds of legitimate places - for example the company you work at will have a "pension scheme".
In U.S. English it has a connotation that it is nefarious in some way.
GitHub is not forcing you to use 2FA to store your repos elsewhere. Just to interact with their website.
> I should get to decide the appropriate level of security.
People are really bad at deciding the appropriate level of security.
GitHub hosts a lot of very important projects that have impact in the real world. Forcing people to use the bare minimum to keep that environment relatively secure is probably not a bad idea.
That way when you set your password as "batman123" and are given commit access to some obscure project that is included as a dependency in 1000 other projects, your account is much less likely to be taken over as a means of pushing a malicious commit.
Note the disclaimer: "This course has not yet been updated to work with the Raspberry Pi models B+ and A+. Some elements may not work, in particular the first few lessons about the LED. It has also not been updated for Raspberry Pi v2."
The 3A fuse is due to the way the UK wiring system works rather than what is optimal for this device.
All appliances in the UK have a fuse where they connect to the building wiring, normally in the plug, but can be in a fixed fuse-holder like this device. Somewhere in the process it was recognized that having lots of different fuse values would be confusing and awkward for users, so these fuses are the same size and always one of three standard values: 13A, 5A, and 3A. As noted elsewhere, you can buy these particular fuses in UK supermarkets and convenience stores.
If 3A is too high for the appliance then what the designer has to do is to fit it with a flex rated at 3A so that is protected by the fuse at the plug-end and then add additional, lower current, protection at the device end.
The UK system is clever and has subtle details like the standard fuse values which were good at the time it was introduced. But, it is also rather over-engineered, and not optimized for modern homes that have a lot of low-current appliances.
Oh yeah the UK system.. I lived in Ireland for a long time and it was a bit archaic sometimes.
I like the idea of fuses in every plug, mind you. Because some equipment just can't be trusted. I didn't like the switches in every outlet (even though they're not mandatory, they are very common). And the way the plugs are so huuuge and always fall with the pins up do to the design so they are a foot-piercer.
In Ireland 1A fuses were available though even in the fuse kits in Tesco. With the same size as the others. And the practice doesn't always lead to actual safety, I've seen a lot of tinfoil and paperclips. Yes, really.
But the thing I really thought was the worst was the concept of having only one tap connected to the mains water line in the house, and having all the others fed by a huge dirty water tank in the attic, full of dead insects brewing away in the summer heat (yes even there it can get hot in summer). It seems like an ecological disaster and locals were always warning me to not drink the water from the bathroom or bedrooms taps. It's also a big possible cause of leaks. Here in Spain and in my home country of Holland we just feed all taps onto the mains.
But overall I tend to prefer EU standards rather than BS. The "Schuko" does have a few serious design flaws like the ability to plug it in upside-down so neutral and phase are reversed, but the French have found a solution for that :)
I think many cold water tank system in Britain have been removed in the last 20 years or so, as people install more efficient central heating / hot water systems.
No idea about Ireland.
(Here in Denmark there are switches on sockets. I find it useful on the rice cooker, which doesn't have its own switch and would otherwise need to be unplugged. The other sockets are generally left with the switch "on".)
Because BBC Basic had a built-in assembler it was pretty uncommon for BBC programs to inline machine code as raw data (unlike some other computers from BITD).
It's been around more than 15 years in various forms now, but people still love playing it. If you're in London it is at https://www.novelty-automation.com/
What a clever idea! It got an exercise bike and noticed it was boring, so I hooked it up to a speed sensor and used that control VLC playback speed. Very motivating, to watch a movie like that because if you slack off it will slooowwww dooooowwwwnn.... And not nearly as boring :)
Yes, Paul did the original as a Java Applet. I did the port to run in the x-compile to allow it to run in the browser. After that we cooperated on it for a while. I stepped back a few years ago to focus on other things, but he's kept up with improvements. Kudos.
I posted that rather quickly, so a bit more information for those who are interested (inspired by some of the comments on the thread).
I found Paul's sim by chance and really liked it because it was the first electronics sim that I had seen that was properly interactive and visual in its approach. I thought it was a great tool for building intuition about circuits. However, at a certain point it became clear that Java in the browser was on its way out, and this really needed to become a plug-in free experience if it was going to continue to be useful.
This was about the time that V8 was coming along and revoluationizing the performance of JS. Originally there was no license attached to the project, so I asked Paul if he was OK in me trying to port it to run on JS using the GWT framework. He was fine, but said he'd done old experiments with some of his other sims and found that JS wasn't performant enough, but with the strides in JS performance I was more optimistic.
I took the Jave code and commented just about everything out to get a minimal implementation of the standard LRC circuit just to see the performance. Once I was comfortable with that working I started adding every feature and every component back. Most of the work was replacing the Java graphics primitives with the equivalents from GWT.
Once the initial version JS version was out I did quite a lot of work mostly on UI features, especially the 'scopes. They were rather weak in the original and still not as good as I would really like, but much improved.
I have thought about monetizing and extending with EDA features, socials, etc. but its never been enough of a priority to do it. I kind of like its simplicity as it is.
It has been used a lot in education and a couple of teachers have contributed to the code to support their uses in classrooms.
It's kind-of amazing that it still has a very distinctive niche that nobody else has really gone after in quite the same way. I think a lot of that is because Paul's original vision and work on the Java version was so good.
