The most basic security feature is user sign-in.

If your app has any confidential data whatsoever, you should require user sign-in. 

If your app needs to distinguish between users in a secure/reliable way, you should require user sign-in. 

There are five levels of security afforded to apps that require user to sign-in:

  1. Requiring sign-in with a specific provider --- only users with an account hosted by a specific provider (eg: Google or Dropbox or Office365) can access the app.
  2. Specifying a user whitelist --- only specific users explicitly listed in a whitelist can access the app. You can learn more about granting application access and revoking it. One approach to this is using domain groups, which you can learn about here
  3. Utilizing security filters --- the app can be configured to show different subsets of data to different users.
  4. Using expression logic within the app based on the USEREMAIL() and USERNAME() functions to customize the app on a per-user basis.
  5. Auditing --- the app can explicitly capture the identity of each user who makes a change to the app. Additionally, the audit history automatically captures the identity of every user who interacts with the app.

None of these security mechanisms are available to apps that disable the user sign-in feature.

How does this affect the choice of subscription plan?

As their names suggests, the main feature difference between the public (aka Publisher) plans and the secure plans is security. 

User sign-in is available with a secure plan and not with a public plan. When you deploy your apps with user sign-in, you should be on a secure plan (Standard, Premium, or Pro). 

If you do not require sign-in, the data and the usage scenarios should be meant for the general public, and you can use a public plan (Publisher, Publisher-Plus or Publisher-Pro). 

How public is an app on a public plan?

If you deploy an app on a public plan, you should assume that all the data in the app is visible to anybody. Further, you should assume that anybody who wants can run the app. If the app permits data changes, then anybody can make those changes.

Customers who deploy public _want_ this broad reach and accessibility. AppSheet will in fact help them by enabling search engine crawlers to access their data. Consequently, if an app is marked as not needing user signin, AppSheet requires app creators to explicitly confirm that they understand the implications and accept the security consequences on behalf of their organization. 

Can I secure an app without making users sign-in?

This question comes up occasionally from app creators who want to use one of the public Publisher plans. The answer is No.
 Some app creators try to create their own workarounds for each of these levels of security. However, these approaches are inherently flawed:

  1. Instead of a whitelist, can I control distribution of the app install link?

While this is possible initially when the app creator sends the install link to other users, there is no way to control who those users send the link to. Anybody with the link has access to the app.

We have had multiple instances where an employee of a company has access to the app and then that person leaves the company. At this point, the company requests us to disable access and there is no way to do this.

If the link is ever placed on a publicly accessible site, it may be crawled by a search engine. And the content of the app (the data shown in the app) could also be indexed by the search engine. This is because the intent for Publisher apps is to have broad public access to the app.

    2. Can slices be used instead of a security filter?

Slices are a mechanism used to define "virtual tables". Even if somehow the user was identified and used in the filter condition of a Slice, this doesn't guarantee that the entire data set isn't accessible as well.

When the app is opened in a browser, all the data used by the app is accessible to anyone who spends a couple of minutes to open the developer console and examine the data of the running application. There is no guarantee that the entire table isn't available even if a slice is defined on that table. The only way to ensure this is to use a security filter for the table.

    3. Can I create my own username/password mechanism?

Not really. If you want to roll your own security, you need to worry about authentication (is the person who they claim they are), and a secure implementation (encrypted capture, transmission, and storage of passwords, as well as mechanisms to handle forgotten passwords, revocation, etc). This is a huge and complex undertaking. In fact, this is why AppSheet does not provide its own username and password mechanism. Instead, we utilize third party authentication via highly credible providers like Google, Dropbox and Office365.  

To reiterate, if your app does not require user sign-in, you must be confident that the data in the app is meant for public consumption. If the app permits users to update the data, you must be willing to have anonymous user updates to the data. In all other cases, please require your users to sign in. 

    4. Can I verbally tell people to sign-in and use expressions with USEREMAIL() to control app behavior? 

No. USEREMAIL() and USERNAME() do not have a defined value if the app does not enforce user signin. The LogIn option in the app menu will also only be visible for apps that require sign-in. Apps should either assume all users are signed in, or assume that no users are signed in.

Alternatives to requiring sign-in

For reasons of cost, some app creators may want to stay with a public plan. We want to emphasize that these apps are inherently insecure. However, if the main goal is to acquire the user's email address rather than data/app security, here are some aspects of the functionality that can still be achieved:

  1. In forms, instead of using USEREMAIL() to automatically fill in a column value, the user can explicitly type in their email address. This will not be verified, but an email can still be captured and used.
  2. The app can utilize the UserSettings feature to ask the user to provide their email address. The benefit of this approach is that the email address is typed in once and then can be used in formulas (eg: UserSettings("MyEmail") ). This email is not authenticated (any user could claim to be bill.gates@microsoft.com), so this is not a security mechanism.
  3. If you have a fixed list of users in a Lookup table, you could assign each user an id and ask them to provide their id via the UserSettings feature. This id can be used with the Lookup table. Please note that this is not a password. It is not encrypted and all users will have access to the Lookup table, so this approach is in some ways even less secure than the other options.

Did this answer your question?