Disclosure policy

[stuartpb]

Having one of these is important, and, I would say, part of the platform's DNA: it states how it wants to treat its participants. A lousy disclosure policy says "we don't want smart, responsible users figuring out our problems" (see: Oracle, whose instant-classic dissent over vulnerability disclosures was tragically removed within a day of posting). Meanwhile, a communications platform like DingRoll has the potential to be even better about handling this manner of bugs, as users can be kept in-the-loop with the progress being made on their reported issues. (And, DingRoll's open-source nature opens the potential to say "While we don't want you to be scared if you accidentally broke something, if you think you see a bug in DingRoll, test it in public staging rather than the main deployment".)

Example disclosure policy (linked, not read): http://help.getpocket.com/customer/portal/articles/1225832-pocket-security-overview

Also: if possible, offer bounties.

[stuartpb]

dingroll-issues can be a group and +vulnerabilities can be a role.

[stuartpb]

Also, this would probably be the place to include a clone of Wikipedia's "Do not disrupt Wikipedia to illustrate a point" policy - it's okay to point out a flaw in the code/DNA by addressing the flaw, it's not okay to point out a flaw by exploiting it (even if your argument has been, from your point of view, misunderstood).

It's fine to argue the reduction to absurdity to convey a reasoned point: however, if the response is "we don't think that's a realistic thing for somebody to do", it's not your job to become that absurd thing.