DRM in all apps?


#1

Could some explain this article to me?


Will this affect F-Droid? Will this affect our ability to distribute DRM-free apps?


#2

Reading the linked blog post

In short, this is cast as a security/anti-piracy step.

This is specifically, currently all about Google “Play-approved peer-to-peer sharing apps” in which F-Droid doesn’t usually fall (other than “Nearby” mode) & doesn’t even vaguely try to pretend it’s distributing GPlay binaries (except if 1 adds, e.g., Unofficial Firefox F-Droid repo which isn’t officially F-Droid’s anyway.)

Generally, in the future? This could easily be abused into evolving into Apple’s “walled garden” approach to appstores, which obviously kills F-Droid, other than by rooting devices.

Time will tell. 🤷


#3

How exactly?````````````````````````


#4

@Licaon_Kter So tell me, where is F-Droid (or equivalent) for iOS? & how is it accessed?


#5

“whataboutery” much?

You’ve made a statement, given what was announced, how to you envision that this move helps a walled garden?


#6

Ok, a “straighter” answer :wink::

If Google takes this step (i.e., adding DRM-type metadata header) to police apps not installed directly from GPlay to prevent piracy/security issues, this lack of header would also affect any app that is installed, e.g., via Unknown Sources (were y’all aware of the ruckus re: the Exodus privacy app, F-Droid vs GPlay releases

which seems ☐ly in this category?)

Now, if Google chooses to enforce (really, a tiny step: the infrastructure after the above is accomplished would be completely in place) requiring that header for any app to run successfully, this moves the ecosystem to be the same as Apple’s “walled garden”

(mentioned earlier, 'cuz its a term of art), where only what is vetted per the OS “standard” is permitted.

Therefore, the answer to my question re: F-Droid on iOS? There really isn’t allowed to be 1, officially!

Further clarification needed on my analysis? :bowing_man:


#7

If things getting that worse I hope that’ll boost MicroG development…


#8

Yes, they can remove Unknown Sources all together, hence I find this “DRM” bit panic is kinda useless.


#9

@Licaon_Kter True, but, since the code for that already exists, many device manufacturers may choose to leave it in their ROMs (such as they do w/ other features Google deprecates), given demand.

A DRM-style “security” feature would likely be much more likely be woven tightly throughout the OS, making it virtually certain no OEM would dare risk Google device decertification by trying to leave it out.

But, in another sense, you’re right. As I mentioned previously, right now, this is all “The-sky-is-falling!”-type concern. But if the sky gets pushed, this might be the time to start preparing. 🤷


#10

A preliminary example of this in ChromeOS?


#11

That new metadata thingy is not looking good. Looks like DRM. At least it’ll take a long while to roll out…


#12

Where do you see this will take a long time? They announced this version of it in December 2017, & are saying it’s now in effect. Why would flipping the switch for all apps take any time @ all⁉️ It’s just a matter of compiling some “compelling stats” & coordinating that enabling w/ the next Android malware news (due anytime now).

Yes, I’m a bit cynical. It’s served me well.


#13

For that DRM metadata to have any meaning, it would need to be signed as
part of the APK signature. Most Android apps are signed by the
developer, so Google does not control those keys at all. They have
added this to the Android SDK tools to make it automatic, but many
developers do not frequently upgrade. So my guess is that only a
minority of the APKs out there have this metadata in them. So they
can’t turn on strict enforcing if it’ll block most app installs.


#14

Then all it’d take from Google is to require (for Play Store inclusion/privileges) for apps to be signed such, e.g., after a certain date or Android version, &c.