Book delay

(You can still win a free copy)

I’m sorry to have to announce that the availability of my book, Trust in Computrer Systems and the Cloud, is likely to be delayed. Wiley, my publisher, had hoped to get copies in the US for early December, and to Europe a month or so after that, but problems getting hold of paper (a core component of physical books, for the uninitiated) mean that these dates will be delayed.

I’m obviously disappointed about this, but it’s really not Wiley’s fault (the paper shortage is wide-spread across the US, it appears). Travel rules permitting, I intend to attend the RSA Conference in San Francisco in February 2022, and we hope to have copies of the book available there (book your signed copy now[1]).

Anyway, sorry to announce this, but it does give you more time to follow this blog, giving you a chance of a free copy when they are available.


1 – I will, actually, sign[2] your copy if you like: do feel free to contact me!

2 – I’m hoping we don’t get to the stage where, as in the film[3] Notting Hill, unsigned copies are worth more than signed ones!

3 – yeah, yeah, “movie” if you must.

Image by Peggychoucair from Pixabay

Cloud security asymmetry

We in the security world have to make people understand this issue.

My book, Trust in Computer Systems and the Cloud, is due out in the next few weeks, and I was wondering as I walked the dogs today (a key part of the day for thinking!) what the most important message in the book is. I did a bit of thinking and a bit of searching, and decided that the following two paragraphs expose the core thesis of the book. I’ll quote them below and then explain briefly why (the long explanation would require me to post most of the book here!). The paragraph is italicised in the book.

A CSP [Cloud Service Provider] can have computational assurances that a tenant’s workloads cannot affect its hosts’ normal operation, but no such computational assurances are available to a tenant that a CSP’s hosts will not affect their workloads’ normal operation.

In other words, the tenant has to rely on commercial relationships for trust establishment, whereas the CSP can rely on both commercial relationships and computational techniques. Worse yet, the tenant has no way to monitor the actions of the CSP and its host machines to establish whether the confidentiality of its workloads has been compromised (though integrity compromise may be detectable in some situations): so even the “trust, but verify” approach is not available to them.”

What does this mean? There is, in cloud computing, a fundamental asymmetry: CSPs can protect themselves from you (their customer), but you can’t protect yourself from them.

Without Confidential Computing – the use of Trusted Execution Environments to protect your workloads – there are no technical measures that you can take which will stop Cloud Service Providers from looking into and/or altering not only your application, but also the data it is processing, storing and transmitting. CSPs can stop you from doing the same to them using standard virtualisation techniques, but those techniques provide you with no protection from a malicious or compromised host, or a malicious or compromised CSP.

I attended a conference recently attended by lots of people whose job it is to manage and process data for their customers. Many of them do so in the public cloud. And a scary number of them did not understand that all of this data is vulnerable, and that the only assurances they have are commercial and process-based.

We in the security world have to make people understand this issue, and realise that if they are looking after our data, they need to find ways to protect it with strong technical controls. These controls are few:

  • architectural: never deploy sensitive data to the public cloud, ever.
  • HSMs: use Hardware Security Modules. These are expensive, difficult to use and don’t scale, but they are appropriate for some sensitive data.
  • Confidential Computing: use Trusted Execution Environments (TEEs) to protect data and applications in use[1].

Given my interest – and my drive to write and publish my book – it will probably come as no surprise that this is something I care about: I’m co-founder of the Enarx Project (an open source Confidential Computing project) and co-founder and CEO of Profian (a start-up based on Enarx). But I’m not alone: the industry is waking up to the issue, and you can find lots more about the subject at the Confidential Computing Consortium‘s website (including a list of members of the consortium). If this matters to you – and if you’re an enterprise company who uses the cloud, it almost certainly already does, or will do so – then please do your research and consider joining as well. And my book is available for pre-order!

Logs – good or bad for Confidential Computing?

I wrote a simple workload for testing. It didn’t work.

A few weeks ago, we had a conversation on one of the Enarx calls about logging. We’re at the stage now (excitingly!) where people can write applications and run them using Enarx, in an unprotected Keep, or in an SEV or SGX Keep. This is great, and almost as soon as we got to this stage, I wrote a simple workload to test it all.

It didn’t work.

This is to be expected. First, I’m really not that good a software engineer, but also, software is buggy, and this was our very first release. Everyone expects bugs, and it appeared that I’d found one. My problem was tracing where the issue lay, and whether it was in my code, or the Enarx code. I was able to rule out some possibilities by trying the application in an unprotected (“plain KVM”) Keep, and I also discovered that it ran under SEV, but not SGX. It seemed, then, that the problem might be SGX-specific. But what could I do to look any closer? Well, with very little logging available from within a Keep, there was little I could do.

Which is good. And bad.

It’s good because one of the major points about using Confidential Computing (Enarx is a Confidential Computing framework) is that you don’t want to leak information to untrusted parties. Since logs and error messages can leak lots and lots of information, you want to restrict what’s made available, and to whom. Safe operation dictates that you should make as little information available as you possibly can: preferably none.

It’s bad because there are times when (like me) you need to work out what’s gone wrong, and find out whether it’s in your code or the environment that you’re running your application in.

This is where the conversation about logging came in. We’d started talking about it before this issue came up, but this made me realise how important it was. I started writing a short blog post about it, and then stopped when I realised that there are some really complex issues to consider. That’s why this article doesn’t go into them in depth: you can find a much more detailed discussion over on the Enarx blog. But I’m not going to leave you hanging: below, you’ll find the final paragraph of the Enarx blog article. I hope it piques your interest enough to go and find out more.

In a standard cloud deployment, there is little incentive to consider strong security controls around logging and debugging, simply because the host has access not only to all communications to and from a hosted workload, but also to all the code and data associated with the workload at runtime.  For Confidential Computing workloads, the situation is very different, and designers and architects of the TEE infrastructure (e.g. the Enarx projects) and even, to a lesser extent, of potential workloads themselves, need to consider very carefully the impact of host gaining access to messages associated with the workload and the infrastructure components.  It is, realistically, infeasible to restrict all communication to levels appropriate for deployment, so it is recommended that various profiles are created which can be applied to different stages of a deployment, and whose use is carefully monitored, logged (!) and controlled by process.


Header image by philm1310 from Pixabay.

Recruiting is hard

It’s going to be easier to outsource this work to somebody who is more of an expert than I’ll ever be, would ever want to be, or could ever be.

We (Profian) are currently looking to recruit some software engineers. Now, I’ve been involved in hiring people before – on the interviewing side, at least – but actually doing the recruiting is a completely new experience for me. And it’s difficult. As the CEO of a start-up, however, it turns out that it’s pretty much down to me to manage the process, from identifying the right sort of person, to writing a job advert (see above), to finding places to place it, to short-listing candidates, interviewing them and then introducing them to the rest of the team. Not to mention agreeing a start date, “compensation package” (how much they get paid) and all that. Then there’s the process of on-boarding them (getting contracts sorted, getting them email addresses, etc.), and least some of which I’m pleased to say I have some help with.

The actual recruiting stuff is difficult, though. Recruitment consultants get a bad rap, and there are some dodgy ones, but I’m sure most of them are doing the best they can and are honest people. You might even be happy to introduce some of them to your family. Just a few. But, like so many other things about being start-up founder, it turns out that there comes a time when you have to say to yourself: “well, I could probably learn to do this – maybe not well, but with some degree of competence – but it’s just not worth my time. It’s going to be easier, and actually cheaper in the long run, to outsource this work to somebody who is, frankly, more of an expert than I’ll ever be, would ever want to be, or could ever be. And so I’ve found someone to work with.

What’s really interesting when you find somebody to help you with a new task is the time it takes to mesh your two worlds. I’m a software guy, a we’re looking for software people. I need to explain to the recruitment consultant not only what skills we’re looking for, but what phrases, when they appear on a LinkedIn page or CV[1], are actually red flags. In terms of phrases we’re looking for (or are nice to haves), I’d already mentioned “open source” to the recruitment consultant, but it was only on looking over some possible candidates that I realised that “FOSS” should be in there, too. A person whose current role is “Tech lead” is much more likely to be a fit than “Technical manager”. What’s the difference between a “cloud architect” and a “systems architect”? Is “Assembly” different to “WebAssembly” (yes! – oh, and the latter is sometimes shortened to “Wasm”).

There are, of course, recruitment consultants who specialise in particular technical fields, but what we’re doing (see the Enarx project) is so specialised and so new that I really don’t think that there are likely to be any specialist recruiters anywhere in the world (yet).

So, I feel lucky that I’ve managed to find someone who seems to get not only where we’re coming from as a company, but also the sorts of people we’re looking for. He wisely suggested that we spend some time going over some possible candidates so he could watch me identifying people who were a definite “no” – as useful for him as a definite “must interview”. Hopefully we’ll start to find some really strong candidates soon. If you think you might be one of them, please get in touch!

(Oh – and yes, I’ve invited him to meet my family.)


1 – that’s “resume” for our US friends.

Enarx first release

Write an application, compile it to WebAssembly, and then run it in one of three Keeps types.

I was on holiday last week, and I took the opportunity not to write a blog post, but while I was sunning myself[1] at the seaside, the team did a brilliant thing: we have our first release of Enarx, and a new look for the website, to boot.

To see the new website, head over to https://enarx.dev. There, you’ll find new updated information about the project, details of how to get involved, and – here’s the big news – instructions for how to download and use Enarx. If you’re a keen Rustacean, you can also go straight to crates.io (https://crates.io/crates/enarx) and start off there. Up until now, in order to run Enarx, you’ve had to do quite a lot of low level work to get things running, run your own github branches, understand how everything fits together and manage your own development environment. This has now all changed.

This first release, version 0.1.1, is codenamed Alamo, and provides an easy way in to using Enarx. As always, it’s completely open source: you can look at every single line of our code. It doesn’t provide a full feature set, but what it does do is allow you, for the first time, to write an application, compile it to WebAssembly, and then run it in one of three Keep[2] types:

  1. KVM – this is basically a debugging Keep, in that it doesn’t provide any confidentiality or integrity protection, but it does allow you to get running and to try things even if you don’t have access to specialist hardware. A standard Linux machine should do you fine.
  2. SEV – this is a Keep using AMD’s SEV technology, specifically the newer version, SEV-SNP. This requires access to a machine which supports it[3].
  3. SGX – this is a Keep using Intel’s SGX technology. Again, this requires access to a machine which supports it[3].

The really important point here is that you’re running the same binary on each of these architectures. No recompilation for different architectures: just plain old WebAssembly[4].

Current support

There’s a lot more work to do, but what do we support at the moment?

  • running WebAssembly
  • KVM, SEV and SGX Keeps (see above)
  • stdin and stdout from/to the host – this is temporary, as the host is untrusted in the Enarx model, but until we have networking support (see below), we wanted to provide a simple way to manage input and output from a Keep.

There’s lots more to come – networking and attestation are both high on the list – but now anyone can start playing with Enarx. And, we hope, submitting enhancement and feature requests, not to mention filing bugs (we know there will be some!): to do so, hop over to https://github.com/enarx/enarx/issues.

To find out more, please head over to the website – there’s loads to see – or join us on chat channel over at https://chat.enarx.dev to find out more and get involved.


1 – it’s the British seaside, in October, so “sunning” might be a little inaccurate.

2 – a Keep is what we call a TEE instance set up for you to run an application in.

3 – we have AMD and SGX machines available for people who contribute to the project – get in touch!

4 – WebAssembly is actually rather new, but “plain old” sounds better than “vanilla”. Not my favourite ice cream flavour[5].

5 – my favourite basic ice cream flavour is strawberry. Same for milkshakes.

Win a copy of my book!

What’s better than excerpts? That’s right: the entire book.

As regular readers of this blog will know, I’ve got a book coming out with Wiley soon. It’s called “Trust in Computer Systems and the Cloud”, and the publisher’s blurb is available here. We’ve now got to the stage where we’ve completed not only the proof-reading for the main text, but also the front matter (acknowledgements, dedication, stuff like that), cover and “praise page”. I’d not heard the term before, but it’s where endorsements of the book go, and I’m very, very excited by the extremely kind comments from a variety of industry leaders which you’ll find quoted there and, in some cases, on the cover. You can find a copy of the cover (without endorsement) below.

Trust book front cover (without endorsement)

I’ve spent a lot of time on this book, and I’ve written a few articles about it, including providing a chapter index and summary to let you get a good idea of what it’s about. More than that, some of the articles here actually contain edited excerpts from the book.

What’s better than excerpts, though? That’s right: the entire book. Instead of an article today, however, I’m offering the opportunity to win a copy of the book. All you need to do is follow this blog (with email updates, as otherwise I can’t contact you), and when it’s published (soon, we hope – the March date should be beaten), I’ll choose one lucky follower to receive a copy.

No Wiley employees, please, but other than that, go for it, and I’ll endeavour to get you a copy as soon as I have any available. I’ll try to get it to you pretty much anywhere in the world, as well. So far, it’s only available in English, so apologies if you were hoping for an immediate copy in another language (hint: let me know, and I’ll lobby my publisher for a translation!).

3 things you need from a VC

A perspective from a first-time start-up founder.

As I discussed in a recent article (Announcing Profian), we recently received seed funding for our start-up from two Venture Capital firms: Project A Ventures and Illuminate Financial (thanks again, folks!). When you’re looking for start-up funding, in my experience, you’re focussed at the beginning on one thing, and one thing only, and that’s money. The clue’s in the phrase: raising a funding round is about, well, funding. So you might think that the answer to the question “what 3 things do you need from a VC” is “money, money and money”. However, you’d be wrong.

I found, at the beginning of the process, that this was absolutely our focus. This was our first time doing this, and we were desperate to get enough money to be able to start the company and get things moving. That didn’t change, but along the way, I received some very good advice about other areas we should be thinking about, and I really think it’s worth sharing this perspective from a first-time start-up founder.

1. Money

OK, so the first one is money, but it’s not money at any cost. You need to have enough funding to be able to see your way through to your next injection of cash (whether that’s an A Round, loans or just revenue), but a VC-led seed round isn’t the only way. There are angel investors (we had some in our seed round, in fact – thanks to them as well!), enterprise capital, crowd-funding, grants and other options. Even if you are going to do a standard VC-led seed round, you need to think about how much equity (your share of the business, as a founder) you’re will to give up, what further financial help your VCs will give you in the future, what timescales they’re looking at, and what sort of exit they’re looking for. For instance, if they want to sell the company as soon as possible and you want to spend 10 years building a multi-billion business, you need to consider whether they’re the right investors for you right now.

2. People

What is your relationship with your investors? What personal chemistry do you share? How well do you get on? Do you trust them? Are they people you can contact for advice when you have a tricky problem? What experience can they (or their partners) bring to the table when you encounter a situation which is new and you could use some guidance? I’m not suggesting that they should be the first person on your speed-dial list for every bump in the road, but you’re going to be spending a lot of time with these people over the next few years, and their views, expertise and advice are likely to be instrumental in the successful running (or unsuccessful running…) of your company. If the relationship breaks down, they can make life difficult for you (very difficult, if the board composition is such that they can control it). You want people who you trust, and preferably get on well with: these should be people you can turn to when things are tricky. They have experience which should help you navigate difficult situations – particularly ones which are new to you, but which they’ve seen many times before.

3. Network

VCs bring networks with them. They should have a portfolio of companies who they have funded in the past, and set of companies they didn’t end up investing in, but continue to be on good terms with, companies they’re considering investing in, and the customers and business partners of all of those companies. You want to be choosing investors who can put you in front of all of these people as possible partners and customers, experienced hands and even future investors, and you want them to be relevant. If you’re launching a consumer financial product, and all of your VCs’ networks are in institutional medical pharmaceuticals, then you should probably reconsider. Choose investors who can help you.

There’s another type of network: some VCs are what are called operational VCs, meaning that they provide specific services for their portfolio companies. Some of these may be free, others provided at discounted prices, and they may include everything from branding services, marketing, accounting, recruitment or the opportunity to embed one of their staff in your organisation for a while to fill a requirement while you find a permanent employee. Again, choose investors who can help you.

Conclusion

Without funding, your start-up will, eventually, fail, or it just won’t happen. You need money, and the venture capital market (it is a market) is one proven way to get it. It can be a hard slog to get the initial interest – we got very close to giving up – but once you do get that initial “bite”, try not to jump for the very first VC who shows a sign of giving you a termsheet. We decided not to follow up with a number of VCs for all of the reasons above (specifically – differing expectations on exit; no personal chemistry; no strong match with portfolio), and are happy with our decision. If you’re going to make your start-up business succeed, it deserves – and you deserves -the best fit: and that’s not just money.

10 ways to avoid becoming a start-up founder

It’s all rather like hard work, and so best avoided at pretty much all costs.

In last week’s article, I announced the start-up, Profian, for which we’ve just got funding, and of which I’m the co-founder and CEO. This week, I want to give you some tips so that you can avoid the same fate that befell me: becoming a founder, a role which is time-consuming and stressful. Just getting funding can take (did take, in our case) months of uncertainty and risk, and then, when (if) you get funding, there are the responsibilities towards your employees, your investors, government, the law and all the other pieces that whirl around your head (and into your inbox). It’s all rather like hard work, and so best avoided at pretty much all costs. Here’s my guide to doing that.

1. Avoid interesting work

Probably the biggest reason that I fell into the trap of starting a new company was that I couldn’t see myself doing anything other than working on Enarx, the open source project for which Profian is custodian, and on which we will be basing our products and services. I’d had other responsibilities in my previous job, but Enarx was what I cared about the most, and the idea of giving up working on it was unconscionable – I just had to do it. So started the quest to find a way to continue working on Enarx, and to do it full-time.

2. Don’t be passionate

It’s also probably best to avoid getting too excited about what you do. That way, you can give up after a while, and stop bothering your family and friends with your annoying obsession. Most importantly, investors are much less likely to give you money (not to mention customers much less likely to buy your products and services) if you’re basically luke-warm about the whole idea.

3. Work with dull people who you dislike

If you have the misfortune to enjoy spending time with your co-founder(s) and founding team, you’ll have less interest in working with them, not to mention working through complex and sometimes awkward topics such as how to split equity, who can absorb upfront expenses before funding comes through, when it’s appropriate for either or any of you to take some holiday (and for how long), and even more important questions like what colour your logo should be, and what font family best defines your brand. If you don’t like your team or co-founders, or find their company uninteresting, you are much more likely to give up on working with them, hence avoiding getting too far down the start-up road.

4. Ignore customer need

You may not have actual, paying customers early on (we don’t, yet), but at some point, you are probably going to need to get some. And one of the things that investors seem completely fixated on, in my experience, is how you’ll get revenue (very customers). The investors seem to think that you should listen to customers and gear what you’ll be producing to their (the customers’) needs and requirements. This suggests that your vision for the company should be diluted – nay, adulterated – by the market, as opposed to what you want, and what you think should be happening. In the very worst case, your investors may require you to talk to actual people from actual possible customers. If you can ignore their views, you’re much less likely to have to accept funding, and can give up much earlier.

5. Assume you know best

Related to our last point, if you know best, then you don’t need to take advice from anyone. Possible investors love providing their expertise and experience, and there’s a wealth of material in blogs, wikis, podcasts, news articles, LinkedIn posts and beyond which allow you to tap the collected wisdom of thousands of people who’ve trodden similar paths before you. The excuse you can give is that they can’t all be right, so rather than listening to the various advice you’re offered (for free!), reading, listening to and watching the various sources and then taking the time to sift through them all and work out what’s relevant and useful, you might as well assume that you know best (and always have done), and keep plugging away at what you’re already doing. This is almost guaranteed to remove any chance of funding (let alone anyone wanting to work with you).

6. Set your pitch deck in stone

Before I started on this journey, I’d heard about pitch decks: they’re what you show to possible investors to try to interest them in working with you. They should be short, punchy and lacking in extraneous information. I could have suggested long, waffly decks with random cat pictures and irrelevant market sector data, but I think that an even safer way of avoiding attracting interest for your start-up is to create a one-off pitch deck right at the beginning of the process and then never to change it. This is related to the previous point about knowing best, but the pitch deck is such an important tool in the journey towards creating your start-up that I felt it was worth its own section. As you learn more (well, assuming you do – see last point) and get more advice, the way you present your great idea for the company, if not the idea itself, will change. Having a pitch deck which reflects this new, improved thinking, will only aid you on your path, and as we’re trying to avoid such a dangerous move, you’ll want to have a single pitch deck, crafted at the beginning of your quest, and completely immune from improvements or changes of any kind.

7. Tell investors what you assume they want to hear

This one is a little counter-intuitive. You might assume that telling people what they want to hear is a sure-fire way to ensure that they give you money, and will therefore make you more likely to end up as a founder. But no! If you tell people what you think they want to hear, rather than what you actually believe, investors will either see through you (most of them have met many, many founders and heard many, many pitches – they’re not stupid) and reject you, or you’ll end up with a bunch of investors who actually think you’re doing something completely different to what you want to do, and things will fall apart as soon as it becomes clear that you’re not aligned. This is likely to be around the time that you’re getting into the nitty-gritty of your business plan or agreeing final terms, and is a pretty safe way of guaranteeing that everything will implode just in time to stop you having to becoming a founder.

8. Reject support from friends and family

I mentioned, right at the top of this article, that the journey to founding a start-up was long and stressful. Well, there’s a possibility that, from time to time, friends and family will want to discuss things with you, and offer you support to get through the hard times. Taking this sort of support significantly reduces that likelihood that you’ll burn-out before the process is complete, as they may help you to keep some perspective, provide emotional support and generally keep your mental health on an even keel. Crashing and burning because you’ve failed to accept support offered by people outside the process, who can see things in a different light, where the entire world isn’t bounded solely by just incorporating the company, getting through the funding round, hiring your first employees, filing initial tax returns, setting up bank accounts and the rest, is an easy way to avoid becoming a founder. As an extra bonus, failing to involve your close family (spouse, partner, etc.) in the decisions about financial risk, likely time pressures, etc., is a recipe for family break-up if ever I heard one.

9. Remember it’s all about you

Who knows best? You (see above). Who’s running this show? You, again. Who’s this all about? You. Other co-founders, employees, investors, customers (again, see above) are incidental to the main event, which is you, the “hero founder” who will carry the company through thick and thin, providing the vision and resources to succeed, no matter what. This is the attitude you need if you want to alienate everyone around you (including family and friends, see above), and cause all your possible allies to desert you. Working as a collaborative team is so trendy and 21st Century: who needs support and buy-in when you have the drive to make it all happen yourself? Well, the answer will be you, as you won’t have any funding, employees or customers – but that’s what we were trying to avoid in the first place, right?

10. Don’t take any time off

You can fail to do all of the above, ignoring my advice and setting yourself up for a collaborative, well-funded, supported, successful company and still fail with this one, simple trick: make your entire life – every waking moment, every dream, every action, every thought and every word – about the start-up. Find no time for anything else. Become unhealthily obsessed with the company to the exclusion of all other. And you will fail. Taking time off would help recharge your passion, give you insights into other people’s views, allow you to accept support from friends and family and give you a sense of perspective: all things we’re trying avoid in our quest not to become the founder of a start-up. Refusing to take time off might seem like a way to concentrate all your efforts on succeeding, but in the longer term, it’s the opposite.

Summary

I find that writing “how not to” articles is a useful and fun way to provide a different perspective on sometimes important topics. I can’t pretend that the road to start-up foundership has been easy, nor that I’ve avoided taking some of the advice above, but it’s certainly exciting and worthwhile. And I wish I’d seen this article, or one like it, before I started.

Announcing Profian

Profian, a security start-up in the Confidential Computing space

I’m very excited to announce Profian, a security start-up in the Confidential Computing space that I co-founded with Nathaniel McCallum, came out of stealth mode today to announce that we’ve completed our Seed Round – you can find the press release here. This is the culmination of months of hard work and about two years of a vision that we’ve shared and developed since coming up with the idea of Enarx. Profian will be creating products and services around Enarx, and we’re committed to keeping everything we do open source: not just because we believe in open source as an ethical choice, but also because we believe that it’s best for security.

Enarx grew out of a vision that we had to simplify use of Trusted Execution Environments like AMD’s SEV and Intel’s SGX[1], while not compromising on the security that we believe the industry wants and needs. Enarx aims to allow you to deploy applications to any of the supported platforms without needing to recompile for each one, and to simplify both the development and deployment process. It supports WebAssembly as its runtime, allowing a seamless execution environment across multiple hardware types. Engineering for Enarx was initially funded by Red Hat, and towards the end of 2020, we started looking for a way to ensure long-term resourcing: out of this Profian was born. We managed to secure funding from two VC funds – Project A (lead investor) and Illuminate Financial – and four amazing angel investors. Coming out of stealth means that we can now tell more people about what we’re doing.

Profian is a member of two great industry bodies: the Confidential Computing Consortium (a Linux Foundation project to promote open source around Trusted Execution Environments) and the Bytecode Alliance (an industry group to promote and nurture WebAssembly, the runtime which Enarx supports).

The other important thing to announce is that with funding of Profian comes our chance to develop Enarx and its community into something really special.

If it’s your thing, you can find the press release on Business Wire, and more information on the company press page.

A few questions and answers

What’s confidential computing?

I tend to follow the Confidential Computing Consortium’s definition: “Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment”.

What does Profian mean?

It’s Anglo-Saxon, the language also sometimes called “Old English”, which was spoken in (modern day) England and parts of Scotland from around the mid-5th century BCE to 1066, when Norman French had such an impact on the language that it changed (to Middle English).

One online Anglo-Saxon dictionary defines profian thus:

profian - 1. to esteem; regard as 2. to test ; try ; prove 3. to show evidence of ; evince

It’s the root of the English word “to prove”, from which we also get “proof” and “proven”. We felt that this summed up much of what we want to be doing, and is nicely complementary to Enarx.

How is Profian pronounced?

Not the way most pre-Conquest Anglo-Saxons would probably have pronounced it, to be honest. We (well, I) thought about trying to go with a more “authentic” pronunciation, and decided (or was convinced…) that it was too much trouble. We’re going with “PROH-vee-uhn”[2].

What does Enarx mean?

You’ll find more information about this (and how to pronounce Enarx), over at the Enarx FAQ. TL;DR – we made it up.

Who’s part of the company?

Well, there’s me (I’m the CEO), Nathaniel McCallum (the CTO) and a small team of developers. We also have Nick Vidal, who we recruited as Community Manager for Enarx. By the beginning of October, we expect to have six employees in five different countries spread across three separate continents[3].

What’s next?

Well, lots of stuff. There’s so much to do when running a company of which I knew next to nothing when we started. You would not believe the amount of work involved with registering a company, setting up bank accounts, recruiting people, paying people, paying invoices, etc. – and that’s not even about creating products. We absolutely plan to do this (or the investors are not going to be happy).

No – what’s next for this blog?

Ah, right. Well, I plan to keep it going. There will be more articles about my book on trust, security, open source and probably VCs, funding and the rest. There have been quite a few topics I’ve just not felt safe blogging about until Profian came out of stealth mode. Keep an eye out.


1 – there are more coming, such as Arm CCA (also known as “Realms”), and Intel’s TDX – we plan to support these are they become available.

2 – Anglo-Saxons would probably have gone with something more like “PRO-fee-an”, where the “o” has sound like “pop”.

3 – yes, I know we’ve not made it easy on ourselves.