Aily is committed to ensuring the safety and security of our customers and employees. We aim to foster an environment of trust, and an open partnership with the security community, and we recognize the importance of vulnerability disclosures in continuing to ensure safety and security for all of our customers, employees and company. We have developed this policy to both reflect our corporate values and to uphold our legal responsibility to good-faith security researchers that are providing us with their expertise and whistleblowers who add an extra layer of security to our infrastructure.

Aily will not engage in legal action against individuals who submit vulnerability reports through our Vulnerability Reporting inbox. We openly accept reports for the currently listed Aily products. We agree not to pursue legal action against individuals who:
• Engage in testing of systems/research without harming Aily or its customers.
• Engage in vulnerability testing within the scope of our vulnerability disclosure program.
• Test on products without affecting customers, or receive permission/consent from customers before engaging in vulnerability testing against their devices/software, etc.
• Adhere to the laws of their location and the location of Aily. For example, violating laws that would only result in a claim by Aily (and not a criminal claim) may be acceptable as Aily is authorizing the activity (reverse engineering or circumventing protective measures) to improve its system.
• Refrain from disclosing vulnerability details to the public before a mutually agreed-upon timeframe expires.

How to Submit a Vulnerability
To submit a vulnerability report to Aily’s Security Team, please utilize the following email security@ailylabs.com
When reporting vulnerabilities, please consider
• attack scenario / exploitability
• security impact of the bug

PGP key details
We encourage security researchers to use encrypted communication channels to protect the confidentiality of vulnerability reports using our PGP public key

-----BEGIN PGP PUBLIC KEY BLOCK-----
mDMEZjj/jBYJKwYBBAHaRw8BAQdAhnoOnc8MpHkQ88h4E+GHFVNNnsjRzvyjtgiQ53VvWVy0IEFpbHlMYWJzIDxzZWN1cml0eUBhaWx5bGFicy5jb20+iJMEExYKADsWIQQmM2xaLfW9r3M8fW4Z9fxFQ/5x3wUCZjj/jAIbAwULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRAZ9fxFQ/5x309eAP9gbIdvLCes45/CpCV28cRkXuWwKbEOadRbd3pk1CE6+gD/ZKFDxkVeDNBTOJBGO3nlMvQwYOjxasCasXdKbhglLAy4OARmOP+MEgorBgEEAZdVAQUBAQdAEiDSR5S9QlTr6ocnzgcI028RJVUkojf2MICwZOY7PRQDAQgHiHgEGBYKACAWIQQmM2xaLfW9r3M8fW4Z9fxFQ/5x3wUCZjj/jAIbDAAKCRAZ9fxFQ/5x31BgAQC+XC0Kaqbf4Swy8EP+A+ufGe9QjJFau2ycy20K7ckr3QEAjF2ML71FY1EKxefM3Z+XHqfXfOSXBTrhkQBT4PUECQw==oQF0
-----END PGP PUBLIC KEY BLOCK-----

Preference, Prioritization, and Acceptance Criteria
We will use the criteria from the next sections to prioritize and triage submissions

What we would like to see from you:
• Well-written reports in English will have a higher probability of resolution.
• Reports that include proof-of-concept code equip us to better triage.
• Reports that include only crash dumps or other automated tool output may receive lower priority.
• Reports that include products not on the initial scope list may receive lower priority.
• Please include how you found the bug, the impact, and any potential remediation.
• Please include any plans or intentions for public disclosure.

What you can expect from Aily:
• A timely response to your email (within 2 business days).
• After triage, we will send an expected timeline, and commit to being as transparent as possible about the remediation timeline as well as on issues or challenges that may extend it.
• An open dialog to discuss issues.
• Notification when the vulnerability analysis has completed each stage of our review.

Out of scope
Below are some examples of issues that are out of scope:
• Any activity that could lead to the disruption of our service (DoS)
• Attacks requiring MITM or physical access to a user’s device
• Best practice reports without a valid exploit (e.g., use of “weak” TLS ciphers)
• Clickjacking on pages with no sensitive actions
• Comma Separated Values (CSV) injection without demonstrating a vulnerability
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
• Disclosure of server or software version numbers
• Hypothetical subdomain takeovers without supporting evidence
• Issues that require unlikely user interaction
• Missing best practices in Content Security Policy
• Missing best practices in SSL/TLS configuration
• Missing email best practices (Invalid, incomplete, etc.)
• Missing SPF/DKIM/DMARC records, etc.
• Missing HttpOnly or Secure flags on non session cookies
• Open redirect – unless an additional security impact can be demonstrated
• Previously known vulnerable libraries without a working Proof of Concept
• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.
• Rate limiting or bruteforce issues on non-authentication endpoints
• Reports of spam
• Self-XSS
• Social engineering
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
• Tabnabbing
• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]