

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

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.<p>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.<p>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.<p>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.<p>Alternatively, should I tell them about the exploit, its mechanism, and its implications, and suggest they stop implementation?<p>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?<p>(Actually this is really two intertwingled choices: {continue helping vs. suggest stopping} and {reveal exploit vs. keep quiet})
======
ASutton
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.

------
haseman
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.

~~~
rndmcnlly0
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.

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

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

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

------
ffpaladin
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?

------
foobarbazetc
I hope you're getting paid for your time.

~~~
rndmcnlly0
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).

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

~~~
rndmcnlly0
Nope, and it's not Amazon either.

------
araneae
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.

~~~
cgranade
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.

------
gte910h
No, you should just point it out.

