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’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.
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:
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.
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
When does the UID get created? My use case is the following: New user enters email/PIN code through the Glide screen. Once in the app, if it is a new user (no username, or other data in the Profile row), the user is taken to a screen to populate these items and then Save the profile. If UID requires a form entry, then that would create a new row in Profiles, so I have user going to a Tab and editing/entering the remaining profile data. Somewhere in the flow, UID is not getting created.
A unique ID needs to be deliberately set by a unique ID special value. It’s an auto generated value, but needs to be set by the special value column. It’s not automatic in the way that Row ID automatically fills in whenever a new row is generated. Is there any reason why you are not using the Row ID in place of the Unique ID? Are rows automatically added by the User Profiles process when a user signs in? Is your Complete Profile screen just a details screen? If it’s a details screen, I don’t think you will have access to the Unique ID special value to set the Unique ID column, like you do when you are on an Add/Edit/Form screen, or the AddRow/SetColumns actions.
Basically, you need to set the value. It won’t automatically appear. Only Row ID does that.