If you want to know what a "Vulnerability Disclosure Policy" (VDP) would look like if its main purpose is to claim we have VDP and create an appearance of responsible security posture, but not really to learn about vulnerabilities - read Flock's VDP.
They sincerely welcome your vulnerability disclosures, except in cases where you have to "interact" with the device/service or download its data. Other than that TINY carveout, everything is okay.
Oh, if the vuln about configuration and hardening "preferences" like SSL/TSL - Sorry, not interested.
And also, infrastructure vulnerabilities like DNS config - no no, try harder.
I know what you're thinking..ha ha...but we are good guys. You can still report vulnerabilities in the above categories, but the onus is on you to convince us that we should care about them. It is only fair.
The TLS/SSL and DNS carveouts are pretty normal. There are a million security options for those services and enabling them all would often mean denying access to anyone running a browser/client more than a few weeks old. Documenting them all would be a PITA so most policies simply prohibit them entirely.
Testing against customers is also a common prohibition for obvious reasons.
Hm... not normal in my experience. Not enabling a config is not a vulnerability in itself. If not enabling something means a security guarantee is broken (Eg: videos are accessible) then it is a vulnerability, and typically included in VDP, atleast VDPs that are in good faith.
There are a lot of theoretical vulnerabilities in various encryption algorithms used by TLS/SSL/DNS. There are also older protocols that have known vulnerabilities but yet don't present a realistic threat to most types of services. I've worked for more than one company that had to decide whether disabling an algorithm and blocking 5-10% of your customers was worth the tradeoff. Having these debates with researchers is tedious.
That said, there are numerous options that should be enabled and several protocols that should be disabled. It just isn't worth the spam you get if you allow submissions for these type of issues.
vayup · · focus · HN ↗
They sincerely welcome your vulnerability disclosures, except in cases where you have to "interact" with the device/service or download its data. Other than that TINY carveout, everything is okay.
Oh, if the vuln about configuration and hardening "preferences" like SSL/TSL - Sorry, not interested.
And also, infrastructure vulnerabilities like DNS config - no no, try harder.
I know what you're thinking..ha ha...but we are good guys. You can still report vulnerabilities in the above categories, but the onus is on you to convince us that we should care about them. It is only fair.
<a href="https://www.flocksafety.com/legal/vulnerability-disclosure-policy" rel="nofollow">https://www.flocksafety.com/legal/vulnerability-disclosure-p...
bink · · focus · HN ↗
Testing against customers is also a common prohibition for obvious reasons.
vayup · · focus · HN ↗
bink · · focus · HN ↗
That said, there are numerous options that should be enabled and several protocols that should be disabled. It just isn't worth the spam you get if you allow submissions for these type of issues.
vayup · · focus · HN ↗