Low Severity Issues

The following types of bugs are considered low severity because they have a limited impact on user security. We appreciate if they are reported so they can be fixed, but they are not eligible for rewards.

  • App crashes -- If a bug does nothing but make an app crash, and doesn't prevent the app from restarting, it is not eligible, as it does not have a meaningful impact on users' security. 
  • Phishing and social engineering attacks -- Like on many platforms, it is possible to write apps that look similar to other apps on Android. Unless an attack involving social engineering uses unintended functionality and is very compelling, it will likely not qualify.
  • Logging sensitive data -- We aim to keep Android logs free of personally identifiable information, but since debugging privileges are required to access logs, an app logging sensitive data is not considered a severe enough vulnerability to qualify.
  • Apps requesting excessive permissions -- We sometimes receive reports that applications request permissions that they do not use, or use for minor functionality. While we sometimes remove permissions as a result of these reports, excessive permissions alone do not have enough of a security impact to qualify for rewards. 
  • An app stores not-very-sensitive data as world-readable -- It is a vulnerability if an app stores sensitive data in a world-readable file, but make sure the data is actually sensitive before you report. In addition, if the amount of information disclosed is tiny (for example, the length in seconds of the last media track played), it's probably not eligible for rewards. 
  • Side-channel attacks -- We receive many reports of side-channel attacks that allow data to be inferred from unrelated functionality. Two significant factors affect the eligibility and severity of a reported side-channel information leak: the type of information being leaked and the reliability of the side-channel.
    See the Android Severity Guidelines for an indication of how different types of data leaks are assessed.  Generally, the information being leaked must cross a security boundary.  For example, if an Android Permission is required to obtain the data under under normal circumstances, then the leak is likely a security issue.  However, in some cases, Permissions are used to prevent apps from calling certain System APIs, but the APIs themselves don't provide any security-critical information.  In those cases, side-channels that leak that information would not be considered security issues.

    Also, for a side-channel attack to eligible, it needs to be reliable under real-world circumstances, not just in an isolated test environment.  For example, many machine learning models perform well when supplied individual events, but they're unable to produce meaningful results when faced with the continuous stream of data you'd find on a device being used by a real person.
    • Hardware attacks -- If an issue requires attacking the hardware of a device, for example removing a chip from the PCB or connecting to the device via JTAG, it is usually out of scope of VRP.
    • Developer mode bugs -- Some bugs require the device to have developer options enabled. These are not accessible on most devices without having physical access to the unlocked device, so are considered low severity.