Very unhelpful to get daily emails at security@grapheneos.org from people seeking bug bounties reporting we have a directory listing at apps.grapheneos.org, lack a captcha for attestation.app + discuss.grapheneos.org registration and have fairly high rate limits.
Conversation
Replying to
How about publishing a #securitytxt file as per #RFC9116 to point to a Policy that informs researchers of the scope of your program? E.g. datatracker.ietf.org/doc/html/rfc91
As an example LinkedIn has their policy specify what qualifies vs does NOT qualify, see
1
1
Replying to
Reporting a directory listing for a package repository as a vulnerability is clearly not valid. Reporting lack of a captcha for a registration / login form is also clearly not valid. Captchas make websites less accessible and are a privacy/security issue when it's third party.
2
1
5
Replying to
It is fair and helpful that you set your own criteria! I wanted to suggest that publishing a policy listing the things you do want to receive could help limit the noise so that you could keep your security e-mail open. Also, you can auto-close irrelevant by pointing to the policy
1
Replying to
It's not our own criteria. It's basic critical thinking.
We do have a security.txt and it's the opposite of helpful because it's likely what's attracting these people to the site since they associate it with being able to get paid bug bounties for low effort reports.
Likely removing the security@ emails and security.txt we've published. They're completely unhelpful and only take away security resources from handling actual security improvements and bug reports including valid AOSP security bug reports we receive on a somewhat regular basis.
1
1
The security.txt standard is the problem, not the solution. By including it we ended up on lists of sites including a security.txt which is attracting grifters who would not be sending this kind of spam to our actual issue tracker. I wish we could undo ever publishing those.
1
Show replies