Volume 22, Issue 2

Drill Bits
Zero Tolerance for Bias

  Terence Kelly

From gambling to military conscription, randomization makes crucial real-world decisions. With blood and treasure at stake, fairness is not negotiable. Unfortunately, bad advice and biased methods abound. We'll learn how to navigate around misinformation, develop sound methods, and compile checklists for design and code reviews.

Drill Bits, Code, Development, Performance

Kode Vicious
Structuring Success

The problem with software structure is people don't really learn it until they really need it.

Dear KV, In teaching an algorithms course this semester, I discovered my students had received very little instruction about how to divide their code into functions. So, I spent a weekend trolling various programming handbooks and discovered most of them are silent on this topic. I ended up writing a quick handbook to help my students, but was struck more by the advice gap. We just don't give people guidance!

Development, Education, Kode Vicious

Trustworthy AI using Confidential Federated Learning

  Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani

Federated learning and confidential computing are not competing technologies.

The principles of security, privacy, accountability, transparency, and fairness are the cornerstones of modern AI regulations. Classic FL was designed with a strong emphasis on security and privacy, at the cost of transparency and accountability. CFL addresses this gap with a careful combination of FL with TEEs and commitments. In addition, CFL brings other desirable security properties, such as code-based access control, model confidentiality, and protection of models during inference. Recent advances in confidential computing such as confidential containers and confidential GPUs mean that existing FL frameworks can be extended seamlessly to support CFL with low overheads. For these reasons, CFL is likely to become the default mode for deploying FL workloads.

AI, Security

Confidential Computing or Cryptographic Computing?

  Raluca Ada Popa

Tradeoffs between cryptography and hardware enclaves

Secure computation via MPC/homomorphic encryption versus hardware enclaves presents tradeoffs involving deployment, security, and performance. Regarding performance, it matters a lot which workload you have in mind. For simple workloads such as simple summations, low-degree polynomials, or simple machine-learning tasks, both approaches can be ready to use in practice, but for rich computations such as complex SQL analytics or training large machine-learning models, only the hardware enclave approach is at this moment practical enough for many real-world deployment scenarios.

Hardware, Security

Confidential Container Groups

  Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa

Implementing confidential computing on Azure container instances

The experiments presented here demonstrate that Parma, the architecture that drives confidential containers on Azure container instances, adds less than one percent additional performance overhead beyond that added by the underlying TEE (i.e., AMD SEV-SNP). Importantly, Parma ensures a security invariant over all reachable states of the container group rooted in the attestation report. This allows external third parties to communicate securely (via remote attestation) with containers, enabling a wide range of containerized workflows that require confidential access to secure data. Companies obtain the advantages of running their most confidential workflows in the cloud without having to compromise on their security requirements. Tenants gain flexibility, efficiency, and reliability; CSPs get more business; and users can trust that their data is private, confidential, and secure.

Architecture, Security

Operations and Life:
Make Two Trips

  Thomas A. Limoncelli

Larry David's New Year's resolution works for IT too.

Whether your project is as simple as carrying groceries into the house or as complex as a multiyear engineering project, "make two trips" can simplify the project, reduce the chance of error, improve the probability of success, and lead to easier explanations.

Business and Management, Development, Operations and Life, Systems Administration

Elevating Security with Arm CCA

  Charles Garcia-Tobin, Mark Knight

Attestation and verification are integral to adopting confidential computing.

Confidential computing has great potential to improve the security of general-purpose computing platforms by taking supervisory systems out of the TCB, thereby reducing the size of the TCB, the attack surface, and the attack vectors that security architects must consider. Confidential computing requires innovations in platform hardware and software, but these have the potential to enable greater trust in computing, especially on devices that are owned or controlled by third parties. Early consumers of confidential computing will need to make their own decisions about the platforms they choose to trust. As confidential computing becomes mainstream, however, it's possible that certifiers and regulators will share this burden, enabling customers to make informed choices without having to undertake their own evaluations.

Privacy and Rights, Security


Volume 22, Issue 1

A "Perspectival" Mirror of the Elephant

  Queenie Luo, Michael J. Puett, Michael D. Smith

Investigating language bias on Google, ChatGPT, YouTube, and Wikipedia

Many people turn to Internet-based, software platforms such as Google, YouTube, Wikipedia, and more recently ChatGPT to find the answers to their questions. Most people tend to trust Google Search when it states that its mission is to deliver information from "many angles so you can form your own understanding of the world." Yet, our work finds that queries involving complex topics yield results focused on a narrow set of culturally dominant views, and these views are correlated with the language used in the search phrase. We call this phenomenon language bias, and this article shows how it occurs using the example of two complex topics: Buddhism and liberalism. Language bias sets a strong yet invisible cultural barrier online with serious socio-political implications for how these platforms hinder efforts to reach across societal divides.

Privacy and Rights

Kode Vicious
Software Drift

Open source forking

Since the systems have a common parent, they probably work in the same technical domain, and therefore the features and fixes that are going to be added are probably similar. KV happens to have an example case at hand: two operating systems that diverged before they added SMP (symmetric multiprocessing) support. When an operating system adds SMP to an existing kernel, the first thing we think of is locks, those handy-dandy little performance killers that we've all been sprinkling around our code since the end of Dennard scaling.

Kode Vicious, Open Source

Challenges in Adopting and Sustaining Microservice-based Software Development

  Padmal Vitharana, Shahir A. Daya

Organizational challenges can be more difficult than technical ones.

MS (microservice) has become the latest buzzword in software development. The MS approach to software development offers an alternative to the conventional monolith style. While benefits of MS-based development over monolith style are clear, industry experts agree that neither style provides an absolute advantage in all situations. Proponents contend that an MS approach to software development more readily facilitates mapping organizational changes manifesting from a more dynamic business environment to corresponding IT/IS (information technology/information systems) changes. This article identifies key challenges from the initial decision to adopt MSs to the ongoing task of sustaining the new paradigm over the long haul. It aims to provide insights to those considering MS-based software development.


The Bikeshed
Free and Open Source Software—and Other Market Failures

  Poul-Henning Kamp

Open source is not a goal as much as a means to an end.

Open source was not so much the goal itself as a means to an end, which is freedom: freedom to fix broken things, freedom from people who thought they could clutch the source code tightly and wield our ignorance of it as a weapon to force us all to pay for and run Windows Vista. But the FOSS movement has won what it wanted, and no matter how much oldsters dream about their glorious days as young revolutionaries, it is not coming back, because the frustrations and anger of IT in 2024 are entirely different from those of 1991.

The Bikeshed, Open Source

The Soft Side of Software
Give Your Project a Name

  Kate Matsudaira

It goes a long way toward creating a cohesive team with strong morale.

While some people are driven by infinite backlogs and iteration, others prefer launches and deadlines. Over the years, I have found certain milestones to be instrumental in creating a cohesive team with strong morale. When people have to work together to get through a challenging task, reaching those milestones bring them together.

Business/Management The Soft Side of Software

From Open Access to Guarded Trust

  Yifei Wang

Experimenting responsibly in the age of data privacy

The last decade witnessed the emergence and strengthening of data protection regulations. For software engineers, this new era poses a unique challenge: How do you maintain the precision and efficacy of your platforms when complete data access, one of your most potent tools, is gradually being taken off the table? The mission is clear: Reinvent the toolkit. The way we perceive, handle, and experiment with data needs a drastic overhaul to navigate this brave new world.

Privacy and Rights, Data

Developer Ecosystems for Software Safety

  Christoph Kern

Continuous assurance at scale

How to design and implement information systems so that they are safe and secure is a complex topic. Both high-level design principles and implementation guidance for software safety and security are well established and broadly accepted. For example, Jerome Saltzer and Michael Schroeder's seminal overview of principles of secure design was published almost 50 years ago, and various community and governmental bodies have published comprehensive best practices about how to avoid common software weaknesses. This article argues, based on experience at Google, that focusing on developer ecosystems is both practical and effective, and can achieve a drastic reduction in the rate of common classes of defects across hundreds of applications being developed by thousands of developers.

Development, Security


Volume 21, Issue 6

Drill Bits
Programmer Job Interviews: The Hidden Agenda

  Terence Kelly

Top tech interviews test coding and CS knowledge overtly, but they also evaluate a deeper technical instinct so subtly that candidates seldom notice the appraisal. We'll learn how interviewers create questions to covertly measure a skill that sets the best programmers above the rest. Equipped with empathy for the interviewer, you can prepare to shine on the job market by seizing camouflaged opportunities.

Code, Development, Drill Bits, Business/Management

DevEx in Action

  Nicole Forsgren, Eirini Kalliamvakou, Abi Noda,
  Michaela Greiler, Brian Houck, Margaret-Anne Storey

A study of its tangible impacts

DevEx (developer experience) is garnering increased attention at many software organizations as leaders seek to optimize software delivery amid the backdrop of fiscal tightening and transformational technologies such as AI. Intuitively, there is acceptance among technical leaders that good developer experience enables more effective software delivery and developer happiness. Yet, at many organizations, proposed initiatives and investments to improve DevEx struggle to get buy-in as business stakeholders question the value proposition of improvements.

Business and Management, Development

Resolving the Human-subjects Status of Machine Learning's Crowdworkers

  Divyansh Kaushik, Zachary C. Lipton, Alex John London

What ethical framework should govern the interaction of ML researchers and crowdworkers?

In recent years, machine learning (ML) has relied heavily on crowdworkers both for building datasets and for addressing research questions requiring human interaction or judgment. The diversity of both the tasks performed and the uses of the resulting data render it difficult to determine when crowdworkers are best thought of as workers versus human subjects. These difficulties are compounded by conflicting policies, with some institutions and researchers regarding all ML crowdworkers as human subjects and others holding that they rarely constitute human subjects. Notably few ML papers involving crowdwork mention IRB oversight, raising the prospect of non-compliance with ethical and regulatory requirements. We investigate the appropriate designation of ML crowdsourcing studies, focusing our inquiry on natural language processing to expose unique challenges for research oversight.

AI, Privacy and Rights

Kode Vicious:
Is There Another System?

Computer science is the study of what can be automated.

One of the easiest tests to determine if you are at risk is to look hard at what you do every day and see if you, yourself, could code yourself out of a job. Programming involves a lot of rote work: templating, boilerplate, and the like. If you can see a way to write a system to replace yourself, either do it, don't tell your bosses, and collect your salary while reading novels in your cubicle, or look for something more challenging to work on.

AI, Kode Vicious

Research for Practice:
Automatically Testing Database Systems

  Manuel Rigger with introduction by Peter Alvaro

DBMS testing with test oracles, transaction history, and fuzzing

The automated testing of DBMS is an exciting, interdisciplinary effort that has seen many innovations in recent years. The examples addressed here represent different perspectives on this topic, reflecting strands of research from software engineering, (database) systems, and security angles. They give only a glimpse into these research strands, as many additional interesting and effective works have been proposed. Various approaches generate pairs of related tests to find both logic bugs and performance issues in a DBMS. Similarly, other isolation-level testing approaches have been proposed. Finally, various fuzzing approaches use different strategies to generate mostly valid and interesting test inputs that extract various kinds of feedback from the DBMS.

Databases, Research for Practice, Testing

How to Design an ISA

  David Chisnall

The popularity of RISC-V has led many to try designing instruction sets.

Over the past decade I've been involved in several projects that have designed either ISA (instruction set architecture) extensions or clean-slate ISAs for various kinds of processors (you'll even find my name in the acknowledgments for the RISC-V spec, right back to the first public version). When I started, I had very little idea about what makes a good ISA, and, as far as I can tell, this isn't formally taught anywhere. With the rise of RISC-V as an open base for custom instruction sets, however, the barrier to entry has become much lower and the number of people trying to design some or all of an instruction set has grown immeasurably.

Computer Architecture, Hardware

Operations and Life:
What do Trains, Horses, and Home Internet Installation have in Common?

  Thomas A. Limoncelli

Avoid changes mid-process.

At first, I thought he was just trying to shirk his responsibilities and pass the buck on to someone else. His advice, however, made a lot of sense. The installation team probably generated configurations ahead of time, planned out how and when those changes need to be activated, and so on. The entire day is planned ahead. Bureaucracies usually have a happy path that works well, and any deviation requires who knows what? Managers getting involved? Error-prone manual steps? Ad hoc database queries? There's no way I could know. The point was clear, however: Don't change horses midstream, or the color of the train.

Business and Management, Operations and Life, Systems Administration

Case Study:
Multiparty Computation:
To Secure Privacy, Do the Math

A discussion with Nigel Smart, Joshua W. Baron, Sanjay Saravanan, Jordan Brandt, and Atefeh Mashatan

Multiparty Computation is based on complex math, and over the past decade, MPC has been harnessed as one of the most powerful tools available for the protection of sensitive data. MPC now serves as the basis for protocols that let a set of parties interact and compute on a pool of private inputs without revealing any of the data contained within those inputs. In the end, only the results are revealed. The implications of this can often prove profound.

Case Studies, Privacy and Rights, Security


Volume 21, Issue 5

Bridging the Moat:
The Security Jawbreaker

  Phil Vachon

Access to a system should not imply authority to use it. Enter the principle of complete mediation.

When someone stands at the front door of your home, what are the steps to let them in? If it is a member of the family, they use their house key, unlocking the door using the authority the key confers. For others, a knock at the door or doorbell ring prompts you to make a decision. Once in your home, different individuals have differing authority based on who they are. Family members have access to your whole home. A close friend can roam around unsupervised, with a high level of trust. An appliance repair person is someone you might supervise for the duration of the job to be done. For more sensitive locations in your home, you can lock a few doors, giving you further assurance. Making these decisions is an implicit form of evaluating risk tolerance, or your willingness to accept the chance that something might go against your best interests.

Bridging the Moat, Security

Improving Testing of Deep-learning Systems

  Harsh Deokuliar, Raghvinder S. Sangwan, Youakim Badr, Satish M. Srinivasan

A combination of differential and mutation testing results in better test data.

We used differential testing to generate test data to improve diversity of data points in the test dataset and then used mutation testing to check the quality of the test data in terms of diversity. Combining differential and mutation testing in this fashion improves mutation score, a test data quality metric, indicating overall improvement in testing effectiveness and quality of the test data when testing deep learning systems.


Kode Vicious:
Dear Diary

On keeping a laboratory notebook

While a debug log is helpful, it's not the same thing as a laboratory notebook. If more computer scientists acted like scientists, we wouldn't have to fight over whether computing is an art or a science.

Development, Kode Vicious

Low-code Development Productivity

  João Varajão, António Trigo, Miguel Almeida

"Is winter coming" for code-based technologies?

This article aims to provide new insights on the subject by presenting the results of laboratory experiments carried out with code-based, low-code, and extreme low-code technologies to study differences in productivity. Low-code technologies have clearly shown higher levels of productivity, providing strong arguments for low-code to dominate the software development mainstream in the short/medium term. The article reports the procedure and protocols, results, limitations, and opportunities for future research.


The Soft Side of Software:
Software Managers' Guide to Operational Excellence

  Kate Matsudaira

The secret to being a great engineering leader? Setting up the right checks and balances.

Software engineering managers (or any senior technical leaders) have many responsibilities: the care and feeding of the team, delivering on business outcomes, and keeping the product/system/application up and running and in good order. Each of these areas can benefit from a systematic approach. The one I present here is setting up checks and balances for the team's operational excellence.

Business and Management, The Soft Side of Software

Use Cases are Essential

  Ivar Jacobson, Alistair Cockburn

Use cases provide a proven method to capture and explain the requirements of a system in a concise and easily understood format.

While the software industry is a fast-paced and exciting world in which new tools, technologies, and techniques are constantly being developed to serve business and society, it is also forgetful. In its haste for fast-forward motion, it is subject to the whims of fashion and can forget or ignore proven solutions to some of the eternal problems that it faces. Use cases, first introduced in 1986 and popularized later, are one of those proven solutions. Ivar Jacobson and Alistair Cockburn, the two primary actors in this domain, are writing this article to describe to a new generation what use cases are and how they serve.


Device Onboarding using FDO and the Untrusted Installer Model

  Geoffrey H. Cooper

FDO's untrusted model is contrasted with Wi-Fi Easy Connect to illustrate the advantages of each mechanism.

Automatic onboarding of devices is an important technique to handle the increasing number of "edge" and IoT devices being installed. Onboarding of devices is different from most device-management functions because the device?s trust transitions from the factory and supply chain to the target application. To speed the process with automatic onboarding, the trust relationship in the supply chain must be formalized in the device to allow the transition to be automated.

Hardware, Networks, Security



Older Issues