WebXDC threat model?

[9er]

@Simon, thanks for your clarification!

[maphouse]

@Simon

There are ideas of adding apis to the messenger (like deltachat) to get data from it, but that will probably rather evolve into its own messenger specific extension specification.
Like a webxdc with geolocation web api would not be of much use when you don’t have the web view open (it could not share the position in the background), so this is a feature that should rather be implemented directly into the messenger to use the native apis directly.

Though there could be an extension specification that allows access to the data, so you could have an alternative map app or similar, though as I said such a thing would be probably use a messenger specific api as all messengers have different features. Also you would really need to think hard about security and permission model if you expose more data from the messenger to the webxdc which could still exfiltrate it to an evil group member.

Hey Simon, would really like to read/hear more from you/ or others about this, and what the status of location sharing is more generally. I haven’t found any webxdc apps in dchat that use any geo features, which leads me to believe location sharing is not possible at this time via webxdc? the experimental map feature appears to be a core webxdc integration of some kind that allows for location sharing. Can this be mobilized by other webxdc apps somehow?

[WofWca]

@maphouse

location sharing is not possible at this time via webxdc?

Yes, it’s not possible generally. The “location sharing” feature is indeed based on WebXDC, but it is a special case. Normal WebXDC apps don’t have access to the geolocation API.
See Allow access to camera, geolocation, other Web APIs - #4 by WofWca.

[Joshua]

@Simon

As of right now there is no official way to disable access in chromium webviews

Do you have a little more background on that? I did some research because the progress bar was annoying me. I’m not really deep into the topic so I might be missing something. My understanding is that modern webview versions should support blocking it via CSP policy.

In the past there seems to have been a problem in the spec that seems to have been addressed as far as I can see: WebRTC bypass CSP connect-src policies · Issue #35 · w3c/webrtc-nv-use-cases · GitHub

But as I’m typing this, I’ve found Chromium which seems to be exactly the problem we have right here and honestly it’s shocking how little they seem to care over there.