Well the basic premise was to use a security protocol to deny service locally to a domain after that domain will have loaded client-side code into the browser as a service worker. It's described with more detail near the end of the deck:
https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20pre... -- but the practical implementation of the aforementioned is to cause local DoS by means of rapid key rotation on a domain protected by HPKP. By rotating keys (cyph.ws does this just about once every twelve hours, for instance), you can trap a service worker in the browser for up to 60 days, the length of time pins are permitted to be valid with supported browsers. I'm pretty sure we coined "HPKP suicide" for publicity's sake, but should any other ultra-footgun-prone client-side TLS-impacting security protocols emerge, this same pattern should be feasible with those as well. Local DoS was briefly described as a risk in the HPKP RFC, and we further fleshed it out and reduced it to practice as a tool for engineers to achieve the goal described in my last comment (equal credits to Ryan Lester and Jann Horn as well).
The specific device we put into production (and patented because of its criticality to Cyph) worked through the use of localized denial of service to pin signature validation logic into the local store of the browser to verify payloads received from other endpoints; in our case, we pin bad keys for the maximum permitted duration. That said, there are many different ways to use HPKP suicide that don't have to do with adding signature validation for client-side application logic, and they still come fairly close to achieving the goal of reducing how often you have to trust the server. The pattern described in this paragraph allows for Cyph to deploy new builds of the full messaging application whenever by just signing new builds such that they're validated by the pinned service worker, but if that flexibility is not a necessity, keep reading.
Since you can effectively pin any code into the browser through HPKP suicide, one different approach might be to pin a key for a more reasonable amount of time, such as two weeks, in order to stick e.g. critical application logic in the browser and rest assured that each user will use a certain build for at least two weeks time. This has the effect of reducing the exposure of an application's userbase in the event of a service compromise—at the expense of possibly committing some users to a bad build (or possibly even a compromised build) unless they manually clear pins. If you're writing a light application, this'll serve you pretty well. If you're writing a heavier application, you can outsource most of the heavier dependencies through SRI (the code pinned as the service worker would use SRI to validate the supporting libraries). The nuance here is that you're not implementing signature validation; you're just relying on that local DoS to ensure that certain code stays in the browser for as long as the bad keys are pinned and just confirming that any separate resources hash as what you'd expect them to. You're still certain to see that code--and any hashes you bake into it for SRI, should you choose to go this route--persist for as long as the invalid pins are live in your users' browsers.
HPKP still works in Firefox, so we intend to continue to research this pattern and related implementations of it. However, considering the browser with the largest market share just deprecated it while publicly mentioning the risk of footgunning via the standard, I'm not sure how much you stand to gain by implementing anything like the pattern we fleshed out two years ago. I'd love to build support to keep/fix the protocol rather than bin it, but the team that created is the team that gave up on it.
If you're curious, the private reason I've heard voiced to others by a person closely connected to the standard is that the protocol was not anticipated to be used in any manner other than what was documented, hence why termination of support for HPKP was preferred in Chrome over revision of the standard. I'm deliberately delicate with my words here because 1) it's hear-say, 2) it was expressed both off the record and in confidence to someone other than myself, and therefore 3) I can't be certain that it was expressed at all. However, key pinning--or any other TLS DoS--should always support what I described above as long as the DoS doesn't interrupt local code from executing in-browser, a behavior I doubt will change for the foreseeable future. You wouldn't want a TLS error to forcibly refresh an offline Google Docs instance just to show you said TLS error (resulting in loss of data from that offline GDocs instance), would you?
TL;DR: you can research alternatives based on the general pattern we described, but using HPKP specifically might be a dead-end for you.
But if you're keen on talking about it in more depth, I'm on keybase.io/bryant