diff --git a/proposals/4140-expiring-events-with-keep-alive-endpoint.md b/proposals/4140-expiring-events-with-keep-alive-endpoint.md
index b49671a353d..ad16c189bf3 100644
--- a/proposals/4140-expiring-events-with-keep-alive-endpoint.md
+++ b/proposals/4140-expiring-events-with-keep-alive-endpoint.md
@@ -1,6 +1,6 @@
 # MSC4140: Expiring events with keep alive endpoint
 
-Currently there is not mechanism for a client to provide a reliable way of
+Currently there is no mechanism for a client to provide a reliable way of
 communicating that an event is still valid. The best expiration method is to post
 another event that is stores that it is expired.
 In some situations the client just looses connection or fails to sent the expired
@@ -121,8 +121,29 @@ the `"will_expire":"running"` events for a specific event type but render the
 
 ## Alternatives
 
+[MSC4018](https://github.com/matrix-org/matrix-spec-proposals/pull/4018) also
+proposes a way to make call memberships reliable. It uses the client sync loop as
+an indicator to determine if the event is expired. Instead of letting the SFU
+inform about the call termination or using the call app ping loop like we propose
+here.
+
 ## Security considerations
 
+We are using unauthenticated endpoint to refresh the expirations. Since we use
+the token it is hard to guess a correct endpoint and randomly end `will_expire`
+events.
+
+It is an intentional decision to not provide an endpoint like
+`PUT /_matrix/client/v3/expiration/room/{roomId}/event/{eventId}`
+where any client with access to the room could also `end` or `refresh`
+the expiration. With the token the client sending the event has ownership
+over the expiration and only intentional delegation of that ownership
+(sharing the token) is possible.
+
+On the other hand the token makes sure that the instance gets as little
+information about the matrix metadata of the associated `will_expire` event.
+
 ## Unstable prefix
 
 ## Dependencies
+