Background

It’s been quite a while since I thought about my old friend EncryptedSharedPreferences 😅

Like most Android developers, the relationship I had with EncryptedSharedPreferences was a complicated one. It was a library that initially saw a flurry of excitement, support and adoption, then over time faced a slow and gradual demise with minimal updates, a lack of official guidance, and a whole heap of frustration from the library’s consumers as the updates slowly dried up.

Finally, after what felt like an eternity, the most recent updates eventually brought some clarity via a long-overdue deprecation. But, this left many devs confused at what, if anything, would or should replace it!

Securing the Future: Navigating the deprecation of Encrypted Shared Preferences

I’ve written and spoken about this saga several times before, most recently back in May 2024, and to the best of my knowledge, that was when the story had its final chapter all wrapped up. I was quite wrong 🙃

This post explores the interesting and quite surprising development of encryption support being added within AndroidX DataStore 1.3.0-alpha07, how it works, why it exists and if it’s the right tool for your apps.

I apologise, I have a lot to say. So, get nicely caffeinated and let’s dive in✨☕️

What’s New: A case of Déjà vu!?

As part of AndroidX’s regular release cadence, AndroidX DataStore 1.3.0-alpha07 was recently launched on April 11th 2026, with the following noteworthy extract contained within its release notes:

Encryption Support: Introduced the new androidx.datastore:datastore-tink artifact which provides support for encryption of your datastore using the Tink library

For the sake of brevity, I will assume you are generally familiar with DataStore and how it works. However, if you aren’t, the official docs are a great place to get caught up.

The new androidx.datastore:datastore-tink dependency exposes the AeadSerializer class, which is created by wrapping an existing Serializer instance used to handle the read/write operations. During write events, the plaintext data is encrypted by AeadSerializer utilising Tink's Aead (more on that shortly!) with the encrypted bytes of the ciphertext being then passed to the existing Serializer to consume. During read events, the AeadSerializer uses the Aead and decrypts the encrypted ciphertext bytes read from the wrapped Serializer back to the original plaintext.

The example code below is lifted directly from the release notes and shows the minimum code required to use AeadSerializer in its current initial alpha release¹.

val keysetHandle =
    AndroidKeysetManager.Builder()
        .withSharedPref(applicationContext, "keyset", "keyset_prefs")
        .withKeyTemplate(KeyTemplate.createFrom(PredefinedAeadParameters.AES256_GCM))
        .withMasterKeyUri("android-keystore://master_key")
        .build()
        .keysetHandle

val aeadSerializer = AeadSerializer(
    aead =
        keysetHandle.getPrimitive(
            RegistryConfiguration.get(),
            Aead::class.java,
        ),
    wrappedSerializer = SomeExistingSerializer,
    associatedData = "settings.json".encodeToByteArray(),
)

val dataStore = dataStore(
    fileName = "settings.json",
    serializer = aeadSerializer,
    scope = scope,
)

But how does this actually work? 🧐 Under the hood, the cryptography is achieved via Tink’s Authenticated Encryption with Associated Data (AEAD) primitive, a widely adopted, industry-standard approach that combines encryption and integrity protection into a single operation.

In short, this works great for this use case as AEAD ensures that data remains confidential while also guaranteeing that neither the encrypted content nor any related unencrypted metadata, known as ‘associated data’, has been modified. It does this by producing an ‘authentication tag’ that is cryptographically bound to both the ciphertext and the associated data, allowing the verification of their integrity before decryption. If any part of the input has been altered, verification fails, and the data is considered tampered with.

Of course, this is a huge simplification². But, in fairness, I am not a cryptographer! 😅 Nevertheless, the takeaway here is we should sleep easier knowing the approach taken looks to be a solid one!

But, and you must forgive me, this all feels a little bit too familiar. Our old sidekick EncryptedSharedPreferences also utilised Tink under the hood, including Aead, but then suffered from years of sporadic updates to bump Tink, which led to an eventual downward spiral to what could only be described as “abandonware” status.

“Well, what’s different this time?” I rightfully hear you cry…

Why is this library needed?

It’s worth reminding ourselves that this is the very first alpha release of this new capability, so naturally, several unanswered questions will likely become clearer as time progresses.

At this time, the burning unanswered question is what the primary use case for this functionality is considered to be. In a past life, I used EncryptedSharedPreferences for a fintech application to ensure we met certain compliance regulations, and this feels like one of the small number of potential ‘valid’ use cases that I can personally envision. I’d certainly be interested to see what the AndroidX team considers a valid use of this library 😎

I think it’s also noteworthy that with 950 “+1” votes, the closed feature request for the addition of encryption was DataStore’s single most popular item within Google’s issue tracker by a significant margin. However, I suppose that’s slightly less impressive when the request had itself been open for 5½ years 🙃

So, was this just a case of ‘giving the people what they want’ or is there another motive behind this addition? That remains to be seen at this stage, but I am certainly excited to find out more as future releases become available.

For full transparency, I did reach out (via a mutual connection) to one of the authors of the new code to hear their perspective, but they have yet to respond as of the time of writing. I will add an update here should that change 💪

Sure, but is this functionality for me? 🫣

The TL;DR is probably not.

As of Android 10, file-based encryption is enforced at the OS level, and Android’s app sandboxing model ensures that, under normal conditions, one app cannot access another app’s files, including DataStore, Preferences, etc. Therefore, to compromise such files, it likely would require extreme measures such as physical access to the device, rooting the device, or having malware present in order to do so. These sorts of attacks are extremely difficult to pull off successfully, and unless you are working on a high-risk application with the highest level of scrutiny placed on your app’s security, I would argue it’s more than likely encrypting your DataStore’s contents is overkill and probably unnecessary.

That said, an obvious counterargument would be something akin to “it’s improving the overall security of my application”, which at first glance feels like a valid position.

However, as it was with EncryptedSharedPreferences, I still believe my primary reservation with these encrypted persistence APIs is that their existence often inadvertently encourages developers with a poor understanding of mobile security to store sensitive data on-device rather than guiding them to consider whether it should be stored at all.

Please, please, please stop storing sensitive data on-device 🙏
- Me, Literally all the time

It should hopefully go without saying that, whenever possible, storing sensitive data should always be avoided on-device. Therefore, creating APIs that make violating this principle trivial feels like a step in the wrong direction (at least to me). This is also especially true if said APIs are available without the associated documentation needed to advise developers of the dangers of storing sensitive data.

EncryptedSharedPreferences was super guilty of this, but let’s wait and see if androidx.datastore:datastore-tink falls foul as well 😬

Conclusion

While my thoughts on this new API may seem a tad pessimistic, I am aware that at this early stage, there’s plenty of scope for significant change.

For some developers, this addition will be fantastic news as the void left by EncryptedSharedPreferences ‘s departure is now seemingly being filled with an officially maintained alternative.

However, I hope the AndroidX team uses this opportunity to not only provide the missing value that EncryptedSharedPreferences enabled for the small number of legitimate use cases where encrypting DataStore data makes sense, but also make a huge effort through documentation in educating the majority of users where it doesn’t.

But with that all being said, I am reminded of a famous quote that captures my initial thoughts rather more succinctly

Those who cannot remember the past are condemned to repeat it
- George Santayana, The Life of Reason, 1905

I am quite hopeful and quietly confident that this can and will be a change for good, and the harsh lessons the EncryptedSharedPreferences saga taught us has been learned from. But I suppose in reality, only time will tell 🤞

Let me know if and what you plan to use androidx.datastore:datastore-tink for 💪 Happy data-storing!

Thanks as always for reading! I hope you found this post interesting, please feel free to contact me with any feedback at @Sp4ghettiCode and don’t forget to clap, like, share, star etc — It really helps!

Footnotes

[1]: This API may change significantly. Please check the release notes for the latest docs
[2]: Here’s a great blog post by Adolfo Ochagavía to learn more about AEAD ✨

Prologue

こんにちは and welcome! 👋

Before we dive into this article, we need to quickly discuss the Japanese language. Why? Well, that will all become apparent shortly!

For some context, over the last 12 months, I have slowly been learning Japanese. It’s been an incredibly rewarding experience, but one that has been no easy task for someone who never really mastered English (despite being born and raised in the UK 😅).

Unlike English, which uses a single character-based alphabet, Japanese has three main writing systems. These all have slightly different purposes, and a simplified overview of this is as follows:

• “Hiragana” which is commonly used for Japanese words and has symbols (known as kana) that represent specific syllables
   — e.g. いぬ — pronounced ‘inu’, meaning dog 🐶
• “Katakana” which is commonly used for ‘loan words’, i.e. words borrowed from languages outside of Japanese. It is similar to hiragana in that it shares the syllables it represents but uses different kana.
   — e.g. ホットドッグ — pronounced ‘hotto doggu’, meaning hot dog 🌭 ¹
• Finally, you also have “Kanji” which, as the odd one out, is derived primarily from Chinese characters. A single kanji symbol can represent an entire word or a concept, while multiple can represent a lot of information all in a very small text footprint. In fact, there are around 50,000 kanji, and even the most literate Japanese speakers know a mere fraction of them! As a novice Japanese student, these are what keep me up at night 🥲
   — e.g. 犬 — pronounced ‘inu’ which, as you now know, means dog 🐶

Given kanji can often be difficult even for native speakers, in certain settings, you will often find they are written down with their pronunciations in hiragana annotations above each symbol.

This concept of showing these annotative pronunciations is known as Furigana in Japanese and ruby characters more generally within typography. Pretty useful right?! We’ll come back to this 😌 ²

Moving on, the other interesting (and relevant) fact about Japanese is, like English, it is commonly written and read horizontally left-to-right but depending on the context and medium, can be written vertically where it is then read in the opposite right-to-left direction.
This vertical writing style is called tategaki (縦書 / たてがき) and is most commonly used in Japanese typography within books, newspapers and manga. However, if you, like me, have ever picked up manga and tried to read it like an English book only to then spoil the surprise ending, you might have already realised this 😂

Let’s hold those thoughts, as with that knowledge we can now move onto the main event ✨🙇

So, what’s actually new in AndroidX?

On August 27th 2025, the brand new androidx.text library group was released with a single library, androidx.text:text-vertical:1.0.0-alpha01, a new dependency providing enhanced support for ‘vertical writing capabilities’. ³

As of the time of writing (early Sept 2025), and as with most of the very earliest releases of AndroidX libraries, extremely limited documentation outside of the commits and release notes exists. However, to understand what this library introduces, let’s explore the code and the small sample app that accompanied the release within the AndroidX codebase.

What’s in text-vertical:1.0.0-alpha01

One immediate noteworthy quirk with this new library androidx.text:text-vertical is that, unlike the majority of AndroidX libraries, it has a minSdk 36 (Android 16) requirement.

This does unfortunately mean the library currently only caters for the very latest Android version, but digging a little deeper shows this is due to the introduction of Paint.VERTICAL_TEXT_FLAG in Android 16 which is used by the library to ensure the text rendering does indeed perform vertical text layout calculations correctly. So it is worth noting that does likely mean backwards compatibility to meet AndroidX’s more general minSdk 23 (Android 6.0) support might not be forthcoming in future. However, from my testing, should the AndroidX developers find a backward compatible alternative for the flag, it may allow for the library to be minSdk 24 (Android 7.0).

The main entry-point for this library is the VerticalTextLayout class which, despite the name, is not to be confused with a layout in either the traditional XML/ View system sense or the more contemporary compose-based approach either. The class exposes a Builder for construction and, once built, requires consumers to call a method to draw the VerticalTextLayout result to a Canvas.

This is achieved in Jetpack Compose using an approach that is showcased within the sample app:

@Composable
fun VerticalText(text: Spanned, paint: TextPaint, modifier: Modifier = Modifier) {
    var vTextLayout by remember { mutableStateOf<VerticalTextLayout?>(null) }
    Layout(
        modifier =
            modifier.fillMaxSize().drawWithContent {
                drawIntoCanvas { c ->
                    // Draw method used to draw text to Canvas
                    vTextLayout?.draw(c.nativeCanvas, c.nativeCanvas.width.toFloat(), 0f)
                }
            },
        content = {},
    ) { _, constraints ->
        vTextLayout =
            VerticalTextLayout.Builder(
                text = text,
                start = 0,
                end = text.length,
                paint = paint,
                height = constraints.maxHeight.toFloat(),
            )
                .build()
        layout(constraints.maxWidth, constraints.maxHeight) {}
    }
}

At this time, there is no current official example of how to also do this using a View but if that is something you need, you can find my crude attempt at implementing a similar approach here. ⁴

A Basic Example — Vertical Spans

Within the sample application, a very simple DSL style API is applied to aid the building of the vertical text. It elegantly applies the new library’s newly supported spans which can be demonstrated using this basic example using my name and some numbers:

@Composable
fun SpanExampleText(
    paint: TextPaint,
    modifier: Modifier = Modifier
) {
    VerticalText(
        buildVerticalText {
            // Basic spans examples
            // text("エド 123\n")
            // Upright("エド 123\n")
            // Sideways("エド 123\n")
            // TateChuYoko("エド 123\n")

            // Example with emphasis
            withStyle(textColor = Color.Red) { text("エド 123\n") }
            withStyle(textColor = Color.Blue) { Upright("エド 123\n") }
            withStyle(textColor = Color.Magenta) { Sideways("エド 123\n") }
            withStyle(textColor = Color.DarkGray) { TateChuYoko("エド 123\n") }
        },
        paint,
        modifier,
    )
}

This renders the following output, which shows some subtle differences (and remember we read this top-to-bottom, right-to-left!)

• The red text is the most basic example where the text’s paint has the Paint.VERTICAL_TEXT_FLAG applied and no other spans. As you can see, the text is displayed vertically but numbers are displayed vertically and rotated to display ‘sideways’ at 90 degrees. You should note that this isn’t typically how numbers are normally displayed in this writing style, but we’ll discuss that in a second!
• The blue text is set to use the TextOrientationSpan.Upright() span behind the scenes and displays text in the same orientation as the previous example and now also renders numbers in the same style. As I understand it, there are occasions where this style is used but it is still not primarily how numbers are displayed.
• The magenta text utilises TextOrientationSpan.Sideways() as displays all characters rotated 90 degrees to be sideways. The docs note that this “may be useful for orienting text horizontally when the surrounding text is vertical”.
• The grey text displays text in a common style used to display horizontal text within a vertical flow using TextOrientationSpan.TextCombineUpright(). In Japanese, this style is known as 縦-中横 (たて-ちゅう よこ) ‘tate-chū yoko’ which translates to “horizontal in vertical” and is primarily used for legibility using half-width characters. Tate-chū yoko is how numbers are primarily displayed within a vertical span.

Final Example — Adding Emphasis

The final example highlights two additional features the library currently supports (as well as my extremely bad Japanese, sorry!)

• ‘Bouten’ 傍点 (ぼうてん), which are marks or dots placed above text to add emphasis to a phrase, similar to the use of italics in English
• Font shear, which displays text at a 15-degree angle, akin to italics and is also used in situations where emphasis is needed

@Composable
fun FinalExampleText(paint: TextPaint, modifier: Modifier = Modifier) {
    VerticalText(
        buildVerticalText {
            text(
                text = "私はアンドロイド開発者です。",
                rubyMap = mapOf("私" to "わたし", "開発者" to "かいはつしゃ")
            )
            text(text = "\n")
            TateChuYoko(text = "5")
            text(
                text = "歳の犬を飼っています。",
                rubyMap = mapOf("歳" to "さい", "飼" to "か", "犬" to "いぬ")
            )
            text(text = "\n")
            text(
                text = "人間の年齢に換算すると",
                rubyMap = mapOf(
                    "人間" to "にんげん",
                    "年齢" to "ねんれい",
                    "換算" to "かんさん"
                )
            )
            TateChuYoko(text = "36")
            text(text = "歳です。\n", rubyMap = mapOf("歳" to "さい"))
            
            // Add emphasis with bouten
            withEmphasis(style = EmphasisSpan.STYLE_DOT) { text(text = "すごい", rubyMap = mapOf("歳" to "さい")) }
            text("ですね。\n")
            
            // Add emphasis with font shear
            withFontShear { text(text = "読んでくれてありがとう。", rubyMap = mapOf("読" to "よ")) }
        },
        paint,
        modifier,
    )
}

Is this library for me?

Ok, let’s be honest, this is currently a niche library heavily tailored to Japanese specifics which may see limited use outside of the handful of use-cases where the specific vertical writing system is needed. So, based on my knowledge of my post’s regular audience, it’s probably not something you’ll be using anytime remotely soon 😅

However, as a developer with a keen interest in equality and user-friendly software, I hope you’d agree this is exciting to see Android evolve ever further and start allowing developers to cater for their audiences needs with a consistent experience, even if those needs are unique geographically, culturally or otherwise.

If you like me found this subject interesting, I highly recommend the Netflix engineering blog post ‘Implementing Japanese Subtitles on Netflix’ from 2017. It highlights some of the other quirks of implementing Japanese typography and was a great resource while investigating this topic.

In closing, I’m very excited to see what’s next for the androidx.text suite of libraries. I highly doubt androidx.text:word-art is coming anytime soon, but fingers crossed just in case… ⁵

Thanks as always for reading! I hope you found this post interesting, please feel free to contact me with any feedback at @Sp4ghettiCode and don’t forget to clap, like, share, star etc — It really helps!

Footnotes

1: After checking online, inu in katakana (イヌ) is occasionally used in certain specialised contexts such as biology. So, for completeness, you have now learned to write dog in all three writing styles, you are welcome!

2: If this looks useful, you should definitely check out android-compose-furigana by @mainrs on GitHub!

3: If you read the prologue, you probably know where this is going 😌

4: I can’t remember the last time I wrote a View, so please take this with a pinch of salt 😂

5: 📎💬 It looks like you’re trying to write a blog conclusion… would you like some help?

Whats new in… ‘AndroidX Text — 1.0.0-alpha01’ was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

🎉 Excellent news, everyone! After what feels like a long wait, we are finally seeing progress with Certificate Transparency (CT) being made readily available to developers via official APIs as of Android 16.

In this blog post, we’ll discuss what this means, the pros/cons, and of course, how to implement certificate transparency in your applications for Android 16+ and older devices.

What even is Certificate Transparency? 📜

Before discussing what changes are available in Android 16, we should take a few minutes to remind ourselves what CT actually is and why it is important via some useful background info, followed by a quick history lesson. I won’t be detailing all the nuts and bolts or how/why certificates are used, but instead some key details that will help us understand where CT becomes relevant.

Firstly, when talking about certificates, I should probably point out that I am not talking about paper certificates you may have received as a kid for swimming 50 meters or being top of the class. No, I am of course talking about the digital certificates that are deeply ingrained within modern secure web browsing and are used by our browsers and networking tools to verify the identity of domains. In complete layperson terms, the certificates are part of the process that underpins that little padlock icon in your browser’s address bar 🔐 You know the one right?

Next, we need to discuss entities known as certificate authorities (CA). A CA forms an important role in this verification process as their responsibility essentially boils down to being a ‘trusted source’ that can perform the verification of both a server’s certificate and determine if secure access to it is possible. Browsers and operating systems usually ship with a list of CAs that they consider trusted sources, and along with that responsibility, there’s a mutual understanding that all CAs follow the most stringent security best practices to ensure their verification process is legitimate and trustworthy. Trust is the key word here, and with that in mind, this segues nicely into our brief history lesson.

Certificate Transparency History 101 👨‍🏫

In 2011, a Dutch CA called DigiNotar was hacked 😅
This was far from ideal for several reasons:

• At the time, DigiNotar was considered a trusted CA by pretty much all major browsers and mobile/desktop operating systems
• Thanks to a pretty big lapse in their own security practices, a breach went unnoticed by DigiNotar for around 5 weeks and led to the attackers issuing around 500 fraudulent certificates for popular sites
• The breach was only brought to DigiNotar’s attention when attackers used these forged certificates to perform a man-in-the-middle (MITM) attack and eavesdrop on Iranian civilians’ Gmail accounts via a fake *.google.com certificate
• All affected applications (browsers/OS, etc) then had to scramble and immediately push security updates to remove DigiNotar from their trusted CA lists and prompt their users to update

If you want to learn more about the DigiNotar hack, there’s a great Darknet Diaries episode which dives deeper. Give it a listen!

So, in short, DigiNotar swiftly became “DigiNoMore” (they went bust) and the landscape of secure browsing suddenly needed to change to account for any future cases of untrustworthy CAs.

Who watches the watchers? 👀

When the DigiNotar hack occurred, the fallout was great enough that it triggered a change in attitude towards certificates.

How could a fraudulent certificate be issued for a domain by a trusted CA and be spotted quickly?

The answer, of course, is ✨ certificate transparency ✨

The ‘transparency’ aspect is now achieved by CAs publicly logging when they have issued a new certificate to a number of log servers. Critically, these log servers are ‘append only’ and cryptographically hashed, meaning CAs can only add new data to them and cannot be tampered with.

The use of public log servers allows for the auditing of certificate authorities to occur, which in turn means any discrepancies can be caught quickly and dealt with in a timely fashion. Many of the popular browser vendors perform such audits, as well as large tech companies such as Google and Facebook, thus making it significantly harder for any forged or unexpected certificates to be incorrectly issued through a CA.

Well, what about pinning? 📌

Ok, so what? You’ve possibly heard of “certificate pinning” before; it’s supported by Android already, and that’s probably good enough, right?

Well, no. Not quite.

Certificate pinning is different in that only a specific certificate’s public key for a given domain is checked against. This is problematic, particularly in mobile apps, as if the wrong certificate is pinned, or a developer forgets to rotate the pins before a certificate expires, the application will no longer be able to communicate with that endpoint, and an immediate app update would be required. Yikes.

In this scenario, CT works far better. When a new certificate from a CA is issued, the log server also issues a signed certificate timestamp (SCT) which can then be verified by a client. As there is no longer a reliance on the public keys of certificates, the need to release an app when certificates rotate is eliminated and a new certificate’s authenticity can be checked without disruption.

While this overview glosses over a lot of finer details, Matt Dolan’s talk “Move over certificate pinning. Certificate Transparency is here!” gives an excellent insight into both certificate pinning and transparency. So don’t just take my word for it!

Android 16 Changes 🆕

So, with a lot of preamble out of the way, what has actually changed as of Android 16 (API 36)?

The Network Security Config file now contains acertificateTransparency tag allowing CT to be enabled globally or per domain for Android 16+ devices.

Adding this to your existing security configuration is super straightforward and can be done with just a couple of additional lines.

Per-Domain:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">example.com</domain>
      <certificateTransparency enabled="true"/>
  </domain-config>
</network-security-config>

Globally:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
  <base-config cleartextTrafficPermitted="false">
    <certificateTransparency enabled="true"/>
  </base-config>
</network-security-config>

While this is a quick-win, it is worth noting that enabling this feature may interfere with your setup if you are currently allowing user or custom certificates. Given that those certificates may not be public, certificate transparency will not work.

You can read the docs for further information here.

What about pre-Android 16?

With official Android 16+ support available long term, what support is available to enable CT for pre-Android 16?

The de facto go-to library for this is Matt Dolan’s Certificate Transparency lib, which provides support for Java projects as well as Android 4.4 (API 19) and above.

The library provides support for certificate transparency within WebViews via a custom Java Security Provider and also allows for CT with simple integrations for common networking libraries, such as OkHttp, via an HttpInterceptor.

Basic integration:

val interceptor = certificateTransparencyInterceptor()

val client = OkHttpClient.Builder().apply {
    addNetworkInterceptor(interceptor)
}.build()

Importantly, the library also attempts to address the issue of certificate revocation by providing an interceptor to allow developers to manually define revoked certificates. As Matt points out in his README, you can read more about the problem this attempts to solve here.

Summary ✨

In conclusion, certificate transparency is certainly an upgrade to certificate pinning and is now officially supported as of Android 16+, bringing Android up-to-date with security best practices and iOS, which has had support since around 2016.

If you, like me, are a security-conscious developer, then enabling certificate transparency is a quick win that makes your apps more secure with minimal effort.

So, with all that said, it’s my hope you too will see the clear benefits of transparency 💪

Thanks 🌟

Thanks as always for reading! I hope you found this post interesting, please feel free to contact me with any feedback at @Sp4ghettiCode and don’t forget to clap, like, share, star etc — It really helps!

How to have “Crystal Clear Certificates” was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

This month, Google hosted the first of its follow-up series of events for their annual Google I/O conference. In this post, Ed Holloway-George highlights what he learned at the I/O Connect event held in Berlin, Germany.

As an Android developer and self-proclaimed tech nerd, the Google I/O conference is one of the dates I always look forward to on my calendar each year.

Held at the impressive Shoreline Amphitheatre in Mountain View, California, it’s usually Google’s primary showcase of all the exciting announcements they have to share across their software, hardware and other digital products. In years gone by, we’ve seen major announcements including the launch of Google Assistant, Google Home, numerous Android versions and of course, the ill-fated and slightly ahead of its time, Google Glass.

However, this year’s edition held on May 14th had from the offset a very specific focus — AI. As the hottest topic in tech right now, it comes as no surprise that Google is also going all-in with its AI offerings this time around. In fact, so much so, that “AI” was mentioned at least 120 times during the main keynote presentation 😅 That aside, there were also many other announcements in the mobile, cloud and web spaces for developers and consumers to look forward to. If you missed any of these yourself, you should check out the official site and catch up 👀

Whilst the main conference was primarily focused on announcements, Google also has several smaller developer-focused follow-up events known as I/O Connect. The idea behind I/O Connect events is to get the new technologies announced at the main conference in the hands of developers, have Google employees (Googlers) readily available to take questions as well as present additional content and of course, for developers from across the world to meet up and share a common passion for Google’s tech.

Being a Google Developer Expert for Android, I was fortunate enough to be invited to this year’s European instalment of I/O Connect, held in a swelteringly hot Berlin 🤒

So, to completely misquote the Ramones, “I/O let’s go!”…

What I learned at I/O Connect 24

In my experience, there’s no such thing as a dull Google event. I/O Connect this year comes as no exception with an indoor artificial river installation being the centrepiece of the event’s location within a converted warehouse complex. With multiple auditoriums, workshop spaces and free barista-made coffee, the stage was already set for a great developer event.

But what did we learn? There were some amazing announcements, but here’s a summary of some of my personal key takeaways!

• Google’s investment in AI is scaling up

Google used I/O Connect’s keynote to announce their latest “Gemma 2” suite of models. The newly available models boast the ability to support either 9 billion or 27 billion parameters and have performance metrics that surpass known industry leaders such as the popular Llama-3 offering from Meta. The rapid release of Google’s AI products and the mind-boggling numbers associated with them is a testament to how much effort they are focusing on this area and it continues to be at the forefront of developer’s minds.

A live demo of Google’s Gemini AI being used in developer tooling to aid the investigation of a bug in software was incredibly popular with the Keynote’s crowd and despite another AI live demo going a bit wrong, the sentiment with most is that AI is not just something to benefit end-users but something that can be used at all stages of software development.

Like many tech-centric companies, we are no strangers to AI’s benefits as we’ve previously blogged about a real-world application of AI/ML used here at ASOS and also our process of looking into new ways to use Gen AI through hackathons. Google’s recent announcements have all but reinforced our belief that the future is AI ✨

• Kotlin Multiplatform continues to thrive

Kotlin Multiplatform (KMP) are the words on many mobile developer’s lips right now. The ability to effectively share code between iOS, Android, Desktop and Web sounds almost too good to be true, but the KMP model is one that is growing in popularity and shows no signs of slowing down its adoption at scale.

Google recently announced a series of changes to some of their core Android ‘Jetpack’ libraries that allows their popular libraries such as ViewModel, Paging and Room to now be used in a KMP context. I/O Connect was an opportunity to revisit these announcements, see them in action and have a discussion with Googlers about their future plans for KMP support. As it was made clear in their presentations, Google is now fully endorsing ‘KMP for shared business logic between Android & iOS’ which is an exciting prospect for many mobile developers.

I am pleased to reveal that our mobile teams at ASOS have recently been exploring KMP for shared business logic between our iOS and Android apps and have been actively trialling the use of shared ASOS KMP libraries in our most recent Android release (with iOS coming very soon). If you’d like to find out more about how this went, our approach and results, then perhaps keep an eye out for a future blog post! 👀

• Performance in mobile is still key

Another key area of focus within Google’s Android ecosystem right now is that of app performance. I/O Connect was no exception with hands-on workshops and tech-talks focussing on performance libraries such as Baseline Profiles and Macrobenchmarks.

This was an awesome opportunity to chat, raise any issues and pair program directly with the Googlers involved in these libraries and had great feedback from all involved. Sadly, a conflict with another event commitment meant I wasn’t able to attend directly — but I am told it was incredibly useful!

App performance is something we are always looking to improve at ASOS and I am pleased to say we have a roadmap to introduce these libraries into the Android app in the very near future. Watch out Usain Bolt, we are coming for your speed record 🏃‍♂️💨

• The wider tech community continues to be impressive

With over 100 countries represented from across Europe, the Middle East and Africa, Google’s I/O Connect event embodied the very best of the tech community and brought together people who all share a common passion; To make the world a better place through technology.

ASOS is one of many companies that actively work with cutting-edge technologies, such as those announced at I/O, to deliver better results and experiences to our customers. We’ll continue to keep on top of the rapidly changing tech landscape and we are all excited to share more about our advancements in these areas in future posts!

In closing, I hope you found this insightful and join me in looking forward to seeing what else comes from the remaining I/O Connect events in Bengaluru — India and Beijing — China later this summer.

I hope to catch you at next year’s events wherever they might be! 🗺️

Hi, I am Ed Holloway-George an Android Lead here at ASOS and Google Developer Expert for Android. I joined the company in 2021 and when I’m not sweating buckets at developer events abroad, I can be found talking about Mobile Security or tweeting pictures of my dog 🐶

Here’s what we learned at Google I/O Connect Berlin was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

Sad news everyone. Very recently the Jetpack Security (JetSec) team at Google quietly deprecated the androidx.security:security-crypto dependency (aka “JetSec Crypto”), the library responsible for popular classes such as EncryptedSharedPreferences

The knock-on effect is that this move is causing some developers to ask “What does this deprecation mean for my app and its security?” and begin frantically looking into alternatives 😬

In this post, we’ll take a look at what this news really means for those who have previously embraced EncryptedSharedPreferences and also for those who may have been looking to adopt it.

Ed Holloway-George 🍝 on Twitter: "RIP JetSec Crypto 😢 You were a fun little library with big ambitions#AndroidDev pic.twitter.com/9sqt7RT07L / Twitter"

RIP JetSec Crypto 😢 You were a fun little library with big ambitions#AndroidDev pic.twitter.com/9sqt7RT07L

A recap on JetSec Crypto 🔏

I’ve previously talked about JetSec Crypto in more detail before, but in case you missed that, let’s quickly re-acquaint ourselves.

The library began life in alpha releases in May 2019, went stable 1.0.0 in April 2021 and has seen infrequent 1.1.0 pre-releases from that date forward before the recent deprecation.

JetSec Crypto consists of only a small handful of classes, primarily wrappers around popular storage mechanisms, (i.e. EncryptedSharedPreferences and EncryptedFile) that offer convenient methods to encrypt/decrypt the data held within them. The library also provides a wrapper around Google's cryptography library Tink through the MasterKeys class which, via a straightforward API, allows developers to create secure keysets for the encryption process utilising best practices for Android.

Despite being a relatively infrequently updated and small library, JetSec Crypto has seemingly been widely adopted, thanks namely to the ‘added security’ it provides and the simplistic familiar APIs.

So in light of this news, what are the cases for and against using EncryptedSharedPreferences in 2024 post-deprecation?

Why NOT JetSec Crypto in 2024?

Firstly, why would we not want to use JetSec Crypto post-deprecation?

To some extent, using EncryptedSharedPreferences should be seen as a red flag that perhaps your app isn’t following security best practices in the first place 🚩

Ask yourself, are you using the library for storing data locally on a device that’s sensitive? This would include data such as personally identifiable information, financial data, credentials, etc. If you are, should you be? Chances are, no — you shouldn’t. Any sensitive data should ideally be server-side, only fetched when required, and require some form of authentication to access.

So if EncryptedSharedPreferences was your solution to storing sensitive data on the device, you might have bigger problems…

Additionally, now the library is deprecated it’s certainly worth considering that there will (likely) be no further updates. Any existing bugs, performance issues, etc will remain and not be patched.

That said, given this library is so small there’s no reason to fret, as you could consider pulling the key classes out of the current version and manually maintaining them within your project directly.
⚠️ However, this approach is not recommended unless you know what you’re doing! Doing this and just keeping Tink up to date is a good start, but be aware that any additional changes may put your app at risk if you aren’t already knowledgeable about cryptography and the Android APIs used by JetSec Crpyto. You have been warned!

Finally and arguably most importantly, you might just need to ask yourself “What does EncryptedSharedPreferences really do for me that SharedPreferences doesn’t?”

It sounds silly, but given SharedPreferences are held locally on the device in the app’s own folder which isn’t accessible by default, is EncryptedSharedPreferencesreally adding that much. Additionally, as of Android 10 (Q), all devices encrypt user data on the filesystem by default, adding another level of security.
A common rebuttal to this is “Well, what about rooted users?” and yes, a user with root access would be able to read cleartext SharedPreferences but once the device’s integrity is compromised is anything really safe, EncryptedSharedPreferencesincluded? Many experts (and I), would argue that it isn’t. 🥲 Some food for thought there!

Why JetSec Crypto in 2024?

Ok, so we’ve heard a few reasons why EncryptedSharedPreferencesmight not be the best choice going forward. However, there are undoubtedly still some positives and a handful of reasons to use it!

Firstly, if you have already adopted EncryptedSharedPreferences there’s certainly no immediate need to move away from it or seek an alternative. The library won’t stop working overnight and you can still manually update the transitive Tink dependency via your project’s Gradle dependency management. If it’s working for you in the short term, great! Just be aware that in the long term, there will be no updates. If that’s an acceptable level of risk for you and your app, then you are all good 😊

Another often-overlooked reason why JetSec Crypto is so popular is the APIs are straightforward and follow the best practices for cryptography in Android. I personally would trust that the JetSec team knew what they were doing and as such, EncryptedSharedPreferences is a very attractive option if I ever find myself needing to secure data locally. This won’t change with deprecation and I’d always prefer (and recommend) to use this over rolling my own solution. That’s never a good idea…

Finally, you might also just have no choice and need to use EncryptedSharedPreferences 🥲 What do I mean? Well, there are a number of industries (FinTech, Banking, Healthcare, etc) that have regulations that all businesses must abide by. Depending on your location or the markets your apps are available in, you may well be bound by laws or regulations that dictate any data stored locally must be encrypted to some degree. If you are wondering if this applies to you, then you should probably speak to your legal department as I’m not a lawyer, I’m just a lowly developer 😅

The future 🔮

Unfortunately, I don’t have a crystal ball so I can’t guarantee what comes next. However, it’s been clear from the last handful of major Android releases that security continues to be at the forefront of Google’s mind and providing developers with the tooling and resources to implement secure best practices is not likely something that will disappear any time soon.

I still have my fingers crossed that the JetSec team releases some guidance of their own shortly, but until then we’ll need to wait patiently to see if something completely brand-new comes along and whether we learn for certain whether JetSec is truly dead and buried.

Conclusion

Ultimately, as the custodian of your own applications, it is your decision to make whether EncryptedSharedPreferences and JetSec Crypto is the right choice for you and it’s my hope this post will help you make a better-informed decision!

In any case, JetSec Crypto was a great little library that we learned a lot from ✨ I look forward to seeing what comes next in the Android Security world!

As always, I’ll be the first to let you know when we find out more…

Thanks 🌟

Thanks as always for reading! I hope you found this post interesting, please feel free to contact me with any feedback at @Sp4ghettiCode and don’t forget to clap, like, share, star etc — It really helps!

Securing the Future: Navigating the deprecation of Encrypted Shared Preferences was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

A quick introduction 🤗

I don’t want to alarm you, but if you’ve ever updated the Gradle version in your Android project, you’ve probably done it incorrectly at least once 🥲

How do I know this? Well, first and foremost I was also guilty of this for a long time but since repenting and learning the ‘correct way’, I have seen it occur in many large open-source projects too (and of course, authored fixes to address it).

But don’t just take my word for it, here’s a poll I conducted on X (or ‘Twitter’ for those living under a rock)

What’s the problem you may ask? In this post, I hope to answer that question and ensure you update Gradle correctly every time going forward!

How to not update Gradle 🔥

Let’s consider a real-world scenario. You’ve noticed Gradle has just released a new version (which at the time of writing is version 8.7). Your app’s project is behind that version, and you want to update it.

Most developers, my past self included, would probably open gradle-wrapper.properties and just simply change the distributionUrl property as follows:

diff --git a/src/some-project/gradle/wrapper/gradle-wrapper.properties b/src/some-project/gradle/wrapper/gradle-wrapper.properties
index a3dc3ba8fe3..d4b79aa7c54 100644
--- a/src/some-project/gradle/wrapper/gradle-wrapper.properties
+++ b/src/some-project/gradle/wrapper/gradle-wrapper.properties
@@ -1,6 +1,6 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-8.5-bin.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-bin.zip
 networkTimeout=10000
 validateDistributionUrl=true
 zipStoreBase=GRADLE_USER_HOME

Alternatively, you could also use the wrapper task directly by using a command similar to ./gradlew wrapper --gradle-version=8.7 which will effectively just update the gradle-wrapper.properties for you. Nice.

Job done right? Well no, not really, and hopefully a handful of observant readers have already spotted the issue.

How to (properly) update Gradle ✨

To ensure you migrate to the new version correctly, you need to run the gradlew wrapper command up to two times, depending on the update method you previously chose above.

While editing your gradle-wrapper.propertiesfile will ensure your wrapper will correctly pull the new version’s distribution the next time Gradle is run, it will, unfortunately, leave your wrapper files themselves (i.e. the gradle-wrapper.jar and gradlew scripts) untouched and out-of-date 😬 Yikes!

The same applies to calling wrapper directly, the first pass will download the new distribution, but won’t touch your gradle-wrapper.jar and gradlew files unless you run it a second time. 🥲

Why is this? Simply, the wrapper can only write the wrapper files for its own version, so if you haven’t previously pulled the distribution, it requires another call once it is downloaded to create/update the relevant wrapper files for the new version.

Confused? So was I. However, the Gradle documentation does mention this explicitly:

If you want all the wrapper files to be completely up-to-date, you will need to run the wrapper task a second time.

D’oh.

Why bother?

Ok, this is something you might have missed, but why should we go to the effort of doing this?

Indeed, using an outdated Gradle wrapper won’t stop your project from building, but to ensure you get the very best from Gradle you’d probably want to make sure you’re using the latest and greatest wrapper. This ensures you reap the benefits of doing so, including bug fixes, security updates, performance improvements etc.

For the sake of an extra call to ./gradlew wrapper it seems pretty worth it to me!

But wait, there’s more… 😱

If you’ve read my posts before, you’ll know I tend to talk a lot about mobile security and may have previously seen me present how to secure Gradle (now also available as a blog post). Therefore, it would be quite rude of me not to shoe-horn a little sprinkling into this!

By adding a gradle-distribution-sha256-sum field to the ./gradlew wrappercall with a SHA256 checksum, whenever the distribution is downloaded, the checksum of that file will be compared with the string in the supplied property and the build will fail should they differ. As these distribution checksums are known for each Gradle version, any unauthorized changes to the Gradle distribution you downloaded will be caught and you will have just saved yourself from a supply-chain attack!

If you wanted to upgrade to Gradle 8.7, you could call the following:

./gradlew wrapper --gradle-version=8.7 --distribution-type=bin --gradle-distribution-sha256-sum=544c35d6bd849ae8a5ed0bcea39ba677dc40f49df7d1835561582da2009b961d

🚨 If you do, make sure you run this twice. Once to update the distribution and expected SHA-256 and again to update the wrapper files themselves

For more on this, make sure you check out my talk!

TL;DR

If you’re lazy (like me) and skipped to the end, we can summarise the above as follows!

• If you update Gradle via editing your gradle-wrapper.properties file, make sure you always run gradlew wrapper after
• If you normally update Gradle via the gradlew wrapper directly, make sure you run it twice! You also get bonus points from your fellow developers for using the gradle-distribution-sha256-sum field 💞

Finally, you can also check your wrapper is the expected version by running ./gradlew wrapper --version(Thanks to Xoangon for pointing this out)

Of course, if you want to learn more about the Gradle wrapper, check out the documentation ✨

Thanks 🌟

Thanks as always for reading! I hope you found this post interesting, please feel free to contact me with any feedback at @Sp4ghettiCode and don’t forget to clap, like, share, star etc

Introduction

First and foremost, a very happy 2024 to you 🎉 I know it’s February already, but given this is my first post of the year I hope you can forgive me for being slightly late.

That aside, the good news is this year has already kicked off with some exciting news in the mobile security space. In this post, we’ll discuss the changes that have been made to the OWASP Mobile Top 10 for 2024 and see what this means for you, the security-conscious developer!

For those that are already familiar with my OWASP Mobile Top 10 talks or posts, you can totally skip ahead to the more juicy “Top of the OWASP” section and find out what all the excitement is about. However, if you aren’t familiar or would just like a quick refresher, stick around as I recap what OWASP is and why the recent changes they made are a big deal in mobile security circles.

What the heck is OWASP? 🐝

If you are new to mobile security, my blog posts, or have just been living under a rock for some time, you might not be aware of OWASP and the excellent work they do.

Founded in 2001, the Open Worldwide Application Security Project (OWASP) Foundation is a non-profit that provides documentation, tooling, educational resources and many other community-based services to advance and educate people in software security practises. They are widely acknowledged to be the leading application security community in our field and have many dedicated volunteers within their various projects, including those that touch upon mobile security.

Part of the guidance OWASP provides is their ‘Top 10’ threat lists. These are lists of OWASP’s perceived top 10 threats to the security of particular areas and an incredibly useful resource for any developer ¹.

I have previously put out plenty of content surrounding their past guidance, so if you’d like to learn more, please check my talks page and my previous OWASP-related blogs for far greater details and more relevant links.

If you are a more hands-on learner, there’s also a companion app to my OWASP talks that demonstrates some of the topics outlined.

Regardless, 2024 sees the most significant modifications to the Mobile Top 10 in nearly a decade, so without further ado let’s see what has changed 👀

“Top of the OWASP” ✨

After a long consultation period and several revisions, the newly released OWASP Mobile Top Ten 2024 is the third and latest major revision of the Mobile Top Ten list since its initial release in 2014.

The 2024 release now supersedes the 2016 release and brings some noticeable changes that better reflect the present mobile security landscape, including four brand-new threat categories and a complete re-ordering of threats.

This is all well and good, but what has actually changed and what does it all mean? 😅 Well, in true Billboard chart style (or for me as a Brit, Top of the Pops), let’s very briefly discuss each threat in reverse order starting at number 10!

#10: Insufficient Cryptography ⬇️

Moving down from 2016’s 5th spot, Insufficient Cryptography is the threat posed to mobile apps by poor adoption of modern cryptography best practices. This could be through implementing algorithms that are deemed insecure (SHA-1, MD5, etc), not using secure data transport (HTTPS) or perhaps even by not adding delicious salt to your keys ² 🧂.

When utilising cryptography, ensure you follow the best practices for your particular needs such as using algorithms like AES with at least 128-bit block size or RSA with at least 2048 bits. If in doubt, defer to a professional or utilise trusted tools such as Google’s tink library.

Stay tuned to my blog for a post on this in the future (I hope) ³.

#9: Insecure Data Storage ⬇️

Another big mover from 2016’s list is Insecure Data Storage which moves from the second spot, right down to 9th. Ouch 😣

Your apps may be vulnerable to Insecure Data Storage if they are printing any data (including network calls ⁴) to logs, storing passwords or tokens, creating temporary files or even just using standard storage techniques such as SQL databases or Shared Preferences.

I’ve covered Insecure Data Storage in detail before, so be sure to check out my post on it and ensure your app’s data is stored safely & securely.

As always, it’s worth reiterating that it is a best practice to avoid storing sensitive data on a device whenever possible!

#8: Security Misconfiguration ⬆️

On the rise, from the 10th spot is Extraneous Functionality under its new moniker of ‘Security Misconfiguration’.

If you are aware of the concept of ‘RTFM’ ⁵, then you might be able to figure out what this threat is. It’s often caused by developers using incorrect settings in production builds, requesting elevated access or permissions when it’s not required or maybe exposing functionality that was originally intended to be internal to the application.

Documentation can often be your friend. Don’t neglect to read it. 🥲 Grab a coffee and get stuck in!

#7: Insufficient Binary Protections ⬆️

In a similar vein to famous bands like Cream, Audioslave or Atoms for Peace, by forming a proverbial “supergroup”, 2016’s 8th and 9th spots (Code Tampering & Reverse Engineering) have now combined and moved up the chart to 7th. 😎

Binary Protection focuses on ensuring your app’s binaries (i.e. your .apk/.aar for Android or .ipa for iOS) do not leak information or can be repackaged. If you are not obfuscating your app correctly, or utilising integrity checks, you may find attackers can reverse engineer or potentially redistribute your apps with malicious code injected.

I highly recommend my good friends at Guardsquare and their excellent tools (e.g. DexGuard and Proguard Playground) to help keep your app safe from these particular threats. Alternatively investing time into learning more about R8 and the Google Play Integrity API may also benefit you!

#6: Inadequate Privacy Controls 🆕

A brand new entry at number 6 is ‘Inadequate Privacy Controls’.

If your app handles a user’s personally identifiable information, i.e. data like full names, precise location, financial details, sexual orientation, etc, which in the wrong hands could be used to impersonate/harass them or possibly commit fraud, then this may apply to you! 🥸

Ensure your app is never storing or logging PII locally and you only ever request/transfer the minimal amount of information from the user to perform your app’s functionality. This will drastically reduce the chance of PII potentially being exposed through weaknesses in your storage or data transfer.

For example, should a cinema booking app require your sexual orientation or your precise location to book tickets? Probably not right! It would be far better to instead request a coarse location to find nearby cinemas and allow the user the option of supplying further personal details to serve recommendations, while also allowing them to opt out at a later date.

#5: Insecure Communication ⬇️

Another mover! 2016’s number 3 Insecure Communication falls two places to 5th.

These are the threats associated with the transfer or receiving of data. Most applications will be doing that via the internet, but your apps may utilise other communication methods such as NFC or Bluetooth. When there’s data communication, you can bet your last dollar there are risks associated with that!

I won’t go into more detail here, as I have previously blogged about Insecure Communication, so be sure to check that out.

#4: Insufficient Input/Output Validation 🆕

A brand new entry for number 4 sees us visit the topic of user input and outputs.

It’s incredibly important to ensure both your mobile app and APIs are correctly sanitizing user input when it’s communicated or when it is used as an output 🛁 Failure to do so can potentially lead to threats such as SQL injection or Cross Site Scripting (XSS) which may be used to expose sensitive user data or in more extreme circumstances compromise a device. Make sure you are ensuring you are getting the values and format you expect and discard anything that doesn’t meet that criteria.

Do you remember the ‘Effective Power’ or the ‘Black Spot’ messages that circulated on WhatsApp? These were issues caused by specifically crafted inputs that when outputted in WhatsApp messages were designed as a ‘Denial of Service’ of sorts. — Could sanitisation have saved the day here? Quite possibly!

In short, by being cautious of I/O, you can sleep easy knowing ‘Little Bobby Tables’ won’t be causing you any issues ⁶.

#3: Insecure Authentication/Authorization ⬆️

A combo of the previous 4th and 6th places sees insecurities surrounding authentication and authorization make the new 3rd spot.

To avoid any confusion given the similarity in naming, authentication is the act of verifying the user is who they say they are while authorization is the act of verifying the user has the role(s) or credentials to access a particular resource.

In both cases, it’s recommended that checks for authentication and authorization are always made server-side to avoid vulnerabilities introduced through binary modification or other means.

If you are communicating with APIs that require authorization, ensure you are using revocable tokens that are tied to the device so tokens can be revoked by users if their device is lost/stolen. Ensure tokens are refreshed periodically and your backend team are correctly authenticating when authorizing access to restricted resources!

Again, for more info on Insecure Authentication, you can check out my previous blog on the subject 🤠 Another will follow in due course for Insecure Authorization.

#2: Inadequate Supply Chain Security 🆕

A new entry for the 2nd spot sees the focus shift onto the tools and processes we use to build our apps.

A ‘supply-chain attack’ is an attack on the tooling you use, to introduce vulnerabilities, insecurities or malicious code into the tooling without being detected. It could be done internally within your organization by a rouge employee, or perhaps externally by a malicious actor who has gained privileged access to a system or tooling.

To protect against it, a thorough code review process should be part of your regular workflow and regular audits of access control to your supply chain should be performed. You should monitor (or limit) your app’s dependencies and ensure they are also regularly reviewed to avoid introducing vulnerabilities.

If you haven’t checked it out already, I have both previously blogged and talked on the subject of supply chain attacks and how to mitigate them when working with Gradle.

#1: Improper Credential Usage 🆕

Drumroll please 🥁 The biggest threat to mobile security, as determined by OWASP is… Improper Credential Usage

This is a catch-all category for cases where there is improper security surrounding credentials, applying to the user’s credentials, API keys and everything in between!

In an alarming 2021 report, an estimated 1 in 200 apps were estimated to be leaking AWS credentials through hardcoded API keys

Researchers from CloudSek, a cybersecurity vendor based in India, said that a study of some 8,000 apps found that around 0.5%, or one in every 200 mobile apps, contained hardcoded private keys for the APIs that the apps use to communicate with AWS services

Source: TechTarget & CloudSek

An exposed API key or hard-coded credential could have devastating outcomes. The leaking of these sorts of credentials has previously caught out major companies such as Uber, Verizon, Accenture and many more, allowing for data breaches where customer data including PII and payment details have been exposed 😅 In general, any sensitive data that needs to be stored locally should always be encrypted and the keys used for encryption should be securely stored within a hardware-backed keystore.

This all sounds scary, but avoiding falling foul of improper credential handling yourself is fairly straightforward. Do not store user credentials such as passwords on the device (ever!), ensure you routinely rotate any third-party API keys and ensure you always transmit credentials securely via HTTPS. Simples!

In Conclusion… 🐝

In conclusion, while there’s been some significant movement between 2016’s and 2024’s list, as a security-conscious developer you should be always monitoring your applications for potential threats regardless of their position. The Top 10 might have changed, unfortunately, the reality that mobile security is not overly well understood by many developers has not. By learning more and sharing this knowledge, you can make a difference in changing that!

If there’s to be one takeaway from this post, please make sure you and your teammates are clued up on the potential threats to mobile applications (through great resources like the MASVS or by reading my blogs!) and consider integrating tools such as AppSweep, MobSF, Snyk or SonarQube into your build pipelines to continuously check your code/binaries for these issues.

Well done for making it to the end! I hope you have a fantastic and secure 2024 🥰 🔐

Thanks 🌟

Thanks as always for reading! I hope you found this post interesting, please feel free to tweet me with any feedback at @Sp4ghettiCode and don’t forget to clap, like, tweet, share, star etc

Further Reading

• owasp-top-five Companion App (2016 edition)
• OWASP Mobile Top Ten 2024
• Mobile Application Security Verification Standard: MASVS
• Mobile Application Security Testing Guide: MASTG

Footnotes

[1]: If you are indeed a security-focused mobile developer, you should certainly pay particular attention to the updated MASVS and MASTG to apply and test your mobile app’s security model.

[2]: Nothing to do with sodium chloride. A salt in this context is randomised data that should be concatenated to plaintext before being hashed to ensure different hash values are generated, even if the entered plaintext is the same multiple times!

[3]: Annoyingly, I had the Insufficient Cryptography post mostly written before the 2024 Top 10 was finalized when it was in the 5th spot, not the 10th. (Whose idea was a 10-part blog series anyway!?)

[4]: Please stop logging your network calls in production. It’s 2024. 🥲

[5]: The ‘F’ is for fricking right 😅

[6]: https://xkcd.com/327/

What’s the buzz about the 2024 OWASP Mobile Top 10 changes? was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

This month, the tech team have been hard at work improving their skills and getting their hands dirty through our ‘Tech Develops’ initiative. In this post, Ed Holloway-George highlights some examples of what the team has been doing in their own words!

Working at ASOS certainly has its benefits. In one of our recent blog posts by Leah Wolstenholme, we showcased some of the perks that any ASOS employee can expect when they join. However, on top of these, there are also some unique perks for our tech team members!

“Tech Develops” is our monthly self-learning day for the tech team. Whether it’s joining teammates to create something innovative to present back to the team, or using the time to learn something completely new, Tech Develops is a time when the tech team down-tools, clears their diaries and focuses on developing their skills in a way of their own choosing.

This month was slightly different in that Tech Develops, which usually happens on the last Friday of every month, was moved to coincide with ASOS Develops over a two-day period (For more on ASOS Develops, see Leah’s previous post!).

With double the fun this time around, here are some highlights of what some of our teams got up to!

Native Apps

The Native Apps team at ASOS consists of engineers working on our Android and iOS mobile applications. When they aren’t arguing about which platform is better (Editors note: It’s Android by the way 😉), they spend their Tech Develops looking into all sorts of tech to make our apps and processes better.

Joshua Cotterell recently joined ASOS’ Android team for the second time, after taking a brief break of a few months to travel around Asia. For his Tech Develops, he created a web-based tool to help modify internal JSON config files.

For Tech Develops, I decided to build a JSON editor website. I wanted a quicker way to edit JSON, rather than using Find & Replace in a text editor.

To tackle this problem, I decided to load all text/number values into text/number fields, all bool values into switches, and display the keys as headers with the text size determined by the depth. I also created a simple filtering system using a search bar, so when you enter some text into the search bar, the JSON is filtered to display only the JSON that matches the search term.

I originally wrote this in JavaScript, but have since rewritten the app using Flutter — not only to learn a cross-platform framework, but because it allows direct persisting of any changes to the opened file, whereas a web solution only allows the changes to be saved as a new file.

Two days was a great amount of time to get stuck into a problem and really flush out a small working prototype. As with most POCs, testing and refactoring were left out of the building process as I wanted to focus on the features and the UI. Overall, I was happy with the project and found it to be the perfect learning experience for the two-day tech develops here at ASOS.

Notifications

It’s certainly frustrating to miss out on a new drop or not know when your latest ASOS order is on the way, but thanks to the smart cookies in the Notifications tech team this is a problem of the past!

Joe Conway is a Lead Engineer within the Notifications team and this month used Tech Develops to explore the increasingly more relevant topic of AI.

For this month’s Tech Develops, I decided to immerse myself in the world of generative AI, an area I find fascinating. 2023 has been awash with AI related developments and news, a fair proportion of which has centred around the ability that LLMs like OpenAI’s ChatGPT have to write code.

Alongside the rise of LLMs, there has been a rise in systems to orchestrate the LLMs into groups of interoperable agents. These systems allow different agents to be defined and converse with one another to reach a final goal. One such system is Autogen, from the labs of Microsoft Research.

I decided to run an experiment to expose the kinds of results that could be achieved and get a feel for the technology. As with many things, it started with a Pip install of the autogen library and a prompt 😊

I followed one of the more simplistic examples from the Autogen documentation and created an example involving an AssistantAgent and a UserProxyAgent.

The assistant would represent our friendly engineer, the user proxy would run the output from the assistant and delegate back to me in case of any further queries. My initial prompt was as follows (Note: The JSON ‘searchresponse’ input contained the raw search response from the ASOS Search API when searching for “red dress”).

“Write a program to find the first product image in the list of products in the searchresponse.json file that contains the text ‘PETITE’, use the ‘imageUrl’ field to download the image, use easyocr for the ocr reader.”

The resulting conversation resulted in a back and forth between the two agents The assistant began:

“Sure, I can help with that. Here’s the plan:

1. Read the JSON file and parse it.
2. Iterate over the list of products and find the first product that contains the text ‘PETITE’.
3. Extract the ‘imageUrl’ field from the product.
4. Download the image from the URL.
5. Use easyocr to read the text from the image.”

The user agent would follow on to execute the script and respond with any errors, this back and forth continued for a couple of iterations, until the model stumbled on one of the requirements. My intention was for the code to read the text content from the images themselves, and not the step that the assistant outlined in step 2. The assistant asked for help.

“Please provide a new keyword or a new JSON file if available. If not, we may need to terminate the task here.”

The user agent (in this instance, me) responded

“Do not search for text in the json file, search for images that contain the text as part of the image itself”

The agent and user proxy continued to write code, test the code, iterate (sound familiar?) before finally the user agent (Python interpreter and LLM combined!) responded with the code below

It even printed the final image to the same directory!

Commercial Tech

Kishor Achtani is a Platform Lead for our Commercial Integrations team, a critical area of the Commercial Technology platform. This month, Kishor’s Tech Develops was far from ordinary!

This Tech Develops I managed to muster some courage and made my second attempt to learn a foreign language by learning some Italian. My first attempt was German when I was teen and I was kicked out of the class within 15 mins 😂

However, this time I managed to survive for 60 mins and learnt some basics of this wonderful language. Now I can confidently walk in to any Italian restaurant and say “Ciao, come stai, tavlo per 2.” or perhaps if I am stranded in middle of nowhere in Naples with no access to internet “Mi Scusi, Ciao, dove la stazione piu vicina 🚈”

The second half of Tech Develops was much more fun and thrilling than the first, as a colleague and I attended a MIRO innovational event located at Level 39 of the iconic Gherkin building in London!

Not only did we receive a hearty welcome, we also witnessed some mesmerizing views and got to munch on some lip smacking food. 🥞☕

We learnt how a culture of psychological safety is a vital part of successful innovation. We also heard about a ton of new features (Talk Tracks + Miro AI Assists + Integration with DevOps etc).

We were feeling as proud as a peacock when ASOS featured in one of their slides during the keynote session.🦚

The evening concluded with a champagne networking reception, where we got an opportunity to learn from likeminded leaders from the world’s most interesting brands over champagne and canapes.🥂

That’s all for now!

What would you bring to Tech Develops? Why not check out our open positions within the Tech team and come find out?

Ed is a Lead Android Developer at ASOS and a member of the Tech Blog team.
In his spare time, you can find him talking about mobile security at conferences or posting pictures of his dog!

Here’s what we got up to this month in Tech Develops… was originally published in ASOS Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

👋 Hi and welcome to the fourth post in this series where we deep-dive into Android Security (Part 1, 2 and 3). This series focuses on the Top 10 Mobile security threats as determined by The Open Web Application Security Project (OWASP) Foundation, the leading application security community in our field. Before checking this post, please consider checking out the previous one 'Insecure Communication' which is available on my site, and on Medium.

⚠️ Please note that this series is for educational purposes only. Remember to only test on apps where you have permission to do so and most of all, don't be evil.

Finally, if you enjoy this series or have any feedback, please drop me a message. Thanks!

Introduction

In this helping of my series on Android Security, we shall take a look into the #4 threat to mobile application security as determined by OWASP, "Insecure Authentication".

But what does authentication involve? Well, put simply, authentication is the process of verifying a user's "identity" is what they claim it to be. Once verified, this identity is then often used to authorize the user to access a service, data or other restricted resource.¹

Authentication is achieved by using at least one of three basic authentication factors: ²

💭 Something you KNOW

• Such as a password, passphrase, user ID, etc ³

🎁 Something you HAVE

• An authorization token, a physical crypto-key, an authentication code, etc

👀 Something you ARE

• Via your own biometrics. i.e. fingerprint(s) or forms of visual recognition such as facial/retinal recognition

In theory, the more of these factors that are used, the stronger the authentication is and the harder it becomes to pretend to be someone you aren't. This is, in fact, the guiding principle behind multi-factor-authentication (MFA) and hopefully, something you are familiar with and using already when it comes to your own authentication practises! ⁴

That said, these individual authentication factors aren't foolproof and still require care to be taken by the developer in order to ensure the user is protected and your app is secure. So let's do just that!

What's the passw*rd?

Something that certainly isn't unique to Android apps is users making poor decisions when it comes to password security. Given when data breaches occur the most common choices are usually password, 12345, qwerty or similar variations, we can assume that when given the option users may opt for incredibly simplistic and insecure passwords.

However, as developers, we have a duty to ensure that when users create passwords they are as secure as possible by enforcing 'password policies' which will (hopefully) encourage users to create not only strong passwords, but also unique ones.

"Ok, but what makes a good password policy?" I quite clearly heard you say. 🤗 I am so glad you asked, here are some tips on how to come up with one.

Set a minimum length

Firstly, ensure your policy has a minimum length of characters that is required. It should be obvious that a longer password is generally more secure than a shorter one, but choosing character limits that add security and also allows users to generate passwords they will find memorable can be difficult. A good minimum number for this task, and also recommended by the National Institute of Standards and Technology (NIST), is 8 characters.

Ideally, you should also consider the maximum length of any passwords to be at least 64 characters to facilitate and encourage totally unique passwords or phrases. Visually reinforcing longer passwords within your app's UX is also a great approach to ensure users make better choices.

Reconsider the use of 'complexity requirements'

When you read password policy you probably instinctively thought of rules that enforce a mix of letters, numbers, and special characters, as this fairly common place. The theoretical aim of rules of that nature is to make it more difficult for attackers to simply guess or use brute force to crack a password. However, guidance on this has shifted in recent years due to concerns that such complexity requirements actually lead users to create more insecure passwords ⁵ 🤯. In this case, perhaps less is more! Giving your users increased flexibility may encourage longer, harder to crack passwords, which is better for everyone.

No hints allowed!

You may occasionally come across applications that ask you to supply a memorable phrase as a hint for future password recovery. This is certainly something you should avoid as it gives extra information to a potential attacker as users routinely choose hints which severely compromise their passwords 😅 The next point highlights exactly why.

Knowledge is porridge ⁶

What was your first pet’s name?
Who was your favourite teacher?
Where were you born?

Be aware that security questions might occasionally seem like an added layer of safety, but in extreme cases can be (and have been) obtained by social engineering. Social engineering plays upon our human-emotions and as humans are fallible, much like software, even basic social engineering could give malicious actors enough information to work towards compromising a user's identity. Depending on your visibility online, you might well have already been leaking some of this information yourself without realising. ⁷ Social Engineering has caused numerous high profile security breaches in the last decade and is an attack vector that is seeing an increase in popularity.

Best practises change over time

This guide is just that, a guide. Please make sure you consult your own cyber-security team (or other professionals) to determine if your current policy is up to scratch. Guidance on passwords has continuously shifted for decades, and will likely continue to do so for many more to come!

But wait, there's more. Once the password is created there are some further considerations to take on board:

1. Password expiration: Setting a limit on how long a password can be used before it needs to be changed. This helps to limit the window of time during which an attacker can use a cracked password.
2. History: Preventing users from reusing passwords that they have used in the past. This helps to prevent attackers from using passwords that have been compromised in previous breaches.
3. Use of password manager: Encourage users to use a password manager that can store their password securely.
4. Remember Me: If you provide some form of 'remember me' functionality during sign-in, never store the user's password locally on the device. Instead, utilise a long-life authentication token that can easily be revoked if needed.

With these tips - you can do your very best to help users make a well-informed and secure password. You can hopefully sleep easy knowing you have done your part, and as long as the users do theirs, their passwords are secure!

Clearly, passwords continue to present a very real security problem for apps, but I am pleased to say the future is beginning to look to be somewhat brighter...

Passkeys

When I originally wrote my very first draft of this blog post, I pretty much wrapped it up here. However, as a consequence of tinkering and toying with this post for a while, Google has now already begun the push to a post-password world in the form of 'passkeys'. Doesn't technology move fast! 😅

In fact, Google, Apple and Microsoft have all committed to providing a common password-less solution through the adoption of the FIDO (Fast IDentity Online) Alliance's passkey standard. So this isn't something to be sleeping on 👀

Pass-whats?

But what even is a passkey? Well, a passkey is a unique cryptographic key pair used to identify a user and their associated account for a given service. When a new passkey is created, the private key is saved on the issuing device with the public key being sent to be securely stored by the service.

This may sound just like bog-standard public key cryptography, and guess what? It is! Albeit, with the additional requirement of requiring authentication via the issuing device. If we think back to the list of authentication factors, this new flow requires something you have (i.e. the issuing device) and something you are (i.e. biometrics) or know (i.e. device PIN).

The good news is, from a user's perspective, there's very little that changes from a standard password flow. When a user is prompted to sign-in via passkey, the user approves the sign-in with the same authentication factor that the user has to unlock the device, such as their biometrics, password or PIN. Should a passkey exist for the user, then this authentication is enough for the user to continue - no further action required. If the device has yet to issue a passkey for that user and account, one is created and the sync process between the issuing device and service is also initiated to ensure the user can continue to use the device.

Passkeys in Android

Over the last few months, Google released a bundle of new online content (see: Further Reading) to aid Android developers in providing passkey support.

The first thing to note is passkeys are only supported on devices that run Android 9 (API level 28) or higher, meaning older OS versions will need to fall back to an existing password flow. Sadly we haven't eliminated passwords completely, but this is progress!

Under the hood, using the androidx.credentials:credentials suite of libraries, we can utilise the CredentialManager class to aid us in the generation of credential requests and the handling of the various response types. I won't discuss the full technical implementation here, but rest assured the official docs have you covered 😎

If this sounds like something you'd like to learn more about, I would highly recommend reading the original Bringing Passkeys to Android & Chrome announcement blog post and watching the associated YouTube video before attempting to implement this yourself using the Sign in your user with Credential Manager development guide.

In any case, you may also wish to check out the sample app provided by the Google identity team to give an idea of the best practices surrounding passkey implementation.

Hopefully, in a few year's time, we'll have totally ditched the dodgy passwords and have made our apps much more secure in the process!

Next up 🚀

In the upcoming posts within this series, we shall explore more of the OWASP Top 10 for Mobile. Next up is #5 Insufficient Cryptography

Thanks 🌟

Thanks as always for reading! I hope you found this post interesting, Please feel free to tweet me with any feedback at @Sp4ghettiCode and don't forget to clap, like, tweet, share, star etc

Further Reading

• owasp-top-five Companion App
• M4: Insecure Authentication : OWASP Foundation
• Security Queens: Mobster4 - Insecure Authentication
• Android - Security Best Practices
• NIST Special Publication 800-63B - Digital Identity Guidelines
• How to reduce reliance on passwords in Android apps with passkey support
• Sign in your user with Credential Manager

Footnotes

[1] Spoiler alert, we will revisit authorization in a future blog! You can swot up in advance by checking out OWASP - M6: Insecure Authorization

[2] You could also use 'location' and 'behaviour' as separate authentication factors. However, to keep it simple I have limited it to the most common 3 factors.

[3] Assuming that you, unlike me, can remember your passwords! In any case, I highly recommend a decent password manager such as 1Password

[4] Please use MFA whenever it's available. It usually takes no time at all to set up!

[5] For example, JohnDoe@1992 could be cracked a lot easier than android is my favourite mobile os

[6] One of my favourite 'Thick of It' quotes (NSFW)

[7] I've never (to my knowledge) posted my dog's name on the internet - just in case.

Unpacking Android Security: Part 4 — Insecure Authentication was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the accompanying blog post for my recent Droidcon Berlin 2023 talk “How to stop the Gradle Snatchers: Securing your builds from baddies” — you can find the slides, video and other resources for this talk at my site spght.dev/talks

If you are an Android developer like me, you will likely be somewhat familiar with the ‘elephant in the room’ when it comes to our builds, Gradle. For over 10 years, it has been the go-to build tool for the Android ecosystem replacing ant, and helping developers move forward into a more configurable and pleasant developer experience¹.

However, like any tool we use in our developer utility belt to build our apps, it is susceptible to security risks that can (and do) pose a threat to our codebases, apps and users.

While my talk and this post approach the topic from an Android development angle, the tips and tricks shared can be applied to any Gradle project. In this post, we will explore some simple steps we can take to ensure Gradle doesn’t fall foul to a supply-chain attack.

A supply-what?

A supply-chain attack is loosely defined as an attack on the tooling you use with the intention to introduce vulnerabilities, insecurities or malicious code into the tooling without being detected. It could be done internally within an organization by a rouge employee, or perhaps externally by a malicious actor who has gained privileged access to a system or tooling.

These types of attacks, while rare in the mobile industry, do happen and Gradle has been proven to be a popular choice of tooling to attack in the past.

Let’s look at three distinct areas where we can make improvements to secure our Gradle projects: Dependencies, Gradle Wrapper and Gradle Distribution.

Dependencies

It should come as no surprise that most Gradle projects contain external dependencies. Unless you have an extremely large development team, a lot of time or perhaps some incredibly strict security requirements of your own, it’s highly unlikely you will re-write particular code each time you begin a project. Third-party networking libraries, logging or other utilities are common dependencies to add at the start of most Android projects, but once we have added them to our build.gradle and we leave it to Gradle to import them from external repositories, how do we know these dependencies are legitimate 😧?

In 2018, a supply-chain attack was observed via a number of compromised dependencies hosted on the now-defunct Maven repository, JCenter. In Márton Braun’s excellent blog post ‘A Confusing Dependency’, he describes how a malicious actor was able to upload artifacts to JCenter that shadowed popular libraries found in other repositories such as Jitpack. These libraries shared package names and common code with their shadowed counterparts but also contained maliciously injected code to run on a user’s device when these libraries were used by unsuspecting developers. From the developer’s standpoint, there would be little to no obvious difference when using a legitimate or malicious library, however, the security of their users would be severely compromised. The full story itself is best described by Márton, but fortunately JCenter is no-more and we have some tools to protect us from these attacks going forwards.

Dependency Verification

When working with dependencies, we have two tools available to verify the dependency is legitimate and what we expect. Firstly, we have the ability to check the integrity of the dependency (i.e. has the dependency been modified in any way when compared to the trusted version) and also the origin of the dependency, also known as the provenance (i.e. is the dependency being provided by the legitimate trusted author).

Integrity is checked via a checksum verification process. A checksum is a value that can be generated for a given file, via a specific algorithm, that does not change if a file is an exact copy of an original. For example, using the SHA-256 algorithm, a simple file containing just the string Hello World would always resolve to d2a84f4b8b650… (You get the idea!). This same concept applies to Gradle dependency artifacts, as if we know the expected checksum, we can verify the integrity of the dependency we download.

To enable these checks via Gradle is as simple as running the following command

./gradlew --write-verification-metadata sha256 someTaskName

Running this task² will create a verification-metadata.xml file within your $PROJECT_ROOT/gradle folder that may look similar to the following:

<verification-metadata>
   <configuration>
      <verify-metadata>true</verify-metadata>
      <verify-signatures>false</verify-signatures>
   </configuration>
   <components>
      <!-- All your dependencies here! -->
      <component group="com.jakewharton.timber" name="timber" version="5.0.1">
         <artifact name="timber-5.0.1.aar">
            <sha256 value="ffedddfcc8eff42a1604c8577fcfa4b4ffd9f252122c52ea36cfe7967f512f71" />
         </artifact>
      </component>
   </components>
</verification-metadata>

This metadata file will contain checksums for your dependencies and their artifacts. Any subsequent fetches of these files will be compared with the provided checksum values and should any mismatch occur, a build error will occur — allowing you to catch any suspicious differences quickly.

In addition to this, an HTML report is also generated within the$PROJECT_ROOT/build/reports/dependency-verification folder of your project. This report gives further information surrounding any issues including links to relevant documentation and details on the warnings or errors present.

But where are these checksum values actually coming from?

When a dependency is added to a Maven repo, such as Maven Central, the artifacts are uploaded with checksum files with .md5, .sha1, .sha256 or .sha512 file suffixes after the corresponding file’s original name (e.g mylib.aar.sha256). These files contain the hash value for the artifact using the given algorithm and are downloaded from the Maven repo as part of the verification meta-data process.

Once this verification is enabled, when you add or update a dependency you’ll need to ensure the correct data for each relevant artifact is added to the metadata file — otherwise your builds will fail and you might get an earful from anyone else working on your project(s)! 😅 If your builds fail without any update to your dependencies, you must investigate as this would be the first indication of a supply-chain attack!

The provenance, or origin of a dependency is verified via the signature that was used to sign the artifacts. This signature is generated by a public-private key pair used by the library’s author when uploading the library to a Maven Repo.

To allow for this check to occur in your Gradle builds, amend the previous Gradle task to the following

./gradlew --write-verification-metadata sha256,pgp someTaskName

When this is enabled, you’ll see a number of trusted-key elements added to your metadata file representing trusted public keys for given dependencies.

<verification-metadata>
   <configuration>
      <verify-metadata>true</verify-metadata>
      <verify-signatures>true</verify-signatures>
   </configuration>
   <trusted-keys>   
     <trusted-key id=“47bf5922…” group="com.jakewharton.timber" name=“timber" version="5.0.1"/>
   </trusted-keys>
</verification-metadata>

These trusted public keys are stored locally and tested against the .asc PGP signature files that are also present within the Maven repo for the given dependency. When the dependency is fetched from the repo, these files and associated keys are used to authenticate a particular artifact's author.

⚠️ PLEASE NOTE: While the setup of this checksum/signature verification is quite straightforward, for it to provide total security it requires that you begin the process with complete trust in the pre-existing dependencies you have imported. Failure to first pre-verify each dependency’s checksum against a value you consider trusted renders this process useless. This process also applies to situations where you update the dependency — so while this is a far from frictionless experience, if done properly you can guarantee the integrity of your dependencies.

The Gradle documentation for dependency verification goes into great detail on these two methods. It is an excellent place to find out much more information about how to secure your dependencies and a must-read for any security-conscious developer! 😎

Repository Filtering

Another approach to using dependencies in a more secure way is to use repository filtering. This is the process of creating allow/deny rules for specific repositories surrounding the dependencies they are allowed to fetch. The APIs available for this give developers plenty of scope for creating simple or more complex rules and is something that can be implemented relatively easily through modifications to your existing repositories block.

In the example below, we allow all dependencies with the group com.example and the specific dependency com.example:foo to be fetched from JitPack, while excluding all dependencies from dev.spght.*³

repositories {
    maven {
        url "https://jitpack.io"
        content {
            // Fetch dependencies
            includeGroup "com.example"
            includeModule("com.example", "foo")
            // Exclude dependencies             
            excludeGroupByRegex("dev\\.spght\\..*")
        }
    }
}

By defining your rules correctly (i.e. in a mutually exclusive way), you can completely guarantee dependencies are downloaded from the source you wish them to be.

However, it should be noted that while this might add some degree of trust, this approach does not verify the dependencies themselves are legitimate like the checksum or signature checks discussed previously. So certainly consider using repository filtering in combination with other methods. 🙏

Gradle Wrapper Verification

The Gradle Wrapper is a tool we use often with little thought. For most of us, the gradlew script in our projects is commonly the entry point we use to run specific tasks relating to our projects, such as running tests, building artifacts and everything in between. We might give it no attention, but behind the scenes, the wrapper has an important role in ensuring the “correct version” of Gradle is downloaded and executed for your project.

Part of this process is running the gradle-wrapper.jar , a Java executable that is likely checked into your version control. As this file is commonly executed, it is certainly a potential security risk should it be maliciously modified.

In fact, in late 2022 a supply chain attack on the wrapper .jar file was first observed in the wild within the codebase of an incredibly popular Minecraft Server. A malicious Minecraft plugin, in conjunction with the wrapper JAR executable, was responsible for accessing user data and granting particular users admin/root-level access to the game as well as the underlying tech stack used to serve it.

On the back of this, Gradle has released a GitHub Action that can be used as part of your build pipeline to verify that the Wrapper’s JAR is legitimate. It uses the known wrapper checksums to ensure the wrapper has not been tampered with and also is smart enough to check files named gradle-wrapper.jar with homoglyph variants (i.e. where an attacker uses a Unicode character that looks similar to an ASCII one in order to deceive developers into using the wrong file).

However, should you not be using GitHub for CI and require a solution you can run both locally and remotely, I also created a simple script to verify the Wrapper’s JAR

Sadly no official solution exists for verifying the gradlew script, but a GitHub issue exists as a feature request. It may be worth keeping an eye on… 👀

Gradle Distribution Verification

Finally, it is also possible to verify the actual Gradle distribution that the wrapper downloads. You may have seen the distributionUrl property within your $PROJ_ROOT/gradle/wrapper/gradle-wrapper.properties file, which contains the URL of the distribution of Gradle to fetch. However, how can we guarantee that what is downloaded is legitimate?

By adding a distributionSha256Sum property to this file with a SHA256 checksum, when the distribution is downloaded the checksum of that file will be compared with the string in the supplied property. These distribution checksums are known and therefore can be added to your project easily.

It is also possible to add the distributionSha256Sum property dynamically when updating your Gradle wrapper by using the gradle-distribution-sha256-sum flag

./gradlew wrapper --gradle-version=7.5 \
       --gradle-distribution-sha256-sum=cb87f222c…

Should you download something that doesn’t match the distributionSha256Sum checksum, your builds will fail and you can begin to investigate. You never know, this might just save you one day!

Final Thoughts 💭

Phew, that’s it. Thanks for sticking to the end 😅

In conclusion, while a supply-chain attack on your Gradle tooling might not be as common as other forms of attacks, it is still a viable attack vector that has been proven to occur many times over.

The mechanisms Gradle supplies to thwart such attacks are more than simple enough to integrate into any project relatively quickly. Fingers crossed this post helps you make a more informed choice and perhaps look into adding one or more of these to your project.

For more information, check out spght.dev/talks and catch my talk “How to stop the Gradle Snatchers: Securing your builds from baddies” at Droidcon

Stay safe out there! 💪

Thanks 🌟

Thanks as always for reading! I hope you found this post interesting, please feel free to contact me with any feedback at @Sp4ghettiCode and don’t forget to clap, like, share, star etc

[1]: If you remember the time before Gradle, you will hopefully be in agreement. In my talk, I refer to this time as ‘the dark ages’.

[2]: In this example, someTaskName is an optional param that, if provided, should be the name of a Gradle task that exposes the dependencies you wish to verify. Gradle’s documentation recommends using the help task, but depending on your own configuration, there may be better tasks to run instead.

[3]: Who could trust someone with a domain that silly?! 😅

Android Security: Securing your Gradle builds from baddies was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.