WIP: feat: a way to grant permissions to webxdcs

[WofWca]

Closes https://support.delta.chat/t/allow-access-to-camera-geolocation-other-web-apis/2446?u=wofwca

TODO:

• Move this behind an experimental setting

[Simon-Laux]

would rather make the app specify it in its manifest.toml file

[WofWca]

Huh? How would that be useful?

[Simon-Laux]

That would allow xdc app stores to show permissions.
And we could also say you need to specify a reason string there that we can show in the permission request dialog.

[WofWca]

Hmmmm idk idk. I think a "website" model is more suitable. Where the website (webxdc in this case) itself would explain why it's going to request a permission, in its UI.

This "manifest" model is more suitable for when there is no way to request permissions dynamically, where you have to assess them prior to installation, but with all permissions defaulting to "denied" I think it's not needed.

[Simon-Laux]

we could show an electron/native dialog in webxdcWindow.webContents.session.setPermissionRequestHandler when the permission is requested the first time.
Also would make sense to persist webxdc permissions, maybe for now in ui.* config key. like ui.webxdc_permissions.<messageId>. later it would be nice to have a core api for storing permissions per webxdc instance, so that core can automatically delete the permission config when the webxdc is deleted.

[hpk42]

1) It's not agreed that we want to generically allow access to such APIs as it can open a can of worms and cause further work on all platforms. Eying video/audio calls is certainly interesting but maybe better achieved by an agreed cross-platform "integrations" approach instead of a generic permissions-one for all apps. 2) As long as there are 53 open bugs (as of now on Desktop) and we need to maintain 1.46.X releaseability, let's please focus on maintenance and stabilization first.

[WofWca]

Pushed a few changes:

• hid this behind an experimental toggle
• more possible permissions to grant
• don't show permissions that were never checked or requested
• security: check requestingUrl origin just in case
• adjust log text
• a refactor of makeMenu

[Simon-Laux]

app can call window.location.reload() in it's iframe, you can only not reload the parent page.

[Simon-Laux]

What I would like to see in this pr:

• clipboard read access as toggle-able permission, also loosely related to Make sure WebXDC cannot access the clipboard #3416 (when we find a way to disable the execCommand("paste") method)
• persist the permissions you have selected in ui config key (probably sth like key=webxdc.permissions.<webxdc_id/msg_id>)
• ask user automatically when app requests permission in an electron native dialog (because electron native dialog is the least effort) -> only ask one time for each permission, if the user has denied it don't ask again.

permission storage format could be

enum PermissionState {
 GRANTED,
 USER_DENIED, // denied, don't ask again
 UNDEFINED // denied, but ask on first request, not really in that enum, use the normal undefined instead
}

type PermissionStore = {[permission:string]: PermissionState | undefined}

Edit: these 3 states are already common in other web apis, see https://developer.mozilla.org/en-US/docs/Web/API/Notification/permission_static

[Simon-Laux]

For other platforms:

I don't think waiting for integrations makes much sense, they come with their own questions and challenges.

The ui does not need to be complicated, we can just start with the following:

• Experimental setting to turn on the permission system
• For now only implement the web standard permissions such as camera/microphone/media and clipboard read.
• UI:
  • in the 3 dot menu on iOS and Android webxdc add a new entry "Permissions" that opens a native dialog with checkboxes that is the ui to change the preferences (on iOS it could also be an action sheet, like how we did the experimental settings there in the past)
  • additionally when the app requests permission for something the first time show an confirmation dialog asking the user to allow / deny it -> only show the dialog if the user has not denied that permission for that app before.
• Store settings in ui config for now as I described in my last post in this thread.

code implementation:

on both android and electron there is a permission handler function/callback that is called when the website requests a web permission, the handler can then accept or deny the request:

• android: WebChromeClient.onPermissionRequest and WebChromeClient.onPermissionRequestCanceled API 21
• iOS only supports gyroscope and media (camera & microphone) permissions, there are 2 specific handlers instead of the one that android/electron has:
  • webView(_:requestDeviceOrientationAndMotionPermissionFor:initiatedByFrame:decisionHandler:) iOS 15
  • webView(_:requestMediaCapturePermissionFor:initiatedByFrame:type:decisionHandler:) iOS 15
  • regarding clipboard read permission: we could use user scripts to overwrite other apis to deny access like we did for webrtc

Later we can improve it:

• define what web permissions the app can request, by manifest, like there needs to exist a key with a reason string, like in iOS.
• store the permissions somewhere else, like with a new core api?
• if we do crypto signing we could think about sharing permission settings for a signed app version instead of having it separate for each instance.

[Simon-Laux]

I rebased it to main (after merging monorepo, I offered to rebase all prs that were made before that)

[r10s]

sorry to be a killjoy and to repeat things:

this PR and this discussion here is tricky timing-wise.

there is no agreement about the way to proceed with permissions. and the PR does not help on any open, much more important issue - but it adds issues and work on all platforms. distracting development resources from far more important things.

(also, the original idea of a "share location" webxdc seems to be a bit lost on the way - how useful are desktop permissions to make a “share location” thing where most desktop do not even know their locations. this underlines, that it is not just this single PR, but will keep lots of devs busy)

i am not saying that it does not make sense, but i doubt it makes sense now.

i suggest to move this PR to resurrection and reconsider later.

[WofWca]

Do you think it would be okay to merge if we were to remove the toggle from the UI completely? so that it's only possible to enable for developers.

[r10s]

i would postpone the pr fully, freeing development resources.

otherwise there will still be discussion, pressure on other os etc., removing focus from other things - let alone bugs :)

developler can still use this PR for experiments