René Mayrhofer :verified: 🇺🇦

Prof. for networks and security at #JKULinz, formerly leading Android platform security at #Google. This account will mostly carry IT security stuff, occasionally politics and other comedy.

Screeching voice of the minority. I will not cooperate with fascists or nazis - traditional or neo; Austrian, German, US, Russian, or otherwise. I will not help build surveillance and oppression states. Never again.

"I need privacy, not because my actions are questionable, but because your judgement and intentions are."

Statements are only my own opinion, not my employers'.

This is currently my primary infosec account in the #Fediverse. It should be #searchable through https://tootfinder.ch. Previous Twitter posts are available in archival form at https://twitterarchive.mayrhofer.eu.org/.

Homepage: https://www.mayrhofer.eu.org
University: https://jku.at/ins

Last Notes

2026-06-09 20:42:18 UTC

I'm leaving #Google: https://www.mayrhofer.eu.org/post/leaving-google/
While I believe that I have been able to do some good with my continuing (part-time) engagement in the Android security and privacy team since returning to Austria a couple of years ago, the deal with the US #DoW is completely misaligned with my personal ethical principles. I will, therefore, no longer be able to act as a contact point to Google-internal teams and discussions, but will continue our research on private digital identity, end-to-end secure communication and storage, network privacy, (embedded/mobile) operating system security, supply chain transparency, etc. from a purely academic point of view. Android - and in particular AOSP - will remain a research interest, so please feel free to reach out on any of those topics for potential collaborations or discussions on the academic side.

2026-04-19 10:05:32 UTC

On a train to #Dagstuhl, I finally got to read the nice write-up about on-device local-web-to-app tracking: https://localmess.github.io/assets/bridges-to-self-localmess-usenix-security-26.pdf
TL;DR summary: You might want to uninstall (or deactivate if pre-loaded) all #Facebook and #Yandex apps from your phone. That kind of behavior is pretty clearly malicious - not even just ethically wrong, but seems actually illegal (at least in the EU, though IANAL).

2026-03-24 20:47:14 UTC

I just learned that a new release of the decentralized, open source Android (and iOS, but that requires a centralized Apple service) key attestation library warden-supreme has landed. It explicitly supports alternative/custom roots of trust for the attestation chain now and comes with a test for @npub1kwa…e0nj keys: https://github.com/a-sit-plus/warden-supreme/blob/development/serverside/roboto/src/test/kotlin/GrapheneOsTests.kt
Nice! That's a good match to our academic research direction on digital identity (https://digidow.eu) - avoiding points of centralization for better resilience (against many types of threats). We'll most probably use this for our prototype Android apps that require or benefit from key attestation guarantees and can't/shouldn't use Play Integrity (e.g., because they only communicate over Tor hidden services with each other, and having a Warden backend included on one side is much easier than coming up with a form of mixnet proxy service for querying central instances while retaining an unlinkability guarantee).

2025-11-08 23:25:44 UTC

The #KeepassXC discussion about GenAI coding tool use seems a bit too simplistic at the moment.
There is room for nuance:
1. Yes, LLM based code generators consume insane amounts of electricity and generate collateral environment damage. That's bad, and we should talk much more about energy efficiency and reasonable use of resources.
2. Yes, LLMs generate a lot of bad output that should never ever be used without cross-checking for any purpose that needs to work on facts instead of convincing fiction.
3. No, using LLMs for coding work does not automatically mean all the resulting code (at the end of a multi-stage process) is bad or insecure. If the generated code is manually verified by human experts, that is not much different from code contributed by junior developers in such a domain. They also make mistakes and might not have the right mental model when writing code. That's why production code - especially with security impact - *strictly requires* code review by senior developers. I still trust @npub16s6…2ny3 developers to do that based on their track record.
4. I have used LLMs for quicker coding myself, but so far only as autocomplete++ when I know the program structure I want to achieve and get some help for language syntax and standard libraries that I am not completely familiar with (hello to Rust...). However, I always review every single line of autocompleted code, and often correct/change it.
5. With some of the recent research and industry practice I have seen, specific aspects of programming might actually be candidates for benefitting from LLMs as a tool because those tasks fall into the one niche problem category for which I believe these tools to help *and* where they can be used with limited risk: a) the problem domain actually being textual languages; b) with a huge potential solution space; c) coupled with the possibility for automated verification of the solution quality. LLMs can be used to generate solution *candidates* (potential source code) which are then rigorously checked (automatically through strongly-typed compilers, fuzzing, extensive unit and integration tests, etc., and manually through code reviews).
6. It seems to become realistic to use much smaller, locally hosted LLMs instead of huge, cloud hosted ones. Yes, the quality difference is significant at the moment. No, that does not have to stay that way.
While I personally remain quite skeptical about the benefits/risk balance of LLMs for many of the use cases they are currently applied to, I am going to watch this particular one very closely in the near future.

2025-10-31 17:50:39 UTC

- reply

I could not in good conscience recommend Netgear at this point, both in terms of hardware longevity and security track record. #OpenWRT is a good pick on devices that support it or come natively with it like @npub16u6…33yx. If open source is not a priority but networking flexibility is, then @npub1lu0…q9t4 are fairly impossible to beat in terms of features-per-pricepoint (and support old hardware with #RouterOS for basically forever). None of these require cloud registration, of course.

2025-09-19 18:26:27 UTC

- reply

Are OEMs classified as gatekeepers? Because they decide what goes into the system images.
@npub158w…p2m9

2025-09-19 18:16:07 UTC

- reply

Uninstalling is indeed technically impossible if an OEM bundled the app into any of the (read-only, compressed, integrity protected) system/OEM/vendor partitions. Disabling is functionally equivalent with the only exception of the storage space not being freed.
So the real option is only for OEMs not to pre-install these apps in the first place, but potentially only during first setup wizard.

2025-05-16 15:14:57 UTC

- reply

I have been running my own personal/family email server since over 25 years ago and recently migrated from my last custom postfix/dovecot/rspamd setup to @npub1zq8…44y6.
Yes, occasionally Gmail erroneously puts my whole domain in a block (not even marking as spam, but SMTP receipt blocking) and I have to wait for months for it to be lifted again. And let's best not talk about the various kinds of Microsoft email badness. #JKU has been running a local email service for even longer, and it still very much works. All the issues caused by big centralized email hosters are even more of an argument to keep servers decentralized and federated than to give up, from my point of view...

2025-05-16 06:40:01 UTC

Email is critical infrastructure in today's digitalized world. Relying on foreign hosting is not a good idea for anybody at risk of political interference because of their profession.
Hosting email locally is still very much possible, even if it gets more involved year of year. Email is the one federated protocol that we have for direct communication. Even with all of its deficiencies in security and privacy, it is the common denominator that connects people. Don't give up control over your own, most basic digital communication channel. Use local hosting companies that you can still call in an emergency, ideally within your own (maybe extended, like EU level) jurisdiction.
Context: https://eupolicy.social/@bert_hubert/114511178410991783

2025-05-05 15:02:20 UTC

I co-signed this open letter (https://edri.org/our-work/technical-experts-call-on-virkkunen-for-a-seat-on-the-table-european-commissions-technology-roadmap-on-encryption/) from the academic side because I (still) do not believe that #messenger #surveillance (aka #chatcontrol) can be done in a safe manner. While the goals - at least as worded, maybe not always as intended - are worthwhile, the proposed measures simply do not work on a technical level, and laws cannot change that reality.

2025-04-13 08:18:37 UTC

If you are an #academic in the #US with a position comparable to tenured or associate professor and a solid research track record in a field related to computer science (treat this in a very broad manner) and are interested in relocating to beautiful, liberal, safe, #Austria, then please reach out to me. We'd love to welcome new colleagues in the Austrian academia!
A couple of us are collecting profiles to potentially match with organizations that are looking to fund such opportunities. Full caveat: I don't yet have concrete positions confirmed, but am trying to get the funding bodies into position to do so.
Please boost!

2025-04-09 08:12:52 UTC

Sigh. We are, as a security community, making good progress on some old as well as some new topics. #Rust, #Go, and other memory safe systems languages are going well and having a real impact in reducing memory safety issues - which has been the most important security bug class for decades, and we are finally improving! Compartmentalization and isolation of processes and services have now become common knowledge and the minimum bar for new designs. Security and privacy by design are being honored in many new projects, and not just as lip service, but because the involved developers deeply believe in these principles nowadays. #E2EE is finally available to most end-users, both for messaging and backups.
And again and again, we are forced into having discussions (https://www.theregister.com/2025/04/03/eu_backdoor_encryption/) about breaking all the progress.
Let me be clear for Nth time:
* We *cannot* build encryption systems that can only be broken by the "good guys". If they are not completely secure, foreign enemy states, organized crime, and intimate partners will break and abuse them as well. There is no halfway in this technology. Either it is secure or it isn't - for and against everybody.
* We *cannot* build safe, government-controlled censorship filters into our global messaging apps that are not totally broken under the assumption of (current or future) bad government policies and/or insider attacks at the technology providers (https://www.mayrhofer.eu.org/talk/insider-attack-resistance-in-the-android-ecosystem/). Either one-to-one communication remains secure and private, or it doesn't (https://www.ins.jku.at/chatcontrol/).
* We *cannot* allow exploitation of open security vulnerabilities in smartphones in other devices for law enforcement. If they are not closed, they are exploitable by everybody. "Nobody but us" is an illusion, and makes everybody less secure.
My latest recorded public talk on the topic was https://www.mayrhofer.eu.org/talk/secure-messaging-and-attacks-against-it/, and nothing factual has changed since then. Policymakers keep asking for a different technological reality than the one we live in, and that sort of thing doesn't tend to produce good, sustainable outcomes.
CC [@epicenter_works](https://chaos.social/@epicenter_works ) @npub1w4r…8cxz [@suka_hiroaki](https://chaos.social/@suka_hiroaki ) @npub13td…njnt [@matthew_d_green](https://ioc.exchange/@matthew_d_green ) @npub1qda…wevs

2025-03-26 14:21:33 UTC

It is pretty much certain that, given the current situation, I - and supposedly many others - won't be traveling to the US this year. This means not being able to attend 3 out of 4 of the main academic security conferences, because they all keep refusing even to consider moving outside the US. Looking at you, @npub1a39…n3y2, @npub1lq0…0y9k, and @npub1grf…9wxf.
It is clear that this is hurting the global security research community. We need to talk about major conferences outside the US to again become more inclusive.

2025-02-27 15:52:11 UTC

Because <reasons> in #Austria right now, we seem to again have the debate about "chat surveillance" (#chatcontrol) on the (newly forming) government level...
The arguments and facts have not changed, so I am just posting my last public presentation slides [https://www.mayrhofer.eu.org/talk/secure-messaging-and-attacks-against-it/2024-08-29_Secure-Messenger-Attacks.pdf] and recording [https://media.ccc.de/v/26cd6d27-247f-5cf3-8adb-54c87bc372b2] again. Oh, and https://www.ins.jku.at/chatcontrol/ is still unchanged as well.
To our new (and old) policymakers: Maybe read/listen and then we can happily talk efficiently about any new ideas that might come up?
CC [@epicenter_works](https://chaos.social/@epicenter_works ) [@suka_hiroaki](https://chaos.social/@suka_hiroaki ) @npub1vmg…yk7t [@isec_tugraz](https://infosec.exchange/@isec_tugraz ) @npub1p2p…hjzg

2025-02-05 14:15:45 UTC

Google owner drops promise not to use AI for weapons
https://www.theguardian.com/technology/2025/feb/05/google-owner-drops-promise-not-to-use-ai-for-weapons
> Alphabet guidelines no longer refer to not pursuing technologies that could ‘cause or are likely to cause overall harm’
https://media.infosec.exchange/infosec.exchange/media_attachments/files/113/951/699/432/436/491/original/d26a4ddfe99cc194.png

2024-08-31 11:01:52 UTC

I did a talk at #hackmas on "Secure Messaging (and attacks against it)" and the great organization team has already put the video recording online at
https://media.ccc.de/v/26cd6d27-247f-5cf3-8adb-54c87bc372b2. Many thanks to the audience for so many insightful questions and discussions - it is rare that the audience is so engaged and aware of nuance! Slides are available at https://www.mayrhofer.eu.org/talk/secure-messaging-and-attacks-against-it/
Abstract: Secure messaging apps are one of the most-used app categories on current mobile devices, and a significant subset of human communication is handled through them. This makes them an interesting target for forensics, surveillance, and general information collection for intelligence services and police institutions. In this talk, we will discuss various options for such surveillance and their respective difficulties, pointing out which options do not seem realistic given all the practical considerations.
TL;DR: There is no good option for surveiling E2EE messenger apps; all of them are broken or practically unrealistic in various ways. I don't see an option to do that without real, significant problems that make all of us less safe. Please stop claiming that it is possible without these nasty issues.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/113/056/292/041/282/310/original/754cf6ed7842109e.png