Key phase here is that data isn’t downloaded to the device…meaning that it can’t be used by the app. And really, there isn’t anything preventing the developer from turning off the protection and viewing the data. I think it’s more useful in cases where you have an existing table with columns that should not be used by an app, for example, like in the U.S. where we should never share an SSN or Tax ID. If you happen to have an existing table of data that contains a tax id, but is not needed by the app, you can make it a protected column, so glide completely ignores it and it’s contents. So for those reasons, protected columns wouldn’t work in this case.
As far as encrypting data, I don’t think there is a good way to do that with glide. I think the data is encrypted during transmission, but while on the device, it must remain unencrypted to be read by the app.
Glide really isn’t designed to hold data that is not viewable in some way by the developer. The best you could do is use a bunch of user specific columns, which would get you closer, but it doesn’t stop the developer from viewing the app as anybody else to view that user specific data. The only safe solution would be if a copy of the database could be stored locally on each user’s device, but that’s not the case with glide. Just knowing what I know about how glide works, I don’t see any way that user data could be stored in a way where it’s not visible to someone with access to develop the app. That’s where it’s useful to make sure the developers are trustworthy and/or they have signed an NDA, or make sure the types of data fit within Glide’s Terms and Privacy policies.