π blog!
-
A weird #ActivityPub message from #Frendica.
Signed on 2026-09-01
Published on 2026-03-02That's a skew of six months! The message type is "Undo" - so they're undoing a like they sent in March.
Is there *really* a worry about accepting requests like this? Given the message has been signed, what risk is there to replay attacks?
@Edent Looking at it from the other angle, there doesn't seem much upside to accepting it.
-
@Edent I do not think the published date would matter to the request itself.
- What if the content was in draft or some other editing process by the author? Why would you reject the content because the
published,changeddates in the object are different from when the request was sent out? - What if your server timed out the first time, and the message is being resent from a poison queue?
- What if the average request time was 5 seconds, and it was delivering to over 120 instances and yours was last on the list?
- What if there is a queue that processes outgoing activities, and it only does it once per...
- What if the content was in draft or some other editing process by the author? Why would you reject the content because the
-
A weird #ActivityPub message from #Frendica.
Signed on 2026-09-01
Published on 2026-03-02That's a skew of six months! The message type is "Undo" - so they're undoing a like they sent in March.
Is there *really* a worry about accepting requests like this? Given the message has been signed, what risk is there to replay attacks?
@Edent wait, why would you even care if the publish date and the signature date are skewed? They are two different pieces of information that don't have to match.
For example your server could have been down for a day and a task queue might have been retrying to send you the message which was created by a different part of the sending pipeline
-
@Edent wait, why would you even care if the publish date and the signature date are skewed? They are two different pieces of information that don't have to match.
For example your server could have been down for a day and a task queue might have been retrying to send you the message which was created by a different part of the sending pipeline
@Profpatsch yeah, that's the question I'm asking. Is there any risk in accepting a message that old?
I don't think there is - but I wanted to check with wiser minds. -
@Edent I do not think the published date would matter to the request itself.
- What if the content was in draft or some other editing process by the author? Why would you reject the content because the
published,changeddates in the object are different from when the request was sent out? - What if your server timed out the first time, and the message is being resent from a poison queue?
- What if the average request time was 5 seconds, and it was delivering to over 120 instances and yours was last on the list?
- What if there is a queue that processes outgoing activities, and it only does it once per...
@mradcliffe yeah, that's the question I'm asking. Is there any risk in accepting a message that old?
I don't think there is - but I wanted to check with wiser minds. - What if the content was in draft or some other editing process by the author? Why would you reject the content because the
-
@Profpatsch yeah, that's the question I'm asking. Is there any risk in accepting a message that old?
I don't think there is - but I wanted to check with wiser minds.@Edent personally I think it's healthy for the network to accept these, but @silverpill knows best
-
@Edent personally I think it's healthy for the network to accept these, but @silverpill knows best
An HTTP signature proves that an activity exists on the originating server - it's substitute for fetching activity by its ID. The originating server has full control over the activity JSON and the request headers, so the date of publishing doesn't matter.
What may matter is the date when the signature itself was created. If you receive a request signed several days ago, that might indicate a replay attack... Or a broken clock on the sender side.
-
An HTTP signature proves that an activity exists on the originating server - it's substitute for fetching activity by its ID. The originating server has full control over the activity JSON and the request headers, so the date of publishing doesn't matter.
What may matter is the date when the signature itself was created. If you receive a request signed several days ago, that might indicate a replay attack... Or a broken clock on the sender side.
@Edent @silverpill @Profpatsch yeah, the Activity could have been in a low priority queue. Either way this type of activity isnt always fetchable so Iβd accept!
-
@evan Thanks - I had mine at two minutes.
I'm starting to see more exceeding 10 minutes.
I wonder what the actual risk is of accepting something with that long a delay?Just in case: I believe Evan is referring to the delay between the signature's date and "now" on the receiver.
This is different from your original question about a pub date and sig date, which I believe has no maximum distance. With imports, edits, searches, boosts, undo, it wouldn't surprise me if these can be very far apart. As long as it valid now and was signed/sent to you recently, that should be secure. The pub date could be anything.
See also: https://mitra.social/objects/01a05e04-e18e-7f83-9999-7cb58ed4de05
-
@Edent @silverpill @Profpatsch yeah, the Activity could have been in a low priority queue. Either way this type of activity isnt always fetchable so Iβd accept!
@django it could be on exponential backoff.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better π
Register Login