# 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:** 8\ **Page:** 1
**Author:** ![singpolyma](https://support.delta.chat/user_avatar/support.delta.chat/singpolyma/32/1795_2.png) [@singpolyma](https://support.delta.chat/u/singpolyma)\ **Post date:** [April 22, 2023, 11:12pm UTC](https://support.delta.chat/t/security-of-sender-info/2541/1 "2023-04-22T23:12:52Z")
Right now, webxdc apps can include a “sender” in the payload if they need it, which works, but has absolutely no security of any kind. I would like to see the sender of an update included as an extra key injected by the “host” app (such as deltachat) like the sequence numbers are, instead of in the payload, to prevent trivial spoofing. Related to this, it would be great if there was a property injected containing the address of the “initiator” of the app, eg whoever sent the original message with the app attached. This would allow for the poll app for example to only show the configuration UI to the original sender instead of to whoever happens to open it first. ---
**Author:** ![hpk](https://support.delta.chat/user_avatar/support.delta.chat/hpk/32/9_2.png) [@hpk](https://support.delta.chat/u/hpk)\ **Post date:** [April 23, 2023, 6:17pm UTC](https://support.delta.chat/t/security-of-sender-info/2541/2 "2023-04-23T18:17:18Z")
So i guess it would be some “update.peer\_uri” attribute, maybe. Anyone who has a hacked up version of Delta Chat could anyway get at this info, anyway, Do you have some app prototyping going on where you would need that? ---
**Author:** ![singpolyma](https://support.delta.chat/user_avatar/support.delta.chat/singpolyma/32/1795_2.png) [@singpolyma](https://support.delta.chat/u/singpolyma)\ **Post date:** [April 23, 2023, 6:38pm UTC](https://support.delta.chat/t/security-of-sender-info/2541/3 "2023-04-23T18:38:36Z")
Most existing apps could benefit from it. For example, with the existing poll app I can spoof a vote from anyone else in the chat by sending an update with `payload.sender` set to their address. Since all sender info is just in the payload there is no protection and the app has to just trust it. ---
**Author:** ![hpk](https://support.delta.chat/user_avatar/support.delta.chat/hpk/32/9_2.png) [@hpk](https://support.delta.chat/u/hpk)\ **Post date:** [April 24, 2023, 8:44pm UTC](https://support.delta.chat/t/security-of-sender-info/2541/4 "2023-04-24T20:44:30Z")
FYI we do not yet engage much with the “one of the chat members and participating xdc app users is a cheater” threat model … and there are many other ways to cheat like sending a different XDCs to different people while they think it’s the same. That said, it might still make sense to add an update.peer\_info attribute because it’s a convenient thing to use for an app (and as seen from my device, it’s more authentic if DC marks incoming updates with the precise peer\_info from the sender of an update – this does make spoofing harder, agreed). ---
**Author:** ![singpolyma](https://support.delta.chat/user_avatar/support.delta.chat/singpolyma/32/1795_2.png) [@singpolyma](https://support.delta.chat/u/singpolyma)\ **Post date:** [April 24, 2023, 8:58pm UTC](https://support.delta.chat/t/security-of-sender-info/2541/5 "2023-04-24T20:58:53Z")
I’ve been calling it `sender` but happy to use `peer_info` or whatever else makes sense. ---
**Author:** ![r10s](https://support.delta.chat/user_avatar/support.delta.chat/r10s/32/1513_2.png) [@r10s](https://support.delta.chat/u/r10s)\ **Post date:** [May 8, 2023, 7:42pm UTC](https://support.delta.chat/t/security-of-sender-info/2541/6 "2023-05-08T19:42:13Z")
somehow related, we aim to remove the need to let `selfAddr` be equal to the email address. that way, other implementations can follow the spec, see [`selfAddr` may be any unique ID by r10s · Pull Request #42 · webxdc/webxdc\_docs · GitHub](https://github.com/webxdc/webxdc_docs/pull/42/files) this won’t protect against the “cheater threat model”, however, will improve privacy. ---
**Author:** ![ebert](https://support.delta.chat/letter_avatar_proxy/v4/letter/e/41988e/32.png) [@ebert](https://support.delta.chat/u/ebert)\ **Post date:** [April 24, 2025, 6:26pm UTC](https://support.delta.chat/t/security-of-sender-info/2541/7 "2025-04-24T18:26:10Z")
> [@hpk](#): > > Do you have some app prototyping going on where you would need that One could create an gift coupon app were changes of the current amount of “stamp fields” and further “stamps” are signed which should be available anyways. (I’m not talking about blockchains, I’m talking about gift coupon apps, really) These both persons WANT to interact with each other so no hacking involved here. But in order to trust the Webxdc itself the available signs could be used. Maybe you could pay your next food delivery this way 🤷 ---
**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…