DRM in all apps?

Could some explain this article to me?

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

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. :person_shrugging:

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

1 Like

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

“whataboutery” much?

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

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:

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

1 Like

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

@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. :person_shrugging:

A preliminary example of this in ChromeOS?

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

1 Like

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.

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.

1 Like

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.

Here’s a likely candidate route for all this to happen:

The salient quote for our above discussion:

One slightly controversial bit here is that devs needs to entrust their signing keys to Google in order for it to properly authenticate the split APKs the Play Store generates. Considering they’re already placing a lot of trust in Google by selling software through its store, we doubt that’s going to stop many devs from participating.

Elsewhere:

Dev (with Google credentials and several apps, none the less) puts WIP app on Github, users install it, Google Play store treats it like malware: [CLOSED][APP][5.0+] FairEmail - Fully featured, open source, privacy oriented email app | Page 7 | XDA Forums

Dev needs to submit to Google Play store to be whitelisted: [CLOSED][APP][5.0+] FairEmail - Fully featured, open source, privacy oriented email app | Page 7 | XDA Forums

Yeah, that started popping up a few days ago, & seems to create a device-local whitelist of APK sources (i.e., apps allowed to download them) — I get that popup only 1× per source. Right now, it’s mostly ok, 'cuz 1 can simply INSTALL ANYWAY. What concerns me is whenever that option would be removed, as detailed above in FP.

When Appp Bundles become “required” devs will have to give Google their keys: https://mobile.twitter.com/t_grote/status/1040552782703546368

Another step forward…

1 Like

@Licaon_Kter Thanks very much for chasing that detail down. Salient quote for the TLDR crowd:

Google Play Apps & Games
@GooglePlayDev
Sep 16
Replying to @t_grote
The enrollment when using App Bundles is a must. Sorry for the inconvenience that this might caused and thank you for your feedback! We’ll pass this to our product team. We take feedback very seriously as it helps us improve your experience! #AskPlayDev

The TL;DR is that devs give Google a BUNDLE that’s split as resources, locales, libs, etc, and Google Play serves only the parts needed for that device that installs, and each part is a signed APK (signed by Google build system with the DEVELOPER key!!!).

1 Like