User Data: EU-U.S., Swiss Privacy Shield
If you access, use or process personal information made available by Google that directly or indirectly identifies an individual and that originated in the European Union or Switzerland (“EU Personal Information”), then you must:
-
Comply with all applicable privacy, data security, and data protection laws, directives, regulations, and rules;
-
Access, use or process EU Personal Information only for purposes that are consistent with the consent obtained from the individual to whom the EU Personal Information relates;
-
Implement appropriate organizational and technical measures to protect EU Personal Information against loss, misuse, and unauthorized or unlawful access, disclosure, alteration and destruction; and
-
Provide the same level of protection as is required by the Privacy Shield Principles.
You must monitor your compliance with these conditions regularly. If at any time, you cannot meet these conditions (or if there is a significant risk that you will not be able to meet them), you must immediately notify us by email to info@vikki.tech and immediately either stop processing EU Personal Information or take reasonable and appropriate steps to restore an adequate level of protection.
As of July 16, 2020, Google no longer relies on the EU-U.S. Privacy Shield to transfer personal data that originated in the European Economic Area or the UK to the United States. (Learn More.) More information is outlined in Section 9 of the DDA.
User Data: Personal and Sensitive Information
Personal and sensitive user data includes, but isn't limited to, personally identifiable information, financial and payment information, authentication information, phonebook, contacts, device location, SMS and call related data, inventory of other apps on the device, microphone, camera, and other sensitive device or usage data. If your app handles sensitive user data, then you must:
-
Limit your access, collection, use, and sharing of personal or sensitive data acquired through the app to purposes directly related to providing and improving the features of the app (e.g., user anticipated functionality that is documented and promoted in the app's description in the Play Store). Apps that extend usage of this data for serving advertising must be in compliance with our Ads Policy.
-
Post a privacy policy in both the designated field in the Play Console and within the app itself. The privacy policy must, together with any in-app disclosures, comprehensively disclose how your app accesses, collects, uses, and shares user data. Your privacy policy must disclose the types of personal and sensitive data your app accesses, collects, uses, and shares; and any parties with which any personal or sensitive user data is shared.
-
Handle all personal or sensitive user data securely, including transmitting it using modern cryptography (for example, over HTTPS).
-
Use a runtime permissions request whenever available, prior to accessing data gated by Android permissions.
-
Not sell personal or sensitive user data.
Permissions: Restricted Permissions
Permission requests should make sense to users. You may only request permissions that are necessary to implement current features or services in your app that are promoted in your Play Store listing. You may not use permissions that give access to user or device data for undisclosed, unimplemented, or disallowed features or purposes. Personal or sensitive data accessed through permissions may never be sold.
Request permissions to access data in context (via incremental requests), so that users understand why your app is requesting the permission. Use the data only for purposes that the user has consented to. If you later wish to use he data for other purposes, you must ask users and make sure they affirmatively agree to the additional uses.
In addition to the above, restricted permissions are permissions that are designated as Dangerous, Special, Signature, or as documented below. These permissions are subject to the following additional requirements and restrictions:
-
Sensitive user or device data accessed through Restricted Permissions may only be transferred to third parties if necessary to provide or improve current features or services in the app from which the data was collected. You may also transfer data as necessary to comply with applicable law or as part of a merger, acquisition, or sale of assets with legally adequate notice to users. All other transfers or sales of the user data are prohibited.
-
Respect users’ decisions if they decline a request for a Restricted Permission, and users may not be manipulated or forced into consenting to any non-critical permission. You must make a reasonable effort to accommodate users who do not grant access to sensitive permissions (e.g., allowing a user to manually enter a phone number if they’ve restricted access to Call Logs).
-
Use of permissions in contravention of official Android developer App permissions best practices or in violation of existing policies (including Elevated Privilege Abuse) are expressly prohibited.
Certain Restricted Permissions may be subject to additional requirements as detailed below. The objective of these restrictions is to safeguard user privacy. We may make limited exceptions to the requirements below in very rare cases where apps provide a highly compelling or critical feature and where there is no alternative method available to provide the feature. We evaluate proposed exceptions against the potential privacy or security impacts on users.
​
Permissions: Location Permissions
Device location is regarded as personal and sensitive user data subject to the Personal and Sensitive Information policy, and the following requirements:
-
Apps may not access data protected by location permissions (e.g., ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_BACKGROUND_LOCATION) after it is no longer necessary to deliver current features or services in your app.
-
You should never request location permissions from users for the sole purpose of advertising or analytics. Apps that extend permitted usage of this data for serving advertising must be in compliance with our Ads Policy.
-
Apps should request the minimum scope necessary (i.e., coarse instead of fine, and foreground instead of background) to provide the current feature or service requiring location and users should reasonably expect that the feature or service needs the level of location requested. For example, we may reject apps that request or access background location without compelling justification.
-
Background location may only be used to provide features beneficial to the user and relevant to the core functionality of the app.
Apps are allowed to access location using foreground service (when the app only has foreground access e.g.: "while in use") permission if the use:
-
has been initiated as a continuation of an in-app user-initiated action, and
-
is terminated immediately after the intended use case of the user-initiated action is completed by the application.
Apps designed specifically for children must comply with the Designed for Families policy.
Device and Network Abuse
We don’t allow apps that interfere with, disrupt, damage, or access in an unauthorized manner the user’s device, other devices or computers, servers, networks, application programming interfaces (APIs), or services, including but not limited to other apps on the device, any Google service, or an authorized carrier’s network.
Apps on Google Play must comply with the default Android system optimization requirements documented in the Core App Quality guidelines for Google Play.
An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).
We don’t allow code that introduces or exploits security vulnerabilities. Check out the App Security Improvement Program to find out about the most recent security issues flagged to developers.
Deceptive Behavior
We don't allow apps that attempt to deceive users or enable dishonest behavior including but not limited to apps which are determined to be functionally impossible. Apps must provide an accurate disclosure, description and images/video of their functionality in all parts of the metadata. Apps must not attempt to mimic functionality or warnings from the operating system or other apps. Any changes to device settings must be made with the user's knowledge and consent and be reversible by the user.
Misrepresentation
We do not allow apps or developer accounts that:
-
impersonate any person or organization, or that misrepresent or conceal their ownership or primary purpose.
-
that engage in coordinated activity to mislead users. This includes, but isn’t limited to, apps or developer accounts that misrepresent or conceal their country of origin and that direct content at users in another country.
-
coordinate with other apps, sites, developers, or other accounts to conceal or misrepresent developer or app identity or other material details, where app content relates to politics, social issues or matters of public concern.
©2022 by Vikki.tech
