Ask HN: How do I prevent execs from obsessing over copy-protection?
The org sells to a very niche luxury market and distributes a native application at a high price. The execs at this company are extremely perturbed by the appearance of cracks of the software that appear sometime after every release. The issue is that our present architecture as a native application means the attacker already has root and we cannot protect any key, there are also domain specific reasons why some users will always need to be remote at some point. While I want to encourage the org to eventually move to a client-server architecture we could protect, the need to provide the remote copies means all we can do is create puzzle boxes via security by obscurity, that are cheaper to unlock for an attacker (in terms of their likely hourly rate) than for us to create.
I believe they are over-reacting to the emergence of these cracks by pushing the dev team to introduce more checks into the software and thereby harming productivity and potentially even stability of the software while also failing to solve the issue. To give you an example of my fear; I was talking to one of our devs recently about a dependency issue where some extra license checks had been baked into the UI and I was encouraging better composition to extract these sorts of checks to a specific layer instead. They replied "but if we put all the license checks in the same place, won't that make it easier to crack?".
I appreciate this is probably a red flag and I should run but I believe myself to be a convincing person and I would like to try. They are a little old-school, so I feel like a gentle approach is necessary. For the most part I am wanting to attempt to reframe the issue from a "tech problem" to a "social problem" and focus less on adding more security by obscurity and more on tracking down where the leaks are coming from where consequences can be enforced via license agreements.
So I appeal to you all to help me with this endeavour. I imagine some of you have been in this sort of situation before, and have experience I could draw from, or might have knowledge of various sources I can use. The one that springs to mind for me is the issues that big online gaming companies have with aim-bots or other cheats in markets where the value of the hack is close to the zero and the resources of the engineering department trying to defend are high; to demonstrate the futility of the approach. However I worry a little, that given the old-schoolness at play that gaming might not be an example they will be receptive to.
Conversely, if anyone has any counterpoints or suggestions about low hanging fruit, outside of simple obfuscation and/or hardware dongles, this would also be appreciated, as it might help if I can also suggest something from their angle that beats the typical curve of severely diminishing returns.
More to your question, if you need to sell this to execs, you need to talk in terms of dollars. How much is this change going to cost? How much will it make or save them? What are the risks to the business if it isn't done? The more abstract or hypothetical the risk or financials, the less likely they are to buy what you're selling.
Sorry I can't give any specific suggestions, as I'm having trouble conceptualizing what the product is. What is this key you need to protect? A product license key that they want to validate without an internet connection? Is that the goal?
I mention keys because of suggestions that encryping things in a stand alone, fully offline product achieves anything, given those values will have to be unencrypted on the device that the attacker controls, in order for the values to be useable, thereby rendering it somewhat/entirely pointless.
> More to your question, if you need to sell this to execs, you need to talk in terms of dollars. How much is this change going to cost? How much will it make or save them? What are the risks to the business if it isn't done? The more abstract or hypothetical the risk or financials, the less likely they are to buy what you're selling.
This is a good argument and is something I want to touch upon. The issue is that the fear is much like how the RIAA and MPAA reacted to the advent of the internet. As we saw then, the person with the fear can invent their own numbers, given its all off-book so its not measurable. I can certainly focus on aspects of the dev cost but I fear it might be challenging to wrap it all up in a convincing fashion when put up against an unmeasurable fear.
Is the fear they have that solid practices would make things easier to crack well founded? If you make the changes you want to make, will it put an end to the cracks, or will you spend a lot of time/money on development costs and end up in the exact same place or worse?
What are the risks if you do the client/server thing? Are you going to phone home? What are the risks there? Now if someone is offline they can’t use the software. You now have to maintain a license server until the end of time. If the company goes under, the clients will lose access to the software they paid for. Is that something the clients are OK with? Do your competitors have similar network requirements, or would that be a reason for clients to look elsewhere?
You bring up the RIAA and MPAA. These industries had to change their entire business models to adapt to the piracy threats to their businesses. And they didn’t even solve the problem themselves, it took other companies to solve it for them and drag them along, because they were desperate. If that’s the kind of change you’re talking about, the execs have every right to be scared. They have something that works today, even if it’s not perfect, and a new model might not work. If the changes aren’t that extreme, I don’t know that I’d use that analogy. If the execs are desperate, the company is in trouble, and something needs to be done to save it, than maybe it is a good analogy, but the execs seem more scared of change than worried about cracks. Is that the right read?
There is also the question of if these cracks actually have an impact on business. Most people I know who download a lot of movies would never pay money for them, even when they are free they don’t watch most of them they download. A download isn’t always a lost sale. Product keys tend to be a lot like door keys, they keep honest people honest. As long as you have enough honest customers, how much money should you spend fighting people who were never going to be customers, no matter the cost? Can some of these cracked versions also lead to future sales? Kids in school may be cracked copies of Adobe software, they learn on it, and then once they have jobs they are customers, because they already know and like the software from the experience on the cracked version. Probably less of an issue now with subscriptions vs how it was 20 years ago, but cracked software can act as trials and a means to lower the risk for future buyers, because they can try before they buy.
I’m bouncing all over here, but another thing you might want to explore is fear setting [0]. Outline what the fear is, what’s the worst thing that can happen, and what you can do if those worse case scenarios happen. That could help reduce the unknown and bring logic back into a room that has been run by a fear of the unknown.
[0] https://tim.blog/2017/05/15/fear-setting/
Who hired you? Have you spoken to that person?
>I was talking to one of our devs recently
He or she isn't your dev, they are your clients. You are a temp.
Its a little awkward, the chain of command is a little ad-hoc. So lets say the person who hired me is one of these execs. They were quite excited to hear about my knowledge of security which was dampened when they realised I was more talking about auth and securing endpoints as opposed to smth like DRM.
> He or she isn't your dev, they are your clients. You are a temp.
that particular detail is intentional noise. So sadly that advice doesn't apply.
Like I said, the attitude is so pervasive that I worry that it will interfere with the successful delivery of the product. That part, regardless of the noise remains pertinent.
Let the owners, board of directors, management, and employees figure it out.