Restructuring app for actual privacy

Ask for Help
1

After a great call with @Darren_Murphy my eyes are now opened to data and how available it is, even if you do not want it to be. I had seen @Robert_Petitto’s video on Row Owners but not fully understood the implications of how Glide actually works.

So what I understand is:

  • data in most Glide apps is basically available to any user of the app using ‘Inspect’ (if using Chrome) then navigating to the Networks area (?) and scrolling down to one part… and you can see everything. Argh.
  • ‘hidden tabs’ are not really hidden. The device can still see all the data. All of it that Glide uses somewhere. You can use Row Owners (email) or then Roles (see below) or Protected Columns (a good option for some data types)…
  • some of the security options for ‘Private’ apps are odd (at best) - such as ‘restrict by password’. This means ONE password. You might as well write it on your web site. Argh. Odd choice…
  • the ‘anonymized email’ is bizarre - the email names are friendly, you cannot see them as the dev… but they are also totally unusable as they are not real emails at all. You cannot send the person an email and resolve the alias. It just goes into space. It is not pointless, but hardly point-ful.
  • Private Pro is NOT the same thing as Pro (it just used half the name). A Pro app (I have one the $32 a month option) gives you Row Owners but NOT controlling via ‘role’ (or groups, etc). Then it is $40 per month min (as $2 per month x 20 min people) - and Glide might come up with a better price. This seems like an app could become expensive quite quickly as I do not know what counts as an active users (going into the system once in a month?). A 50K user system… might be 100K a month? (OK, likely discounts, but still)

Next what data is actually made available if it is out in the clear? If you have a sheet / Glide table and it contains Rel columns, is the data from the Rel column ‘target’ also brought into the device at the same time? Might we try to hide more confidential in another part of the app… but the Relationship column brings it in anyway?

This EU GDPR thing is a real issue for anyone who has any EU users. Which will be a lot of people. Now you can ask permission to do things, and I am doing more investigations on what is best to do (thanks to @Krivo for actually pushing me in this direction). From what I can tell Personal Identifiable Info (PII) is a defined thing (mostly) but it drives you into a logic of ‘do I really need this data in my app… is it worth the potential hassle’.

Then it will come down to a readable Terms & conditions that cover the app, plus the underlying Glide and Google Sheets issues (and all the other plug-ins that might be part of the overall app). I am still making my way through one service (recommended in here - thanks!) that will make a custom Terms & Conditions doc based on the various services used and how they are being used.

Fortunately for now the app I am building is a prototype not really being played with by users. It does make me think now how I can architect the app and data better to be less open by the ‘Inspect’ backdoor. I would imagine it would not be hard for a motivated person to be able to scrape all the data from all Glide apps they could find… argh.

I then do not know how a 200K row system would function, how slow it might become for end users (as they would be downloading the entire dataset - unless the app has been more rigorously protected).

And just thinking about restructuring… making a copy of the template, playing around in it, then using some magic (actual magic with a wand) to copy across changes from one template to another. OK, no magic exists. I have been doing screenshots and diligent manual copying (with at least 1 mistake always). Argh.

Still, I love the platform and so much can be done with it. I have been very impressed by all the improvements over the last 12 months and am therefore hopeful for more on the horizon. Maybe for my app I end up with something for a good sized group of friendly people who accept the T&Cs and conditions of privacy (or absence thereof), and use it as a reference for a different platform eventually. Personally I like playing in Glide and GSheets as I understand them, whereas otherwise I have no idea how to code!

Anyway some thoughts for the evening and some work for the rest of the week. Thanks all!

1 Like
2

Yes, privacy and data protection is a deep and complex topic.

To be clear, you have full control over what data is accessible, by any means, to your users. This is your choice. Glide does not make data available to users “even if you do not want it to be.” You could create an app full of sensitive information and make it world-readable. Or you could make it tightly protected in a secure way. We give you a broad set of tools to protect your data, but it does take some learning and you must apply them.

Overall, I suggest:

  1. Pick an appropriate login method for your app. (Does your app contain private data for your company? Then it should really be private.)
  2. Secure every table containing PII using Row Owners and/or Roles—every table, including tables that are targets of relations.
  3. Understand that filtering and hiding things in your app UI is not a security feature, as we explain in a blocking dialog when you first use these features.
3 Likes
3

I’ve seen services offering a ‘wrapper’ to put responsive web apps like Glide apps into Google Play & App Store. I could not see how data would be handled, whether a) it really works and b) would the data problem (/way it works) still exist.

For some apps, if the app could get to the play stores, not have this data leak problem, and be able to somehow use notifications, then a grand or two would be very worthwhile!

4

From what I’ve seen here, and outside the community it looks like that it works. It’s a native iOS app that opens a web page (PWA). The user will see « no difference ». But it has been said here countless of times that it’s totally unsupported.

I can’t see anything going wrong here, but dont quote me on that.

Hope it helps, and can’t wait to hear more from David.

5

Wrapping your Glide app in an app-store wrapper does not increase the security of your app.

3 Likes
6

A really important thing to understand is that all computed columns are computed on each end users device, including relations. So Lookups, Rollups, Split Text columns, etc, etc are all dynamically computed in real time in each users device. That means that all data (minus any that’s protected by row owners) is firstly downloaded to the users device, rather than the other way around. (at least that’s my understanding - happy to be corrected on that)

1 Like
7

I thought a bit more about accessing the app with email + password (single password for everyone).

It means that it wouold be super easy to log in to someone else’s profile if you know (or find out) their email address. As the password is the same for everyone.

I genuinely wonder what the use case is for this feature!

8

Probably any type of general information app that doesn’t have data specific to any one user. Maybe like HR forms or a corporate intranet, where the content isn’t user specific, but it is specific to a single company.

9

Then any company employee could be easily be impersonated without trace. I would not find that compellingly good…

10

And find all their personal info … so a user could be, say DavidATglidapp.org… as that is a known email, use the generic single ‘password’, and then go into David’s accounts, see David’s things, interact as David… then log out and go in as JeffAT… etc.

Why?? It is bizarre. (why approach the single PWD in that way is bizarre… people cheating is understandable, sadly).

You do have event sites that have a password to access it that is common… but these sites might not have the data leak problem on the device… I have not tried to use sites like these in this way (but not implausible that they work the same way as there is no attempt to verify the email outside of Glide)

11

What I’m trying to say is that it would be for sites that do NOT have personal information for multiple users, but still needs to lock out users that don’t have the password. In the scenarios I’m describing, there is no impersonating of users because an app protected with the password option shouldn’t contain personal private information if that’s the only authentication method.

The glide documentation states that the Limit Access by Password option does not track user’s emails, so they can’t benefit from user specific data. You can however allow them to further sign in with email and pin verification if they need to access private information that would be protected by row owners.

2 Likes
12

Password-protected apps are essentially single user. When you sign in with a password, you don’t also get to say “my email is abc@xyz.com.” There is only one user identity for those apps.

Yes, these apps have fewer features because they cannot distinguish users from one another. If you want distinct users, we have sign-in options for that.

3 Likes