Malware and unwanted software

Google checks websites to see whether they host software or downloadable executables that negatively affect the user experience. Malware and unwanted software are either downloadable binaries or applications that run on a website and affect site visitors. You can see a list of any suspected files hosted on your site in the Security Issues report.

What is malware?

Malware is any software or mobile application specifically designed to harm a computer, a mobile device, the software it's running, or its users. Malware exhibits malicious behavior that can include installing software without user consent and installing harmful software such as viruses. Website owners sometimes don't realize that their downloadable files are considered malware, so these binaries might be hosted inadvertently.

What is unwanted software?

Unwanted software is an executable file or mobile application that engages in behavior that is deceptive, unexpected, or that negatively affects the user's browsing or computing experience. Examples include software that switches your homepage or other browser settings to ones you don't want, or apps that leak private and personal information without proper disclosure.

For more on how Google helps protect users from unwanted software, see That's not the download you're looking for... in our Google Online Security Blog.

Guidelines

Be sure that you don't violate the Unwanted Software Policy, and follow the guidelines given here. Though this list isn't comprehensive, these behaviors can cause apps and websites to display warnings to users upon downloading and visiting. You can see a list of any suspected files hosted on your site in the Security Issues report.

Don't misrepresent yourself

  • Accurately inform users of a software's purpose and intent. Users must be able to download the software intentionally, with accurate knowledge of what will be downloaded, by clicking on an accurate advertisement that clearly informs the user of what will be downloaded. Advertisements leading the user to the download must not be deceptive or inaccurate, such as:
    • An ad that only contains the words "Download" or "Play" without identifying the software it advertises for.
    • A "Play" button that leads to a download.
    • An ad that mimics the look and feel of the publisher's website and pretends to offer content (for example, a movie) but instead leads to unrelated software.
    • Read about Social Engineering in our Online Security Blog.
  • Behave as advertised. Make sure your program is clear about its functionality and intentions. If your program collects user data or injects ads into a user's browser, package these behaviors in clear language and don't frame them as insignificant features.
  • Explicitly and clearly explain to the user what browser and system changes will be made by your software. Allow users to review and approve all significant installation options and changes. Your program's main UI must clearly disclose the binary's components and their primary functionality. The binary must offer an easy way for the user to skip the installation of bundled components. For example, hiding these options or using barely visible text is not good disclosure.
  • Use endorsements only when authorized. Don't use other companies' logos in an unauthorized way to legitimize or endorse a product. Don't use government logos without authorization.
  • Don't scare the user. Software must not misrepresent the state of the user's machine to the user, for example by claiming the system is in a critical security state or infected with viruses. Software must not claim to provide a service (for example, "speed up your PC") that it does not or cannot provide. For example, "free" computer cleaners and optimizers must not be advertised as such unless advertised services and components require no payment.

Software guidelines

  • Use the Google Settings API if your program changes Chrome settings. Any changes to the user's default search settings, startup page, or new tab page must be made via the Chrome Settings Override API, which requires the use of a Chrome extension, as well as compliant extension installation flow.
  • Allow browser and operating system dialogues to alert the user as intended. Don't suppress alerts to the user from the browser or from the operating system, notably those which inform the user of changes to their browser or OS.
  • We recommend that you sign your code. While an unsigned binary isn't a reason for flagging your binary as unwanted software, we recommend programs have a valid and verified code signature issued by a code-signing authority that presents verifiable publisher information.
  • Don't degrade the security and protection measures provided by TLS/SSL connections. An application may not install a root certificate-authority certificate. It may not intercept SSL/TLS connections unless designed for experts to debug or investigate software. For more details, see the related Google Security Blog post.
  • Protect user data. Software, including mobile apps, must only transmit private user data to servers as it is related to the functionality of the app, and these transmissions must be both disclosed to the user and encrypted.
  • Do no harm. Your binary must respect and not harm the user's browsing experience. Make sure that your downloadable binaries adhere to the following common policies:
    • Don't break the browser's reset functionality. Read about the reset browser settings button in Chrome.
    • Don't bypass or suppress the browser's or operating system's UI control for setting changes. Your program must provide users proper notice and control over settings changes that occur in the browser. Use the Settings API to change Chrome settings (see this Chromium Blog post).
    • Use an extension to change Google Chrome functionality, rather than causing browser behavior change via other programmatic means. For example, your program must not use DLLs (dynamically linked libraries) to inject ads in the browser, must not deploy proxies that intercept traffic, must not use a Layered Service Provider to intercept user actions, or insert new UI into every web page by patching the Chrome binary.
    • Your product and component descriptions must not scare the user and/or make false, misleading, claims. For example, your product must not make false claims about how the system is in a critical security state or infected with viruses. Programs like registry cleaners must not show alarming messages about the state of a user's computer or device, and claim they can optimize the user's PC.
    • Make the uninstallation process findable, simple, and non-threatening. You program must have clearly-labeled instructions for returning the browser and/or system to its previous settings. The uninstaller must remove all components and not deter the user from continuing the uninstall process, for instance by claiming potential negative effects on the user's system or privacy if the software is uninstalled.
  • Keep good company. If your software bundles other software components, you are responsible for making sure that none of these components violate any of the recommendations.

Chrome extension guidelines

  • All extensions need to be disclosed and installed in Chrome to be policy-compliant. Extensions must be hosted in the Chrome Web Store, disabled by default, and compliant with Chrome Web Store policies (including the single-purpose policy). Extensions installed from a program must use the authorized Chrome Extensions installation flow, which will prompt the user to enable them within Chrome. Extensions may not suppress Chrome dialogues alerting the user to settings changes.
    Chrome popup requesting approval to install an extension.
  • Instruct users on how to remove a Chrome Extension. A good user experience is when a user uninstalls a program, everything that was installed along with it gets removed too. The uninstallation flow includes instructions for the user to disable and delete the extension themselves.
  • If your binary installs a browser add-on or changes default browser settings, it must follow the browser-supported installation flow and API. For example, if the binary installs a Chrome extension, it must be hosted in the Chrome Web Store and adhere to the Chrome Developer Program Policies. Your binary will be identified as malware if it installs a Chrome extension in violation of the Chrome Alternative Extension Distribution Options policy.

Mobile application guidelines

  • Inform users of your intent to collect their data. Provide users an opportunity to agree to the collection of their data before you start collecting and sending it from the device, including data about third-party accounts, email, phone number, installed apps, and files on the mobile device. Make sure you securely handle any personal or sensitive user data that you collect, including being transmitted using modern cryptography (for example, over HTTPS). For non-Play apps, you must disclose your data collection to the user in the app. For Google Play apps, disclosure must adhere to Play policy. Don't collect data that goes beyond the published use of your application.

  • Don't impersonate another brand or app. Don't use improper or unauthorized imagery or design similar to another brand or app in a way that is likely to confuse the user.
  • Keep all content within the context of the app. Apps must not interfere with other apps and the usability of the device. Apps must not display ads or additional content to the user outside of the context or function of the app itself without getting informed consent from the user and including clear attribution of the ads' source wherever those ads appear.
  • The app must deliver on promises made to the user. All advertised functionality must be available to the user in the app. Apps may update app content but must not download additional apps without getting informed consent from the user.
  • Keep behavior transparent. Apps must not uninstall or replace other apps or their shortcuts, unless that is the app's stated purpose. Uninstall must be clear and complete. Apps must not mimic prompts from the device OS or other apps.

Apps distributed via Google Play must comply with the Developer Program Policies and Developer Distribution Agreement, which have additional requirements.

Fixing the problem

Ensure that your site or application follows the guidelines, then you can request a review in the Security Issues report.

If your mobile application is showing warnings, you can file an appeal.