I recently found out that Shelter is behind on updates on the Play Store as it seems the last update was from September 2020 and on F-Droid, the newest update came much more recently, from September 2022.
The only option (as it seems to me) to download a recent version of Shelter is from the official F-Droid repository, but the Privacy Guides Team doesn’t recommend installing apps from the official F-Droid repository due to the notable problems of it and the official F-Droid client.
More about it here and here.
So I think it would be a great idea to put a warning or disclaimer that recent versions of the app are only available on the official F-Droid repository, with a little explanation of why this bad is.
I will never understand why developers leave their apps up on a store but stop updating it. If you no longer want to distribute an app on a specific store, why not take it down? I’m assuming that Play Store provides for that functionality.
It may be that Shelter requests some permission that Play Store doesn’t like, which would explain why.
I’m not certain whether that is worse or better to recommend.
It seems that the developer said they would remove the app from Play Store “very soon” in March 2022:
On a slightly related note, I don’t see much point in recommending work profiles at this point, so a discussion about removing Shelter might make sense if the team is open to that?
The way I see it, what it provides is profile data separation without having to switch to a different user profile. However, the work profile is not as isolated as user profiles. For example, I believe that apps in the work profile can see apps in the Owner profile and vice versa.
I contacted the developer of this app. This is apparently because of the Google Play policies surrounding file permissions. They were surprised it had not been delisted as they had received a delisting notice. They said they will manually remove it.
I assume that this only contains beta versions of the app, which is generally not preferred to recommend for people who need stability for the apps. Also, I didn’t find any other way to install the app from the custom F-Droid repository without using the official F-Droid Client or with a custom client like Neo Store.
I have read more about this on here, and it seems true, or am I missing something?
I don’t think its possible for work profile apps to see apps in owner profile atleast incase of user apps ,(some system apps might have the privilege access to some unique device identifiers, owner data and apps list.) and viceversa. But there are some quirky settings in work profiles which if not paid attention to could allow cross-sharing of data like contacts etc.
I agree that User profiles provide much more isolation in user data and even system apps would have isolated data. There is an additional option in user profile to disable phone calls and sms which could prevent apps from getting cell provider information.
That is true, but it doesn’t solve the problems with the official F-Droid repository either, and compared to an alternative F-Droid client like Neo Store, there aren’t any automated updated on Obtainium.
There are automatic updates on Obtainium, just no seamless updates, which means it’ll automatically check the updates for you, it just won’t install them.
But yes, this doesn’t necessarily eliminate the problems with F-Droid, but it does provide a way to get F-Droid apps without an F-Droid client.
Also I think Obtainium allows adding apps from F-Droid repositories other than the main one, so it should be possible to add the app from the dev’s own F-Droid repo, where they have signed the app instead of F-Droid, which eliminates F-Droid from the equation entirely. I haven’t tested this, though.
I have tried this, but with no succeed. Do you know if adding the signing key fingerprint of the repository from the developer itself is mandatory? If yes, then I can’t add it to Obtainium, because I don’t see such option there.
The signing key shouldn’t be necessary, but from my testing it seems that the Shelter repo doesn’t work in Obtainium. You can try opening an issue about this.
It’s unclear to me whether this could be implemented in a way that doesn’t require these permissions. However, seeing as apps adhering to Play Store policy at the very least used to be a requirement for Android apps, should Shelter be reconsidered? That, plus the fact that you’re essentially trusting this app with whatever you put in the work profile makes this a bit of a subpar recommendation, imo.
The proper way to do what Shelter does is to use user profiles.
On GrapheneOS. I think this recommendation is for Android in general.
It could never be a requirement on the site for apps to adhere to all Google Play policies, many of them are arbitrary decisions. Whether apps should comply with this particular policy, I’m not sure… I’m looking through Google Play’s policies relating to file permissions and can’t find any Shelter would violate, assuming they submitted a permissions declaration form, and they should be eligible to do so as a device management app. I’d be interested in finding out what particular policy Google cited in this case.
I wonder if we should recommend Island instead or in addition to Shelter. I don’t think the current release is open source, but the developer is relatively well known.
@dngray It may also be worth revising our F-Droid listing to endorse custom/developer-run repos, at least until Accrescent is released. We run into a number of cases where all other app distribution platforms are insufficient at present, like this one.
Not necessarily. Don’t get me wrong, GrapheneOS does make a lot of improvements to user profiles, including QoL improvements, but if someone is using a work profile in order to isolate a particular set of apps, the proper way to do so would be by using user profiles, even outside of GrapheneOS.
An app not requesting the INTERNET permission doesn’t necessarily mean that whatever access it has to your device is a-okay. An app having extended access to data on your device means that if it is vulnerable in some way, it’s a lot more of a juicier target should there be a way to exfiltrate said data.
There is also of course the (admittedly far-fetched) scenario of either the app developer becoming malicious, in which case they can just introduce the INTERNET permission whenever they want, or the app becoming compromised by a third-party which does the same thing.
At the end of the day, work profiles were not designed to quarantine apps, Shelter and other apps like it are trying to use functionality meant for something else as a means to an end, and while I’m not saying they do a horrible job at that, a work profile is at the end of the day just not as isolated as user profiles.
May not all, but I think they generally do a good job of weeding unmaintained apps out, or apps that request more invasive permissions than they should. Unsure if this applies to Shelter here, although storage permissions are generally regarded as fairly dangerous/sensitive permissions, which is why they’re becoming more and more granular with newer APIs.
Separating apps in the profile from personal apps and data is precisely what work profiles were designed for, actually. I’m unfamiliar with limitations compared to a user profile besides the fact that they share a single encryption key for the underlying data, which is hardly relevant for this use-case.
Correct, but the main purpose of work profiles, to my understanding, is to ensure that your organization/employer can control what you can do within the work profile/with the work apps.
In my mind, this is the true power of having a work profile / a device manager app:
If your device is personally-owned, your organization can carry out some or all of the following actions:
Remotely create, access, and delete data in your work profile
Enforce minimum passcode requirements on your work profile and device
Change the password to your managed account (the account associated with your work profile)
Suspend access to your work profile
Restrict what can be shared across your work and personal profiles
Block screen captures in your work profile
Manage access to your organization's corporate mail server and internal data
Remotely install (and uninstall) apps and certificates in your work profile
Manage permissions and other settings for apps in your work profile
User profiles, on the other hand, were developed to be the closest thing to a distinct phone without it actually being a distinct phone. While I am not insinuating that Shelter/Island/Insular etc. would use being the work profile/managing the work profile for evil, it’s always a better idea not to extend that trust.
That is not true. Shelter can’t access everything that’s in Work Profile and Shelter doesn’t require network permission too. It is fully open source and work profiles have numerous benefits over user profiles some of those are that you don’t need to keep switching between different profiles, you can see the content of notifications from apps that are in a work profile and you can reply right away. You can use a work profile app in split screen which you couldn’t do with an app from a different profile. I could keep going with all the possibilities that work profiles provide.
Here’s a comparison table that Insular made to compare between those three apps. (SAF Enhancer lite is a third-party FOSS (GPL 3) app which leverage Storage Access Framework in the share option, to be able to save it locally on storage.)
Also, either something incorrect or not precised. The ″Block Contacts Searching″ is referring to apps checking the Work Profile contacts according to their readme.md, as it state that it does block those apps from searching it in the main profile. Insular also allow SMS & GPS location permissions by default.
