Attention: Do NOT follow this link!

Program Rules

Since our inception, our security team launched a Vulnerability Reward Program. We have long enjoyed close cooperation with the security research community - and encouraged by the success of Google and other site Vulnerability Reward Programs, we decided to take this step to invite cutting-edge external research that would help us keep our users safe.

Services in scope

Any BaD web service that handles reasonably sensitive user data is intended to be in scope. This includes virtually all the content in the following domains:

  • www.bidadollar.com / bidadollar.com and all root domains and subdomains

We make an important exception for acquired companies: for the first 6 months after the acquisition, the vulnerabilities in acquired platforms will usually not qualify for a reward. We will revisit this exclusion if a decision is made to align our operations and security programs more closely.

Qualifying vulnerabilities

It is difficult to provide a definitive list of bugs that will qualify for a reward: any bug that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:

The following reports are definitely excluded:

  • Attacks against BaD corporate infrastructure
  • Social engineering and attacks on physical facilities
  • Brute-force denial of service bugs
  • SEO techniques
  • Vulnerabilities in non-web applications
  • Vulnerabilities in BaD-branded services operated by third parties.

Out of concern for the availability of our services to all users, we ask you to refrain from using any tools that are likely to automatically generate significant volumes of traffic.

Reward amounts

Currently we are only able to offer our profound thanks and a spot on our Hall of Fame for any findings submitted.

Once we reach 1000 customers, rewards for qualifying bugs will be $20 - $1,000 in BaD bids.

We will be making cash bounties available when we reach a larger user base and are actually making money!

In each case, the ultimate decision is made by the reward panel and is at our discretion. In particular, we may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide that a single report actually constitutes multiple bugs; or that multiple reports are so closely related that they only warrant a single reward.

We understand that some of you are not interested in money. We also offer the option to donate your reward to charity. If you do, we will match it - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.

Regardless of whether you're rewarded monetarily or not, all vulnerability reporters who interact with us in a productive manner will be credited on the Hall of Fame. If we file a security bug internally, we will acknowledge your contribution on that page.

Investigating and reporting bugs

When investigating a vulnerability, please, only ever target your own accounts. Never attempt to access anyone else's data and do not engage in any activity that would be disruptive or damaging to your fellow users or to BaD.

If you have found a vulnerability, please contact us at security@BaD.com. Please be succinct: the mailbox is attended by security engineers and a short proof-of-concept link is more valuable than a video explaining the consequences of an XSS bug.

Note that we are only able to answer to technical vulnerability reports. Non-security bugs and queries about problems with your account should be instead directed to Support.

Frequently asked questions

Q: Who determines whether my report is eligible for a reward?

A: The reward panel consists of the members of the BaD Security Team.

Q: What happens if I disclose the bug publicly before you had a chance to fix it?

A: Please read Google's stance on coordinated disclosure which we feel is a positive and benificial process. In essence, our pledge to you is to respond promptly and fix bugs in a sensible timeframe - and in exchange, we ask for a reasonable advance notice. Reports that go against this principle will usually not qualify, but we will evaluate them on a case-by-case basis.

Q: I wish to report an issue through a vulnerability broker. Will my report still qualify for a reward?

A: We believe that it is against the spirit of the program to privately disclose the flaw to third parties for purposes other than actually fixing the bug. Consequently, such reports will typically not qualify.

Q: What if somebody else also found the same bug?

A: First in, best dressed. You will qualify for a reward only if you were the first person to alert us to a previously unknown flaw.

Q: My employer / boyfriend / dog frowns upon my security research. Can I report a problem privately?

A: Sure. If you are selected as a recipient of a reward, and if you accept, we will need your contact details to process the payment. You can still request not to be listed on our public credits page.

Q: Are there any commonly reported vulnerabilities that are not clear-cut that the panel has historically erred on the side of not issuing rewards?

A: Yes. In the spirit of transparency and to help focus external efforts, here is an overview of reports we most commonly reject:

  • Vulnerabilities in BaD-branded services maintained by third parties: There is a small number of (typically minor) BaD-branded sites operated by external companies. For obvious reasons, we cannot authorize you to test such servers on behalf of these companies - and therefore, we regrettably can’t consider any eventual reports as in scope for our reward program.

    Before getting started with any security testing, we ask you to confirm that the service is actually operated by BaD: examining WHOIS and DNS records, and reading the fine print on the target page itself, should offer sufficient insight.

  • URL redirection: Some members of the security community argue that open redirectors are a security issue. The common argument in favor of this view is that some users, when presented with a carefully crafted link, may be duped into thinking that they will be taken to a trusted page - but will be not be attentive enough to examine the contents of the address bar after the redirection takes place.

    On the other hand, we recognize that the address bar is the only reliable security indicator in modern browsers; and consequently, we think that any user who could be misled by a URL redirector can also be tricked in other ways, without relying on any particular trusted website to act as a relying party.

    The reward panel will likely deem URL redirection reports as non-qualifying: while we prefer to keep their numbers in check, we hold that the usability and security benefits of a small number of well-implemented and carefully monitored URL redirectors tend to outweigh the true risks.

  • Legitimate content proxying and framing: The panel applies similar reasoning to most cases of content proxying and framing.

    In general, we expect our services to label third-party content unambiguously and to perform a number of malware and abuse detection checks. However, we recognize that well-implemented content proxying brings innovative and unique functionality to many of our user-oriented services, and similarly to URL redirection, we believe that usability benefits substantially outweigh the risks.

    When it comes to framed third-party content, we recognize that framebusting is an interesting – and still unsolved – vector for petty mischief. That said, as with many other architectural improvements attempted today, it will be a while before this problem is fully eradicated.

  • Logout cross-site request forgery: At this time, the ability of malicious web sites to log users out of unrelated web applications is essentially unavoidable; it is a consequence of how the web is designed and cannot be reliably prevented by any single website. You might be interested in the following personal blog posts published a while ago on this topic by two Google employees:

    Consequently, in most cases, the panel will not consider reports of the ability to log out users from BaD as qualifying for the reward. Difficult, long-term browser-level improvements are required to truly eliminate this possibility.

  • Flaws present only when using out-of-date browsers and plugins: The security model of the web is being constantly fine-tuned and improved by the vendors and by the security community. The panel will typically not reward reports of vulnerabilities that affect only the users of outdated or unpatched browsers. In particular we have decided to exclude all Internet Explorer versions prior to version 8.

Legal points

We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.

This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time and the decision as to whether or not to pay a reward has to be entirely at our discretion.

Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.