How to reduce AI slop
The primary goal of this proposal is to reduce AI slop by focusing on two questions:
- Who created this data?
- How did they want the data to be used?
The methodology is to start with hardware signatures on “raw inputs” like images and key presses. These hardware signatures will give better confidence that the “raw inputs” into the computer are attributable to physical actions in the physical world. From there, we can devise programming languages that can track attribution and enforce permissions as data is transformed and shared. So once we can better verify whether data was produced by a person, we can also respect how that person wanted their data to be used. We call this Authorized Computing.
We will be focusing on the technical details, but questions of authorship, attribution, and permissions are ultimately social questions. People in different societies will come to different conclusions regarding their laws and enforcement on copyright, software licensing, deepfakes, nonconsensual sharing of images, etc. The point of Authorized Computing is to provide a strong enough technical foundation to allow people to decide for themselves.
Hardware Signatures and Verified Inputs
The first step is to build cameras and keyboards that create hardware signatures for “raw inputs” at the time of creation. These hardware signatures will give better confidence that the “raw inputs” into the computer are attributable to physical actions in the physical world. We are starting to see hardware support in cameras from companies like Cannon and Apple, and I am hopeful that keyboard manufacturers will start offering hardware signing as well.
Hardware signatures are a great first step in reducing AI slop. They allow us to verify things like:
- “This image has not been altered since capture.”
- “This sequence S of key presses results in document D.”
On the images side, one can imagine computing devices that explicitly mark unverified images. Many older relatives might benefit from a browser that does not show unverified images at all, and I would personally love to fully block synthetic images on my own devices. Whatever your personal view, once hardware verified images become more common, we will at least be able to decide for ourselves how frequently we would like to see synthetic images.
I am personally more excited about Verified Keyboards. I am eager to start using websites where articles, comments, and reviews are known to be produced by physical actions in the physical world. (The businesses and intelligence agencies that use bots to run influence operations online will at least have to get some keyboards involved.) I am sure many parents and educators will also be excited to restore a baseline level of trust in the essay and the term paper as instruments of higher learning.
Obviously there are many practical obstacles to overcome in this first step, like the security and privacy concerns discussed in the “Apple Reference Image” article here, but I want to focus on where we go from there with the help of programming languages and compilers.
Authorized Computing
Once we have hardware signatures and verified inputs, we can start to label it with the author’s intent. From there we can write programs that preserve this authorization as the data is transformed and shared. We will ultimately be able to create an “authorized computer” and “authorized internet” that maintains attribution and permissions from device to device.
At the moment, attribution and permissions are handled quite differently in different jurisdictions. In the United States, lawsuits like this are struggling to convince courts that software licenses should be enforced. “If an LLM is trained on 100% GPL code, its output is not GPL? What about 99%? Or 50% or 20%?” On the other end of the spectrum in Denmark, citizens have been granted copyright over their body, facial features and voice in an effort to protect people from deepfakes and the nonconsensual sharing of images.
Regardless of how the laws shake out in different jurisdictions, most widely used programming languages have no systematic way to even approach the issues of attribution and permissions. I propose approaching this in three phases:
- Authorized Data
- Authorized Compilers
- Authorized Operating Systems and Networking
Each phase builds upon the former, so we will go through them one at a time. There are interesting research questions in each phase, so I hope some readers will take this as inspiration to start working out the details in their language and compiler work.
Authorized Data
With attribution, we want to track information like:
- “This article was produced by keyboards K1 and K2 by authors A1 and A2.”
- ”This specific paragraph was produced by an LLM by company C.”
With permissions, we want to enforce policies like:
- “This image can be viewed on the devices of people in set P, but nobody else.”
- “This personal information can be used by company C, but cannot be resold or shared with other entities”
There are many different design directions to explore here. How expressive should we make policies? How can these policies be implemented efficiently to have low runtime overhead? Etc. All of these design choices will have major implications for the next phase.
Authorized Compilers
Next we need programming languages that track attribution and enforce permissions. The major questions are:
Attribution — How do we turn a sequence of verified keypresses into an essay? What if those keypresses occur on multiple devices? What if there are multiple authors? Etc. How should we merge attribution with simple and generic language features or data structures? In the context of Elm, I would wonder about the type of a “verified string append” function. How far can we go with “attribution sets” and simple set unions? Can we get fine-grained attribution such that the exact character-by-character contributions of author A1 and A2 are preserved into the final document? Etc.
Permissions — Once we have attribution, we can start using it to enforce permissions as data moves around. Say Alice creates a document that can be shared with Bob and nobody else. Now if Bob uses data from Alice’s document, the result must also follow Alice’s sharing policy. How should we represent these sharing policies? How expressive should they be? How do we merge them? Can this be modeled nicely with a traditional HM(=) type system? Are there ways to work with permissions in languages like Elm that aim to be simple to use?
Obviously there is a lot of existing related work: provenance [1], capabilities [2], contracts [3], collaborative real-time editors [4], etc. Rather than suggesting a specific design, my goal is to show how we might collectively channel our efforts towards solving the AI slop problem.
From there we would want to prove that all programs written with a certain programming language properly track attribution and permissions, and that the compiler itself maintains these guarantees.
Authorized Operating Systems and Networking
One can imagine creating an operating system that only runs Authorized Programs. Most importantly, such an “Authorized Computer” would offer a networking stack that only communicates with other Authorized Computers. At that point, people could state permissions like “this data can only be shared within the network of Authorized Computers”. Perhaps this can be acheived with unikernels in the spirit of MirageOS.
Once we have a network of Authorized Computers, people and businesses will be able to decide for themselves where they want to share their data. Do I want to use the “normal internet” or the Authorized Internet? Where do I want to distribute my images and writing? Where should students write their essays? Where do I want to read product reviews? Etc.
Conclusion
The ultimate goal of this proposal is to reduce AI slop. The methodology is to use hardware signatures to build up robust systems for tracking attribution and enforcing permissions. As we work through the various phases of Authorized Computing, different societies can start discussing questions like:
- How do we feel about “devices for falsifying keyboard inputs”? Many societies have rules for food, alcohol, drugs, vehicles, counterfeiting machines, etc. Many societies attempt to protect the cognitive development of children with such rules. Do falsification devices warrant special consideration?
- What is the legal status of “throwing away data permissions” and working with the data without authorization?
- Are laws like “To operate within this jurisdiction, companies must only work with Authorized Data” plausible? This way companies that mine and resell copyrighted material cannot sell data to entities that want to work in certain jurisdictions.
Obviously there is no single answer to these questions. People in different societies will come to different conclusions regarding their laws and their levels of enforcement. The point of Authorized Computing is to provide a strong enough technical foundation to allow people to decide for themselves.
I think the practical path forward is to build up collaborations across a bunch of languages and institutions, so if you also work in a related subfield and share the overall goals of this proposal, please contact me here! Hopefully we can start building up a network of people interested in such a project.