# Security of sender info **URL:** \ **Category:** Mini Apps\ **Tags:** webxdc-api-future\ **Created:** [April 22, 2023, 11:12pm UTC](https://support.delta.chat/t/security-of-sender-info/2541 "2023-04-22T23:12:52Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![ian](https://support.delta.chat/user_avatar/support.delta.chat/ian/32/3164_2.png) [@ian](https://support.delta.chat/u/ian)\ **Post date:** [April 7, 2026, 11:55am UTC](https://support.delta.chat/t/security-of-sender-info/2541/8 "2026-04-07T11:55:47Z")
It is difficult to come up with a good workaround lacking an authentic sender ID. Each participant could generate a key pair and sign their updates so at least impersonation wouldn’t be an issue, but then anyone could still forge an unbounded number of identities and the host still couldn’t see who voted for what in the end either. Keeping the key in local storage will make multi-device impossible, while deriving the key from `selfAddr` kept secret would only be useful if it contained sufficient amount of entropy. It is known that Delta Chat aims for delivering the minimal viable product first. It is reasonable to then postpone supporting cases where as many parts of the system could act in a malicious manner. Note that exposing just these two fields would already solve the very common use case where one of the participants in a group chat, the host, is trusted by other members, none of whom need to be trusted by any other member themselves. The trusted member would be the one to send in the webxdc and to optionally validate business rules after each update. You are already placing ultimate trust in one who develops and sends in the webxdc anyway. We could protect against a malicious participant sending different updates to different peers by confirming having received the same, unaltered update by each participant. The webxdc app could add the checksum of their whole public aggregate state (or of past updates) to the payload on their turn to achieve this. Again, this would only be possible with an authentic sender ID field. Related: > [@Find sender of app?](https://support.delta.chat/t/find-sender-of-app/4603/1): > > Is there a way to know which user is the sender of the application? In order to create for example a game where the sender is the first player. > [@API to select "host" participant](https://support.delta.chat/t/api-to-select-host-participant/3020/5): > > It sends the self address in the updates and does not answer to join request from the same address as the selfAddr. This could be improved when we have a unique userid that core would assign as metadata next to the payload. > [@WebXDC and other protocols](https://support.delta.chat/t/webxdc-and-other-protocols/2543/3): > > The “webxdc.selfAddr” is a bit of an ad-hoc design to leave it to xdc apps whether they sent the identity of users around. But Delta Chat is already itself itself in the business of knowing from where an update comes from, namely e-mail + cryptographic identity but it does not expose this in the “update” struct pased into the Updatelistener [Webxdc Specification - Webxdc](https://docs.webxdc.org/spec.html#setupdatelistener) Maybe a new “webxdc.selfUri” with a “mailto:…” could be offered but what do you think this would help with? Possibly a precondition to: > [@Request for API to send update in private to channel owner](https://support.delta.chat/t/request-for-api-to-send-update-in-private-to-channel-owner/4998/1): > > The owner of a broadcast channel sends in a webxdc app. The webxdc as ran by the owner (preferred) or a separate bot would send in xdc updates to the broadcast channel for members to consume similarly to how they can already send in messages. As the channel is receive-only as seen by subscribers, their webxdc app instance can’t send an update back. However, they can already reply in private to messages on the channel. The webxdc app that they ran could similarly post the update payload as a pr… --- _[View the full topic](https://support.delta.chat/t/security-of-sender-info/2541)._