Comment by LeifCarrotson | Hacker News Reader

Comment by LeifCarrotson | Hacker News Reader

Parent Full thread

> Security through obscurity isn't a thing, and the better response is just to make a better algorithm, not try and suppress knowledge about it.

Obscuring an algorithm or making it more tedious to reverse may not make it perfectly secure, but that's not the goal. It's not like actual information security, where loss of the encryption keys means your product is broken or your database is on the Internet. You're just trying to minimize the workload on humans who act as a back-up for the few posts that slip through.

If an email spam detection algorithm was public, spammers could precisely craft their content to slip through. If the heuristics for showing a CAPTCHA were public, bots could automate their requests to avoid it. If a ranking algorithm was public, people who might financially benefit from the front-page traffic could force content there through vote rings and sock puppets.

If the algorithm is secret, far fewer will be able to do so, and this small fraction of abusers can be handled by humans.

You can always find reasons why something has to be a certain way. But at the end of the day, you can't expect to attract and retain curious hackers/entrepreneurs in this way. The author presumably spent some time compiling the original story, the math symbols and graphs are quite nice for instance, just to have it removed without explanation. It's not a very good way to treat people.

There is no proof it has been removed by different means other than those mechanisms all stories are subject to. I myself am not convinced at all.

Does it matter? The author seems representative of exactly the type of users you want in a community like this. Long standing user account, high karma, produces decent comments and great content (the visualizations in the Swype article is another example [0]) and even puts HN comments on the blog. Whatever mechanism that ends up discouraging people like this in favor of trigger happy flaggers is broken. Fortunately for the community the author didn't go "fuck it", but instead wrote another sensible blog post which makes them an even better community member.

[0] http://sangaline.com/post/finding-an-optimal-keyboard-layout...

See also, a discussion a couple weeks ago about how people can "buy" upvotes on HN and how HN takes steps against that: https://news.ycombinator.com/item?id=13676362

Once it's public (even unofficially), people will begin to rely on the current implementation and then complain if it is ever tweaked or changed. They build towards the value it grants and then complain that the value was arbitrarily stolen from them.

That's for sure. I rarely visit SEO websites or forums, but the few times I did I saw lots of complaints from people who seemed to think that Google owed them something after tweaking their page ranking algorithms.

But aren't the people who are relying on that value precisely the people you want to keep out?

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.

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

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

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.

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.

Reply on news.ycombinator.com