DRM in all apps?

“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

The next stage is here, w/ good & bad sides:

Oh, Google copied F-Droid Swap!

2 Likes

Yes, but in a quite DRM-y method, for claimed security reasons. Again, there’s good & bad to that.

It reminds how tracking may be implemented via SSL quirks:

solved by

which, of course, led to

(gives Tor Browser & Orbot a shout out for defeating this 1! :mega:)

Another setting has appeared in Play Store settings: “Protect my updates”

which trialed a while ago, but looks like it’s ready for full roll-out now. Best quote from above (formatting is mine):

The warning messages feel a little misrepresentative by associating the issue with stability and improper functionality. It should focus on the nuance that switching sources may affect the consistency and timeliness of updates since they may differ from one source to the next. All the same, the wording is sufficiently ominous as to prevent most regular people from pulling the trigger.