How can you tell a human actually understands? Prove to me that human thought is not predicting the most probable next token. If it quacks like duck. In psychology research the only way to research if a human is happy is to ask them.
Does speaking in your native language, speaking in a second language, thinking about your life and doing maths feel exactly the same to you?
> Prove to me that human thought is not predicting the most probable next token.
Explain the concept of color to a completely blind person. If their brain does nothing but process tokens this should be easy.
> How can you tell a human actually understands?
What a strange question coming from a human. I would say if you are a human with a consciousness you are able to answer this for yourself, and if you aren't no answer will help.
Oh, I dunno. The whole "mappers vs packers" and "wordcels vs shape rotators" dichotomies point at an underlying truth, which is that humans don't always actually understand what they're talking about, even when they're saying all the "right" words. This is one reason why tech interviewing is so difficult: it's partly a task of figuring out if someone understands, or has just learned the right phrases and superficial exercises.
That is ill-posed. Take any algorithm at all, e.g. a TSP solver. Make a "most probable next token predictor" that takes the given traveling salesman problem, runs the solver, and emits the first token of the solution, then reruns the solver and emits the next token, and so on.
By this thought experiment you can make any computational process into "predict the most probable next token" - at an extreme runtime cost. But if you do so, you arguably empty the concept "token predictor" of most of its meaning. So you would need to more accurately specify what you mean by a token predictor so that the answer isn't trivially true (for every kind of thought that's computation-like).
> A shared secret removes the potential for detection from the service while asynchronous key signing does not.
I would approximate that 95% of the time when a webhook sender discusses signatures they are referring to HMAC (symmetric-key signing). There is a clear benefit to asymmetric-key signatures but that's not the focus of this article. It's discussing the industry convention of using symmetric-key signing.
> If you move authentication to the web hook implementer you lose control of what authentication mechanisms are in use
I don't understand where you are coming from. The article is comparing shared secret vs signing. In both those auth methods the "control" remains in the same place. The webhook consumer has to do the auth verification. The webhook sender mandates what authentication method is used.
Under none of these scenarios is the webhook consumer providing their own "authentication system".
Re-reading the article, I'm confused about where I was coming from too. The article claims that it was last updated May 7th but the two Archive captures[0][1] seem to be broken for me ATM. The link to the blog source on GitHub[2] (linked from the page) just gave me a 404 and searching for the file didn't yield another location so I can't look for a commit timestamp or delta.
There is a bit of switching back and forth between speaking from an API provider and an API consumer standpoint and it is possible that in not reading sufficiently carefully I misunderstood. I was also previously oblivious to the context of the product they are marketing here that turns out to include API SDK generation (including a webhook acceptance sdk for validating requests? I don't know). The nuance that the implementer is an API provider providing both direct API access and a webhook delivery API could easily have caused me to misunderstand properly written words that flew over my head in the midst of getting bored with the content in my failure to understand it.
A great question from the article, in its current state[3], is asking: are API keys are secure enough for webhooks? In theory, you could validate a webhook request by confirming that the API key matches your in memory copy of that key. Either that or signature validation is usually supplied by the service SDK or example code that you cut and paste anyway.
Sadly, for a long time, it was too much to ask some clients to provide HTTPS security for connections and those requests had to be sent over HTTP, which would require alternative mechanisms of supplying non-repudiation (proof the content had not been altered in transit). This may be a forcing factor of the convention and thank you to Let's Encrypt and others for helping the industry shift (though I still find stragglers occasionally).
In the current environment of mostly ubiquitous HTTPS any non-secure URL configuration could be rejected by a webhook sender and an API key comparison could be authentication enough while retaining the sender controlled nature of the authentication. However, that newly assumes confidentiality of the API key by two parties which a webhook implementer may not be sufficiently competent to guarantee. This could leave a webhook implementer in the position of processing malicious requests without the valid sender having a mechanism for detecting the breach and exposing the sender of the webhook request to messy, relationship damaging, potentially legal, arguments about whether they leaked a key. The signing process retains private signing materials under the custody of the sender, simplifying the threat model and reducing its surface.
So, while you're right that (if we aren't talking about the webhook request implementer using webhook implementer authentication) the webhook consumer isn't providing their own authentication system, they are providing security for the authentication system in the case of API key use. Perhaps this is a version of Postel's law? Personally as a business generating SDKs for APIs I would be inclined to go the other way and encourage customers to generate SDKs with signing rather than encouraging webhooks without signing. Demand is what it is and so are clients so... I can't fault them either.
Thank you for helping me understand that I had missed context (or at least giving me an opportunity to respond to the latest version of the page, though my making an error seems more probable).
> Thank you for helping me understand that I had missed context
My pleasure!
> The signing process retains private signing materials under the custody of the sender
In the signing process, with a symmetric key, the signing materials do not remain under the custody of the sender. Both parties need access to the signing key. If the consumer leaks the key they have to notify the sender and vice versa.
Asymmetric signing is used very sparingly in the context of webhooks.
Sorry if I'm misinterpreting your sentence a little too literally here.
When using symmetric signing, the threat model advantage I was advocating for disappears. Finding examples like Stripe and GitHub using symmetric signing was easy. Given this it seems far more likely this is an artifact of a time that you couldn't expect customers to host using HTTPS.
I'll chalk this up as another one of those "oh god, really?" moments with this industry.
The API producer will always retain ownership over the authentication mechanism.
The article is comparing the use of a shared secret vs HMAC.
For shared secret: Who specifies auth? The webhook producer. Who implements auth? The webhook consumer. For HMAC / signing it's exactly the same parties who do those things.
Discussions about mutual TLS and public keys are out of scope.
I think the webhook producer tends to implement auth in both scenarios but agree that the webhook consumer executes auth in the webhook case. You perhaps meant this but I was initially confused by what you were trying to say here. You other comment was far more helpful, thank you for making it.
In summary of my other comment, it is the case that the implementation and execution roles are the same but the threat surface is very different.
I would be curious too. I think it comes down to the benefits are there and they're cheap enough that they may as well recommend a more secure approach.
Depending on your performance requirements extra milliseconds of roundtrip to the externalized queue may be too long of a wait. Or you may simply not care enough for an extra piece of infrastructure that you'd need to support, and maybe this is good enough.
It's is all about trade offs, no solution fits all use cases.
its always about tradeoffs. one nice compromise position here is that the log is always consistent, so you don't need to wait at all if you don't mind losing the tail on a crash.
