My Views on #LLM and #OpenSource Development
https://blog.muntashir.dev/2026/09/20/my-views-on-llm-and-osd/
Remote
Muntashir Akon
@muntashir@infosec.exchange
mastodon 4.8.0-alpha.3+glitchPh.D. student at UC Riverside. Creator of @appmanager@floss.social. My interests are security, privacy, linguistics, medical science and physics.
188 Followers
34 Following
14 Posts
Joined October 12, 2023
Website:
GitHub:
Replying to
UPDATE: #Google seems to have fixed the issue anyway. I was able to register both App Manager and Captive Portal Controller in the Android developer verification console.
Replying to
Another issue is the 50% download requirements. Traditionally, most people would download the apps from #FDroid which historically used their own signing keys to sign the apps. Since most people have used #FDroid instead of other methods, only that signing key shows up there, and currently, it doesn't offer an option to choose a different key.
Replying to
Also, since I do not have access to the signing keys used by F-Droid, it's effectively a dead-end. Taking down apps from F-Droid (and move to IzzyOnDroid completely) potentially forfeiting all the users who rely on updates from F-Droid.
Replying to
Today I've received the following generic-looking response from "Android developer verification support":
Replying to
Apps subjected to potential impersonation attack:
- App Manager
- Captive Portal Controller
Apps with F-Droid priorities:
- SetEdit
- UnApkm
- Metro (since this app is exclusive to F-Droid)
Replying to
Google has added an “other ways to verify” option now. So, now it may be possible to bypass the 50% rule.
“The tune had been haunting London for the past three weeks. It was one of countless similar songs published for the benefit of the proles by a sub-section of the Music Department, called a versificator. The words of these songs were composed without any human intervention whatever on an instrument.[..] But the woman sang it so tunefully as to turn the dreadful rubbish into an almost pleasant sound.” — George Orwell, 1984
Replying to
@grote@chaos.social @y20k@chaos.social This issue can be addressed in several different ways depending how the app was published on F-Droid.
For apps published with the explicit consent from the maintainer: F-Droid can ask the maintainer to include an adi-registration.properties with the maintainer's own unique key if the developer has an account with Android developer verification program. Otherwise, they can ask the maintainer to use F-Droid's own key and let F-Droid claim the package ID instead.
If the developer doesn't care, inactive, or no explicit consent has been given, F-Droid can claim it using an skeleton package (https://github.com/android/security-samples/tree/main/AndroidDeveloperVerificationAPKSigningExample) for verification. But this can be complicated depending on the package ID. If F-Droid uses a different package ID, it should be easy. If not, F-Droid needs to ask Google to explicitly allow them to use the same package ID since Google wants to reduce collision as much as possible.
Replying to
@y20k@chaos.social I think a potential solution is creating a verifiable build by pushing adi-registration.properties file into the version control system. Once it's published on F-Droid, you can add that signature as an additional key in the Android developer verification page.
Replying to
@y20k@chaos.social If you see the warning like in the screenshot, it means someone else has claimed the package ID, not F-Droid. For me, it was easy since the domain name that I use (muntashirakon.github.io) has already been verified.
Replying to
@y20k@chaos.social Once F-Droid makes a successful build, you can add the key to your existing package ID and upload the APK built by F-Droid for verification. After that, Play Protect will stop complaining about the app if it's installed from F-Droid.
Replying to
@lambert@rheinneckar.social This is because world data contains more copylefted code than source available code (or most other open source licenses). So, whenever LLM spits out something verbatim, chances are that it is a copylefted code. If the project doesn't have a copyleft license, this can be problematic. This, of course, doesn't hold true for certain proprietary algorithms, but this is very rare. I think FSFE and SF Conservancy (linked in my blog post) both talked about this issue.