We (Firefly) also wanted to extend a massive thanks to @thedaofund, @quantstamp and @wintermute_t for their role in helping Firefly thrive via GivETH.

Their strong alignment with open-source projects and philosophies makes the world a better, more free (as in speech) place. :)

Thank you! Your support (financial and morale) keeps us ticking and keeps us excited.

I was an avid iOS developer when it launched, and love how obsessed with attention to detail the iOS human-interface guidelines were and just in general with all the little things the Cocoa API took into account and cared far too much about.

It was largely fluff, fancy animations and interactions with weight, like stretching near the end of a scollable area. But all the fluff made the phone more intuitive to use and helped convey the topology, like when a window slides offscreen to the left, it was obvious where it went and how to swipe to get it back.

But also the Apple apps used the same API (with very few exceptions) and same fluffy UX recommendations in their first-party apps as was available to third-party apps. It is powerful dog-fooding and encouraged everyone to make apps that felt like they belonged.

For Firefly, we love the fluff too. We feel it is important for a security device to be easy and intuitive to use.

It should be something you want to use and enjoyable. You should never be confused about what it is doing or what you need to do next. It must be fun, beautiful and intuive. Via fluff and such.

A big step towards being able to add more fluff are hierarchal clipping masks, which open up true scrolling and lay the ground work for the future, such as composite layers, localized blurring effects and nested translucent items.

The scene graph now has complete support for clipping bounds (if you are a CSS person, think overflow: hidden. This allows a given node to clip (not render) anything outside a given bounds, including its children.

A common use for this is creating a more intuitive scrolling UI element, as things scroll within it, they don't extend outside the scrollable area.

Examples below, showing what a world without clipping looks like, where text must scroll an entire segment at a time, and with clipping where we can smoothly scroll as the text is clipped as it moves past the top bounds of the scroll area and new text scrolls in from the bottom.

A model of the Firefly exists with support for a secure-enclave, but we also want to work towards a world where only commodity hardware is required, while still mitigating the associated risks.

A key derivation function (KDF) converts a password or PIN into an encryption key, which can be used to encrypt and decrypt secret information, such as private keys, address books, etc. A common feature of many KDF's is key-stretching, which increases the amount of time and resources required to brute-force guess a password.

For example, with 10 seconds of key-stretching, to brute-force 10,000 passwords (i.e. a 4-digit pin), an attacker needs to spend 100,000 seconds on a single computer (which is just over a day) or spend 10 seconds of time across 10,000 computers (vastly increases the hardware costs) or any linear combination in between.

For a 7 digit pin that becomes 3 years on a single computer. Extended to include non-trivial passwords, that space expands rapidly.

It does mean the legitimate user, who really does know their password, is required to wait 10 seconds for their device to become unlocked after entering their password.

A feature of a provisioned Firefly is read-protected and write-protected RSA private key, which was derived entirely on-device during its provisioning and has never existed outside of the device and its secure region call the Digital Signing Peripheral.

Since the key can never be extracted and the key has never been copied, only that device can use it, which cuts off the above 10,000 computers strategy.

With a 7-digit PIN, a given Firefly would need to run straight for 3 years to brute-force the PIN, during which time hopefully you'd notice your missing device and move your funds to a new device. Of course not everyone picks good PINs, so there is nuance we can go further into, in the future. Letting the device randomly choose your PIN can solve this, but at the risk of the user being more likely to forget their PIN.

To illustrate this simple primitive, you can imagine the following simplified psuedo-code:

Thanks for checking out this article, and please feel free to follow us on GitHub and Twitter/X. (or follow me, ricmoo).

We're planning on a lot more technical and semi-technical articles in the near future. :)