Transnational hacking and FOSS bonding in action! Family trip brought me across the Atlantic, but got a chance to meet @pan and bring a FairPhone for development. It's amazing when we can not only hack, but also meet and enjoy the human part of it :)
I think that the robots.txt file itself isn’t a significant enough creative work to warrant copyright protection regardless of the license I put on it, and to put a license on such a trivial work would instead communicate that it’s meant to be reused.
It’s not meant to be reused as-is anymore now that I have a longer article that actually explains how and why I block what I block, but it doesn’t make sense to enforce non-reuse either.
In other words: I’m not sure that the file can receive copyright protections, and to act as if it does by giving it e.g. a CC license would simply encourage people to re-use it when they should be thinking for themselves and applying the nuance I hoped to inspire in my article.
I would rather not use restrictive licenses on my site, especially on works that I don’t think do or should receive copyright protections. and i would rather not advertise that the robots.txt be copied. A bit of a tricky place to be.
I love to see coding tutorials like this make the coder code for accessibility by giving them examples and stating up front they do not treat accessibility as an afterthought write-on.org/html/ #CSS #WebDev #HTML #Accessibility #A11y
NLS Lays Out Its New Digital Player | News October–December 2024 - National Library Service for the Blind and Print Disabled (NLS) | Library of Congress loc.gov/nls/about/news/news-oc…
Introducing the new NLS audiobook players. NLS technology from 1934 to present. And one that stayed on the drawing board. FY24 highlights. Art that's made to be touched.
F-Droid now claims PoC 5a is not an "actionable security vulnerability" because "APKs signed by v1-only are not even installable on latest Android versions". This is false. As long as targetSdk < 30 (and e.g. the official F-Droid client has 29) they will install just fine. I even confirmed this by installing my PoC APK on both Android 13 and 14 just in case, something they apparently neglected to bother with before making that claim.
They are now claiming they can't use my patches as-is because of "code quality issues" (private apis). Which... applies to exactly one patch, the one they actually merged 8 months ago.
Because the only way to fix the vulnerability was to monkey patch androguard (and an updated version is still not available in Debian, nor has the Debian stable fdroidserver package received any patches, despite those packages being maintained by the F-Droid team, so that monkey patch is still needed).
They are also downplaying the impact by insisting this vulnerability is only a problem for third party repositories relying on fdroidserver; which even if true is showing a concerning disregard for the security of repositories of other projects relying on fdroidserver.
I have no words to describe how little remaining faith I now have in F-Droid's security and code review processes.
See: https://www.openwall.com/lists/oss-security/2025/01/03/1 Seems a good idea to patch ;) The regex in question -- ^META-INF/..(DSA|EC|RSA)$ -- is supposed to match all filenames that start with ...
the regex fix is a good one, we'll look into merging that. I'd need to see a v2-signed APK that is installable on Android that demonstrates the exploit it in order to consider this an actionable security vulnerability. APKs signed by v1-only are not even installable on latest Android versions, and Android 7.0 and above support v2+ signatures. Looks like obfusk's proof of concept is a v1-only APK. Do you even ship v1-only APKs in IzzySoft anymore?
@eighthave The regex fix is also considered by Androguard, yeah. And I didn't make the POC; that area is not in my expertise¹. I could check if there are any v1-only APKs in our repo² (not aware of any right away, though, but we still have some older apps here – and there are still some older devices around; we support "device longevity" 😉). But v1 IS important here, as we still support signing key rotation³ (and have at least 1 app using that).
¹ I can follow it, but not create such on my own ² we would need time to set up a script for that; remember we're just a very small team with no grants; most work is still on my shoulders, next to a full-time $dayjob ³ we didn't use your implementation for fdroidserver back in spring but applied the patches provided by Fay, so signing key rotation is still supported at IzzyOnDroid
"I'd need to see a v2-signed APK that is installable on Android that demonstrates the exploit it in order to consider this an actionable security vulnerability."
I'd rather not wait until an exploit is out-and-about. The patch is easy and not complex. Better safe than sorry. And one should fix (even potential) vulnerabilities *before* they become exploits.
I understand your concern. From what I know, the IzzySoft repo relies much more on AllowedAPKSigningKeys to provide a secure repo than f-droid.org or guardianproject.info (the repos I'm involved in running). Both had extra verification before AllowedAPKSigningKeys existed, so there, its just an extra layer of protection. The goal of AllowedAPKSigningKeys is to make it easy for non-technical people to manage binary APK repos securely. That is a work in progress, and your reports help
@eighthave Well, if you think AllowedSigningKeys is the only protection we're using, you're a bit misinformed 😉 Of course we have multiple layers in place, too. But not all binary APK repos have, some are relying on the "built-in protection".
Good to hear you have more layers of verification. I'd like to read about what you're doing, since you've been handling the auto-download of APKs for a long time, so perhaps there is more we could add to `fdroid update`. Could you point me to them? There is a good foundation for us to build on: APK v2+ signatures are quite robust and APK signing keys tend to be quite stable over time. That makes it possible to automate checks so repo operators don't have to know all about signing.
@eighthaveandroid.izzysoft.de/articles/n… outlines several of our layers. And you still have one of our scanners in your issuebot – though for some reason that seems not have to be run anymore for quite a long time (I never saw it in issuebot reports for about 2 years now).
You can find our scanning scripts at gitlab.com/IzzyOnDroid/repo (look at the Readme in the lib/ directory). We plan to make them available as Docker/Podman image, but no ETA yet.
Nachdem der Library-Scanner nun seit mehreren Jahren im IzzyOnDroid Repo im Einsatz ist war es an der Zeit, einige zusätzliche APK-Prüfungen zu etablieren.
indeed AllowedAPKSigningKeys was inspired by the various custom scripts and processes we had in place already. We welcome contributions to improve AllowedAPKSigningKeys. We don't currently have funding to work on it. We would gladly help someone put together a funding proposal to work on it.
@eighthave It's not just about F-Droid and Guardian, Hans. You are promoting fdroidserver for all those decentralized repositories, it's your software. IzzyOnDroid has not a single grant (wouldn't your Mobifree grant cover that?), our team is much smaller than yours (~3 vs ~30) – and not a single one here at IoD is being paid vs. 2+ full-time at F-Droid (we're all doing all this in our spare time, I spend 4+ hours each day after my regular 9h $dayjob for example, not counting weekends. (1/5)
(2/5) Still we tried to contribute in the past, more than once (and also on this issue). Our contributions were refused then. But the patches we speak of are available at the POC, like last time. Feel free to use them, of course! They're working fine with fdroidserver here at IzzyOnDroid 😉
> For more than 14 years, F-Droid has been developing solutions which act as pieces of the alternative mobile ecosystem puzzle. So it was a natural fit for F-Droid to become a contributing partner in the broader Mobifree project.
> Our goal is to help mobile technology evolve to a more healthy state, provide people with concrete new tools and more reliable infrastructure, in order to provide better security and allow users more agency and choice.
"Better security". Should be the perfect fit for a security issue, no? 😉
I'm not sure the point you're trying to make here. EU Horizon grants such as Mobifree are large partnerships between around 10 projects. The work and goals are all nailed down between the partners. These kinds of funds are not free money to spend as we please.
@eighthave I was just wondering, as the corresponding issue carries the Mobifree label. And sorry, we have all hands full with work on IzzyOnDroid – so all we can contribute are those patches, we cannot help you rolling them out at F-Droid.org.
The patches work fine, we use them ourselves. Not sure though how they harmonize with your alternative implementation, which we didn't merge at our end (we use the patches we proposed back then). But we even provide a patch for that variant, please test.
Things with the Mobifree label are things that are being considered as part of that grant. It is definitely not a promise. It is quite likely we will work on AllowedAPKSigningKeys as part of Mobifree, I'd like to, but no guarantees. Currently, I'm thinking of making AllowedAPKSigningKeys only support v2+ signatures, since v1 signatures are deprecated, on their way out, and really overly complicated. I see no sense in trying to build security guarantees on top of them.
@eighthave Thanks Hans! But you are aware that you still have v1-only APKs in the repo, right? Not saying AllowedAPKSigningKeys is active for them. And yes, it's older apps (just random findings). A full scan could reveal them all (we need to do the same here at IoD as well, have that on our list, but we are even more "understaffed" than you and still without any grants).
Since you're investing a lot of effort into AllowedAPKSigningKeys, I highly recommend switching the effort to parsing the signing certificate from v2+ signatures, and away from inspecting the deprecated v1 signatures. Apps with targetSdkVersion 30 or higher entirely ignore v1 signatures, so they are gradually disappearing from use.
@eighthave Isn't that what fdroidserver promises to provide to those using it to maintain a repository? We do not "invest a lot of effort into AllowedAPKSigningKeys" – we simply apply it consequently. Signature pinning is expected to be done by fdroidserver; we *accidentally* found flaws there, we even provided patches which were refused. We still have v1-only APKs as the F-Droid.org repo has them, yes. But we don't write/maintain fdroidserver. Are you saying it is unsafe for use by other repos?
I'm saying v1 signatures should not be something that anyone relies on any more. Our current thinking is to remove support for v1-only signatures from AllowedAPKSigningKeys because of the weakness of v1 signatures means we cannot provide good security, so it would only provide a false sense of security. For distributing v1-only signed APKs, I'd recommend verifying them via an alternate method other than certificate pinning.
fdroidserver is fully safe for the tasks it was built for. It has been independently audited as well (we have two more audits coming up). If you have a trusted collection of APKs, then fdroidserver provides the entry point to a trustworthy pipe to the F-Droid client. It cannot protect against malicious upstreams, upstreams losing their signing keys, etc. It cannot fix the deprecated v1 signatures. Require v2+ signatures, and AllowedAPKSigningKeys works with no known weaknesses.
@mnalis Same as IzzyOnDroid most likely: older apps which have long-time seen no updates anymore. At IoD, we've just removed several of those (which were additionally using weak keys, or had other issues as well), leaving only those in that have strong enough keys etc. Some were left for further investigation, in one case (app still actively maintained) we reached out to the devs asking for additional v2 signing. @eighthave
@eighthave Would it make sense (if those abandoned v1 apps are still useful so should not be archived/removed) to recompile and re-sign those abandoned apps with F-droid.org keys (I'm assuming they're not RB), so people who install them from F-droid these days won't be vulnerable to fake upgrades elsewhere on the net (as I'm understanding is the risk currently)? Or maybe tag them with that "Vulnerable" flag that F-droid apps (esp. browsers) get occasionally?
@mnalis I guess none of us have tried those old ones for RB – and with the projects dead and their devs no longer around, that would not help anyway (as with RB, both F-Droid & IoD would ship the upstream APK, which has that signing issue). Wile at IoD we build apps from source FOR RB, we don't sign ourselves. But (most of) the v1-only apps at F-Droid just needed to be re-signed (adding v2) as they are signed by F-Droid – right, @eighthave ?
Vanavond staan Venus en de maansikkel vlakbij elkaar, een prachtige samenstand. En heel soms passeert er nog een onverwachte bezoeker frankdeboosere.be/nachthemel/j…
Can only recall few software tools keeping backwards compatibility many protocols versions, with forward versions implementations. Then such security new/old reports, unavoidable?
AFAIK still no VSC http3 plugin, and only few for http2 ...While anyone just can test http3 from win/mac/lin shell default curl installs:
Every year, the Dutch government adjusts taxes on electricity, gas, water as well as other things. They publish a table on the official website here: belastingdienst.nl/wps/wcm/con…
On Jan 1, there was no data about 2025 at all. Yesterday, on Jan 2, data appeared, stating the electricity tax to be € 0,10512 per kWh. Today, this number changed to € 0,10154 without any notice of change on that website. 😐
We're going to dive in with more depth on this, exploring why Bluesky's content tools are the second worst we've encountered in a long, rich history of internet censorship (just behind Meta, which are *awful).
Bluesky is a platform which automatically slaps content warnings on posts. It also offers very limited options for putting warnings on your own posts, which look like this.
As you'll see, there's a lot of options for "adult". Which is a *very* loaded term.
Now here's a fun fact: it's not only adults that have vaginas and vulvas. Most of you probably don't need to know this, but about 50% of children have this part of the anatomy, too. And most of these children came out of a vagina. Instagram/Meta is particularly egregious for flagging and shadow-banning anything that even so much as uses anatomically correct language, thus obscuring content which, frankly, young people probably *should* be able to access.
I have a piece of advice for you. If you produce any art, video, or writing that might be considered by the average right-winger to be "pornographic", make sure you have backups of your work. And then make backups of the backups.
SQLite is a remarkable piece of software and I've always been curious about the system and the project. Here are several little known facts about SQLite.
Let’s not fool ourselves, Musk will use all Tesla and X data for his goals in Europe. Every Tesla is collecting video and location information all the time, information that can be (mis)used by Elon . #cybersecurity #privacy #tesla #musk
Finally received the brand new SmartGuard-63A-T0 three-phase 'whole home backup' solution but the box is larger than expected. Also two new SUN2000-12K-MAP0 solar inverters to replace the temporary 17K inverter. It's going to be difficult to fit all this in the remaining space.
The world's richest man has joined a growing chorus of right-wing voices attacking Wikipedia as part of an intensifying campaign against free and open access information. Why do they hate it so much?
The world's richest man has joined a growing chorus of right-wing voices attacking Wikipedia as part of an intensifying campaign against free and open access information.
Sigo insistiendo: Deberían prohibir todo tipo de estufas en la calle. El que tenga frío que venga abrigado de casa. Ya bastante calentamos el planeta como para desperdiciar energía calentando a unos caprichosos.
Las estufas de gas se resisten a desaparecer de las terrazas de Barcelona
Muchas estufas de gas se resisten a abandonar las terrazas de Barcelona. La prohibición municipal de estos dispositivos en vigor desde el primer día del año no se nota mucho en un buen puñado de céntricas calles y plazas.
This is the stuff that's supposed to take over the world. Check out the sound of a crowd of protesters chanting "Black Lives Matter" as brought to you by the inimitable voice of ElevenLabs. Made my day.
even if they did, it would gargle it into something, "ler ler ler heil heil hit!" And then slowly morph the words into, "spler spler style spit!" Somehow repeated feeding of the same input tokens for output creates enough differencials in that output each time that the sound will slowly shape over, and this may actually be a limitation of these multi-LM modals potentially The same way it can't spit exact code back at you when asking for a single change to that code, nope, it'll snoop around and destroy hours of your beautiful efforts if you let it.
the difference is still in RVC vs multi-modal real-time speech and lyrics generation. For simple voice output with multiple sentences it's lesss of an issue as they can either use a pre-created file to RVC and transform the voice into another, or direct TTS without the burden of actually needing to generate the final noise atmosphere and mechanics, which falls more squarely in the territory of general transformer models.
A @Forbes article reveals a Gmail vulnerability @Google has CONFIRMED but WON’T FIX.
Security researchers find that Gemini AI which is integrated into Gmail and other Workspace tools, is susceptible to indirect prompt injection attacks.
So why did Google issue a “Won’t Fix (Intended Behavior)” ticket?
Das sollte man in Bezug auf die Nutzung von kommerziellem #SocialMedia und #Kommunikation nicht unbeachtet lassen, vielleicht auch besonders in #digitaleKirche:
Well, knowing the fact that there's a notification that tells you that Apple will collect audio recordings from Siri, I am not surprised. But yikes. I don't have "Hey Siri" on, but I bought way too many devices in all these years, like more than five. ;)
én azt sajnálom (kis kár örvendéssel), hogy rengeteg ember bújt mögéjük a "Privacy. That’s iPhone" szlogenjük miatt és remélte hogy az érdekeit képviseli a cég, szemben Google-lel.
ezzel most egyértelművé vált hogy nem több ügyes marketing fogásnál, és egy szavát sem lehet hinni a cégeknek, senki nem nézi a vásárlók igényeit és egy "melyik mainstream telefont vegyem" kérdés esetén a személyes igényeken túl nincs értelme moralizálni. (és ezutóbbinak mondjuk eddig sem volt sok értelme)
Agree to disagree. People themselves should be careful what they share. Also, I wouldn't enable hey Siri, I only ask it to go search for my phone because 99%of the time I can't find it. Blind and all that stuff. But honestly, there's no 100%privacy anywhere. Sad fact. That's the world.
@tardis I don't necessary understand your take. on one hand you're pointing fingers at the users they should know better but on the other you're saying there's nothing one can do because everyone will sell their data anyway.
yes, users could educate themselves better how to protect their privacy.
but expecting everyone to question a loud privacy stand from a company when EVERY tech news site announced them as *the privacy hero who protects from evil ads* is a bit of a stretch.
@tardis also, I think "careful what they share" is a very vague exclamation. in general most people don't *share* top secrets from their lives with Siri, search engines, or even during a small talk with their family.
but the problem is **every** part of your life can used against you when a company doesn't respect your privacy. (just think about the wild example of the charged woman (women?) in the US who searched for abortion clinics when the state outlawed it)
I am quite evil, and I don't care enough about the states, sadly. Not a destination in my list. On the other hand, better education about privacy isn't going to be a bad thing. Like I said, no privacy is 100%secured, we'd have to cut ourselves off the internet if we want 100%privacy, even then it's not a guarantee.
@tardis @pcdevil my general takeaway is, even above the privacy topic:
we gave too much power to these companies and most of them are misusing it. Regulations and bans are somewhat hurting them, but It would be better to not give them our money and our data.
That's pretty true, that's no payment, a payment would be an actual fix and actual feedback, and. actual guarantee that won't repeat, but if we're realistic it won't happen. And even if something does happen, people won't be told about it.
@tardis @pcdevil I totally agree that there are not too much to choose from, and I really believe in everyone's right to choose what they want to (based on their focus and needs). But there are some cool projects for smartphones that are worth the look (@GrapheneOS , @calyxinstitute , @LineageOS), and also some great alternative software to use in replacement of the apps and services of the big players.
Yeah, if they are accessible. But they are not. I was thinking of tying half of my family members' eyes and make them all use phones. Real evil, right? Also, do not break my dreams. 100 dollars are enough to travel and pay you all a visit. haha.
Za více než polovinou darů pro Stranu práv občanů – Zemanovce byl provázaný systém firem, které z velké části ovládal švýcarský advokát Fabio Delco. Spojené státy nyní Delca zařadily na sankční seznam kvůli praní ruských peněz.
Jakub Steiner ⭐
in reply to Jakub Steiner ⭐ • • •Should have done these as a thread long time ago. I'm new to this fediverse thing!
#procreate #sketch #gnome #flathub #flatpak #sketchfriday
Jakub Steiner ⭐
in reply to Jakub Steiner ⭐ • • •Starting a new year by almost forgetting to do a Friday sketch. New year resolution is obvious -- skip as few of these as possible!
#procreate #app #icon #sketch #gnome