Ask HN: an ethical dilemma in recommending an Android DRM solution fix | Hacker News Reader

Ask HN: an ethical dilemma in recommending an Android DRM solution fix

12 pointsrndmcnlly014 comments

An alternative Android app store invited me to sell my apps in their marketplace, which requires integration of a complicated in-house DRM scheme to protect apps from piracy. Upon investigating the docs and sample code for the integration process, I was amazed to see heaps and heaps of unnecessary complexity, brittle design, and many opportunities for mistakes in integration.

Somehow the part of me that abhors terrible software design took over, and before I really thought about it, I had sent them a very detailed proposal for an alternative design that both fully integrated with their existing infrastructure and reduced integration complexity from a collection of scattered changes to Java source (which would break compatibility with other marketplaces) to a three-line XML change in an application's manifest (which could even be applied in an automated fashion upon upload to the marketplace), with no need to even recompile existing code.

The issue now, after a few rounds back and forth with their team, is that I've come to privately realize a major exploit in my design which would allow the creation of a general-purpose launcher app that would completely evade the DRM scheme I recommended.

Should I continue to help this company improve the developer friendliness of their egregious DRM solution? This would (1) make them much more attractive and lead to many more adopters of their marketplace (2) stop a precedent from being set for Android developers having to customize their code for a distinct marketplace and (3) rid the world of a piece of software design that, at best, discourages integration, and, at worst, inspires a new era of terrible DRM design.

Alternatively, should I tell them about the exploit, its mechanism, and its implications, and suggest they stop implementation?

Thirdinatively, should I just keep helping them fix their stuff (which has its share of existing exploits already), and keep quiet about the exploit, leaving it as an easter egg for the curious few with both a deep enough understanding of the Android framework and experience with this particular marketplace to discover on their own?

(Actually this is really two intertwingled choices: {continue helping vs. suggest stopping} and {reveal exploit vs. keep quiet})

It has to be down to your personal preference.

My company runs AndAppStore and, although we don't force anyone to integrate our purchase checking system into their paid apps, I know we'd still appreciate a heads up from anyone who thinks they've found an exploit for it (not necessarily giving a full fix, but a heads up to how the exploit would work so we can look at addressing it if it worked).

In your shoes I'd ask for the DRM requirement to be dropped. You know it's not secure, they've shown they're not paying full attention to the DRM solution, and so even if you spent your time coming up with a totally secure solution there's no guarantee that they wouldn't modify it at some point and inadvertently weaken the protection it offers.

One thing to remember though is that if your app is available through multiple channels you may end up with lower sales across the board if the problem isn't addressed. The reason for this is if pirates get a way to create a DRM free version of your app then it doesn't matter how secure all your other distribution channels are, the pirates have an easy route to create a cracked version of your app they can redistribute.

Continue helping (try to get paid) and tell them about the exploit. Even if it's their project your name will still be on their lips when someone else figures it out. Also... being able to sleep at night is nice.

I hadn't considered the effect on my reputation at all.

So, forward simulating (and embedding my sentiments as a measure of my ease of sleeping):

Case {they implement it any nobody learns of the exploit}: I'm remembered as the one who stood up to help reduce friction to new apps being listed. They keep me as a positive point of contact for future design changes. I feel good about baleeting bad software design. Reputation improves, presumably.

Case {I don't tell them about it, they implement it, and somebody turns the conceptual exploit into a real tool after deployment}: The company company loses, consumers win (yarr). The company (and every company they swap stories with) decides never to deal with me, if they decide to pin it on me as intentional. I feel good about baleeting bad software design as well as demonstrating the counterproductiveness of DRM (albeit in a contrived way). Reputation declines, conditionally.

Case {I do tell them, they continue anyway in the name of reduced friction}: They take a calculated risk and own the result. Yay for improved design, but hard to forward simulate any more. Reputation unchanged-ish, regardless of whether the concept is exploited or not.

Case {I do tell them, and they decide to quit the project and keep their old solution}: They feel less receptive to future requests in the name of reduced integration friction ("ya know, it might have a flaw!"). I don't list my apps with them, and I hope that others don't either. Reputation unchanged. The concept of third-party-android-marketplace's reputation (and indirectly Android's)? Decreased relative to potential.

By this, non-exhaustive, in-the-reply-box analysis. It sounds like I should tell them, but somehow do it in a way that doesn't talk them out of it. Best option so far, but somewhat hard to enact.

Btw, I'm not a professional software consultant.

Update: I gave them a high-level overview of the conceptual exploit and even sketched a high-level technical solution for the problem (one that I admitted probably only pushes the difficulty up a few more notches, expected with DRM). I guess I'll play the next move by ear.

I admire your honesty. I find it is, by default, the best policy ;-)

Let them know about the vulnerability. Help Google make decent anti-piracy protection.

P.s.: Don't forget to charge for your consultation :-)

Wow, this really isn't very black and white...

I suppose it's like having some treatment for cancer that is ugly and grueling. Then discovering an elegant cure.

The cure, however, has some mind-manipulating exploit that is only known to you.

What do you do?

Cure people from unnecessary suffering of cancer? Or avoid giving people a vulnerability, unknown to everyone else?

I hope you're getting paid for your time.

Heh, nope. I thought asking for money would only complicate their adoption of my idea for cleaning up the DRM integration process. I'm just trying to save the world from some terrible software here, remember (and trying not to create a bigger mess in the process).

Is this the AppsLib people? I'd stay away, it's disgustingly amateur. Tell them the exploit and walk away.

Nope, and it's not Amazon either.

If you don't consider yourself responsible for the introduction of the exploit, I'd say do what academics do: publicly publish the exploit.

If you are responsible in any way, though, I'd recommend informing of them of the problem. You don't have to fix it, just tell them it's there.

In defense of academics, it's quite common to first notify the vendor so that they can prepare a countermeasure for when the exploit is published. In general, publishing without making a reasonable attempt to contact the vendor is irresponsible at best and often down right unethical.

No, you should just point it out.

Reply on news.ycombinator.com