‘how the web works’ workshop feedback

i’ve been working at the glass room as an “inGenious” and taught an hour-long workshop there on saturday about how the web works. everyone who does a workshop has been sending feedback to everyone else so we can all be more prepared next time we teach. here’s what i said about mine:

hey! here’s feedback from the workshop i did saturday at 3pm:

there were a whole bunch of people (30-40?), so we couldn’t go around and do names/intros. but we did write our names on tape as name tags, which i found helpful and i hope they did too since they had to do an activity together.

i started with an intro and then asked what folks were interested in. the responses were generally either ‘knowing more about infrastructure’ or ‘knowing specific things to do to protect my privacy’

then, i handed out the internet infrastructure cards- about one set per 6-7 people, which i think worked okay. the groups finished laying everything out very quickly, like less than 10 minutes. i asked groups to share out how this activity went for them and there were a few sentiments:
– ‘i thought i knew how this worked, but when i had to lay everything out, i realized there were some gaps in my knowledge’
– ‘what’s a national gateway?’

– ‘why are there two computers?’

in general, i think the cards were really helpful for people. on reflection, and after reading the feedback forms, i think i should have spent more time going over each element in the set of cards instead of only having groups explain their own layouts. i think i also should have done a better job explaining why there are multiple right answers and your configuration could have routers, servers, etc in a different place than other groups.

after doing the big picture stuff, i showed some links that i put together: kaganjd.github.io/how-the-web-works

people were *really* into the submarine cable map!

i used that + infrastructure cards to say that the internet is physical and that there are different places along the line where info can be intercepted. then, i went into vpn vs. tor vs. https. i explained a little bit of the technical stuff and tried to just reiterate over and over again that people should def get ‘https everywhere’ (free!) and try a 2-week free trial of cloak vpn. people had fairly technical questions about vpn’s- how do they work? do i need one at home? does it encrypt everything? etc., so i’d be ready for that (many thx to sara for helping me navigate those!)

there were 2 kinda derailer/mansplainy guys. a way i tried to address them was listen for a little bit, nod my head, and then try to tie something they said back to something someone said earlier or a question someone else asked. then, i could shift the mic to the new person and we could eventually get back on track.

so yeah! it was fun! if you’re teaching this one and have q’s about any of this, let me know!

“change sketch routes” PR walk-through

cassie walked me through a web editor issue that i was having a lot of trouble with. i learned a ton, so i’m documenting the process here.

we wanted to change sketch routes so that sketch URLs included the sketch username because that just makes more sense!


but within the editor, there are client-side routes and server-side routes.screen-shot-2016-11-30-at-5-53-56-pm


cassie explained the difference between these:

  • the server-side routes—which live in server.routes.js—render html. when a user initiates a session, they get data via these routes.
  • the client-side routes—which live in routes.jsx—render a react.js view. when a user doesn’t need a whole new session but just needs some data populated from a small portion of the editor, the interaction usually just makes an ajax request. an ajax request means that the entire page doesn’t have to refresh, so the new content gets loaded more quickly.

there is another set of server-side routes: the api routes, which are internal to the server-side. these endpoints serve JSON data, which is then used to populate react views on the front-end. we didn’t mess with api routes for this PR, but they’re important to know about.

in order to create our sensible new sketch routes, we edited 7 files in total but these were the 2 most important ones:

  • server/routes/server.routes.js
  • client/routes.jsx

so, in order, here’s how we did things:

  1. create a server-side route— /username/sketches/id —the response calls the function renderIndex() which renders the whole appscreen-shot-2016-11-30-at-5-49-53-pm
  2. create a client-side routescreen-shot-2016-11-30-at-6-07-31-pm
  3. then, we had to make sure that all the places in the web editor where you’d click to navigate to a particular sketch—from the sketch list, or to clone a project, or to share a project, or to create a new project, or to save a project—used the correct route to get the sketch you wanted. this is the kind of navigating within the app, as opposed to getting data from the server, that happens via ajax requests. here’s a photo of a link in the sketch list view so you have a sense of what i mean:screen-shot-2016-11-30-at-6-14-15-pm
  4. here’s how we changed the route in the SketchList.jsx file:screen-shot-2016-11-30-at-6-44-54-pmline 28 says: “if props.username is not undefined (so, it exists), then use it to build the route in line 68. otherwise, use props.user.username to build the route.”
  5. rinse and repeat for other places within the front-end where sketches are accessible from. review the pr to see them in detail.

things i found challenging:

  • knowing which react components had access to which props
  • the significance of step 2/the client-side route
  • wrapping my head around the api routes and how the JSON files at their endpoints ultimately get back to the front-end


is the project i’ve been working on with surya. it’s a website that hosts a video and tool that lets users dig into network packets. we’re getting into crunch time, so i’ve started filing issues in the repo to help me keep track of stuff i need to do/write. surya made a little annotated map of the app structure to help me wrap my head around everything:

├── app <- contains all the src for the front end
│   ├── App.vue <- The main ‘app page’. Contains the Toolbar and Console components. Will also contain the viz stuff when i get to t.
│   ├── Stack.vue <- old stuff that ive just left here for ref. right now
│   ├── components <- All the components of the app
│   │   ├── Console.vue  <- all css in _console.scss
│   │   ├── Sniffer.vue <- all css in _sniffer.scss
│   │   ├── Stack.vue <- old stuff that ive just left here for ref. right now
│   │   ├── ToolBar.vue <- all css in _nav.scss (meant to rename it but forgot!)
│   │   ├── third-party <- testing some libs not used yet
│   │   │   └── vue-drag-resize-rotate.vue
│   │   └── tools <- testing some stuff not used yet
│   ├── filters <- vue.js helper functions for formatting text
│   │   └── index.js
│   ├── main.js <- First thing to get loaded. This loads App.vue and has socket.io connections to the back end
│   └── store <- vue.js app state management stuff
│       ├── actions.js
│       ├── getters.js
│       ├── index.js
│       ├── modules
│       │   └── toolbar.js
│       ├── mutation-types.js
│       └── untitled\ folder
├── index.html
├── main.js <- back end main script
├── network-scripts <- back end scripts
│   ├── pcap-filters.js
│   ├── pcap-parser.js
│   └── tcp-test.js
├── package.json
├── static
├── styles <- csssssss

two paths

  1. a useful, practical app to automate uber incentive tracking, store data, and help prevent wage theft
  2. a speculative project, grounded in research, about facebook users as workers that imagines ux elements (buttons, etc.) and policies that would enable organizing and enshrine user/worker protections in law

notes from my meeting with alex

what i brought to the meeting:

things that have happened in the world:
– nodapl facebook check-ins
– instacart strike
– korryn gaines case, baltimore police and facebook collaboration

– re: korryn gaines, i am interested in facebook users mobilizing on the platform to demand accountability, much in the same way as workers would organize to leverage collective power to make demands of employers. however, when i share this with others, it doesn’t totally click. people don’t immediately “get” the facebook users as workers connection, even though after you say it, there is some recognition that it is possible.
– re: instacart, people working within the constraints of the platform itself to call attention to/organizing against/making demands around the misuse of the platform
– re: nodapl, using the platform itself to make demands around misuse of the platform or what the platform should be used for
– working within the constraints of these platforms feels like a kind of hacking that’s interesting to me

people doing work in this space:
– you
– turkopticon
– lightbeam
– do you know others?

these are potential starting points for my work:
– uber driver api (interesting because access is discretionary)
– chrome extension
– do you know existing organizing patterns? communication patterns?

my goals:
– i want to make something rigorous, but where outcomes are not the same as a commercial project. that puts this in “art” world? but where i can ask good questions
– you know how to ask good questions and how to know which questions are worth asking…

these are questions i have for you:
– what are the organizing affordances of these platforms that’s different from IRL organizing, aside from scale which is the one everyone points to


what i took away from the meeting:

Michelle Miller, coworker.org
Robyn Caplan, D&S


– way of defining harm
– is there a precedent in consumer protection law?

**dedicated users**
– who wants to be advocated for?
– probably not casual users/earners

– what does “active” mean? different things on different platforms
– what does it mean that a customer or employee can be “deactivated”
– inventing new language, new vocabulary to obscure responsibility/accountability
– talk to companies who have access to the Driver API
——–> automate incentive tracking, prevent wage theft
——–> 3rd party account of drivers meeting expectations

Urban Hail
– Uber cut off their API access

System design critiques
– common in physics; people who worked on the atom bomb
– what are the ethics of working on grocery supply systems when those are mapped to human/employment systems?
– costs (political, human) of this mapping

Discretionary calls
– norms around being public square in conflict with norms around being a corporation

– discretionary access to controlled APIs (like Uber driver API, which has information about routes and fares) as a way of wielding power

Repos to review

the past few weeks

  • djt was elected president
  • i participated in 32 hours of training with tactical tech and mozilla leading up to working in the glass room, an exhibition and workshop space i’m so excited about
  • the tisch restroom policy committee met to start drafting a statement and signage plan for gender-neutral bathrooms throughout the building. it’s been heartening to work with professors and administrators who care about making tisch work for their trans and gender non-conforming students and colleagues.
  • i saw anna deveare smith’s tremendous show, notes from the field. trying to channel her generosity and energy the next four years++

undoing the demos

this is where i’ll collect quotes from wendy brown’s book undoing the demos that i think are relevant to my project of something something organizing, digital platforms, and labor:

“The transformation of labor into human capital and of workers into entrepreneurs competing with other entrepreneurs obviously obscures the visibility and iterability of class to an even greater degree than classical liberalism does. It also eliminates the basis for alienation and exploitation as Marx conceived them.” -p65

“Third, when everything is capital, labor disappears as a category, as does its collective form, class, taking with it the analytic basis for alienation, exploitation, and association among laborers. Dismantled at the same time is the very rationale for unions, consumer groups, and other forms of economic solidarity apart from cartels among capitals. This paves the way for challenging several centuries of labor law and other protections and benefits in the Euro-Atlantic world and, perhaps as important, makes illegible the foundations of such protections and benefits.” -p39

project studio road map til semester end


  • meet with alex 11/8
  • follow up with media justice center


  • read 3 papers ahead of 11/8 meeting
  • pull quotes from ‘the undercommons’
  • pull quotes from ‘undoing the demos’
  • go back to my performance of politics paper and the undercommons


  • start conceptual scaffolding for thesis:
  • why labor has changed (wendy brown)
  • modes of resistance (the undercommons), discussion of the differences/overlaps between art, tech, spec design, advocacy
  • outline of existing tools in this space/inspiring projects
  • outline of existing opposite-inspiring projects


  • prototype a chrome extension for facebook? uber?
  • prototype an automated script for facebook? uber?
  • prototype an ad for facebook? uber?


  • apply to d&s workshop on labor

SYN flooding test

i’ve been testing the idea i described in my last post. in the vid below, i use james woolley’s python script to flood the ball drop game with syn packets. i execute the script to send 2000 packets consecutively to the ip and port that the server is listening on. while that’s going, i connect to the game with the ball drop client. the client seems to connect with no delay which is unfortunate since i want a delay. i’m not sure whether i’ve set something up wrong or whether 2000 packets just isn’t that many.


well, here we are, a thousand rabbit holes later. when i tried executing the syn flood script with 20,000 packets and the connection didn’t change, i decided i was doing something wrong. i looked into a few other kinds of attacks, but ultimately came back to this one. below are some characteristic screen shots of my wireshark readings.

in the first one, you see a SYN from assigned port to port 8080, SYN/ACK from 8080 to me, and RST from me to 8080. RST means to close the connection because something’s gone wrong, and the client started by the python script kept sending them out when the connections were (predictably) broken. sometimes, a message from the actual ball drop client would get through in the middle of all this SYN/ACK/RSTing, which suggested to me that maybe there was something multi-threaded about the connection? and if there are multiple threads, how do you know how many there are and what their capacities are? and how do you block them all? 😱


here’s another thing that happened: a bunch of SYN packets, with no RST packets (great!) with ball drop client messages in between (not great!). the ball drop client messages here are the two not-gray ones in the middle. the arrow is pointing to the payload, which is “L” for directing the paddle to go left.


so, like, wtf? i went back to where i’d originally gotten the syn flood python script. i realized that i’d totally skipped the first script, which blocks RST packets from being sent out. alas, the utility it relies on, iptables, is for linux and isn’t a thing on mac os x. i went hunting for alternatives and learned about pf.conf and tried to implement a block on RST flags using this solution. double alas. i could edit pf.conf, but couldn’t load the new file to be executed.