On Wed, 10 May 2023 21:59:37 GMT, Phil Race <p...@openjdk.org> wrote:
> > It is not for the "we have all permissions" case, it is for the case when > > we only have a permission to some screens. So it won't hurt. > > But how does the app know when to call it ? Right now it doesn't know. If the user is not satisfied with the result, he can "reset" it. But it seems to be a weak position. > OK, so to make sure I understand, you use the token to see if you can obtain > a stream for all connected displays. If any "fail" you know the user didn't > approve that. > > So we can do this every time right ? And in conjunction with knowing which > screen[s] were connected when we captured the token we know the situation > changed and so we know it is appropriate to ignore the stored token - causing > the user to be re-prompted. > > And even if the screens have changed if we already have the token we need for > THIS screen capture we know whether we already have the permission we need. > And if we do then we just use it and don't cause a user re-prompt. > > At this point I think we've done everything that "revoke" was needed for. The problem is how to relate the tokens to the screens. We don't have some universal id that says that the display we saved earlier is this current display. There is an opaque id of stream: https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.Start Stream properties include: id s Opaque identifier. **Will be unique for this stream and local to this session**. Will persist with future sessions, if they are restored using a restore token. This property was added in version 4 of this interface. Optional. But it didn't help much, as it local to the session(each token - different session), token looks like `0`, `1`, etc We can match the stream layout to the screen layout in the system, but it has its flaws: Let's say we have following layout of screens in system, displays have the same resolution(e.g. 1920*1080):  Screen capture permission is granted for `A` and denied for `B`. 1. On a first run we are capturing screen area at `(100, 100, 100, 100)`. 2. We match an acquired `restore_token` to the screen at `(0,0,1920,1080)` 3. User decided to change screens to following layout:  4. we are capturing screen area at `(100, 100, 100, 100)` again 5. Oh, we have a `restore_token` for the `(0,0,1920,1080)` screen, let's reuse it. 6. Ouch, we got black pixels because the token was issued for display `A` and it is now `(1920,0,1920,1080)` > Then [if I have everything right] the only open question is whether when > permissions to the required screen or screens was previously denied, do we > re-prompt ? My take is that we do not "store" a token that denies access. So > next time the app is run they will be re-prompted. But we _probably_ don't > want to keep re-prompting within this running instance of the JDK. > > BTW "the app" means "any app that can find this token, doesn't it" ? Yes, it is currently shared between Java applications for the same user. > Also if we follow the suggested policy of not storing tokens which don't > grant permission then we'd also not over-write it in that case. Currently we only overwrite tokens when we get a new one from the system. In the full DENY case, we do not receive any token. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1544062418
