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, for example "I can tell when application X is in use based on battery usage". Many of these attacks reveal information that is not particularly sensitive or are unreliable. For a side-channel attack to be eligible, it needs to be both reliable and reveal substantial user data, like the contents of an email. In addition, the attack needs to have a reasonable mitigation. 
  • 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 and are not eligible for VRP