App use consent --- new feature for all apps (privacy and compliance)

Hi all, over the holidays, a few of us at AppSheet have been hard at work to ensure that the apps you build on AppSheet are suitably architected for the business environment of 2020 โ€” especially with respect to privacy and compliance. In Europe, there are GDPR requirements while in the US, California is introducing its CCCA laws this year.
Before an end-user uses and shares his/her personal information via the app, it is considered good practice to inform the end-user about the information that this app will be gathering, the uses that this app will make of that information, and request the userโ€™s consent before proceeding. It is also expected that the Terms of Use (ToS) and Privacy Policy (PP) of the app will be accessible to the end-user to help make this decision. Anyone who goes through an AppSheet sign-in has the opportunity to provide their consent to AppSheetโ€™s use of their data. However, the end-users of individual AppSheet apps do not have a similar opportunity to consent to the use of their data by the app creators.

Starting today, we are gradually rolling out a change that ensures that every AppSheet app will automatically launch such an end-user consent dialog when user X first uses app Y. AppSheet will automatically detect what information the app will access and will prompt the user for appropriate consent. The ToS and PP of each app are customizable by each app creator. You can find the ability to do so on the Info -> Properties pane of the app editor.

If the user does consent, then the app functions normally as it did before. If the user does not consent, then they will not be able to proceed to use the app.

For some, this may seem like an unnecessary level of friction and we understand that sentiment. However, since the vast majority of our customers are businesses for whom topics like compliance and privacy are important and in some cases issues of law, we believe it is important to enforce this change uniformly across the platform.

As always when we make significant changes, we want to make sure we share our motivations and the principles behind the changes, and gladly welcome your feedback and suggestions for improvement. We realize that this consent dialog is not yet localized (it is only in English at the moment) and there may be layout improvements that we can refine as we learn from you.

4 31 3,756
31 REPLIES 31

How does this apply to a suite of applications ran through a launcher? Will the user have to accept this for each โ€œmicroโ€ app?

Yes, the user will have to consent to each individually. This is because each app may have different purposes and different terms of use and different privacy policies.

I know this is at odds with our principles of trying to modularize into many apps. However, it is only once per user per app.

We are trying to accomodate a world where privacy is becoming supremely important. If we introduce a notion of suites of apps with shared terms of use and privacy policies, we can simplify some of this.

Hi @praveen! I just copied a sample app and didnโ€™t notice a difference. I assume that what you wrote about consent will not apply to prototype and sample apps that are made publicly available, because once they are copied, information is no longer being shared with the person who made them. Is that right?

To answer my own question, I found that I have to acknowledge the same โ€œsharing of data with the creatorโ€ even when a prototype app has been copied and hence the actual โ€œcreatorโ€ of the app will, in fact, receive nothing. Unlike the example shown above, where praveen@appsheet.com is shown in parentheses as the creator, the message I received didnโ€™t show the address (which would have been my address, as I made it) but just referred to the โ€œapp creator.โ€ This is a confusing statement. Can this be corrected?

I do keep holding out hope for a scenario in which a suite of apps operate in a more connected fashion.

@Praveen, often the account which โ€˜ownsโ€™ the app is a placeholder / not the intended contact person. Some reasons for this are:

  • The app owner account is the account through which reports / workflows are fired. Often you need to give special permissions within security filters to this account for the reports/workflows to fire properly. As a result of this, the app may function differently / improperly when using it as the app owner account, such that you would not want this account to be a true user.
  • Some team collaboration workflows may have a shared parent account / host production apps in a single source.

My current app consent message is as follows:

2X_0_0f1cc6ff276ee7649c912cb9384ced521822b24a.png

Would it be possible to customize the contact email / add this as a field in the app properties?

@praveen

Another question. Currently, when users are logging in, they must click through a โ€˜sign in withโ€™ page to select the authentication provider, even if the app creator has specified a single-source authentication provider:

2X_7_74fa1596e528ab40976dc8d697dc8a3551074c86.png

As @Grant_Stead pointed out in a separate thread, it would make for a cleaner user experience if this page did not exist when only one option was available.

You mentioned in the same thread that the secondary objective of this โ€˜sign in withโ€™ page was to give users a chance to view the ToS and privacy policies prior to accessing the app. Does this new addition to the apps suggest we can get rid of the โ€˜sign in withโ€™ page when only one option is available?

@Jonathon, I agree, this page should be bypassed when you only allow a single authentication provider.

@praveen, if this updated, would it be possible to also select only 2-3 providers, instead of 1 or ALL?

Also, there are times when all app users use one login (Office365) but the app owner/dev uses Gmail. It would be great if we could allow both, but only show users the Office365 option to avoid confusion when employees try their personal Gmail rather than their work/Office365 account.

Perhaps the user White List could be integrated, with an option to โ€œonly show login providers in White Listโ€. Then the providers that are displayed would dynamically update as you add/remove email addresses from the White List.

@praveen I am one of those app makers who uses Google, but all the rest of my users use Microsoft. However, they all have dropbox and Microsoft accounts, with the same email address user name for each account, so when I share my app with an email, and when they accidentally switch back between accounts, AppSheet double charges me for two users, when I only shared it with one.

Suggestion: @GreenFluxโ€™s idea of selecting a number of providers that doesnโ€™t have to be all or one. This would fix my dropbox/Microsoft issue

Thanks Praveen. Unfortunately, Google users receive the Google notice and then AppSheet will display one as well. If the text is customizable and we can insert links to the appropriate policy, this can certainly be helpful. Where is record of the consent maintained if thereโ€™s an issue?

Bahbus
Participant V

This sounds like good groundwork. @Grant_Steadโ€™s wish sounds feasible in a future update. Perhaps the AppSheet team can find a way to scan the app to detect any and all links to other AppSheet apps (similarly to what its already doing to determine which permissions are needed), and pull the permissions they also need to the forefront of the โ€œbaseโ€ app, so to speak, and apply that consent to the โ€œchildโ€ apps.

Chris_Jeal
Participant V

Hi @praveen

It seems that when using the snapshot() function, the link when clicked; shows this consent page instead of the image initially set up within the workflow.

Is there a fix for this?

Chris

I really appreciate the way yโ€™all have been posting your ideas and plans, before executing them, and getting input from your usersโ€ฆ Itโ€™s a really strong move.

@praveen The consent dialogue keeps popping up, over and over. It seems like of I have the app open, black screen my phone, then unlock my phoneโ€ฆ I make a move, then it pops up again. Anyone else?

Former Community Member
Not applicable

Have you tried uninstalling and reinstalling the app?

No, I havenโ€™t.
I take it this is a serious enough change that we need to do thatโ€ฆ

@Gil How does this effect white label apps in the play/Apple store?

Hi @Grant_Stead, White labeled apps will see the same consent dialogue as other apps.

I meant, do I need to update then in the stores to a new version are actively โ€œdoโ€ anything?

No, you donโ€™t have to upload a new version to the store, or do anything else.

FYI, sometime in the next week, weโ€™ll be introducing the ability to localize or modify the content of the consent dialog. This will be via the UX -> Localization tab as always.

Hi @praveen until now there is no such ability. Neither in my free account nor in my PRO account.

It took a while to get this done, but finally you can also disable or enable the user consent dialog entirely (look for the option in the Security โ†’ Options pane), but it is on by default. And you can localize its contents via the UX โ†’ Localization pane.

Thank you very much @praveen
Iโ€™m using an extra table for localize. In my App I would like to use LOOKUP() expressions.


But I see that the expression is not respected. Only the hard coded โ€œNutzungsbedingungenโ€.
3X_4_2_427091091b1830827152488e593df912f1cb7ba7.png
Is this because the App would not load any table, until the user hits โ€œAcceptโ€?

Yes, it becomes a slippery slope if the app starts loading data and running expressions before consent is received from the user. What if the expression utilizes some information about the user (almost certainly, it would use USERLOCALE()). Maybe it uses USEREMAIL(). Now information about the user has been handed over to the app creator without any user consent.

gamila
Participant I

Newbie here. how do I apply rich text to the "privacy policy" and "terms of use" fields?

Not possible, afaik.

Rich text is just supported as a preview feature on LongText fields

Thanks SkrOYC - that's too bad, as it is very hard to read a substantial document this way.

Is there any other method to at least getting a line break?

By Return/Enter?

yea that would be great, but that is not working in my tests.