[tantanel]

The debate is not really whether the algorithm should be made public or not, it's about the method used to try and keep it secure.

If the algorithm can be reverse engineered then trying to suppress the knowledge that is already "out there" will only create an illusion of it being a secret, and the fewer people know about it the more damage they can potentially do (i.e they more they can financially benefit from their knowledge).

It's the same as with information security - if you discover an exploitable bug then chances are someone else has already discovered it too (or can discover it any time) so making it public is one of the most sensible things you can do.

[dsacco]

It's not the same as with exploitable bugs, because exploitable bugs are fundamentally preventable. Not necessarily in aggregate; but individually, all bugs can essentially be patched given enough time or effort. There's no benefit to keeping them secret if their threats can be neutralized.

As I outlined in another comment in this thread, algorithms that do not offer or adopt significant authorization constraints (as quantified by time/monetary costs) cannot be "fixed." This is fundamentally why reverse engineering e.g. HMAC signing algorithms, search results ranking, spam filtering or front page listing algorithms is possible. The generous usability requirements do not allow for authorization that would mitigate reversing the algorithm, even when it's not embedded in an untrustworthy client.

Suppression is essentially all you can do to prevent reverse engineering, and suppressing the knowledge of how to reverse engineer an algorithm is in effect the same as suppressing the algorithm itself.

[unethical_ban]

I think the difference is that one can make verifiably secure software. Can one make a verifiably ungameable ranking algocfor a news site?

[dsacco]

What does "verifiably" mean for you? Are you talking about provable security?

First establish an upper bound, worst case scenario cost (as a function of time + resources) to fully reverse engineer the algorithm. Use that as the comparison benchmark, and if you can come up with a design that eliminates any reverse engineering efforts with fewer costs than worst-case, you've done it.

Here's where that breaks down: "ungameable" is not precise enough to establish worst-case bounds for, in the same way that we can establish worst-case bounds for breaking an MD5 hash (brute-force it - what does "brute-force it" mean for gaming a ranking algorithm, or reverse engineering more generally?). Other than that, were you to come up with such a measurement, it would almost assuredly increase the costs of reverse engineering to infeasibility by increasing the authorization controls in place and decreasing the usability requirements.

[kilburn]

Well, probably not for such a broad description of "ungameable", but there is an entire research field dedicated to try and come up with such algorithms/systems: Mechanism design!

https://en.wikipedia.org/wiki/Mechanism_design