Hi folks! We're happy to announce <Warden Supreme...

# feed

[Bernd Prünster]

Hi folks!

We're happy to announce Warden Supreme, our new integrated mobile attestation suite, integrating our battle tested server-side attestation libraries and augmenting them with a KMP client module and a unified API across iOS and Android. If you've previously been using WARDEN or WARDEN-roboto. These previously separate projects have been intragrated into Warden Supreme and you can continue using them – a relocation POM will help you upgrade.
Moreover, we have big plans for the documentation: We want it to become THE resource for everything related to mobile attestation – including concepts, technical deep dives and, most importantly, quirks, bugs, and tips on how to deal with the ugly reality of bugged and broken devices out there. A foundation is there, but we can use all the help we get to achieve this goal!

[Kevin Burgmann]

I am trying to understand this (nicely formatted) page of your documentation: https://a-sit-plus.github.io/warden-supreme/bg/threatmodels/

Especially in the example "Concrete Example: Repackaging ID Austria" the linked GitHub project at a quick glance appears to improve the app for end users by removing user-hostile functions that should not be present in the first place. Do I understand correctly from your description that you are essentially trying to restrict/forbid users in how they wish to use their personal phone / device?

[Bernd Prünster]

This really depends on your angle: If you want to modify an app yourself, this may or may not be an issue. For example, if you are able to modify a client for a multiplayer online game (let's say: spoofing the location in Pokémon Go), you may be ruining the game for others. But there is also the very first bullet: distributing malware through repackaged apps to unsuspecting users. From the back-end's point of view, both look and behave the same wrt attestation. What logic you are locking down using attestation is entirely application-dependent.