As is the case for many people working in the security industry, the last few months of my life have been focused on dealing with people wanting to use LLMs everywhere. From an enterprise security perspective that’s not an inherent problem - what’s more of a problem is that people want those agents to have access to resources like their calendar and email and so on, and now we have somewhat non-deterministic agents that seem very enthusiastic to achieve what you asked whether that’s a good idea or not, and we’re combining this with credentials that give them access to sensitive data, and leaving those credentials on disk where they can be committed into git repos or exfiltrated to some other service to make use of them on the agent’s behalf or well just any other number of things, at which point your CEO’s email is suddenly readable by everyone and you’re having a bad day.

As I mentioned in my last post , pretty much every strong mechanism for keeping credentials in place is just not supported in the wider world. We can imagine a universe where agents use hardware (or at least hypervisor) backed certificates to obtain credentials and any that end up leaking are worthless as a result. But, sadly, that’s not an option for most people using existing identity providers. The state of the art is that you use the device code flow and a human authenticates and the token ends up back inside the agent environment and then it proceeds to do whatever it wants with it and you just hope that you wake up the next morning without an awful infoleak occurring.

(An aside: I do not like the device code flow as used in enterprise environments, and I never will. The identity provider doesn’t have a real opportuity to inspect the security posture of the system asking for the token, and as a result some identity providers will restrict tokens that are issued in this way. The common alternative of doing stuff using a more standard flow and having a redirect URI pointing at localhost works fine for local systems and is a pain for remote ones, even if you can commit crimes with SSH forwarding. I’m going to suggest something that I think is better, and you are free to disagree)

I’m not in a position to get every identity provider and service provider to change their security posture, so I’m somewhat stuck in terms of the tokens they’re willing to issue me - largely either JWTs or opaque access tokens, with no support for any mechanism of binding that token to an instance. The token that’s going to have to be provided to the remote service is something I have little influence over. But that doesn’t mean I can’t influence the token that lands inside the agent’s environment. I can issue a placeholder token to the agent, and force it to communicate via a proxy that swaps out the placeholder for the real thing. The worst the agent can do is exfiltrate the placeholder token, and as long as malicious actors don’t have access to that proxy, it doesn’t matter - nobody else can do anything with the placeholder.

This isn’t a terribly novel insight, and it seems like almost everybody has reinvented this on their own. But a lot of these implementations involve you somehow obtaining the real token in advance and then pasting that into something that generates a placeholder that you provide to your agent environment somehow, and it’s all a bit clunky and awkward, and it also means that you need to deal with something that keeps track of the mapping between placeholders and real tokens and oh no we’ve just invented a secret store, and if you want this to work at scale and reliably you’re just invented a high availability distributed secret store, and a lot of people who’ve read that are now shaking their heads and reaching for gin. Can we simplify this, and improve security at the same time? I think we can!

Remember when I said “as long as malicious actors don’t have access to that proxy, it doesn’t matter”? What if they do? What if they compromise one machine inside your environment and are then able to email a bunch of employees and convince their agents to send more tokens back to them and then delete the email before a human reads it? Now you have someone inside the wall with access to those tokens, and presumably with access to the proxy, and now they can be anyone whose agent was gullible enough to think sending them a token was a good idea. This isn’t good!

So, I thought for a while, and I came up with a new idea. We can have a broker service that obtains credentials for us. We can run that centrally, away from the agents. A client in an agentic environment can request a token, and that can result in a URL being generated and the user being directed to open a URL in a browser and authenticate. When the user authenticates, the authentication flow redirects the confirmation back via the broker, and the broker obtains the real auth token. The obvious thing to do now would be to return the auth token to the client in the agentic environment, but we don’t do that. Instead, we mint a new JWT, and add a new claim - one that contains an encrypted copy of the token. In the process we can copy over all the original claims, because those aren’t secret - and now even if the client inspects the token to figure out what access it has, it’ll get a correct answer. We sign the new token with our own signing key, and pass that back to the client. The client now has a legitimate JWT that is utterly useless, because the signature isn’t trusted by anyone other than us.

How does it use it? It makes an API request via a proxy, including the new token in the Authorization: header. The proxy verifies the signature on the token, and then decrypts the original token and swaps out the fake token for the real one. The remote API sees what it expects, and everyone is happy. There’s never a real token in the agentic environment, but also we don’t need to store anyting anywhere. The only state is the encryption keys, and those can be injected into the environment at startup. You need to scale? Just start more of these processes. You need to support multiple availability zones? Just start more of these processes in different places. No persistent data is ever held in the broker or the proxy. You don’t need to care about distributed databases or secret stores.

This felt wonderfully elegant and I felt smug about coming up with a better idea, and then I went to a bar earlier this week and sat down to read RFC 8705 and the guy next to me saw that over my shoulder and asked what I was reading and I explained why I was interested and we talked about agentic identity and then he mentioned that fly.io had something that sounded very similar and I read that and gosh yes it is very similar, so damn you fly.io for stealing my ideas 3 years before I even had them. Anyway. Now I need to do better.

Remember that there’s still a risk around anyone who has access to the proxy having access to the encrypted keys? We can remove that risk as well. It’s not uncommon for agentic environments to have an identity issued via something like SPIFFE , at which point they have a client certificate. You can probably guess where I’m going with this. If we require that an agent present a client cert to the broker when requesting a token, we can embed a representation of that client cert into the token we mint. The proxy can then require mTLS for the client connection, and can verify that the presented certificate matches the one represented in the token. If it does then whoever’s using the token has access to the private key associated with the environment it was issued to. If we then ensure that the private keys backing these certificates are either hardware or hypervisor backed, and as such tied to a specific instance, we now have a high degree of confidence that the token can only be used in its intended environment. Even if our identity provider doesn’t support RFC 8705, we can.

This is fairly straightforward where you’re using a platform where your identity provider is also the environment that’s consuming your tokens, and more annoying for third parties. The broker potentially needs some amount of third party vendor knowledge to make that work for everyone. This is even more the case where login isn’t via your identity provider (thanks, github), but none of this is insurmountable - just annoying. And where vendors issue opaque tokens rather than JWTs, this still isn’t a problem; we can just mint a new JWT that includes the opaque token as an encrypted claim, and include the same certificate binding. The opaque token ends up being the thing that’s presented to the third party, but only after we’ve verified the mTLS binding.

In an ideal world none of this would be necessary - someone would spin up a new agentic environment, a user would prove their identity, and a certificate embodying that identity would be issued to the environment with a private key that can’t be exfiltrated. That certificate would be sufficient to obtain new certificates associated with the same private key, and we could still bind that into mTLS identity. This would be much simpler, but browsers don’t support it, so it’s not likely to happen any time soon.

Anyway. Even if we can’t have the best thing, we can do better than we are at the moment, and also it would be lovely if we could standardise on this rather than have everyone build their own thing. The end.

It’s overdue, but here is my first progress update. If you haven’t read my introductory post , the short version: I’m implementing GPU reset recovery in Mutter , the Wayland compositor at the heart of GNOME Shell . When the GPU encounters a hardware- or driver-level fault and resets, invalidating the EGL context and wiping out all allocated GPU memory, Mutter currently has no way to recover. My project aims to change that.

Here is where things stand at the time of this writing:

After a period of normal operation, a reset is triggered: the display goes dark, then comes back once a new framebuffer is created (currently triggered manually by maximizing the active window via a keyboard shortcut). Windows are rendering, input works, the session is alive. You’ll notice the desktop background looks wrong after recovery; I’ll explain why later in this post. The compositor itself, however, is no longer dead.

The Problem

A GPU reset is the hardware’s way of recovering from a hang or fault in the graphics pipeline. For the rest of the system, it means the GPU’s state has been wiped: any GL context that existed before the reset is invalid, and all GPU-allocated memory (textures, framebuffers, shader programs, etc) is lost.

Mutter’s fundamental problem is that it doesn’t create a robust GL context. While Mutter does call GetGraphicsResetStatus() as part of its existing rendering logic, without opting into the appropriate reset notification mechanism, that call will never return a reset status, even when one has occurred. Mutter (on main ) simply has no way to detect a GPU reset, let alone recover from one.

The consequences in practice are severe. On some drivers (notably Mesa’s radeonsi/amdgpu), the driver deliberately kills the process when a non-robust GL context is present for a GPU that was reset. On others, Mutter would continue rendering blindly against an invalid context, with monitors on the affected GPU frozen on the last frame before the reset. GL errors accumulate on every subsequent frame, and the only way out is to kill the process. Either way, the session is lost, along with every application running within it. This has been a known, long-standing issue .

The Foundation

The API that makes detection and recovery possible is provided by the EXT_robustness OpenGL ES extension and its EGL counterpart, EXT_create_context_robustness . By specifying the EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY attribute with the value EGL_LOSE_CONTEXT_ON_RESET at context creation, we opt into deterministic reset notification: GetGraphicsResetStatus() will now reliably return a reset status when one has occurred, and the context is invalidated in a well-defined manner. Additionally, GetGraphicsResetStatus() can be called repeatedly with the lost context itself and will return NO_ERROR once the reset has fully completed, which is precisely how we know when it is safe to attempt restoration. It’s worth noting this isn’t universally available: not every driver implements reset notification, and even where the EGL/GL layer supports it, actual reset detection depends on cooperation from the kernel driver. Robustness is something we can build on, not something we can assume.

Before GSoC began, Robert had already laid the groundwork for this. His commit did the following:

• Registered EXT_create_context_robustness as a Cogl EGL winsys feature, so that its availability can be queried at runtime.
• Added EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY and EGL_LOSE_CONTEXT_ON_RESET to the attribute list at context creation, when that feature is available, creating a robust context for the first time.
• Added a stub clutter_backend_reset_context() as the hook where recovery logic would eventually live. For the time being, it simply emitted a warning.
• Wired up the detection path in meta_compositor_real_after_paint() ; whenever GetGraphicsResetStatus() returned a reset status, the stub was called.

He also added support for simulating GPU resets in Mesa’s llvmpipe software renderer ( MR !40681 ). By creating or modifying a file at a path specified by the LP_CONTEXT_RESET_FILE environment variable, all llvmpipe contexts using the LOSE_CONTEXT_ON_RESET strategy that were created before that file start reporting a reset; contexts created afterwards correctly report no error. Without this, the only way to test would be to induce actual hardware or driver failures, which is considerably less convenient.

The Recovery Cycle

The naive first instinct, which is to detect the reset, immediately recreate the context, and resume rendering, does not work, and for a subtle reason: a GPU reset is not instantaneous. After GetGraphicsResetStatus() first returns an error, the hardware may still be in the process of resetting. Attempting to recreate the context mid-reset invites further failure, and so the correct approach is to wait for the reset to complete before attempting any restoration.

This led to designing the recovery as a cycle with two phases, Reset and Restoration , tracked by a set of five states:

Graphics reset recovery cycle

All of this state management currently lives in ClutterBackend , with initial reset detection in ClutterStageView ‘s frame handler. When GetGraphicsResetStatus() first returns an error, the state transitions to RESET_IN_PROGRESS and a GLib timeout source begins polling for reset completion every 20 milliseconds. Once GetGraphicsResetStatus() returns NO_ERROR , indicating the hardware has finished resetting, we move to RESET_COMPLETED . If the reset takes longer than 2 seconds, we proceed to restoration anyway; empirically, if a reset is going to complete, it does so quickly.

The restoration phase runs entirely outside the frame dispatch loop, using GLib idle and timeout sources. When this starts, the state transitions to RESTORING . Thanks to Jonas , an important lesson from an earlier implementation was that restoration must not happen during frame dispatch, because that code runs per monitor; you do not want to recreate the EGL context for every connected display.

During recovery, every frame dispatch is aborted. The frame handler signals to the frame clock that the frame should be dropped without scheduling a replacement. This check occurs both at the beginning of the frame handler, before any rendering occurs, and at the end , to catch resets that occur mid-frame.

If restoration fails and retries exhaust a 2-second timeout, the state transitions to FAILED and Mutter exits gracefully with a descriptive error message, rather than aborting or hanging indefinitely.

Restoring The Graphics Pipeline

Once RESET_COMPLETED is reached, restoration begins. The core of it lives in clutter_backend_restore_graphics() , and the sequence is:

1. Unref and destroy the current CoglContext .
2. Tear down the CoglDisplay , destroying the underlying EGLContext .
3. Re-setup the CoglDisplay , creating a fresh EGLContext .
4. Create a new CoglContext against the newly set up display.
5. Emit ClutterBackend::graphics-reset to notify everything else.

Step 2 required a small new addition to Cogl: cogl_display_destroy() . Previously, there was no way to tear down a CoglDisplay ‘s contents without destroying the object itself, which would have invalidated references to it held throughout the codebase. The function calls the object’s destroy() implementation and marks it as no longer set up, leaving the object intact and ready to be re-setup.

Straightforward in isolation, but the interesting work is in everything that happens at step 5.

Propagating the reset through the compositor

ClutterBackend::graphics-reset is the hook through which the rest of the compositor learns that a new EGL context exists and needs to respond. Several objects connect to it, and the order in which their handlers run matters significantly.

The current sequence, enforced through the use of the G_CONNECT_AFTER flag, is as follows:

1. ClutterStage unrealizes: The stage is hidden and unrealize() is called on the stage actor, cascading down to all child actors (including every ClutterText in the scene graph). This must happen before the font renderer is recreated; more on why in the next section.
2. ClutterContext recreates the font renderer: ClutterPangoRenderer , which holds the GPU-backed glyph cache, is destroyed and recreated with the new CoglContext .
3. MetaBackend updates the stage: Stage views are rebuilt, and cursor rendering is updated.
4. ClutterStage realizes: The stage is realized against the freshly rebuilt views and shown again.

One improvement made along the way: Compositor view recreation was previously triggered by a signal emitted when monitors or monitor settings change. With graphics reset recovery requiring the same operation, MetaCompositor would have needed to listen to two sources, along with ordering concerns relative to MetaBackend ’s handler, which rebuilds the stage views. Instead, a new MetaRenderer::views-rebuilt signal was added, and emitted at the end of meta_renderer_real_rebuild_views() regardless of what triggered the rebuild. MetaCompositor now listens to that single, unified signal, and the ordering fragility is avoided entirely.

The signal handler ordering for the graphics-reset signal still depends to some extent on GLib connection order, which is not ideal. A more explicit, well-defined ordering mechanism is already in the works.

Recovering the glyph cache

Window content and client-rendered surfaces come back naturally once the context is recreated and stage views are rebuilt, clients re-render their Wayland buffers, and Mutter composites them. But some GPU-tied state lives inside the compositor itself and needs explicit recovery. The most intricate case encountered so far is the glyph cache.

ClutterPangoRenderer maintains a texture atlas of rendered glyphs, built up as text is drawn to the screen. When the GPU context is lost, that atlas is gone. Simply recreating the renderer, as ClutterContext does in step 2 above, creates a fresh, empty one. But there is a subtlety: ClutterText actors internally cache PangoLayout objects, and each layout carries rendering data tied to the old renderer via GObject qdata. Drawing text with a stale layout against the new renderer produces incorrect results or crashes.

The fix required a small chain of additions:

• clutter_forget_layout() , a new function in clutter-pango-render , removes the qdata from a given PangoLayout , severing its tie to the old renderer. It verifies that both the renderer and the qdata exist and that the qdata was produced by the current renderer before clearing it.
• ClutterText.unrealize() , a new virtual method implementation, calls clutter_forget_layout() on each of ClutterText ‘s internally cached layouts when the actor is unrealized.
• When ClutterStage unrealizes (step 1), the unrealize cascade reaches every ClutterText actor in the scene graph, clearing stale layout data across the board.

This is precisely why the stage must unrealize before the font renderer is recreated. ClutterText ‘s unrealize() calls clutter_forget_layout() , which requires the old renderer to still be alive to destroy the layout’s qdata. If the renderer were already replaced, it would be impossible to correctly destroy the data. The stage is then re-realized in step 4, after the new renderer exists and stage views have been rebuilt, allowing text to render cleanly from a fresh cache.

Where things stand

As the recording shows, the compositor survives a GPU reset, and the session remains usable: windows update correctly, input is responsive, and the session doesn’t crash or freeze. There are two notable gaps, though.

First, framebuffer recreation isn’t automatic yet. After recovery, the display stays dark until something triggers the creation of a new framebuffer; in the recording, I do this manually by maximizing the active window via a keyboard shortcut. Without that nudge, stage views are rebuilt, but nothing causes a fresh framebuffer to actually be allocated, so the screen just stays black. Making this automatic is one of the next things to sort out.

Second, once the display is back, the desktop background renders with incorrect or garbled textures. MetaBackgroundImage and MetaBackground hold references to GPU textures (primarily the background image loaded from disk), and MetaBackgroundContent defines GLSL shaders, all of which are invalidated by the reset. Recovering them requires updating these objects to re-upload their GPU-side resources after the reset.

There are also residual GL errors after recovery that need investigation, and the signal handler ordering situation deserves a more deterministic solution.

What’s next

• Signal handler ordering : replacing the implicit connection order dependency with an explicit, documented mechanism.
• Automatic framebuffer recreation : removing the dependency on a manual trigger (like maximizing a window) for the display to actually come back after recovery.
• Background texture recovery : getting MetaBackground and its counterparts to listen to the graphics reset signal and reload their GPU-side resources.
• Auditing remaining GPU-tied resources : ensuring nothing else in the compositor holds stale references after recovery.
• MR review and upstream integration : the current implementation lives on my fork and is primarily only reviewed by my mentors; as the approach stabilises, it will be proposed for upstream review.

Thanks

A huge thank you to my mentors Jonas Ådahl , Robert Mader , and Carlos Garnacho for their incredible guidance since the beginning. I’d also like to thank Bilal Elmoussaoui for the valuable review comments on my merge request. On to what’s next!

When you log into a service you’re given an authentication token. Each further request to the site includes that token, allowing the server to figure out who you are and ensuring that you have access to your data. Depending on site policy, this token may either be stored in memory (and so vanish if you restart your browser) or disk. The token is the proof of your identity. As far as the site is concerned, anyone with your token is you. These tokens may be traditional browser cookies, but they may also be stored in either site local storage or (if you’re not using a browser) in some other storage location.

In recent years we’ve seen infostealer malware (like LummaC2 ) gain the ability to exfiltrate user tokens, allowing attackers to gain access to the user’s data without needing to retain access to the user’s machine. This attack is viable even if the site has strong MFA requirements, so passkeys don’t help. Encrypting the tokens on disk doesn’t prevent the malware from scraping them out of the browser’s RAM or obtaining whatever key is used to encrypt them. This feels like a pretty hard problem to solve.

But that hasn’t stopped people from trying! Dirk Balfanz wrote an IETF draft describing a mechanism for using self-signed certificates for TLS authentication . This uses the mutual authentication feature of the TLS protocol that requires both sides prove their identity to each other. In regular TLS, the remote site presents a signed certificate that tells you who it is. When performing mutual authentication, you then present a certificate to the remote site telling it who you are. These client certificates are largely unused outside enterprise environments because they’re a huge pain to deploy. It’s not so much that this has sharp edges, it’s that it’s entirely made of sharp edges. Managing certificate deployment to your devices is hard. Browsers get confused if the certificates change under them. You have one certificate and it lives forever, so sites you present it to can track your identity. Users are prompted to choose a certificate to authenticate with, and if they pick the wrong one everything breaks and is hard to recover. I’ve deployed this and I did not have a good time.

But Balfanz’s idea was simple. Rather than require certificates to be deployed, browsers would simply generate a certificate on the fly. The goal wasn’t to prove the device or user’s identity in any global way - but it would associate a TLS session with a specific certificate. You could then, for example, include a hash of the certificate in the cookie, and if someone tried to use that cookie without presenting that certificate then the cookie could be rejected. If the browser used a hardware-backed private key for the certificate then it would be impossible for an attacker to steal it. Sure, you could still steal cookies, but you wouldn’t be able to use them.

This was written almost 15 years ago, and seems simple, elegant, and functional. It didn’t happen. Part of the reason for that is that, well, it wasn’t quite so simple. One problem was privacy related. Cookies are only sent after the TLS session is established, so anyone monitoring the network doesn’t know anything about the user identity. A naive implementation of this approach would have meant the client certificate being sent before session establishment, and now user identity can be tracked (no longer an issue if this was implemented on top of TLS 1.3, but this was a log time ago). This was avoided by reordering the client handshake, but that meant having to modify the TLS specification and implementations would have to be updated to support this. Another was that figuring out the granularity of the certificates was difficult. You’d want to use different certificates for every site to avoid them effectively becoming tracking cookies, but you need to provide the certificate before cookies are set, and you don’t know what origin the site is going to set in its cookies. If you generate a certificate for a.example.com and a different one for b.example.com, and a.example.com sets a cookie for *.example.com and includes the certificate you used for a.example.com, that cookie isn’t going to work on b.example.com and things are broken. This meant supporting it wasn’t as straightforward as it seemed - you’d need to ensure that your cookie scope was compatible with the certificate scope. You could probably make this work well enough by aligning it with the Public Suffix List , but there was still some risk of expectations not being aligned.

And, perhaps most importantly, TLS session resumption (replaced by pre-shared keys in TLS 1.3) somewhat defeats the purpose of the exercise - clients store state that allows them to re-establish a TLS connection without performing certificate exchange (this reduces overhead if a connection gets interrupted or you switch to a new network or anything along those lines), and anyone in a position to steal cookies could steal that state as well.

The followup attempt was channel IDs . This simplified the implementation somewhat - rather than certificates, a raw public key would be sent, along with proof of possession of the private key in the form of a signature over a portion of the TLS handshake. This was required even in the event of session resumption, which avoided having to worry about theft of session secrets. The timing of the exchange was after the encrypted session had been established, so user identity couldn’t be leaked that way either. Cookies could then be bound to this identifier. Unfortunately it didn’t really deal with the problem of scoping keys in a way that would match cookie requirements, and the spec suggests that the right way of handling this is to scope keys to TLDs, which would enable user tracking across sites (Chrome’s implementation apparently restricted it to eTLD+1, which would match the third party cookie policy and avoid the tracking risk).

Chrome added support for this, but it was removed in early 2018 . The discussion of some of the pain points in that message is interesting, explicitly calling out problems with connection coalescing across domains and the incompatibility with zero-RTT TLS1.3. The overall consensus at the time seems to be that trying to solve this entirely at the TLS layer has too many rough edges, and a different approach should be taken.

And so almost 7 years after the initial draft for origin bound certificates, we come to token binding . This ended up being a rather more complex endeavour, covering 3 different RFCs describing how it impacts TLS, how to incorporate it into HTTP, and how to manage all the various parties involved in the process. The short version is that it’s pretty similar to channel ID, except that there’s also a documented mechanism for allowing tokens to be bound to one party and consumed by another, avoiding any need for widely scoped keys. Token binding effectively solved all the issues in the original proposal, but at the cost of somewhat more complexity.

The RFC was finalised in October 2018. Chrome removed its (incomplete, draft) support for token binding in November 2018. Edge carried support until late 2024. Despite getting all the way through the RFC process, it’s functionally dead.

The process up until this point had been largely initiated by Google, with Microsoft contributing significantly to the token binding standards. The work had been focused on identifying a generic solution to the problem rather than tying it to any specific authentication flow. The next step was in a different direction - rather than trying to fix this for the entire internet, how about we try to fix it for OAuth?

RFC 8705 is titled “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”. This is basically the 2011 approach, but (a) with an explicit definition of how the certificate should be incorporated into issued auth cookies, and (b) with a proviso that well uh if you’re going to use tokens issued by your IdP to authenticate to someone else then well you’re going to need to use the same cert for both. This is probably fine for the company-owned-laptop case where you’re actually fine with multiple sites being able to tie identities together (that’s kind of the point here!), and also works for “I am using an app and not a browser”, but doesn’t work for more generic scenarios. It also doesn’t seem to take the session resumption case into account at all? Support for RFC8705 seems poor, as far as I can tell of the big players only Auth0 implements it. In theory it works fine with self-signed client certs but in reality that’s going to be almost as difficult to support across multiple platforms as just issuing proper client certs in the first place, so deployment is going to be kind of a pain. But the good news is it doesn’t rely on any TLS extensions or custom browser behaviour, so at the client side it works fine with any browser.

Which brings us on to RFC 9449 , “Demonstrating Proof of Possession”. This goes even further than RFC8705 in terms of reducing the burden of deployment - it works fine with existing browsers, and it doesn’t even require any certs. The client generates a keypair and provides the pubkey when requesting the cookie. The cookie contains the pubkey. Every request to the service now provides the cookie with the pubkey and also provides a signature over the URI and HTTP method. If the signature matches the pubkey in the token then clearly the signature came from the machine the token was issued to, and everything is good.

This does come with some downsides, though. The first is that it uses browser interfaces to generate the keys (typically crypto.subtle.generatekey() ) and as far as I can tell there are no browsers that guarantee that that key is going to be generated in hardware even if it’s marked non-exportable, so anyone able to steal the cookies can also steal the keys. The second is that the signature only covers the URI and HTTP method, and not the message content or any other headers, so anyone able to exfiltrate a valid signature can replay it against the same URI with different message content. The recommended way to handle this is to reject any signatures that weren’t generated within the last few seconds, which is a wonderful additional way to allow clock skew to give you a Bad Day. And the third is that every single request has to be separately signed, which is not intrinsically a problem because computers are fast and have multiple cores, but if you’re trying to solve the first problem by sticking the key in a TPM then you’re dealing with something that’s slow and single threaded and that’s maybe acceptable if you’re using client certificates (because there’s going to be one signature per session and you can use the same session for multiple requests) but probably not if you’re dealing with a user opening a browser that restores previous tabs and each of those is a webapp that fires off 100 requests in parallel.

In case it wasn’t clear, I don’t like DPoP. It doesn’t feel like it actually solves the underlying problem that we see in the real world (malware running in a context where if it can grab the tokens it can grab the keys), it adds a massive amount of overhead, and it has baked in replay vulnerabilities. I don’t know why it exists and I’m incredibly suspicious of vendors telling me that it fixes my problems, because if they’re telling me that then I’m going to end up assuming that they either don’t understand my problems or they don’t understand their technology, and neither of those is good.

Still. Then we get to the thing that prompted me to write this - Chrome’s announcement that they had launched device-bound session credentials . This is interesting because it’s a Chrome feature that’s explicitly intended to counter on-device malware, which was one of the things that was out of scope in 2018 when token binding was being removed. Since this is entire web level it doesn’t have to be an RFC, and so is instead defined by W3C . I’m going to handwave all the complexity and say that it’s basically a way to register a public key when a cookie is issued, and then prove possession of the private key when it’s time to renew the cookie. By making the cookies shortlived and having support for rotating them in the background, user impact is basically zero and while it’s still possible for an attacker to exfiltrate and use a cookie they’ll only be able to do so for a short window before it needs to be refreshed - something the attacker can’t do, since they don’t have the private key. This avoids the DPoP overhead because you only need to do signing once per cookie per cookie lifetime, and not on every single request. I don’t like this due to the window where exfiltrated tokens can be used, but it feels like a strict improvement over the status quo. An extension called device-bound session credentials for enterprise allows pre-enrollment of device keys, so even though the actual runtime DBCE flow doesn’t involve certificates, certificates can be used for device registration in enterprise environments and you can make sure that auth cookies only go to trusted devices. Unfortunately this is Chrome-only, and so we’re going to need to wait for it to be backported to all the random app frameworks for it to have widespread support on mobile or for almost everyone’s desktop app that’s actually three websites in an Electron wrapper. Mozilla’s current position is that they’re not in favour of it, so I guess we’ll see where Safari lands in terms of broad uptake.

The last thing on my list is another client cert/OAuth binding , this one still in draft state at the time of writing. This one is aimed primarily at the use of agent-driven tooling, where you have something running in the background using a whole bunch of tools that are each acting on your behalf. Authenticating to all of them separately isn’t a fun time, but giving broadly scoped access tokens to a non-deterministic agent and trusting that it’ll never post them somewhere public also isn’t a fun time. The key distinction between it and RFC8705 is that it’s aimed at connections rather than sessions , which avoids the worries about session resumption. This is done with TLS Exporters , which in TLS 1.3 should be unique to the connection even over session resumption (TLS 1.2 may reuse some of the same key material for exporters over session resumption, so it’s recommended to enforce 1.3 for this). By providing a new signature alongside the cookie on every new connection, the client proves that it still has access to the private key. This is a very new spec and I haven’t had much time to work through it yet, but my naive understanding is that unlike RFC8705 this would require some additional client support to be able to regenerate the client signature on every TLS reconnection.

This doesn’t avoid all the problems that RFC8705 has, including how to scope certificates. For the agentic use case that probably doesn’t matter - all these tools are acting on behalf of the same user, it’s fine if all the sites involved know they’re the same user. But it doesn’t solve the general purpose user use case, and right now DBSC seems like the best we have there.

But. Part of me still wonders whether Dirk Balfanz’s approach was the right one. Yes, there’s risk associated with TLS session resumption, but in the worst case you could just switch that off for high risk setups. The cookie scope argument is real, and also in cases where it could violate privacy the site owner could already choose to broaden their cookie scope and violate your privacy, and in cases where it breaks things you could just not make use of it. The other problems are largely fixed by TLS 1.3, and then we’re just left with “Browsers handle client certificates badly” to which my answer is “Yes, and we should fix that anyway”.

Despite having a pretty good answer to this solution over a decade ago, the closest we have to actual deployment is something that offers strictly worse security guarantees. And tokens keep getting stolen, and compromises keep occurring, and for the most part people shrug and get on with things.

Hello GNOME, This is a progress report on the Pitivi Timeline Ruler Rust rewrite.

Progress

We are rewriting the Pitivi Ruler in Rust using a modern GtkSnapshot rendering pipeline to improve performance and memory safety. At its current stage the ruler is being constructed as a standalone widget in a personal repository that can be found here:

Pitivi Timeline Ruler

GTK_DEBUG=interactive cargo run --example sandbox

Any feedback on the code is greatly appreciated!

Updates

The widget is drawing well and a lot of the initial bugs have been ironed out.

A major structural change that has been made after mentor feedback was to pull state orchestration out of the widget itself, and keep more of the logic on the app side. The goal is a "dumb widget, smart app" framework, where the ruler acts as a stateless viewport. The app (or sandbox example) provides the logic for how to handle gestures and what to do when the user interacts with the widget. One example of this is that project_duration was removed as a property entirely, and logic around bounds is now handled entirely on the app side. This allows the widget to be used in a variety of contexts, and allows the app to handle bounds in whatever way is appropriate for the context.

Beyond the pivot on structure, some key systems-level refinements were made:

• Property types we refactored heavily as this moved past the rough prototype stage. zoom_level received a rename to ns_per_pixel to better reflect what the property actually represents. Many properties dealing with pixels were changed to unsigned integers, which allowed me to delete out some negative checks.

• The project does now include a rough doc string and comment draft for the widget, which will be fleshed out more as the widget matures and more of the public API is finalized.

• Cache clearing was added to set_ns_per_pixel to prevent modulo math escapes during purging of cached layouts when users change the zoom level.

Next Steps

The major milestone ahead is the implementation of a custom gtk::LayoutManager to handle the layout of children widgets.

Once the PitiviTimelineLayoutManager is implemented, the playhead rendering will be moved out of the ruler's snapshot pipeline and into the layout manager as a distinct child widget. This will allow Pitivi to easily inject custom markers, loop-brackets, and multiple playheads without modifying the underlying ruler engine.

I am currently studying Marc-André Lureau's rdw (Remote Desktop Widget) repository as a guide on how to make this update.

Uh, it’s been a while. Let me try to pick up blogging again…

I got in touch with ISO standards , also called “norms”. In particular, the information security norms from the ISO 27000 family. I won’t talk much about them in particular but rather about their delivery and how to improve their visual appearance.

During the last three years, many things were converted to online-only formats. Conferences were held exclusively online, work was performed from the hopefully cosy places of one’s home, and trainings were given remotely, with no physical interaction whatsoever.

As part of one of those trainings, I received a set of ISO norms as a PDF file. The PDF renders nicely, despite some fonts not being embedded (looking at you, Helvetica!). One annoying problem, though, is that the document contains more ink than necessary. In particular, some tracking information is printed on the left border of each page. It’s also true for documents obtained via “ Perinorm ” or “ Nautos ” by German scholars.

I prefer real paper for reading so I intend to print the PDF but at the same time, I only want to make printing as expensive as it needs to be. Because I will keep the printed pages safely at home, I have no need to print the tracking information on the left border of each page, if only, because I don’t want to worry and run to the printer straight away, before a colleague can fetch it out of there and get me in trouble for sharing it somewhere. So I decided to save myself some toner and some electricity by removing all that information that is not part of the actual standard.

One approach is to open the document up in some PDF modification software and delete the offending objects from each page. But there are some obstacles. Firstly, the documents are “encrypted”, so my Master PDF editor complains:

Bummer. The encryption, depending on the standard , is anything from a weak RC4 to modern AES. Ignoring the problems with cryptography in PDF, it can actually be pretty secure. So my best guess was to launch “ pdfcrack “. I was prepared to wait for a few days or weeks. After all, I could wait for reading those documents for so many years, a few weeks more or later wouldn’t matter much to me. To my surprise, though, pdfcrack returned immediately. Reporting that the password was the empty string. Well.. Okay.. Then I could launch pdfcpu decrypt and finally edit the document. Selecting and deleting the object on one page was easily done.

The next problem, though, was that I had to deal with about 100 pages. Unfortunately, I could not find anything like a macro for MasterPDF-Editor. As in “Select this text”, “Delete”, “Scroll to next page”, “repeat”. Surely, going through each page and manually selecting the offending object and deleting it would be a waste of my time, as XKCD readers will appreciate.

Fortunately, removing content from the left border is a somewhat solved problem . I played around with pdfcrop , trying to first remove and then re-add the border. But that was all messy and didn’t work out, anyway.

I resorted to using “ iText : The Leading PDF Library for Developers”:
$ cat RemoveContentInRectangle.java

package com.itextpdf.samples.sandbox.parse;

import com.itextpdf.kernel.colors.ColorConstants;
import com.itextpdf.kernel.geom.Rectangle;
import com.itextpdf.kernel.pdf.PdfDocument;
import com.itextpdf.kernel.pdf.PdfReader;
import com.itextpdf.kernel.pdf.PdfWriter;
import com.itextpdf.pdfcleanup.PdfCleanUpLocation;
import com.itextpdf.pdfcleanup.PdfCleaner;

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

public class RemoveContentInRectangle {
public static String DEST = "./target/sandbox/parse/remove_content_in_rectangle.pdf";

public static String SRC = "./page229.pdf";

public static void main(String[] args) throws IOException {
for (String arg: args) {
System.out.println("Arg: " + arg);
}
SRC = args[0];
DEST = args[1];
File file = new File(DEST);
//file.getParentFile().mkdirs();

new RemoveContentInRectangle().manipulatePdf(DEST);
}

protected void manipulatePdf(String dest) throws IOException {
PdfDocument pdfDoc = new PdfDocument(new PdfReader(SRC), new PdfWriter(dest));

List cleanUpLocations = new ArrayList();

int ppage = 1;
for (var page = 1; page <= pdfDoc.getNumberOfPages(); page++) {
// The arguments of the PdfCleanUpLocation constructor: the number of page to be cleaned up,
// a Rectangle defining the area on the page we want to clean up,
// a color which will be used while filling the cleaned area.
PdfCleanUpLocation location = new PdfCleanUpLocation(page, new Rectangle(5, 5, 15, 990),
ColorConstants.WHITE);
cleanUpLocations.add(location);
}

PdfCleaner.cleanUp(pdfDoc, cleanUpLocations);

pdfDoc.close();
}
}

I tried to adjust the rectangle arguments until I had a satisfactory result. That’s a bit annoying but worked well enough for me. Another annoyance is to get hold of the dependencies, but with a bit of searching it should be possible to obtain the jar files:
$ java -cp /usr/share/java/slf4j-api.jar:itext/kernel-7.2.2.jar:itext/commons-7.2.2.jar:itext/io-7.2.2.jar:itext/layout-7.2.2.jar:itext/cleanup-3.0.0.jar RemoveContentInRectangle.java iso.pdf foo.pdf


Before being able to process the files, I gave them a good rinse, because some files were causing trouble:

$ for pdf in ../*.PDF; do gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS="/ebook" -sOutputFile=$pdf.rewrite.pdf $pdf; done

And finally, for good measure, try to get rid of some metadata, to make a file weigh a bit less on the hard-drive:

If you want to restore the document’s metadata because you don’t like how pdfcpu messed with it, the following could help:
$ for pdf in *.PDF; do exiftool -tagsFromFile $pdf $pdf.cleaned.pdf ; done


But you could also delete all metadata (don’t use exiftool for cleaning PDF metadata without flattening the PDF afterwards).
After that treatment, I can print the PDF on the central office printer without fearing anybody taking my printout and getting me in trouble.

If you happen to have some documents that you want to free from tracking data, especially such standards, I’d be happy to assist you.

This blog post is a sequel to Your _get_type() function is not G_GNUC_CONST .

GNOME developers have long used G_GNUC_CONST , which expands to __attribute__((const)) , to annotate GObject _get_type() functions, despite knowing that it is incorrect to do so. const functions by definition have no side effects, but _get_type() functions actually have a side effect the first time the function is called: they initialize the type. Why apply an incorrect annotation to these functions? Because it makes the code faster.

Although this was long known to be incorrect , it worked fine in practice… until now. Regrettably, Sam James has discovered that GCC 16 may optimize away the type initialization , resulting in crashes. This is our fault for providing the compiler with wrong information about our code, so it’s time to audit your use of const attributes to remove them from _get_type() functions. Most GNOME programs use these attributes only for _get_type() functions, but if you use it in more places, then check to make sure those functions are actually const, as defined by the GCC documentation .

Sadly, there is no suitable replacement attribute for _get_type() functions. Two decades ago, Behdad requested a new idempotent attribute for expressing the desired semantics, but nobody has implemented it.

File under: brief half-year catch-ups, me not remembering when I last updated the back-end of this blog

I’m writing this from a terrible AirBnB in Reading, having just wrapped up a four-day visit to my old Typography & Graphic Communication alma mater and happy to have an excuse to put off re-packing. I’ve been fortunate in the first six months of this year to have time to participate in a number of in-person conferences after a few years of not being able to travel, and when I was looking back at the calendar I noticed that these events have been evenly split between FOSS events and type-related events, so I decided it’s worth jotting down a few of the thoughts that presented themselves before they fade away entirely. Here’s a recap:

SCALE : The Southern California Linux Expo (which, for the record, I refuse to bacronymize in a mixed-case form, so don’t at me about the capital A). I’ve been a regular for yikes years at this point, and have helped coordinate the “libre graphics track” for the past several, but this time I actually had to present a workshop as part of that. It was on the subject of learning Scribus if you’re coming from the world of LibreOffice / Microsoft Word / Google Docs / Etc. Turns out that’s an ambitious subject, scope-wise, and we didn’t get through everything I wanted to.

But for me, that highlights the fact that shifting from one Do Real Work application to another is always a monumental effort. Sure, you can fire up GIMP and do some cropping of images in a matter of minutes. But you can’t drop a full production workflow without a lot of spare time, because every individual sub-task now involves a different order of operations (or different operations), a different cycle of tool-switching, and a different set of cross-checks and QA. I don’t think we give this problem enough attention, especially when the well-meaningers on social media (and yeah, that includes Mastodon, as fully as whatever platform you don’t like) entice people to give it a try like it’s no big thing.

It also reiterated for me how important document templates are. Those are fairly forgettable 99% of the time, but what ships in the template choosers of LibreOffice, WhateverOfficeOnline, and in more specialist apps is what people end up using when they need to get things done. The typography in most FOSS templates is pretty awful: the fonts are weak, the hierarchies are non-existent, the alignments are haphazard, and the optical balance is even more non-existent than the hierarchies. I suspect that this can only being improved with a long, slow, many-person grind. I don’t know where to start.

WAVE and ATypI : Both of these are type-related or type-adjacent events, so I don’t have much that feels relevant to say about them here. WAVE is quite specialized, since it focuses on human writing: just as many of the presenters are linguists as anything else, and the type people made a stronger showing this year than they did in the original event a couple of years back but aren’t the majority. It is genuinely a wake-up call to sit down and learn about a written language that does not operate in the way that your own does, and to hear exactly how many people use it every day (as well as to see photos to remind you that all of this happens in the present, when it’s incredibly easy to write off those concerns as belonging to an earlier era in printing and just presume that Computers Fixed All That. Or that OpenType and Unicode did. Or that FOSS did.).

I do think, however, that most of the FOSS projects I’m involved with keep a stout set of blinders on about non-majority language systems and scripts, and that that’s deeply problematic. Indeed, it was not long ago that I mentioned IRL that GNOME could do a valuable bit of good for the global user community by finding and supporting scripts other than Latin/Greek/Cyrillic — in contrast to today, where the attitude is “oh, those users will figure it out for themselves like they always do aren’t they great over there” and/or “Noto Fixed All That.” It’s not hard to say that the next release of your project will also support, say, Arabic, and to at the very least be deliberate about bringing people into the room to find and test the fonts you need to determine if things are working and look good. Yes, you do have to do actual tests. Yes, I mean you.

ATypI, in contrast, is very much a “type production” event. For me, this year the bit that stood out was behind-the-scenes stuff that eeped out around the seams and got more widely discussed. Like, there was evidently initial interest from some on the local organizing side that there would be a verrrry small list of presenters: less than two dozen, total, for 3–4 days (depending on how you count workshops and exhibits). Far less than two dozen. There are two big gotchas there. First, you have to contend with gatekeeping. All of the well-known people are likely to be the ones with The Exciting Announcement to announce and, in theory, they’re a big part of the draw. But that keeps all the new community members out. Second, it crashes the economic viability of attending the event. The locale this time was Stanford, which (despite being perhaps the world’s only Junior University, look it up) is outrageously expensive, even if you already live outrageously in nearby northern California. And any time people can’t justify the cost of travel, yes you’re gatekeeping again (particularly of the hallway track), but you’re also twisting the dial on your conference further from “I Should Go” over to “Going Is Just Paying Money To Be In The Audience Of A YouTube Video That I Can Watch Any Other Time” … which is a hard dial to reverse.

LGM : The Libre Graphics Meeting seems to be back on its feet and in good form after several post-pandemic years of bumping into things. Massive props. I had a lot of side-project stuff I brought along in disorganized form, although I attended every session. I also quasi-roundtabled a session to talk about how the now defunct “Planet LibreGraphics”, may it rest unpeacefully, used to be the clear answer to the perpetual question of “how do we maintain momentum and connection the rest of the year?”

But whereas the old Planet site was a garden variety class-M aggregator of individual blogs’ RSS or Atom feeds, I’m of the unprofessional opinion that a true community aggregator today has to account for different types of inputs and outputs and user modes (sideputs?). E.g., many projects don’t announce new releases on their project blog anymore; they tag a release on GitHub. That’s a different input. A lot of people don’t post long-form content anymore, but do a lot of microblogging. That might suggest having an ActivityPub output … but it would be a bot, and it would incur a TON of overhead and put scores of messages out all day long, which you definitely couldn’t use on the traditional RSS output. So you probably need to handle those differently, maybe batching the Mastodon bits into a once-per-day blog output?

Ultimately, I’m not sure; there are a lot of these details. We’re way out in the high-cosmic-ray environment of the trans-neptunians here, or some other metaphor. Ping me if you find the question interesting, because I want to talk a lot more about it.

LAS : It was my first time going to the Linux Application Summit, as the kids call it these days, so I have more thoughts to get down about that one. For starters, it wasn’t what I expected, because I expected there to be more people there who develop Linux applications. I covered a lot of growth of post–CD-delivered-and-RPM/Apt-updated packaging efforts when I was toiling as a not-so-young FOSS journalist, so I do think I have the right grounding in systems like Snap, Flatpak, FlatHub, AppKit, immutable-image OS approaches and other user-code–confinement technical building blocks. Except Kubernetes; I never cared about that and never will.

Anyway, all of that stuff (hand-waving) is very much where LAS takes place. It’s really good to see that there are people from multiple application ecosystems talking about how they handle the current set of unsolved problems. Selfishly, one of the sessions that stood out most to me was Carlos Garnacho’s talk about the data-search layer that he’s been working on. The gist there is that it’s for searching local data … which you might think you can already do, but you’d be wrong. You can sort of do filesystem-level text searching, but that doesn’t handle complex stuff, and it really, really doesn’t let you handle per-application searching well. I’ve got a keen interest in what people do with their “big data exports” — we FOSS people like to look down our noses at the public and tell them that they should take all of their content out of The Bad Services and walk into the sunlight. But there’s not anything they can do with it when they get here (or there, depending on how you feel), and they’re the ones holding the bag. The TinySparql and LocalSearch stuff, I think, holds the potential to improve on that in a big way.

I was also quite interested to learn more about how the KDE ecosystem does its builds. I don’t do … builds, at least not in the sense that KDE and GNOME do (nor, who else, who else … Enlightenment, maybe?). But I have been forced against my will to get up to speed on some things like GitHub Actions, and the session about KDE’s build architecture did make me want to go back and re-examine some stuff I’ve built. That being the other sense of “build.” I was also very interested in Evangelos Paterakis’s talk about the gritty realities of picking up an abandoned project, reviving it in fork-form, and getting hit with the consequences of that discussion from both upstream and downstream.

For most people, what matters in these sort of pseudoplumbing projects in what’s going to be accessible in end-user applications whenever they land on the next platform releases. That’s why I thought I might encounter app developers at LAS. Instead, much of the session content was about enhancing the the plumbing layer themselves: what’s going on with portals, how sandbox/confinement techniques either fail-open or fail-close, and where the confined-application model is still leaking.

I suggest checking out Sebastien Wick’s talk about the portal situation if nothing else; the slides are available now, even if the video is not. Whenever the videos go up, I also suggest that everyone watches the session about forking a defunct project … not because it’s something everyone should do, although let’s face it, projects appear and fizzle all the time. But mainly because the social aspects of how a revived fork does or doesn’t catch on are things the FOSS community doesn’t say out loud. Not bad or shameful things, just sharp corners.

All that said, I think that what really needs to happen is for application developers to actually go to this event. I know you think you don’t need to. But the platform layer is another one of those things about which you can easily say “Didn’t Somebody Already Handle That?” and be incorrect for a long period of time before it bites you. Moreover, every time I’ve ever asked the developer of a Mac or Windows desktop app what they know about developing Linux apps, they tell me a story about running into giant potholes, missing documentation, and mismatched API expectations. The presence of Linux app developers at a plumbing-layer conference will not instantly fix that, but I do know that a lot of those Linux developers hit the same roadblocks.

LGM made a massive improvement to the ecosystem of creative-arts apps in FOSS specifically because it involved getting users, app developers, and subsystem developers into a single space. That’s not a magic trick, and the general Linux app universe would benefit from repeating the technique.

Grapholinguistics in the 21st century , also known as /gĘafematik/ : This is the one I just came from, and I don’t quite have it all simmered from ingredients into stew just yet. Apart from being hosted in an initially un-airconditioned spot at the university in the hottest UK week since 1666, I don’t think I have any complaints. I introduced speakers and acted as moderator for Q&A blocks, and apart from that I visited with most but not all of the rest of the quantitative type-research clique. You know where to find us.

One takeaway, perhaps, that will be generally useful is that I spent much of the inter-session time when I was on moderator duty trying to gauge the level of nervousness of the upcoming speaker and attempting to defuse it. I don’t know how successful that actually was, but I do think there were sessions elsewhere where it might have made a difference. I don’t know; perhaps that’s projecting.

Anyway, before the Internet runs out of bits, I should wrap up. I do need to be sure to express my appreciation to the GNOME Foundation, who chipped in with some travel expense assistance for LAS, as well as to my friend and mentor-in-a-few-very,-very-limited-capacities-I-can’t-emphasize-that-part-enough Sri Ramkrishna for pinging me about it and then reminding me. I’m definitely glad I went.

At the moment, I’m halfway through reconfiguring the blog site here into static format (fighting Unicode support in the old platform), so don’t count on commenting to work. If you want to reply to anything I said here, try me on Mastodon .