Google has been getting hammered this year for monopolistic Android practices, yet they still have highly questionable ongoing initiatives.

Their losses so far this year:

• The EU successfully fined them €4.1 billion for anti-competitive practices in Android, including that Google required device manufacturers to pre-install Google Chrome and Google Search as a condition for giving their users access to the Play Store.
• Epic Games successfully sued them over their Play Store practices. This has resulted in upcoming changes in the US that include reduced commission rates and a requirement for the Google Play catalogue of apps to be shared with third-party app stores. Further news broke this week that the proposed settlement between Epic Games and Google was withdrawn, resulting in an additional requirement for the Google Play app itself to host third-party app stores.

Here's some ongoing initiatives I have encountered myself, which could see them back in court:

• Devices without Play Protect certification are unable to attain the MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY labels in the Play Integrity API. This can result in app developers locking out all devices that haven't gone through Google's device certification programme. Thankfully, very few apps are currently requiring MEETS_STRONG_INTEGRITY.
• Google is replacing some CAPTCHA puzzles on websites with QR code scanning. For Android users, the device you scan the QR code with must have Google Play Services installed. So your browsing experience on your laptop is becoming affected by your choice of mobile device. I've encountered this QR code scan requirement once so far.
• Google is bringing in a requirement that Google-certified Android devices must only allow app installs from developers who have gone through Google's Developer Verification programme. This includes apps installed from third-party app stores. Most devices are Google-certified so they can give Play Store access to their users, but soon that same certification will lock out developers who have rejected Google's verification process.

I don't like how Android has been a treasure trove of user data for Google, and I also don't like when security features have a dual purpose of monopolising. In the past, we might see these initiatives and hope they are for our benefit. But now we have strong evidence from the courts that Google's past actions haven't put Android users and developers first. This is a strong motivation for engineers to contribute to the software ecosystem of de-Googled Android, including projects like GrapheneOS, F-Droid, Accrescent, and Obtainium.

Historically, the open-source projects that had the strongest level of maintenance were packages and infrastructure. Companies that have lots of money and engineers depend on those, and some of these companies have provided funding for maintainers and dedicated their engineers’ time toward contributions.

However, apps have been a different story. As apps aren’t critical to companies’ bottom lines, they haven’t received the same level of funding and support. This made app maintenance difficult to sustain, as they often had underfunded solo maintainers, and would-be contributors didn’t have enough time to meaningfully help out.

The LLM boom hasn’t helped much with this yet, as slop contributions have caused maintainers a lot of headaches. But I think the ecosystem will learn to filter out the slop soon, and then the new era of LLM-assisted gains for open-source will begin.

While LLM-enabled maintainer productivity gains will be impactful, I see the following as a more fundamental change: engineers who use the apps will be able to make meaningful contributions without dedicating an unsustainable amount of their free time. I think this can result in open-source apps becoming highly competitive with the for-data apps that have historically required full teams of engineers.

Many of us have had a deep appreciation of open-source for years, but haven’t had enough time to consistently contribute. I’ll be helping with security and privacy. What will be your contribution?

Yesterday I attended the Neocypherpunk Summit in Berlin with hundreds of people from various backgrounds who all care about the human right to privacy.

The term “cypherpunk” used to refer to extremely technical lone wolves who dedicated their lives to privacy. Thankfully, it has now evolved into a movement where anyone who cares about privacy is welcome, no matter their background. In one day I heard talks from human rights organisations, activists, engineers, academics, and philosophers.

People care about privacy to differing degrees and for various reasons. Some people need to protect their safety, some want to chat with their loved ones in a safe space, while others simply don’t want their data to enrich a tech oligarch who they don’t trust.

Privacy doesn’t mean isolating yourself from society, it is about the right to choose what information you share with whom. Yesterday was the opposite of isolation, with hundreds of people making friends, sharing ideas, and feeling inspired.

Whatever your reason, if you feel a bit uncomfortable about where your data flows behind your back, feel free to message me and we can come up with something small you can do today. It’s usually as simple as replacing one of your apps with another that has the same features, but is more secure. It feels empowering!

At Breaks & Ciphers I’m building a secure open-source tasks app. Our day-to-day tasks are some of the most valuable data points to creeps, so I think we should protect them.

I intend to use this as a testbed for what the state of the art is in building, testing, and deploying applications when security and privacy are uncompromising goals.

This may have some measures that seem extreme for a tasks app, but the underlying purpose of this project is to push open-source security and privacy forward. I hope to find where these are most difficult to achieve for maintainers, and publish research and tools to fill these gaps.

Some of the early security design investigations I’m doing are:

• Using Rust + FFI vs app development languages like Kotlin/Swift
• Using cross-platform frameworks vs per-platform development
• Peer-to-peer sync / backup options
• Where to use formal verification

As references, I’ll be comparing other apps that are known for their security:

• Signal
• GrapheneOS's built-in applications (SMS, PDF viewer, etc.)
• Bitwarden
• Apps recommended by Privacy Guides

Let me know if there’s a different app you consider to be the gold standard in secure development!

It’s currently too hard for users and developers to figure out which open-source software is secure and trustworthy.

The most prominent assessment tool I’ve found is OpenSSF Scorecard, which assesses projects for security risks through a series of automated checks, assigning each project a score out of 10.

Unfortunately, it hasn’t proliferated enough yet. Most users have never encountered Scorecard, so it doesn't affect their choices. And if it doesn’t directly affect weekly downloads or clout, most maintainers aren’t incentivised enough to adopt it. Scorecard also isn’t a fully comprehensive security assessment.

Whether it’s Scorecard or something else, I do believe automated assessments have strong potential. At Breaks & Ciphers I’ve been considering some features that could result in a successful movement:

• Fact-checking: a trustworthy assessment can’t currently be achieved solely through static checks or AI (hallucinations, prompt injections). There need to be incentives designed to encourage fact-checking or approval of automated results, similar to X’s Community Notes feature.
• Stages instead of scores: a scoring system may be too daunting for maintainers if their projects start out with very low scores. One alternative I like is a stage-by-stage framework, where projects work their way up through several security and trust model stages over time. I saw the effectiveness of this approach in the L2BEAT initiative, and there is a similar Walletbeat initiative in beta. Perhaps we need a Softwarebeat.
• Inform the user: the security and trust status of the project needs to be shown clearly in GitHub, app stores, and package providers. Otherwise users and developers won’t hear about it, and maintainers won’t care about it. Even if we can’t get GitHub or Google Play onboard at the beginning, we could demonstrate the effectiveness by achieving integration in smaller platforms, such as the Obtainium APK installer.

I want to live in a world where the software we use is highly secure, including security against mass surveillance by advertising agencies and intelligence agencies. I don’t believe this will happen if the software we use daily continues to be owned by companies whose primary incentive is to maximise shareholder value. I believe this is achievable through open-source software, now more than ever before, because today’s engineers can build good software on much tighter resources.

There was once an implicit deal between society and big tech: we give you our data, you provide us with great free products, good jobs, and positive economic impact. Whether through greed or other reasons, big tech has betrayed this deal. Products become worse for our health to maximise profits (slot machine algorithms, AI slop, TikTok-like videos). Job cuts are encouraged in favour of centralised AI. Wealth doesn’t trickle down effectively, and the divide seems to be accelerating.

On the surveillance side, whistleblowers and leaks over the years have demonstrated how some states are willing to violate the privacy of innocent people across the globe via software exploits and backdoors. The current geopolitical climate leads me to believe we may see further steps backward in this area. As a citizen of a neutral country, Ireland, I think it's completely reasonable to demand the ability to verify that the technology I use does not contain backdoors or vulnerabilities accessible by foreign states.

At Breaks & Ciphers, we will do consistent work toward regaining our security and privacy. We will analyse trust models deeply to provide recommendations on which software to use, along with how we can improve these trust models over time. We’ll make contributions and security improvements to open-source projects. We’ll produce new open-source projects when necessary.

While the need for Breaks & Ciphers comes from quite a sad state of the digital world, I don’t see the road forward as a lonely, dark path. I see it as a hopeful path where the thousands of engineers, researchers, journalists, activists, lawyers, communities and organisations who have fought for people’s digital sovereignty can win. And we’re going to have tonnes of fun and fulfillment along the way.

For examples of software to be optimistic about, think of Signal, GrapheneOS, Tor.

But I’m not recommending these yet, you’ll need to wait for the research!