ccl 4 years ago
parent
commit
ea8c9735ac
  1. 9
      content/Section 2 - Harm in Computational Infrastructures/1-introduction.md
  2. 14
      content/Section 2 - Harm in Computational Infrastructures/2-introduction-seda.md
  3. 7
      content/Section 4 - Bot Logic/1-introduction.md

9
content/Section 2 - Harm in Computational Infrastructures/1-introduction.md

@ -9,15 +9,6 @@ Summary: How to correct, shift or expose harms in computational infrastructures?
In this section we will unpack how computational infrastructures operate and what impact that has on the digital systems that are being built on top of them.
We will introduce the work of Seda Gürses and dive with her into the following questions:
* What are computational infrastructures?
* What are elements that shape (or are shaped by) computational infrastructures?
* How can we understand the harm caused by computational infrastructures and the systems which deploy them?
* What interventions are possible to mitigate or eliminate this harm?
* What kind of limitations do you see in the realisation of these interventions?
<!-- Her work focuses on privacy enhancing and protective optimization technologies (PETs and POTs), privacy engineering, as well as questions around software infrastructures, social justice and political economy as they intersect with computer science. -->

14
content/Section 2 - Harm in Computational Infrastructures/2-introduction-seda.md

@ -5,9 +5,17 @@ Summary: Seda Gürses, computational infrastructures & *POTs (Protective Optimiz
Seda Gürses is currently an Associate Professor in the Department of Multi-Actor Systems at TU Delft at the Faculty of Technology Policy and Management, and an affiliate at the COSIC Group at the Department of Electrical Engineering (ESAT), KU Leuven. Beyond her academic work, she also collaborated with artistic initiatives including Constant vzw, Bootlab, De-center, ESC in Brussels, Graz and Berlin.
Gürses' work provides us with handles to study computational infrastructures. The paper on *POTs (Protective Optimization Technologies)*[^pots] she co-wrote, for example, proposes forms of critical *optimization* practices. Such practices "aim at addressing risks and harms that cannot be captured from the fairness perspective and cannot be addressed without a cooperative service provider". The paper questions current "fairness" approaches, by inquiring their limitations and creating space for alternative ways to review them. An important factor in this paper is the proposal to approach computational infrastructures as something that is far more than a technological system alone, thus shifting focus from the system itself to the economical, political and social context in which it operates.
Gürses' work provides us with handles to study computational infrastructures. The paper on *POTs (Protective Optimization Technologies)*[^pots] she co-wrote, for example, proposes forms of critical *optimization* practices. Such practices "aim at addressing risks and harms that cannot be captured from the fairness perspective and cannot be addressed without a cooperative service provider". The paper questions current "fairness" approaches, by questioning their limitations and creating space for community-inclusive ways to review them. Following Michael A. Jackson’s theory of requirements engineering, the paper also proposes to approach computational infrastructures as being far more than a technological system alone, thus shifting focus from the system itself to the economical, political and social context in which it operates.
By questioning how technologies could *optimize* their mode of operation in a truly fair way, *POTs* provide "means for affected parties to address negative impacts of digital systems". The work departs from a thorough consideration of multiple forms of *harm* caused by computational infrastructures framed as *externalities*. Examples of such externalities include lack of privacy, discrimination, low wages and surveillance. How a *POT* could possible engage with these externalities is furthermore illustrated through a range of activist, artistic and deployed examples of repurposed optimization technologies that "correct, shift or expose these harms". *Externalities* is one of the concepts and phrases in the paper that are borrowed from software and requirements engineering, and from economics and social sciences.
By questioning how technologies could *optimize* their mode of operation in a truly just way, *POTs* provide "means for affected parties to address negative impacts of digital systems". The work departs from a thorough consideration of multiple forms of *harm* caused by computational infrastructures framed as *externalities*[^externalities]. Examples of such externalities include lack of privacy, discrimination, low wages and surveillance. How a *POT* could possible engage with them is furthermore illustrated through a range of activist, artistic and deployed examples of repurposed optimization technologies that "correct, shift or expose these harms".
We will introduce the work of Seda Gürses and dive with her into the following questions:
* What are computational infrastructures?
* What are elements that shape (or are shaped by) computational infrastructures?
* How can we understand the harm caused by computational infrastructures and the systems which deploy them?
* What interventions are possible to mitigate or eliminate this harm?
* What kind of limitations do you see in the realisation of these interventions?
<!-- They effect different externalities, operate on the basis of specific embedded values and define restrictions of what can be built on top of the infrastructure and what not. -->
@ -36,3 +44,5 @@ By questioning how technologies could *optimize* their mode of operation in a tr
[^progammableinfrastructures]: Seda Gürses, Roel Dobbe, Martha Poon "Seminar on Programmable Infrastructures" (2020). <https://www.tudelft.nl/tbm/programmable-infrastructures/>
[^titipi]: Miriyam Aouragh, Seda Gürses, Femke Snelting, Helen Pritchard "The Institute for Technology in the Public Interest" (accessed on 2020) <http://titipi.org/>
[^externalities]: *Externalities* is one of the concepts and phrases in the paper that are borrowed from software and requirements engineering, and from economics and social sciences.

7
content/Section 4 - Bot Logic/1-introduction.md

@ -3,15 +3,14 @@ Slug: 01-s4-introduction
Date: 2020-11-01 12:00
Summary: Bots as computational infrapunctures.
*Infrapuncture* is a helpful term at a time when there is a lot of discussion around the political roles of automated agents in digital infrastructures. Making a bot can be a way to probe and understand potential forms of interventions, create new imaginaries or deflate existing hegemonic structures.
*Infrapuncture* is a helpful term at a time when there is a lot of discussion around the political roles of automated agents in communication platforms. Making a bot can be a way to probe and understand potential forms of interventions, create new imaginaries or deflate existing hegemonic structures.
A bot is however always relying on the technical restrictions and possibilities of interaction defined by the infrastructure. In order to run a bot, a technical understanding of this infrastructure is therfor required. The API (Application Programming Inferface) is an important entry point here. This technical framework provides a programming interface to communicate with a system. The API can be understood as a *door protocol* that is designed by the owner of an infrastructure, which eventually defines the technical imaginary of a platform.
Before launching a bot into a digital environment, the bot maker does not only need to find a technical entry point, but also a social one. Writing a bot does not only imply technical knowledge about an API of a platform, it also implies a thorough understanding of what determines the possibilities of interaction and the social norms established within a social environment.
Before launching a bot into a digital environment, the bot maker does not only need to find a technical entry point, but also a social one. Writing a bot does not only imply technical knowledge about an API of a platform, it also implies a thorough understanding of what determines the possibilities of interaction and the social norms established within a social environment.
By introducing *bot logic*, the aim of this section is to highlight the sociality that shapes (or is shaped by) bots.
By introducing *bot logic*, the aim of this section is to highlight the sociality that shapes (or is shaped by) bots.
<!-- The editor community of English Wikipedia consists, for example, of both humans and bots. The interactions between them go beyond the maintenance of Wikipedia. Instead, affective relations are formed wherein the bots are anthropomorphised. In the case of Wikipedia, it means that a bot maker needs to develop an understanding of the social dynamics of the community of editors and users of Wikipedia, in order to make a bot that is embedded well into the community. The understanding of Wikipedia's social dynamics are crucial in order to make a bot that can interact with the work of multiple individuals that edit Wikipedia, ranging from first-time editors, dedicated editors, groups coming together during edit-a-thon or different kind of trolls. And that's of course just one example. Bots act differently depending on the platform on which they are running. -->
<!-- While deconstructing infrastructures in order to find the points of stress, harm or hurt, the undoing is as important as the doing. Deconstruction can happen simultaneously to construction and in fact this is the strength of accupuncture: it does not work on its own. -->

Loading…
Cancel
Save