Protect provider intellectual property

This topic describes how the Snowflake Native App Framework protects provider data by redacting or removing information about objects shared by a Snowflake Native App.

About intellectual property protection in the Snowflake Native App Framework

When a consumer installs a Snowflake Native App, they are not allowed to view the objects within the application object unless a provider grants permissions on the objects using application roles.

In general, when a consumer queries object metadata using a schema, view, or uses Snowsight to view the Query Profile or Query History for those queries, the Snowflake Native App Framework redacts information about the objects within the application object.

Information redacted from Query Profile

The Snowflake Native App Framework redacts information from the query profile in the following contexts:

  • Queries that are run when the app is installed or upgraded.

  • Queries that originate from a stored procedure owned by the app.

  • Queries containing a non-secure view or function owned by the app.

For each of these types of queries, Snowsight collapses the query profile data into a single empty node instead of displaying the full query profile tree.

Information redacted from Query History

For queries related to a Snowflake Native App, the query_text and error_message fields are redacted from the query history in the following contexts:

  • Queries run when the app is installed or upgraded.

  • Queries that originate from a child job of a stored procedure owned by the app.

In each of these situations, the cell of the query history in Snowsight appears blank.

Information redacted from SQL commands and views

When a consumer uses the a SHOW or DESCRIBE command to view information about the application object or the objects owned by the app, information about implementation details is redacted. For example, function definitions and the function body are redacted from the output of these commands.

Information about implementation details is redacted from the ACCESS_HISTORY view in the following contexts:

  • Queries generated when the app is installed or upgraded.

  • Queries generated by stored procedures and user-defined functions owned by the app.

Additionally, for views owned by the app, information about the base table is redacted.

Considerations when granting the MONITOR or OPERATE privilege on dynamic tables

Providers should use caution when granting the MONITOR or OPERATE privilege on dynamic tables to an application role. These privileges allow the consumer to view a dynamic table’s metadata, which might expose the implementation details of the app. See Privileges to view a dynamic table’s metadata for more information on what actions the consumer can perform.

Blocked context functions

To protect information related to objects within an application object, the Snowflake Native App Framework blocks the following context functions:

Context Function

Blocked in shared content (returns null)

Blocked in setup scripts and stored procedure and UDFs owned by the Snowflake Native App (throws an exception)

CURRENT_ROLE

CURRENT_ROLE_TYPE

CURRENT_USER

CURRENT_SESSION

IS_ROLE_IN_SESSION

CURRENT_IP_ADDRESS

CURRENT_AVAILABLE_ROLES

CURRENT_SECONDARY_ROLES

ALL_USER_NAMES

GET_USERS_FOR_COLLABORATION

CURRENT_WAREHOUSE

SYSTEM$ALLOWLIST

Protect shared content

To protect the privacy and integrity of a provider’s data content, the Snowflake Native App Framework implements the following restriction:

  • Shared objects are read-only for an application object and installed Snowflake Native App.

  • Shared objects are not directly exposed to consumers. Objects are only exposed through a view that is installed when the setup script runs during the Snowflake Native App installation or upgrade.

  • Only the provider can update the shared content.

  • Only the following objects can be shared with an application object or installed Snowflake Native App. These object must have certain privileges:

    • Schemas: Only the USAGE privilege can be granted to the shared content of an application package.

    • Tables: Only the SELECT privilege can be granted to the shared content of an application package. Tables with defined policies (row access, masking, tag based, etc.) cannot be shared. Policies can be defined on the objects when they are exposed to consumers.

    • Views: Only the SELECT privilege can be granted to the shared content of an application package. Views with defined policies, including row access, masking, tag based, etc., cannot be shared.

Note

A view, or any views from which a view is composed, cannot contain JavaScript, Java, Python, or Scala functions.

Refer to Allow consumers to access shared objects in an app for more information.