Hi
I was happy to find the “unique id” special value, because I want to respect my users’ privacy by not having the ability to match data with emails. I still have emails in the “App: Logins” and Whitelist sheets, and that’s OK, but I want to get rid of all email data from any other sheet, and use only the Unique Id.
But, when trying to filter by signed in user, I see it is only possible with the user’s email. So I’m stuck.
Do you plan on adding this feature some time soon? I mean: Filter rows by signed in user, with a choice between email or unique id.
Thanks
Michael
PS: you should update this doc below, as it doesn’t match the current UI. And it actually seems to hints at a possibility to filter by logged in user with something else than email. That gives me hope :slight_smile
I’m not sure I’m getting the same impression as you are of using UniqueID for Per User Data. I see UniqueID more as a unique identifer for anything from people to products to anything else where you could potentially have a duplicate name, but need a unique identifer for each name (kind of like a product SKU for example), or you want the ability to change the name of something without breaking any existing relations to other sheets. My perception is that it’s not used to identify a unique user. If I were you, I would use the your Whitelist sheet as your main tab. Then I would create a column to hold a UniqueID and establish Unique ID’s for each user before the user logs in for the first time. From there you can use the UniqueID as a relation to other sheets in your database. So essentially, relations would take the place of using per user data since the values being used for the relation would only pertain to that persons uniqueid. Unfortunately everything would need to be linked to the primary whitelist sheet and all navigation would have to start from that whitelist sheet tab.
Well this Unique ID is a special value that is generated by Glide, who basically holds the key of the map between email and unique id. Just to avoid any misunderstanding, I am talking of the special value in ADD screens, with the fingerprint icon next to the email and the timestamp. And it is definitely meant for users, not product or anything else.
The solution you’re proposing with the Whitelist is basically like re-implementing Glide’s unique ID feature. Did I understand correctly ?
Also I want to get rid of the whitelist at some point and switch to Public with email. The whitelist is just a way for me to control the list of alpha testers.
OK now I’m confused. I entered the app from another phone, and after adding a new item to my list I see it created a different Unique Identifier in the new row. OK so what is the Unique identifier?
From the doc it says this:
With the Unique Identifier special value you can add a unique id to a row when users add, edit, or submit forms, giving you sophisticated control over relations between items in your app.
So I guess it means a new id for every new row. That’s not what I thought then. OK so now I need to implement it myself, maybe with your suggestion Jeff.
But I don’t like the fact that I will know the match between id and email. I want to ensure complete privacy to my users, so that even myself cannot know how to match their data with their identify.
Even with the same phone, if you add several items, they will each have their own unique id. I think the fingerprint icon might be a little deceptive here. Like I said before, UniqueID is used to assign a unique ID to just about anything. It it not a unique identifer for a logged in user. It can be, but only if you design the app like I indicated above. The unique id is a value that can never be duplicated (look up the definition of UUID or GUID).
In your case, the only thing that would ensure complete privacy would be some sort of hashing or encryption, which isn’t provided by Glide or Google Sheets at this time.
Here are a couple of posts that illustrate how I plan to implement Unique ID in my project.
Thanks Jeff for the explanation. I actually see places where I can make good use of it
Yes the icon is misleading. I even thought at the beginning it was something like a real fingerprint bytecode that you pass to the sheet, until I switched to the other erroneous thought that it is a unique user id. If I may suggest, I would put a number 1 in a circle as an icon.
I think that without a need for encryption there is a possibility for a unique user id. Something that would be generated internally by Glide without knowledge from the app itself (i.e. myself). This way I could make an “email-free” input sheet, while being able to filter data for the current user. Sure I could maybe infer my own ID by looking at the sheet after I add something, but I can do it only for myself. This would make me compliant enough with a goodwill privacy policy.
I’m not an expert in security, so I may be speaking wrong. Please let me know if this is a reasonable idea or not from your side.
Ping @david. Is there a plan to add a per-user unique identifier ?
I am doing a budget management app, and I would like to tell my users that I respect their privacy and can’t identify them in the expenses table.
The fact that the user’s email is the only proposed special value and key for filtering raises a general privacy problem in Glide apps in general, which is of special concern in these days where the GDPR regulation is being more and more enforced, and now actually complied by major actors like Google.
Having this simple feature would be a great leap toward enabling privacy compliance for Glide customers.
Here are a few links for more information about the European GDPR regulation:
This is very easy and can already be done in Glide.
If you want to give your users complete privacy while giving them the full functionality of the app, then all you have to do is tell them to use a fictitious email and do not reveal any identifying information about themselves or their company.
"Signup with a fake email, fake name, fake company but keep the data real.
Only they will know their email, but you will see the fake email but don’t know who it belongs to. You will be able to communicate with chat, and such without revealing the identity of the person.
Think of it the same way lots of people create fake facebook accounts without anyone knowing who the real person is.
@Lighted_Candle Well I have to disagree with it. True, users can always disguise themselves but that cannot be a requirement from the app. It would be just a second security for them, but apps have a moral duty to make their best not to expose users’ data even to developers.
Specifically in my case, I’m doing this app for friends in an alpha-testers whitelist and I want them to feel comfortable with their privacy.
Yes, I understand what you mean. But glide already gives the power of protecting user data from app developers.
Here’s how.
Once you have finalized your app you are able to sell or give your app to individuals by allow them to copy the app. This will give them a private version of the spreadsheet and you won’t see their data.
You cant ask people for their private information, keep it in your possession and control and then tell them to feel secure you won’t look at it.
If you want to give your clients reassurance about their data, let them know you won’t have it in your possession at all.
Exposure of sensitive data is also one of those things as a society we have to live with, where privileged information has to be exposed to certain people that are needed to help us with our personal lives.
Accountants, lawyers, Doctors, app developers, bankers, most branches of government, church, etc.
These kinds of people cannot functionally guarantee that they won’t look at your private information, because their job is to look at your private information.
The only thing they can guarantee is that they wont share it with other people. And that my friend is the only privacy an app developer can guarantee.
OK @Lighted_Candle, regardless of the endless debate about service providers having access to data and associated identity, the point about copying the app is interesting.
I know about the fact that copying the app will duplicate the sheet and keep it private to the user.
But it has 2 issues:
1- it means my users have to be Glide users, which I can’t reasonably ask from profane users
2- It breaks the possibility for me to upgrade features (and fix bugs) seamlessly.
To fix #1, it would be great if Glide allowed users to log-in with their Google ID, so that it would duplicate the inner sheet to their account. It’s a feature I asked some time ago in a direct conversation with Glide developers, but I didn’t proceed with this thread. I guess I will make it a more official feature request.
For fixing #2, it is possible too with he above feature proposal, if we don’t copy the Glide app itself. Still, a problem would remain in case the feature changes come with a change in the sheet’s structure, in which case we would need some backward compatibility mechanism, and that would get so complicate that I would refrain from asking for such a feature…
Instead, I would propose that Glide prevent changing the sheet in case it was shared in “Copiable” mode (another option next to “Public with Email”, “Whitelist” etc), and if the Glide user-developer insists on doing so, there would be a warning that next users will have a duplicate branch of the app (a bit like a branch in source control), and older users will never benefit again of improvements from the new branch. Yes, I’m proposing that Glide support dev branching…
Back to the debate about privacy agreement between the service provider and the user, many companies enforce a mechanism (based on user unique id) to prevent exposing the users’ private life to the developers. An app developer is not an accountant/lawyer/doctor with whom the user has explicitly agreed to share his life secrets.
I’m sharing this pointer which deals more thoroughly with the identifier issue and the European GDPR regulation (which Google now complies with):
It also boils down to the purpose of the app. If it’s a business promotional site they actually want the info out there and aren’t likely to list their bank account number along with their address.
If it’s a guide and has a user’s location it could only be a stalking app if that data was stored to the sheet. We as app devs don’t get to see that but it could be viewed at Glide I suppose.
Not sure I’d care if someone knew my favourite songs but maybe a feature could be to password protect the Data and Sheet info so that the app owner can prevent the app dev from seeing such data once the app is built using fake sample data.
Not sure if that would be feasible. Maybe they plan a means to transfer app ownership over and then have lower than admin rights for the devs.
Copying the app seems impractical if it has a social component to it. Chatting to yourself is almost as fun as leaving yourself nasty comments.
A smaller version to the enigma is to build a user-controlled reference:
Summary
example.
For each user, you would have a reference column called [key].
Whenever a person wants to see or update their related data they would use edit to add their “Keyword” to trigger that reference column.
All related data to that keyword would then appear in the app. After they have finished adding new records with that key, then they would remove their key and all the data would become detached from that user’s related column.
This way you won’t know who the data belongs to because it does not have an email reference but has some unknown number reference that is only known by the user.
The Caveat.
You could still secretly turn on "Email capture in your app and secretly attach their email in the app without them knowing.
But if you do it the honest way according to how I show you, you would not know who the data belongs to. Unless of course, only one person is using your app.
Related to privacy debate:
This is the “Backdoor” reality we all have to live with. No matter if there are laws or software that exist to protect or encrypt private data, we’re all still at the whim of the people who develop these programs. All developers can see, Trace, and find the true owner of all data. Just ask the FBI. Encryptions cand be decrypted. Even the Us Government, Google, and facebook got hacked.
Glide can see and read all our personal data and all the private and personal data we put into our google sheet. "We gave them “PERMISSION” to do so. Same with Google sheet.
Google can read all our personal and private emails, bank account, gps etc. We gave them PERMISSION to do so.
While you have good intentions to secure your user from your own prying eyes, you are a party to the development and you, therefore are creating a type of conflict of interest by trying to guarantee them that you won’t see their data. Like a surgeon trying to guarantee their patients, he will do a good job without looking at their private parts. (Just saying it sounds suspicious).
No matter how much you don’t want to see your user’s data, you will not be able to guarantee anyone that truthfully, because you are a party to the development process. The only way to guarantee such is to give a third party the job and remove yourself from the equation.
If you need a good third party developer you can call me. I promise I won’t look at their data
