It's important to remember the context of your employment... "a short term dev contact." You may have great ideas for solving all their problems, but if you have a short term contract, and then are gone, and you started them on a long journey to rearchitect their entire app, and then the existing employees have to support it. That's not a great situation. If you're hoping that this effort will get you a full time gig, is this a place you want to work long-term having seen what you've seen?
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?
the context of my employment is actually just intentional noise to avoid doxxing myself. Lets assume that actually I am a full time employee with a very senior role for the sake of argument. Each particular change is minor but taken together they become problematic. Especially the idea that SOLID practices could be avoided under the fear that the product becomes "easier to crack".
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.
It sounds like you’re in a bit of a cat and mouse game now with the attacker. Is there a way to quantify the lost revenue? Is this real or theoretical?
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.
I'll probably wait until I can get closer to the financials but at this point I imagine its mostly theoretical. I think its even mildly plausible that the cracks are coming from sanctioned nations as this "luxury" product is quite key in certain industries. So I doubt we can defeat the l337est state backed h4xx0rs in a game of wits.
As the package is delivered in completeness and runs entirely offline I believe there is no possibility in guaranteeing its protection. Ultimately you can load the app into memory, work out (slowly) what parts are performing checks and recompile the app while removing those parts. While I imagine initial users are paying, somehow the software is falling into the hands of those who wish to the crack it. So the process is just a factor of time. Without an architecture that puts the hard to reproduce part somewhere else that we can protect (e.g. a client-server architecture that is vital to the function of the app), there is no guarantee. From my perspective the only value beyond setting some arbitrary bar of difficulty (which we already have) is perhaps finding ways to fingerprint the software so we can narrow down the origin of the cracked edition (as its much harder for the attacker and beyond their interest to scrub non-functional breadcrumbs from the binary). We would then have an avenue to follow up with the official origin of the leak.
You're right to bring up the trade-offs but given the money at play and the level of support we offer for the product it transitions quite well into a service as opposed to a product. There are obviously issues around such a switch but I believe it does fit into the business model. In terms of competition I am told that for the most part we are streets ahead and have little to worry about at the moment.
> 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?
I don't think the execs are necessarily desperate, but I'd have to look at the financials to be certain of that. I believe that its just that they fear, and are looking to add value and have simply happened upon this as an obsession. The company is reasonably old with a consistent executive team for most of its life, so I just think they have that 80s/90s attitude to technology that hasn't been updated. I'm still trying to get a feel for the organization, but there appears to be a lack of structure which allows execs to effectively directly control the development department. I'm sure if I get a stronger handle on scheduling (which I expect to happen over time) then this issue is going to come up and we might clash over it, as I believe shipping the product (still with some level of copy-protection) is more important that over-fitting the copy-protection and slipping on the schedule. Their development practices themselves need some serious updating and it would be absurd to focus on adding more copy-protection when they don't even have proper continuous integration. There's lots to do.
Their fear isn't entirely unwarranted, they do good work enforcing compliance with current customers and I agree that there's considerable value in chasing the clients with the money to rectify their non-compliance, and I imagine often such issues are accidental as opposed to intentional. There's a lot of money in this market and those benefitting from the software definitely have the ability to pay. However looking at those who are not paying and may never pay as lost revenue is a mistake imho that they're making, but its about how to frame that. I imagine someone has already made such an argument and was hoping to stumble across their resources.
Thank you for the link and the idea of fear setting. Hopefully I will get the time to sit down and better understand their concerns, prior to framing a response.
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.
sorry, that was just intentional noise. I had not expected so many commenters to fixate on that one aspect. Let us assume for the sake of argument I am a full time employee who has been recruited in a senior position.
It's important to remember the context of your employment... "a short term dev contact." You may have great ideas for solving all their problems, but if you have a short term contract, and then are gone, and you started them on a long journey to rearchitect their entire app, and then the existing employees have to support it. That's not a great situation. If you're hoping that this effort will get you a full time gig, is this a place you want to work long-term having seen what you've seen?
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?
the context of my employment is actually just intentional noise to avoid doxxing myself. Lets assume that actually I am a full time employee with a very senior role for the sake of argument. Each particular change is minor but taken together they become problematic. Especially the idea that SOLID practices could be avoided under the fear that the product becomes "easier to crack".
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.
It sounds like you’re in a bit of a cat and mouse game now with the attacker. Is there a way to quantify the lost revenue? Is this real or theoretical?
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/
I'll probably wait until I can get closer to the financials but at this point I imagine its mostly theoretical. I think its even mildly plausible that the cracks are coming from sanctioned nations as this "luxury" product is quite key in certain industries. So I doubt we can defeat the l337est state backed h4xx0rs in a game of wits.
As the package is delivered in completeness and runs entirely offline I believe there is no possibility in guaranteeing its protection. Ultimately you can load the app into memory, work out (slowly) what parts are performing checks and recompile the app while removing those parts. While I imagine initial users are paying, somehow the software is falling into the hands of those who wish to the crack it. So the process is just a factor of time. Without an architecture that puts the hard to reproduce part somewhere else that we can protect (e.g. a client-server architecture that is vital to the function of the app), there is no guarantee. From my perspective the only value beyond setting some arbitrary bar of difficulty (which we already have) is perhaps finding ways to fingerprint the software so we can narrow down the origin of the cracked edition (as its much harder for the attacker and beyond their interest to scrub non-functional breadcrumbs from the binary). We would then have an avenue to follow up with the official origin of the leak.
You're right to bring up the trade-offs but given the money at play and the level of support we offer for the product it transitions quite well into a service as opposed to a product. There are obviously issues around such a switch but I believe it does fit into the business model. In terms of competition I am told that for the most part we are streets ahead and have little to worry about at the moment.
> 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?
I don't think the execs are necessarily desperate, but I'd have to look at the financials to be certain of that. I believe that its just that they fear, and are looking to add value and have simply happened upon this as an obsession. The company is reasonably old with a consistent executive team for most of its life, so I just think they have that 80s/90s attitude to technology that hasn't been updated. I'm still trying to get a feel for the organization, but there appears to be a lack of structure which allows execs to effectively directly control the development department. I'm sure if I get a stronger handle on scheduling (which I expect to happen over time) then this issue is going to come up and we might clash over it, as I believe shipping the product (still with some level of copy-protection) is more important that over-fitting the copy-protection and slipping on the schedule. Their development practices themselves need some serious updating and it would be absurd to focus on adding more copy-protection when they don't even have proper continuous integration. There's lots to do.
Their fear isn't entirely unwarranted, they do good work enforcing compliance with current customers and I agree that there's considerable value in chasing the clients with the money to rectify their non-compliance, and I imagine often such issues are accidental as opposed to intentional. There's a lot of money in this market and those benefitting from the software definitely have the ability to pay. However looking at those who are not paying and may never pay as lost revenue is a mistake imho that they're making, but its about how to frame that. I imagine someone has already made such an argument and was hoping to stumble across their resources.
Thank you for the link and the idea of fear setting. Hopefully I will get the time to sit down and better understand their concerns, prior to framing a response.
>Ive just begun a short term dev contract
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.
> Who hired you? Have you spoken to that person?
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.
If you have a "short term dev contract", this is not your problem.
Let the owners, board of directors, management, and employees figure it out.
sorry, that was just intentional noise. I had not expected so many commenters to fixate on that one aspect. Let us assume for the sake of argument I am a full time employee who has been recruited in a senior position.
You don’t, you’re just an employee. Do your job and whatever your company tells you to do, do it and let money appear in your account.
Do your work, close your computer and enjoy your life.
maybe that works out for you but its not at all how I operate.
Good luck with trying to change a whole corporate culture. What power do you think you have to make a difference?