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