I’m working on security products at a observability vendor who happens to like dogs a lot. Our leadership was early in embracing AI and pushed it hard onto our engineering. This positioned us well to jump onto the AI security bandwagon and products came out (the incident assistant is really impressive and expensive) but the value proposition of the “secure your AI” pitch stayed very vague.
Upon reading the Thinkst debrief of RSAC 2026, I figured we’re not alone and I think I know why.
... ➦Disclosure: This post doesn’t refer directly to my current or past professional experiences. Illustrations aren’t necessarily representative of any actual organization.
I meant to end with some recommendations but this document has been open for two weeks and I want to iterate faster so ¯\_(ツ)_/¯
I am lucky to work in a fast growing startup with a good product, a good team and a good culture.
One of the perk is to get an opportunity to look behind the curtain at how decisions are taken at all level and to contribute.
Since joining my current company, I realized problems tend to fall in three main categories:
When trying to port BSDiff to our platform, we encountered two main challenges. The first was performing the update in place, which resulted in us solving the WbR conflict problem. The second was a bit more intrinsic to the original approach: the idea of compressing part of the payload. Due to our highly stringent memory requirements (the target I had in mind was 16kB of RAM), we had to find a compression algorithm enabling decompression with very little memory, and very little access to the already decompressed data (we wanted to stream the decompressed data in the RAM buffer, not decompress the full payload).
... ➦While working on the project that led to RAVENS, Write-before-Read (WbR) conflicts appeared a little bit out of nowhere and almost became a showstopper. The algorithm Hugin uses to get rid of them is by far the most complex and time intensive part of the whole project. In this article, I’ll try to describe why they are such a big deal, how we got rid of them and why it took me so long. I would also like to apologize the poor showing of my artistic skills.
... ➦RAVENS was started in part as a security research project. Therefore, it has to go beyond simply installing an update, but also need to download it, in a potentially hostile environment.
Although this sounds like a solved problem (HTTPS!), this turned in a surprisingly complex problem when platform limitations had to be taken into account. Specifically, the devices we were targeting (that is, very low power devices powered by a monolithic MCU) may not have the memory to run a TLS stack. Moreover, those devices may lack a persistant clock and be unable to get a trustworthy source of time (making expiration tricky). To top it all off, those devices are mostly deterministic and don’t always have proper sources of entropy nor can be provisioned with device-specific secrets. Our transfer protocol thus had to do a lot, with very little.
RAVENS is the result of my internship at Orange. The challenge this project is solving is updating the firmware of extremely small devices in a secure, resilient and efficient manner.
The project is open source, available on GitHub at https://github.com/Orange-OpenSource/RAVENS. We’re open to suggestions, and pull requests! 😀
... ➦The most obvious challenge is not always the hardest to solve. This is the case of reliable in-place updates. How does RAVENS manage to rewrite “itself”, even if power is cut?
First, there is an important detail to note. Due to how limited are the devices that need this level of efficiency, the running program isn’t copied to RAM. This means that there are some ground rules: you can’t rewrite (i.e. erase the flash page of) running code. This put some restrictions on the update routine: the update code can’t be updated by itself, the update code must not move and as little code as possible should be involved in the update process.
... ➦TL;DR: Code is available on Github
Flamingo is a XMPP client released in 2012 which differentiate itself with a high quality design. Considering the competition consisted almost solely of Adium, a barely maintained, very old (probably the early OS X days) project based on libpurple. From a user experience perspective, Flamingo was light years ahead, but two problems prevented a migration to be a no brainer.
... ➦The release of the new iPad Pro, coupled with Apple communications trying to sell old PC users to iPad sparked some new debates on whatever this platform will overtake the world given the proper tools (the most realistic one being Xcode for iPad and the ability to side load apps (on which I don’t agree but whatever)). I initially wanted to unleash my (hotter) take on Twitter but instead decided to take some time to put it down in clearer words.
... ➦The subway is a strange place: very common in most of the large cities, faster and more reliable than busses, but yet, by its very nature, a challenge to use by navigation apps. By being underground most of the time, there is no GPS or WiFi signal, and LTE/3G is sporadic at best (beside a couple of cities, but far from the standard) and 2G signal would massively increase the battery strain. Moreover, I’m unsure the reception would be good enough to perform a localization precise enough. The builtin location service is thus out of question.
... ➦