Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Submission + - an ethical dilemma in recommending an Android DRM

rndmcnlly writes: "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?"

Comment disconnected (Score 2, Interesting) 276

A related but more general question: When people talk of bits of infrastructure being connected or disconnected from the Internet, are they talking about the presence of direct, layer 3 connectivity (can I ping the airport's tracking systems?), any layer (if I hack the contracting company's intranet can I view aircraft positions through a series of proxies and application layers?) or actual electronic disconnection from the Internet (can you get only get in via getting your man on the inside the tweet the secrets from his cell)? Distributed infrastructural systems communicate Somehow...

Submission + - Google Maps hack serves up an aesthetic upgrade (adamsmith.as)

rndmcnlly writes: "Applying a little image processing to Google's original tiles, this site lets you explore an abstract, artsy view of your home planet: http://www.adamsmith.as/blurry_maps/ Technical users will note the use of Google's own caching proxy to serve the tiles, keeping the service up and bandwidth costs down."

Comment Re:Ajax compared to Flash (Score 1) 347

"Just come to the site and begin using the application."

That was the idea behind a techdemo/test game that a friend of mine and I made. AjaxWar, inspired by Wil Wright's SimWar, uses only javascipt on the client side to produce an N-players in N-games, bandwidth concious, non-polling, visually interesting (although most effects were disabled for the demo), robust, realtime strategy game. In the demo, the two browser windows are shown side by side but could have been behind NAT, firewall, proxies, etc on completely different networks than the server and each other. Oh, sorry, I know the demo requires flash (the real game required some modifications to php on the server side that we didn't want to make on a public web server).

Now, enough showing off. The thing we realized by the time we stopped working on the game is that doing things like making pretty multiplayer games with complex IO patterns is something thats really a lot easier, and more predictable using something like Flash or Java. It kinda felt like we were programming in a hostile atmosphere where you can't breathe without a helmet -- I mean can't get data pushed from the server unless you had a multipart encoded stream hanging in the ready. The latency was not bad at all, and neither was throughput of large chunks of data, however we reached a bottleneck when experimenting with several small updates in a short amount of time -- we couldn't reset our transfer mechanism fast enough to make something like an FPS viable at all. A majority of our time was spent expermenting with methods of moving data from the client to the server, politely, asynchronously, quickly, the actual gameplay was mostly an afterthought. While there aren't many web applications that demand the kind of IO we wanted, the pipe to the server is going to be a limiting factor for Ajax-ONLY type applications. Sure, you can use sockets in javascript if you require a certain browser and make the user click ok to a dialog, but if you have them doing that, you might as well have them install Flash. This issue of plumbing needs to be resolved before smart-client apps become ubiquitous.

Slashdot Top Deals

A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard.