Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request]: Allow app updates without consulting parental controls #5552

Open
2 tasks done
pwithnall opened this issue Oct 6, 2023 · 3 comments
Open
2 tasks done

Comments

@pwithnall
Copy link
Collaborator

Checklist

  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

Currently, app installs and updates are treated the same from the point of view of the parental controls permissions checks. This was intended so that parents have to re-check each app update to make sure it’s still appropriate for their children.

In practice, though, parents are not that hands-on, and there are a lot of regular app updates. The tradeoff between app security/feature updates and not changing so much in apps that a parent’s initial assessment of their suitability for their child is probably skewed the wrong way. We should be preferring security/feature updates, and assuming that if an app is OK to begin with, it’s probably not going to change so radically as to become unsuitable for a child with an update.

As a data point, Google Play’s parental controls will allow apps to be automatically updated even if a child account can’t install new apps.

There was a big discussion on this internally at Endless (https://phabricator.endlessm.com/T33738) which isn’t public, but the tl;dr is what I’ve written above.

Implementing it would be a case of:

  • Modifying flatpak-dir.c to add a new FLATPAK_HELPER_DEPLOY_FLAGS_UPDATE_HINT so that calls to flatpak_dir_deploy() from app updates and installs can be differentiated (I don’t think there’s a way of doing that at the moment)
  • Adding a new polkit rule like org.freedesktop.Flatpak.override-parental-controls, called, o.f.F.override-parental-controls-updates and checking its authorisation on updates (vs installs)
  • Setting a different default policy for the new polkit rule which allows updates by default (different distros can then customise this if they wish, as can users)
  • Updating any relevant documentation
@Mikenux
Copy link

Mikenux commented Oct 10, 2023

We should be preferring security/feature updates

What does that mean? Let apps self-label their updates as security or feature updates? Can we tell the difference between the two without verification by trusted people?

@pwithnall
Copy link
Collaborator Author

We should be preferring security/feature updates

What does that mean? Let apps self-label their updates as security or feature updates? Can we tell the difference between the two without verification by trusted people?

As in, we should prefer to apply available updates to an app, rather than wait for parental authorisation for each of them.

@Mikenux
Copy link

Mikenux commented Oct 11, 2023

Okay. The plan is therefore:

  1. Differentiate between updating and installing apps in terms of policy.
  2. Make the application of updates automatic by default, but modifiable to apply by authorization.

Is it correct? Sorry, because the issue title and policy name suggest overriding parental control settings (but maybe because English is not my native language?).

At first glance this seems like a good idea for the reasons you mentioned. However:

We should be preferring security/feature updates, and assuming that if an app is OK to begin with, it’s probably not going to change so radically as to become unsuitable for a child with an update.

There is no difference between a security or feature update, so any developer can update their app by modifying its content. Developers might take advantage from this default (automatic update), especially if this default will not be changed for convenience and there is no review of these updates by the app provider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants