F-droid's vulnerability scanner automatically identified a known vulnerability in the Simple File Manager app, It was in the PDFium library and the developer has been notified about it - https://github.com/SimpleMobileTools/Simple-File-Manager/issues/656

The vulnerability could be exploited with a .pdf payload.

Meanwhile the app is available in Google Play Store, Aren't play protect supposed to identify the vulnerability as well?

P.S. I have deep respect simple tools, for building high quality FOSS android apps.

File folder icon.

Text reads "We found a vulnerability with Simple File Manager Pro. We recommend uninstalling this app immediately."

Two buttons with "Ignore" and "Uninstall" label.

considered harmful.


by @Pwnallthethings via @evacide

"it’s not safe to use Telegram for chats and calls. Anywhere. For anyone. But especially in Ukraine.

"WhatsApp, iMessage, and Signal all take user security far more seriously...

"If Ukrainian saboteurs in an occupied region are the only ones using, say, Signal or WhatsApp, that itself becomes a red flag for Russian occupiers. Other people need to switch too"


Wait, what?… you don’t mean that your all-important secret for your Small Web site is going to be… A STRING OF EMOJI?!*

(Why yes, yes it is…) :awesome:

  • Or, if you want to take all the fun out of it, a base256 encoding of your ed25519 private key that is purposefully impractical to write down somewhere or type in so you’ll be forced to practice good security hygiene and store it in your password manager.

Wait, what?… you don’t mean that your all-important...

Here's something to try for encrypted messages from Mastodon - Convene is encrypted, self-destructing group chat in any browser built on @matrix by my team @guardianproject - it is like JitsiMeet+CryptoCat with a beautiful, usable interface. Make a room, share a link, easy peasy... i'm giog to hang out in this room for a bit: https://letsconvene.im/app/#/room/%23mastodonencryptedchatdemoroom%3Aneo.keanu.im


ATTENTION EVERYONE WRINGING THEIR HANDS OVER “#MASTODON ADMINS CAN READ MY DIRECT MESSAGES”: have always been able to read your and DMs unless encrypted, including at the big and Internet providers. We used to have t-shirts that said, “I READ YOUR EMAIL.”

It’s just hitting now because you got used to places where the admins were kept away in their cubicles and data centers instead of greeting you at the front door.

Oh, and , , , etc., all down the line too. Unless they have end-to-end where you and only you have the only private key, it’s not . No exceptions.


ATTENTION EVERYONE WRINGING THEIR HANDS OVER “#MASTODON ADMINS CAN READ MY DIRECT MESSAGES”: have always been able to read your and DMs unless encrypted, including at the big and Internet providers. We used to have t-shirts that said, “I READ YOUR EMAIL.”

It’s just hitting now because you got used to places where the admins were kept away in their cubicles and data centers instead of greeting you at the front door.


Google publishes the source code for their TalkBack screen reader. GrapheneOS maintains a fork of it and includes it in GrapheneOS with the help of a blind GrapheneOS user who works on their own more elaborate fork. Eventually, we'd like to include more or all of their changes.

TalkBack depends on a text-to-speech (TTS) implementation installed/configured/activated. It needs to have Direct Boot support to function before the first unlock of a profile. Google's TTS implementation supports this and can be used on GrapheneOS, but it's not open source.

We requested Direct Boot support from both prominent open source implementations:

RHVoice: https://github.com/RHVoice/RHVoice/issues/271
eSpeak NG: https://github.com/espeak-ng/espeak-ng/issues/917

eSpeak NG recently added it but it's not yet included in a stable release and their licensing (GPLv3) is too restrictive for us.

RHVoice itself has acceptable licensing for inclusion in GrapheneOS (LGPL v2.1), but has dependencies with restrictive licensing. Both these software projects also have non-free licensing issues for the voices. Neither provides close to a working out-of-the-box experience either.

Google's Speech Services app providing text-to-speech and speech-to-text works perfectly. Their proprietary accessibility services app with extended TalkBack and other services also works fine. However, many of our users don't want to use them and we need something we can bundle.

There aren't currently any usable open source speech-to-text apps. There are experimental open source speech-to-text implementations but they lack Android integration.

We also really need to make a brand new setup wizard with both accessibility and enterprise deployment support.

GrapheneOS still has too little funding and too few developers to take on these projects. These would be standalone projects able to be developed largely independently. There are similar standalone projects which we need to have developed in order to replace some existing apps.

AOSP provides a set of barebones sample apps with outdated user interfaces / features. These are intended to be replaced by OEMs, but we lack the resources of a typical OEM. We replaced AOSP Camera with our own app, but we still need to do the same with Gallery and other apps.

Google has started the process of updating the open source TalkBack, which only happens rarely. We've identified a major issue: a major component has no source code published.


Google has been very hostile towards feedback / contributions for TalkBack...

This is one example of something seemingly on the right track significantly regressing. Another example is the takeover of the Seedvault project initially developed for GrapheneOS. It has deviated substantially from the original plans and lacks usability, robustness and security.

In the case of Seedvault, GrapheneOS designed the concept for it and one of our community members created it. It was taken over by a group highly hostile towards us and run into the ground. It doesn't have the intended design/features and lacks usability, security and robustness.

All of these are important standalone app projects for making GrapheneOS highly usable and accessible. What we need is not being developed by others and therefore we need to the resources including funding and developers to make our own implementations meeting our requirements.

@jascha That's true. Cisco, fortigates, sonicwalls, mikrotiks.. Even for personal use I recommend cheap tp-links with instead stock firmware for better .


Rosjanie płacą $2,5 mln za działające exploity na Androida. I $1,5m za Signal. To znacznie więcej niż 'konkurencja'. Widaś, że im na czymś zależy. Pytanie na czym. Taki zestaw może być stosowany do komunikacji rządzu/wojska Ukrainy. Klienci: wyłącznie rosyjscy, prywatni i rządowi, co do tego jest jasność. https://twitter.com/lukOlejnik/status/1593688899347521543
Szukają też metod hakowania stacji ładowania pojazdów elektrycznych. Tutaj nie podano cen. Dlaczego ktoś miałby chcieć to hakować?


Rosjanie płacą $2,5 mln za działające exploity na...

@prywatnik to , a z drugiej strony nie trzeba za dużo się wysilać i stosować exploity na userland - w naszym kraju inwigilacja jest na dość wysokim poziomie (co np. pokazują raporty panoptykonu), zatem np. każdy komunikator zakładany na numer telefonu nie jest idealnym pomysłem pod kątem. Taka cena exploitów to raczej też norma (ostatni z głowy przykład tej samej grupy docelowej i podobnej ceny to proftpd ftp.bbc.co.uk).
Nie politykując, łatwo sprawdzić która grupa docelowa jest mniej zależna technologicznie i która rozwija swoją niezależność i jakie są tego efekty. Pytanie - gdzie jesteśmy my?


After my discussion with @myraccoonhands today around why traditional aren't good at app security/CI-CD/etc... and why we're not pushing for it more heavily in our orgs, I decided to get right. And get myself into a better position with Docker, , , , , and a few others.

seemed like a good place to start and I was excited for the tip of the day to be an introduction to the docker sbom command which can give you a software bill of materials for images being used!

Check it out here:

I have just completed a testing project on a very interesting set of proprietary devices:

  • Bluetooth Low Energy (BLE) is a whole separate ecosystem of protocols with very interesting physical engineering properties. Using a BLE sniffer such as Ubertooth suddenly discovers a whole invisible world of BLE devices talking to each other in your neighbourhood, I guess some of them at hundreds of meters away.
  • I like BLE security design. It’s pretty reasonable, based on pretty good cryptographic protocols and pretty safe defaults. The core principle however that makes things much easier for designers is TOFU (trust on first use), which results in a paired device basically refusing to talk to anyone else.
  • This “pretty good” above is not merely a figure of speech. Yes, BLE protocols can be screwed up, used incorrectly or totally opened up, but when compared against protocols such as incompetently used RC4 in WiFi’s WEP encryption, the design and defaults are… pretty good.
  • On top of that physical layer there’s a whole lot of new communications protocols such as COAP, which is a low-power equivalent of HTTP, with new low-power cryptographic protocols such as EDHOC, OSCORE which have fundamentally different usage scenarios and design principles than HTTP and TLS as we know them.

The project involved lots of learning and had some interesting findings. The main issues found were, as usual, in vendor SDK libraries which exposed poorly documented default functionality that the product designers weren’t really aware of. But that’s what is for.


More random thoughts:

  1. Mastodon is pretty chill but expect a surge of troll activity with all the attention. Nothing is totally immune to the challenges associated with attention/scale.
  2. Try to be open to new followers but check them out - Who do they follow? Who follows them?
  3. Block quickly at any hint of malicious behavior/hate/trolling. Don't engage. Keep the vibe positive.
  4. If you see patterns of abuse share that information with your followers.