Hacker News Reader

Comment by vayup | Hacker News Reader

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.

https://www.flocksafety.com/legal/vulnerability-disclosure-p...

View on HN

This looks like a pretty reasonable policy to me all things considered. And no, I'm no fan of Flock. But they do run security cameras for the cops, they can't just say go ahead, go wild on all our customers' cameras. The lawyers would throw a fit.

The carveouts for stuff like configuration and DNS are entirely reasonable. Have you ever been behind a security@ email before? You get a lot of BS reports of that sort.

It's reasonable to not have a VDP for the reasons you mentioned. But not reasonable to have a useless one just so it appears they have a VDP.

Why can't Flock do a "customer setup" that is otherwise sandboxed from their systems and let the white hats go nuts on that?

Content is not the same as configuration and they could get valuable information if they cared.

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.

Makes sense. Thanks.

> 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.

It's understandable. If you have or manage a website you will receive daily emails (the kind that start with 'Hello sir') about automated scans finding low-hanging fruits like that, pretending a bounty payment.

It'd be interesting to know how much of that they put second to "Americans seem to like using our hardware as targets for firearms, reciprocating saws, spray paint, and garbage bags" in their list of corporate concerns.

Antisec was right.

Reply on news.ycombinator.com