Links - 16^th February 2020

I keep talking about this, but I think it’s really fascinating how computer art tools typically are restricted to trying to simulate the art tools that happen in real life. We get very little expression that’s unique to the digital format. You actually have to work pretty hard in Photoshop to simulate glitch art. Even pixel art isn’t very directly supported (you kind of have to work a little to get that).

So when you’re approaching an art tool and the specific goal is to be unique to digital art… designing that is really fascinating. Even just coming up with concepts of “Ok, how do you even support glitch art?” “How should someone draw with a glitch?” is an interesting problem to approach. There’s not defined design language for how you would enable “brokenness” in an art tool.

Brokenness aside, what is unique to computers and how would you properly enable that in an art tool?

Tool design is weirdly a lot like game design. When the tools are very new (unique, and no practical “art language” exists for their purpose), you also have to teach people how to use them. They have to be approachable enough for people to feel comfortable to mess around in them. You can’t have any sense of failure or judgement on part of the tool. If things were presented in such a way as there were “stakes” involved, or some kind of urgency for efficiency looming over experimental tools, then I think people would be too intimidated to explore them.

Like surrealism, abstraction, or a humorous presentation (environment) for them helps a lot.

The tone a program sets is how people will feel inclined to use it.

My conclusion is that’s why many people in the industry think unchecked exceptions are “good enough”. They stay out of your way for the common success paths and, because most people don’t write robust error handling code in non-systems programs, throwing an exception usually gets you out of a pickle fast. Catching and then proceeding often works too. No harm, no foul. Statistically speaking, programs “work”.

Weird machines — the computational models accessible by exploiting security vulnerabilities — arise from the difference between the model a programmer has in her head of how her program should run and the implementation that actually executes. Previous attempts to reason about or identify weird machines have viewed these models through the lens of formal computational structures such as state machines and Turing machines. But because programmers rarely think about programs in this way, it is difficult to effectively apply insights about weird machines to improve security.

We present a new view of weird machines based on techniques from programming languages theory and secure compilation. Instead of an underspecified model drawn from a programmers' head, we start with a program written in a high-level source language that enforces security properties by design. Instead of state machines to describe computation, we use the well-defined semantics of this source language and a target language, into which the source program will be compiled. Weird machines are the sets of behaviors that can be achieved by a compiled source program in the target language that cannot be achieved in the source language directly. That is, exploits are witnesses to insecure compilation.

Dullien defines weird behavior as the difference between two state machines — an intended finite state machine (IFSM) corresponding to the model that the programmer has in her head when writing the program and an implementation that attempts to realize the IFSM. A weird state in the implementation is one that does not correspond to a state in the IFSM. A weird machine is the collection of computations reachable from a weird state.

• 3. The severity of an incident is measured by the number of rules broken in resolving it.

• 10. Your infrastructure uses a lot more self-signed certificates than you think. A lot more. In places that make you weep.

• 26) Your network team has a way into the network that your security team doesn’t know about.

• 37) Nobody knows how git works; everybody simply rm -fr && git checkout's periodically.

• 38) There are very few network restrictions creative and determined use of ssh(1) port forwarding can’t overcome.

• 45) Some of your most critical services are kept alive by a handful of people whose job description does not mention those services at all.

I first got into web design/development in the late 90s, and only as I type this sentence do I realize how long ago that was.

And boy, it was horrendous. I mean, being able to make stuff and put it online where other people could see it was pretty slick, but we did not have very much to work with.

I’ve been taking for granted that most folks doing web stuff still remember those days, or at least the decade that followed, but I think that assumption might be a wee bit out of date. Some time ago I encountered a tweet marvelling at what we had to do without border-radius. I still remember waiting with bated breath for it to be unprefixed!

But then, I suspect I also know a number of folks who only tried web design in the old days, and assume nothing about it has changed since.

I’m here to tell “all” of you to get off my lawn. Here’s a history of CSS and web design, as I remember it.

The Manifest-No is a declaration of refusal and commitment. It refuses harmful data regimes and commits to new data futures.

1. We refuse to operate under the assumption that risk and harm associated with data practices can be bounded to mean the same thing for everyone, everywhere, at every time. We commit to acknowledging how historical and systemic patterns of violence and exploitation produce differential vulnerabilities for communities.

2. We refuse to be disciplined by data, devices, and practices that seek to shape and normalize racialized, gendered, and differently-abled bodies in ways that make us available to be tracked, monitored, and surveilled. We commit to taking back control over the ways we behave, live, and engage with data and its technologies.

3. We refuse the use of data about people in perpetuity. We commit to embracing agency and working with intentionality, preparing bodies or corpuses of data to be laid to rest when they are not being used in service to the people about whom they were created.

4. We refuse to understand data as disembodied and thereby dehumanized and departicularized. We commit to understanding data as always and variously attached to bodies; we vow to interrogate the biopolitical implications of data with a keen eye to gender, race, sexuality, class, disability, nationality, and other forms of embodied difference.

5. We refuse any code of phony “ethics” and false proclamations of transparency that are wielded as cover, as tools of power, as forms for escape that let the people who create systems off the hook from accountability or responsibility. We commit to a feminist data ethics that explicitly seeks equity and demands justice by helping us understand and shift how power works.

• What their mental models were of the system at the time, including the state of the code, the infrastructure, and the expectations of other teams, and how those mental models contributed to their decision making.

• Where their mental models were divergent and the effects of this divergence during incident response.

Performance changes how users use software

It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower.

What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task. Users almost always have multiple strategies available to pursue a goal — including deciding to work on something else entirely — and they will choose to use faster tools more and more frequently. Fast tools don’t just allow users to accomplish tasks faster; they allow users to accomplish entirely new types of tasks, in entirely new ways.