Shadow work is unpaid labor,done byconsumers, in the process making a purchase of a product or service. the self-checkout isle in the grocery story, ikea furniture that you must assemble, self-service gas stations, travel planning, checking in your baggage at the airport. all of these were previously done by someone else. The travel agent, the gas station attendent, the cashier and bagboy etc.

these tasks are offloaded to the consumer to save the producer or merchant the wages and other resources that would be required to fulfill these tasks. In theory, this savings could be passed on to the consumer, but in practice they usually end up as increasing profit margins for owners and shareholders.

Meanwhile, the consumer spends an ever-increasing portion of her day completely these tasks. She recieves no benefit in return(save for maybe avoiding the occasional frustrations of incompetents and new-hires) but merely enriches the merchant through her efforts.

The proliferation of javascript and otheo client-side scripting languages on the www has had a similar,though not identical, effect to users. The host site offloads the work to the client's machine,saving resources and avoiding various network latencies. We,the users, should expect some benefits to trickle down to us, both from reduced operating costs incurred by the host as well improved responsiveness and other performance metrics, but they are often cancelled out by various negative effects, not least of which are related to security and privacy.

This client-side code often uses various methodologies to track users on the host website as well as across other websites. This information can then be used sold to advestizer, released to law enforcement or other government agencies or end up in the hands of a plethora of various ne'erdowells.

it can also run unauthorized code on the user's machine; things like crypto-miners or botnet programs can hijack user resources for various ends. And you might have no way of knowing what is going on if the code is closed sourced or run through an obfuscator. even if the host is reputable and operating above-board, a security breach in a widely-used content management platform could mean that an undetected third party has surrepticiously uploaded malicious scripts onto your favorite website and using your resources to,for example, contribute to a distributed password-cracking operation (good thing that's not a real thing that has definitely never happened...).

a few ways to avoid this without comlpletly upending the client-side scripting paradigm is avoiding closed-source licenses for client-side code or abandoning the use of code obfuscators for easy inspection by users.

But obfuscation has practical uses outside of hiding code and the intellectual property culture of most industry means that expecting open-source adoption at scale is still a utopian pipe dream.

the easiest and most practical solution is to reject all client-side scripting. we may lose some conveniences but it will save most user resources in the short-term and prevent many of the afformentioned security problems in the long-term.

Anybody that uses a script blocker on their browser knows this is an uphill battle, however; a large portion of the www either malfunctions or fails completely when the user blocks all javascript. it will requier a paradigmatic shift in most aspects of web design and development but the alternative is an acceptance of resource cooption and the duct-tape-and-chewing-gum model of netsec that currently plagues the big net.