Webhook destination uses different timestamp between timestamp & signature headers

[alexluong]

Describe the bug
In the default implementation of the webhook destination, there are 2 headers (more but 2 relevant ones in this issue):

X-Outpost-Timestamp: 1748495228931
X-Outpost-Signature: t=1748495228,v0=de1fb18031714debc5a66a615fe98e99b61c1f8c570e87eec2d95508bd926475

You can see, in the signature, the default template includes the timestamp in Unix second. The timestamp on the other hand is Unix millisecond.

Also, in the signature (v0=....), by default, the first part of the signature is the timestamp in second too. I think we should use millisecond for that as well.

Expected behavior
I think these 2 should probably be the same, and ideally they should be Unix millisecond.

[alexbouchardd]

My understanding is that the standard Unix format is seconds, not milliseconds. Including a millisecond timestamp in a signature would be non-standard and offer unnecessary precision, as it's primarily used for replay attacks. I think we either should keep it as is or change the X-Outpost-Timestamp to be seconds.

[alexluong]

Yes, the default Unix is second.

The reason I changed the header timestamp to millisecond was for latency calculation purpose.

There's a disconnect here I think and we should either change the signature or the timestamp header. So it seems you think we should change the timestamp header instead?

[alexbouchardd]

Yep, I believe so

[leggetter]

Ok, so we've ended up using a header for latency that's really there for verification. Let's go with the standard and consistently use seconds.

We may need to have a separate conversation about what we need to measure latency in benchmarks.

[alexbouchardd]

We could use a "reserved" metada property such as x-outpost-latency and include the timestamp in the publish data from the load test tool

[alexluong]

In this case, for latency calculation, we want to get the timestamp when the delivery is initiated, so the data can't really be included in the publish payload.

That's alright for now. We can probably support a config option for custom config or custom behavior for latency purposes. It'll mostly be used internal during the load test or benchmarking, so the end users don't necessarily need to use or even be aware of them?