@[email protected] 👂 🦻 würde mich auch interessieren. OM läuft bei mir derzeit mit eSpeak (aus F-Droid). Geht so, aber redet halt Blech 🙈

@[email protected] and don’t forget the lock picks… Where’s no door, one can’t pick its locks. Simple. 🤷‍♂️

@[email protected] I use uBlock Origin for that. Even kills the cookie consent in 90% of the cases. Not on some Heise pages, but there the Zapper helps to just remove the overlays… Or leave them up, and simply switch to “Reader mode” – just tested, works fine on that page.

@[email protected] Congratulations from here, too!

@[email protected] Remember that WE cannot implement those. Everything that needs changes to the index, is out of our hands – at least as long as we’re still bound to fdroidserver. So such issues would need to be filed there – with the tools that generate the indexes. Our client devs would surely pick up those data once available.

@[email protected] which needs to be implemented serverside (fdroidserver writing the index) AND clientside (to show it). Without the index itself supporting it, there’s nothing the clients can do. So: https://gitlab.com/fdroid/fdroidserver/-/issues/301 ? https://gitlab.com/fdroid/fdroidclient/-/issues/195 ? Does not look like this will happen.

@[email protected] I have my doubts towards the former (that would mean rolling back their implementation, at least in parts, and using the suggested patches instead, which they rejected. The argument was that f-droid.org itself does not need key rotation, IIRC.). And as long as we still use fdroidserver, the only way we can notify is via the inlined per-release changelogs (aka “Fastlane changelogs”), which is what we do.

@[email protected] Key rotation does no longer work at F-Droid.org, but it does at IzzyOnDroid (as we implemented the suggested patches instead of accepting their implementation of the “POC fix” back then). If Key rotation is used, no notifications are needed; IIRC, Android handles that (we have only 1 such app yet). And establishing RB here does not require it either, as we only ship the APKs signed by their resp. devs to begin with (RB runs on a “parallel track” here).

@[email protected] Danke, jetzt schaut es gut aus.

Und ja, für “flott” ist IzzyOnDroid bekannt 😉 Danke auch für das Lob.

Haben wir beide jetzt was gelernt: Ich muss aufpassen, wem ich was schicke (oops) – und Du, was davon Du “einfach so” online stellen kannst 😜

@s3nnet Auch nach force-reload steht das bei mir noch immer so:

@[email protected] Da steht noch immer “By IzzyOnDroid” unter den Screenshots, mit Link auf meinen Mastodon-Account. Braucht wohl noch ein wenig (CDN oder so)?

@[email protected] shit happens – und Du machst Dir da wahrscheinlich wirklich keine Vorstellung. Wir könnten bei IzzyOnDroid schon so viel weiter sein, wenn wir nicht ständig dort Sachen korrigieren und “misleading statements” richtigstellen müssten (wie gerade jetzt im POC).

Oh, und die Screenshot-Dateien sollten vielleicht nicht gerade “izzy-*.png” heißen 😉

@[email protected] TL;DR: bitte entferne IzzyOnDroid als Quelle bei “POC”, und verlinke da stattdessen zum POC selbst. https://github.com/obfusk/fdroid-fakesigner-poc?tab=readme-ov-file#update-2025-01-22 war in meinem public post.

Du kannst gern erwähnen mich gefragt zu haben, wie wir das bei IzzyOnDroid handhaben – und dann das “Bei IzzyOnDroid verwenden wir zwar…” zitieren (einfach ohne das einleitende “PS” – der Text passt ansonsten.

@[email protected] ja, schon. Aber wenn da “IzzyOnDroid” drunter steht, schaut das nach “IzzyOnDroid gegen F-Droid” aus. Und das ist es definitiv NICHT. Bin Dir jetzt nicht böse (naja, ein wenig schon) – aber im Journalismus benennt man vertrauliche Quellen nicht, ohne sie vorher danach zu fragen.

Ist halt eine Scheiß Situation, und ich möchte einfach nicht, dass sie als “persönlicher Konflikt” fehlinterpretiert wird. Gibt da schon genug Stress. Siehe z.B. https://gitlab.com/fdroid/admin/-/issues/447

@[email protected] Umpf… Eine als PRIVAT markierte Nachricht einfach so auf eine News-Seite zu stellen, ohne zu fragen, ist aber schon ein wenig… err… merkwürdig. Ich hatte Dir die Infos extra privat zugeschickt. Kannst Du bitte die Quelle entsprechend redigieren? Ich will hier keinen Flamewar lostreten, habe Dir nur die Infos, vertraulich, zukommen lassen. Als Quelle kannst Du einfach den POC benennen, aus dem die Screenshots ja kommen.

@[email protected] @[email protected] https://github.com/obfusk/fdroid-fakesigner-poc?tab=readme-ov-file#update-2025-01-22

@[email protected] Now guess why e.g. I don’t use “the app store”? I’ve cut my ties to Google ~10 years ago. No Google Services on my devices, no PlayStore. I prefer places where I can actually “talk to a human” instead of getting “robot replies” (if I get any at all), or needing to compromise my privacy 🤷‍♂️

TL;DR: Count us as “someone else” who tries to “get it right” 😉 And visit e.g. https://apt.izzysoft.de/fdroid instead of “the app store” 😜

@[email protected] at #IzzyOnDroid we have scanners in place that check each app on each update for such things. Should something “suspicious” show up, we receive an “alert”, cross-check why the app might need that, reach out to the developers if unclear.

Results: either the permission is clarified (and the explanation added as in the screenshot) – or it is removed (sometimes, dependencies “drag stuff in” without the devs having intended that; we’re all humans, mistakes can happen to each of us).

Btw: that’s why at #IzzyOnDroid we try to make such #permission needs transparent for the #Android #apps we provide. Not just by linking to permission descriptions (what they are meant for in general), but also by explaining what this app needs it for – as the screenshot here shows:

@[email protected] Well spotted! The pattern is that more recent apps are more likely to have RB established already 😉