Comment by comex | Hacker News Reader

Comment by comex | Hacker News Reader

Parent Full thread

The Play Store agreement has a very similar clause which applies to all apps plus the store itself (haven't checked the Amazon one). The Android SDK agreement also has one, which may or may not be preempted by whatever parts of it are available under open source licenses (depending on your interpretation of "require"), but definitely applies to anything closed source (e.g. the new Java compilers, if I remember correctly). So basically the EFF is full of shit.

> Security Features. You may not attempt to, nor assist, authorise or encourage others to circumvent, disable or defeat any of the security features or components, such as digital rights management software or encryption, that protect, obfuscate or otherwise restrict access to any Content or Google Play.

- https://play.google.com/intl/en_us/about/play-terms.html

> 3.3 You may not use the SDK for any purpose not expressly permitted by this License Agreement. Except to the extent required by applicable third party licenses, you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK; ...

- https://developer.android.com/sdk/terms.html

It doesn't require that you put DRM in your app. The iOS one does (which is part of the build / submission process).

I don't know enough about Android technically to tell whether this is true, but the blog post is complaining specifically about restrictions on reverse engineering the SDK.

Another bullet point is about restrictions on jailbreaking; while this is certainly highly onerous and I don't think Google has an equivalent clause, it's worth noting that Google's ban on reverse engineering the Play Store and apps distributed by it (as opposed to the SDK itself) includes activities that, translated to Apple terms, are fairly important to jailbreaking. (In particular, many App Store apps refuse to run on jailbroken devices, and must be reverse engineered to identify how to bypass this check. I don't know what the situation is on Android, but I would be surprised if that clause wasn't rouinely ignored.)

TLDR: Google is doing it too. Thank you for pointing it out.

The main SDK is open source. It's built from the same tree as Android from the AOSP, and you can build it yourself right now, which makes reverse engineering it sort of moot. Things like billing APIs or maps or google's push notifications however are in closed binaries, which I believe is what the clause is protecting.

Additionally, I know enough of the Android build process to know that yes, it is true that the Google Play Store does not require DRM. It's also easy to pull any app that doesn't have DRM off a phone and put it on a phone using the debug tool that google themselves release (ADB).

`adb pull <app location>`

plug in new phone

`adb install <app file you just pulled.apk>`

You can call it DRM but what it really is, is security. Apps are signed, preventing the running of unauthorized code, which keeps malware off the platform.

If google really doesn't have this, then it's a shame, but it would explain why there's so much malware on android.

EFF's position across this article is supporting malware, and preventing malware is the clear cause and reasons for all the things the EFF opposes.

Android encourages users to stick to the Play Store, but has an escape hatch for users who don't want to. If Apple had such a policy, it might increase the presence of malware, but only for users who explicitly decided to circumvent the normal distribution process.

Most Android malware is distributed on the Play Store; the reasons it is prevalent include the lack of review process and the Android permission system, both of which are orthogonal to the ability to circumvent the store.

I think Apple's policy is mainly aimed at preventing competing app stores. You see them having a conniption every time someone submits an app that includes an alternate app store. And while I don't particularly like their policy, they have every right to implement it in order to protect their revenue.

> I think Apple's policy is mainly aimed at preventing competing app stores.

Yes. Malware is the boogey man which apple uses to justify this.

Signing doesn't require encryption that inhibits visibility into the app internals.

Right; Apple submission doesn't doesn't require encryption that inhibits visibility into the app internals.

It does require signing, and Apple prevents unsigned apps from running on non-jailbroken phones.

codesign also encrypts the binary, it is not just signed. https://github.com/jevinskie/Clutch is a utility that decrypts apps for you.

> preventing the running of unauthorized code, which keeps malware off the platform.

This is neither a necessary nor a sufficient condition for controlling malware, yet you speak as if it is both.

You're implying that "preventing malware" is important enough that it overrides all other rights of the user, including some very important freedoms? And that somehow, supporting these freedoms means "supporting malware"? What the actual fuck!? This is as horrible an argument as "only terrorists have something to hide, therefore anyone who wants privacy is supporting terrorism." (Replace "terrorism" with your choice of anything the government is fighting against.)

How about we put everyone in prison, because some percentage of them will become criminals anyway? I don't even...

"Those who give up freedom for security deserve neither."

What about people building their own SDKs from AOSP source? I know quite a few people that does this, which helps them with built-in app developments as you can get all the @hidden methods/properties.

Reply on news.ycombinator.com