{
    "archive_path": "archive/1770703253.631358",
    "base_url": "calebhearth.com/dont-get-distracted",
    "basename": "dont-get-distracted",
    "bookmarked_date": "2026-02-10 06:00",
    "canonical": {
        "archive_org_path": "https://web.archive.org/web/calebhearth.com/dont-get-distracted",
        "dom_path": "output.html",
        "favicon_path": "favicon.ico",
        "git_path": "git/",
        "google_favicon_path": "https://www.google.com/s2/favicons?domain=calebhearth.com",
        "headers_path": "headers.json",
        "htmltotext_path": "htmltotext.txt",
        "index_path": "index.html",
        "media_path": "media/",
        "mercury_path": "mercury/content.html",
        "pdf_path": "output.pdf",
        "readability_path": "readability/content.html",
        "screenshot_path": "screenshot.png",
        "singlefile_path": "singlefile.html",
        "warc_path": "warc/",
        "wget_path": null
    },
    "domain": "calebhearth.com",
    "downloaded_at": "2026-02-10T06:00:58.937284+00:00",
    "downloaded_datestr": "2026-02-10 06:00",
    "extension": "",
    "hash": "1690VBRFTMNJPKY229HK",
    "history": {
        "archive_org": [
            {
                "cmd": [
                    "/usr/bin/curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--proxy",
                    "socks5://tor-socks-proxy:9150",
                    "--head",
                    "--max-time",
                    "60",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "https://web.archive.org/save/https://calebhearth.com/dont-get-distracted"
                ],
                "cmd_version": "8.10.1",
                "end_ts": "2026-02-10T06:02:30.872052+00:00",
                "index_texts": null,
                "output": "TimeoutExpired: Command '['/usr/bin/curl', '--silent', '--location', '--compressed', '--proxy', 'socks5://tor-socks-proxy:9150', '--head', '--max-time', '60', '--user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)', 'https://web.archive.org/save/https://calebhearth.com/dont-get-distracted']' timed out after 60 seconds",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:01:30.819612+00:00",
                "status": "failed"
            }
        ],
        "dom": [
            {
                "cmd": [
                    "/usr/bin/chromium-browser",
                    "--proxy-server=socks5://tor-socks-proxy:9150",
                    "--disable-features=DarkMode",
                    "--run-all-compositor-stages-before-draw",
                    "--hide-scrollbars",
                    "--autoplay-policy=no-user-gesture-required",
                    "--no-first-run",
                    "--use-fake-ui-for-media-stream",
                    "--use-fake-device-for-media-stream",
                    "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'",
                    "--headless=new",
                    "--no-sandbox",
                    "--no-zygote",
                    "--disable-dev-shm-usage",
                    "--disable-software-rasterizer",
                    "--disable-sync",
                    "--window-size=1440,2000",
                    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "--user-data-dir=/data/personas/Default/chrome_profile",
                    "--profile-directory=Default",
                    "--dump-dom",
                    "https://calebhearth.com/dont-get-distracted"
                ],
                "cmd_version": "131.0.6778",
                "end_ts": "2026-02-10T06:01:15.982339+00:00",
                "index_texts": null,
                "output": "output.html",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:01:02.832935+00:00",
                "status": "succeeded"
            }
        ],
        "favicon": [
            {
                "cmd": [
                    "/usr/bin/curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--proxy",
                    "socks5://tor-socks-proxy:9150",
                    "--max-time",
                    "60",
                    "--output",
                    "favicon.ico",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "https://www.google.com/s2/favicons?domain=calebhearth.com"
                ],
                "cmd_version": "8.10.1",
                "end_ts": "2026-02-10T06:01:02.136976+00:00",
                "index_texts": null,
                "output": "favicon.ico",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:00:58.992135+00:00",
                "status": "succeeded"
            }
        ],
        "git": [],
        "headers": [
            {
                "cmd": [
                    "/usr/bin/curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--proxy",
                    "socks5://tor-socks-proxy:9150",
                    "--head",
                    "--max-time",
                    "60",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "https://calebhearth.com/dont-get-distracted"
                ],
                "cmd_version": "8.10.1",
                "end_ts": "2026-02-10T06:01:02.674155+00:00",
                "index_texts": null,
                "output": "headers.json",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:01:02.233512+00:00",
                "status": "succeeded"
            }
        ],
        "htmltotext": [
            {
                "cmd": [
                    "(internal) archivebox.extractors.htmltotext",
                    "./{singlefile,dom}.html"
                ],
                "cmd_version": "0.8.5rc51",
                "end_ts": "2026-02-10T06:01:23.976955+00:00",
                "index_texts": [
                    "Don't Get Distracted (/assets/application-ff2f30defb9e247d298d8f136cd472499c883bb1bd305cc4ab9a85bab85dbed7.css) (/pubkey.asc) (https://calebhearth.com/dont-get-distracted) (/atom.xml) (/micro.json) (Micro notes) (/micro.html) (Articles) (/posts.html) (/icon.png) (https://pub.calebhearth.com/@caleb) (https://social.lol/@c) (https://github.com/calebhearth) (/humans.txt) (https://calebhearth.com/mentionable/webmention)  (/) Caleb Hea rth  (/posts) Blog  (/linked) Linklog  (/reading) Bookshelf  (/now) /now  (/links) /links    Don't Get Distracted   November 16, 2017    Be sure to check out these (/images/dont-get-distracted-sketchnotes--stephanie-nemeth.jpg) Sketchnotes from a 15 minute version of this talk from (http://codelandconf.com) Codeland by (https://twitter.com/stephaniecodes) Stephanie Nemeth   I\u2019m going to tell you about how I took a job building software to kill people. But don\u2019t get distracted by that; I didn\u2019t know at the time. Even before I\u2019d walked across the stage for graduation, I accepted an offer for an internship. It paid half again as much as the most I\u2019d ever gotten in the highest paying job up to that point. Not to mention that I\u2019d spent years in college with low paid student jobs or living only on student loans. I\u2019d be joining a contracting company for the Department of Defense. The Department of Defense, or DOD, is the part of the government made up by the military in the United States. The DOD outsources all sorts of things, from (https://www.defense.gov/News/Contracts/Contract-View/Article/1177766/) P-8A Multi-mission Maritime aircraft to blue, shade 451, Poly/wool cloth . At the time, I thought nothing of the fact that I\u2019d be supporting the military. Besides, they\u2019re the good folks right? My dad was in the military. So was my grandfather. It was good money, a great opportunity, and a close friend of mine had gotten me the gig. Life was good. I showed up for my first day of work in North Virginia, or NoVA as the industry likes to call it. I met the team of other interns, then learned what the team would be building: a tool to use phones to find WiFi signals. It seemed pretty cool compared to what I\u2019d built to up that point. The most complicated thing was an inventory management system. It didn\u2019t concern itself overmuch with persistence. Who needs to stop and restart a program anyhow? The data was right there in memory and if you forgot how many Aerosmith CDs you had, who cares? It got me an A on the assignment, and that was all that mattered. Honestly, the idea of finding WiFi routers based on the signal strength seemed pretty intimidating at the time. The idea impressed me. But don\u2019t get distracted by all this; the software was intended to kill people. I joined the team after they\u2019d already gotten started on the project. The gist of the tool was that it would look at how WiFi signal strength changed as your phone moved around. If the signal strength got stronger, you were getting closer. If it got weaker, you were moving away. To find this information, we\u2019d collect two pieces of information for each WiFi access point in range. The phone\u2019s geolocation information and the WiFi signal strength. To predict the actual location of the WiFi signal, we used a convolution of two algorithms. Both of them relied on the Free Space Path Loss equation. For our purposes, FSPL calculates how far away a phone is from a WiFi signal based on loss in signal strength. It assumes that there is only empty air, or \u201cfree space\u201d, between the access point and the phone. The first algorithm was R^2. It measured the difference between the signal strength we\u2019d observed and the expected signal strength at each distance in a search grid based on Free Space Path Loss. Locations with the lowest R^2 error rate were the most likely location. We\u2019d combine that calculation with a Gaussian estimate. Now I spent two or three days last week trying to understand Gaussian estimates for this talk and couldn\u2019t. The best documentation on them are still research papers. I do know that it creates a probability curve. The high points of the curve are distances where the access point is likely to be, and low points are unlikely. The curve started with a probability hole of low values. They represented low likelihood that the phone is standing right next to the signal. The curve then increased to high probabilities further out. It decreased to near zero even further. The algorithm adjusted the width and height of these two curves by consulting past measurements. It created a heat map of probabilities for the signal source. We\u2019d normalize the probabilities for each location in the search grid. A combination of probabilities was more correct than either algorithm itself. We stored this probability matrix for each location a phone collected from. Using these, if we collected readings while moving in a straight line, we could tell you how far away the WiFi was. If you turned a corner, we could also add direction, so you could find it in 2D space. If you climbed some stairs, we\u2019d show you altitude as well. The technology was the most interesting project I\u2019d ever worked on. But don\u2019t let that distract you; it was designed to kill people. I mentioned that I had a software engineering degree at this point. My teammates were earlier in their education careers. Most of them were a year or two into their four year programs, also a mix of Computer Science and Math majors. My expertise was in the design and process of building software, while theirs was more in high level mathematics or the theory of computer use. I helped to translate the working algorithms they\u2019d designed in MatLab to the Java code we needed to run on the phones. And let\u2019s be honest, we spent plenty of time deciding whether we preferred Eclipse or NetBeans. Can I say how happy I am that as a Ruby developer, I\u2019ve not had to figure out where to put a .jar file in over half a decade? One such example is calculating distance between two points. As these things go, it was in the deepest level of each loop. We were using great circle distance, which is the way you measure the shortest distance between two points on a sphere, such as Earth. Did we need to use this complicated measurement over the meager distances a WiFi network can operate over? Absolutely not. Did I mention this was over half a decade ago? We weren\u2019t always making the best choices. Anyhow, we needed to calculate these distances. The function doing it was being hit hundreds of thousands of time for each collection point, often with the same two locations. It was a very slow process. We solved that by implementing a dictionary of latitude/longitude pairs to distances. This at least meant we didn\u2019t re-do those calculations. This and other optimizations we made sped up the performance from seven minutes to a few seconds. But don\u2019t get distracted; that performance increase made it faster to kill people. The accuracy of the locations wasn\u2019t fantastic. I don\u2019t remember exactly what it was before we focused on improving this, but an average error about 45 feet sticks in my head. That\u2019s a little longer than a Tyrannosaurus Rex nose to tail, or more concretely the length of a shipping container. That\u2019s significant when the WiFi range for 802.11n is only about 100 feet. That means we could be up to almost half the range of the router off from where it was. I talked about the Gaussian estimation, the two curves from the second algorithm. We hard-coded numbers that defined this curve. They were only starting points, but they were starting points every time we made the calculation. A Genetic Algorithm is a type of program that produces a set of values that optimize for a desired result. It\u2019s a perfect fit for tuning these hard coded values to get more accurate results. Each of the Gaussian estimation values will is a gene. The set of values is a genome in Genetic Algorithm parlance. The genes were our 3 constants. A fitness function is what Genetic Algorithms use to measure performance of a genome. For the dataset of readings I was using in the GA, I knew the actual location of the access points. That meant I could run the geolocation algorithm with each genome\u2019s values in place as the fitness function. The result would be the distance between the actual location and the one calculated by the GA-derived values. Genetic Algorithms take a set of genomes, called a generation, and keep a certain percentage of top performers. These top performers \u201csurvive\u201d to the next generation as copies. Sometimes the algorithm mutates these copies by adding a Gaussian random value to each gene. This means that there was a chance that any of the copied genomes would have each gene changed slightly. That way they would have a chance of performing better or worse. New random genomes are created for the remaining spots in the new generation. We saved the top performers across all populations. When the GA ended I could take a look at the values and select the best performer. I let this genetic algorithm run over the weekend. It was able to increase the accuracy from 40-odd feet to about 10.3 feet, 25% of the error from the original. That is less than the GPS accuracy on the smartphones collecting data (which is about 16 feet according to GPS.gov). This is too accurate, so it may have over-optimized against the test data and might not be as accurate against other data sets. This is called overfitting and the way around it is to have separate sets of training and test data. Did I mention this was five years ago? I didn\u2019t even know what overfitting was back then. I loved this. Genetic algorithms, R^2, and Gaussian estimation are the kind of thing that they tell you you\u2019ll never need to use again once you graduate. But we were using them for a real world project! It was great. But don\u2019t let that distract you; this accuracy made it easier for the software to help kill people. The tracking now worked accurately and quickly. The next feature was to add tracking a moving WiFi access point. I briefly wondered why an access point would be moving, but that question wasn\u2019t as interesting as figuring out how to track it. We made use of Kalman Filters to observe state variables: the position, velocity, and acceleration of the WiFi signal. Given these and the time since the last measurement, a Kalman Filter is able to improve the current prediction with surprising accuracy, filtering out \u201cnoise\u201d data automatically. Each time we ran the real time algorithm, we\u2019d also feed this to the Kalman Filter.  With only that information, it was able to produce an estimate that is a weighted average of previous data. A new predicted location that was more accurate than the calculated value. At the same time, we added the ability to track more than one WiFi signal. We\u2019d filter our collection of readings by the unique identifier of each access point. The filtered datasets each went through the full algorithm to produce predictions. We used the APIs on the phone to read the signal strength of all WiFi access points in range. We were able to track multiple hotspots, basically whatever we could see in the WiFi network list. It was all very exciting. These seem like academic problems, but we were getting to use them in a real project! Being a programmer was going to be great. But don\u2019t let that distract you; this meant we could kill multiple more accurately people. We\u2019d been working with the project owner throughout this process. He was laissez-faire about most things. He might check in once a day then going back to his main job in the area of the building dedicated to classified work. Whenever we hit one of these milestones, we\u2019d tell him. He\u2019d be happy about it, but a question always came up. He wanted it to sniff for the signals put out by phones in addition to WiFi hotspots. This is a much harder problem from a technical perspective. The functionality necessary to do this is \u201cpromiscuous mode\u201d, a setting on the wireless network controller. Neither iPhone nor Android supported that option. We\u2019d need to jailbreak or root the phone regardless of the platform. We looked for packages that we could use that would let us do this to \u201csniff\u201d the packets that devices sent back to routers. The closest we ever found was a SourceForge project that seemed promising. We didn\u2019t fully understand its use and it wasn\u2019t well documented. We told the project owner that we\u2019d get to it later. None of us thought it was that important: we had the technology to find WiFi Access Points working. That was the goal right? Each time we\u2019d demonstrate the new exciting tech we\u2019d built though, the same question came up. We got WiFi hotspots located! Great, does it find phones? It\u2019s taking seconds instead of minutes! Great, does it find phones? We looked into it finding phones, it seems unlikely but maybe! Ok, we\u2019ll come back to it. We got moving targets working! Great, does it find phones?  I had been distracted. All of the cool problems we were solving: finding nodes, speeding things up, making more accurate predictions. It was all so cool, so much fun. I hadn\u2019t thought about why we were putting all this work into finding a better place to sit and get good WiFi. That doesn\u2019t even make sense if you look at it for more than a few seconds. Does it find phones.  This was never about finding better WiFi. We were always finding phones. Phones carried by people. Remember I said I was working for a Department of Defense contractor? The DoD is the military. I was building a tool for the military to find people based on where their phones where, and shoot them. I tried to rationalize this then. The military is in place to protect Truth, Justice, and the American Way. But this was the same time that we found out the government had been spying on Americans in the US with drones. They\u2019d also lent out that technology to federal, state, and local law enforcement agencies nearly 700 times to run missions. The military and government do things that I know I don\u2019t agree with pretty often. I didn\u2019t want to be a part of building something used to kill people, especially since I knew I\u2019d never know who it was killing, let alone have a say. I rationalize it now too. We were interns, and we didn\u2019t even have clearance. The projects this company did for the government were classified Top Secret. I wasn\u2019t allowed to know what they were. My code probably got thrown away and forgotten. Probably. This was an extreme example of code used in a way that the creator did not intend it. The project owner conveniently left out its purpose was when explaining the goals. I conveniently didn\u2019t focus too much on that part. It was great pay for me at the time. It was a great project. Maybe I just didn\u2019t want to know what it would be used for. I got distracted. There are other examples of when code is used in ways it wasn\u2019t intended, and of code that does bad things. A year and a day ago, a developer named Bill Sourour (https://medium.freecodecamp.org/the-code-im-still-ashamed-of-e4c021dff55e) (The Code I'm Still Ashamed Of) wrote a blog post . It opened with the line: \u201cIf you write code for a living, there\u2019s a chance that at some point in your career, someone will ask you to code something a little deceitful \u2013 if not outright unethical.\u201d Bill had been asked to create a quiz that would almost always give a result that benefitted his client. Bill worked in Canada, and in Canada there are laws in place that limit how pharmaceutical companies can advertise prescription drugs to customers. Anyone could learn about the general symptoms a given drug addressed, but only patients with prescriptions could get specific information about the drug. Because of this law, the quiz was posing as a general information site and not an advertisement for a specific drug. If the user didn\u2019t answer that either they were allergic to the drug or already taking it, every quiz result suggested this specific drug. That\u2019s what the requirements said to do, and that\u2019s what Bill coded up. The project manager did a quick test before submitting the website to the client. She told Bill that the quiz was broken: it always had the same answer. \u201cThose were the requirements,\u201d Bill responded. \u201cOh. Ok.\u201d A little while later, Bill got an email from a colleague that had a link to a news article. A young woman had taken the drug that Bill had built this quiz for. She had killed herself. It turns out that one of the main side effects of the drug were severe depression and suicidal thoughts. Nothing Bill did was illegal. Like me, Bill was a young developer making great money. The purpose of the site was to push a particular drug - that\u2019s why it was being built. He chalked it up to marketing. He never intended for this to happen. Maybe Bill got distracted too. As his conclusion, Bill writes: As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices. We\u2019re approaching a time where software will drive the vehicle that transports your family to soccer practice. There are already AI programs that help doctors diagnose disease. It\u2019s not hard to imagine them recommending prescription drugs soon, too. The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code. Since that day, I always try to think twice about the effects of my code before I write it. I hope that you will too.   Bill\u2019s story isn\u2019t that far off from mine, but there are still other examples. Earlier this year, a story came out that Uber had built into its ridesharing app code they call \u201cgreyball\u201d. It\u2019s a feature of their VTOS (or violation of terms of service) tool that can populate the screen with fake cars when the app is opened by users in violation of the terms of service. In a statement, Uber said, \u201cThis program denies ride requests to users who are violating our terms of service \u2014 whether that\u2019s people aiming to physically harm drivers, competitors looking to disrupt our operations, or opponents who collude with officials on secret \u2018stings\u2019 meant to entrap drivers.\u201d In practice, as (https://www.nytimes.com/2017/03/03/technology/uber-greyball-program-evade-authorities.html) (How Uber Deceives the Authorities Worldwide) The New York Times reports , it was used in Portland to avoid code enforcement officers working to build a case against Uber for operating without a license. When triggered by Uber\u2019s logic, it populates the app with cars that don\u2019t exist, with fake drivers who quickly cancel after accepting a ride. I am not a lawyer, but it seems like this is likely an obstruction of justice, itself a crime outside of Uber\u2019s unlawful operations in Portland. Greyball is used even today, though mostly outside the United States. I\u2019m a huge fan of ridesharing - though I use a competitor in Austin and Boston called Fasten1  rather than the much larger Uber or Lyft. But it\u2019s not uncommon to see in the news these days articles about heinous things these drivers are doing. Greyball may have enabled some of those. Again, it\u2019s an unintended consequence of a tool built. Maybe the greyball internal pitch was to \u201cgreyball\u201d users who were in violation of the terms of service. People who were under 18, or who didn\u2019t pay to clean up their late night explosive accidents one too many times for example. Rather than block them, probably causing them to create a new account, they could be put into an alternate dimension where for some reason they just couldn\u2019t ever get a ride. That\u2019s fine, right? If these developers had thought about the worst possible case for how this could be used, maybe obstruction of an investigation into Uber\u2019s shady dealings would have come up in that conversation and it could have been addressed early on. Maybe they were distracted by the face value of the request from looking deeper at the purpose and uses. There\u2019s all sorts of things as well that aren\u2019t as black and white (if you\u2019ll excuse the pun). (http://www.deidrariggs.com/2016/11/30/is-instagram-listening-in-on-you/) (Is Instagram Listening In On You?) Apps that always listen to the microphone to tailor ads to you based on what you say near your phone , (https://www.axios.com/sean-parker-unloads-on-facebook-2508036343.html) (Sean Parker Unloads on Facebook) websites designed to exploit psychology to take up as much of your time and attention as possible , and any number of apps that opt you into mailing lists when you sign up or purchase something. These aren\u2019t nearly as obviously bad, but at least in my opinion they\u2019re still kind of shady. This value system is different for others. We don\u2019t always agree as individuals what is right and wrong, or even with what should be legal or illegal. There are actually words for things that society decides are good or bad versus what you or I individually believe: ethics and morals. While modern philosophy more or less uses these terms interchangeably, a common understanding at least between us will be important later. Ethics are imposed by an outside group. A society, a profession, a community such as ours or even where you live. Religions provide ethical systems, as do groups of friends. Societies in whatever form define right and wrong, good and bad, and imposes those on its members. Ethics in societies such as local, state, and national groups are often, but not always, coded into laws. Morals are a more personal version of the same thing. Society as a whole imposes its mores on smaller communities, and all of that trickles down to the individual level. That\u2019s not to say that your morals can\u2019t conflict with the ethics of society. For example, you might think that freedom of speech is a basic human right, but live somewhere that defacing religious or political objects is considered wrong. Let\u2019s not get distracted by morals and ethics yet, though. We\u2019ll come back to them. The unifying factor in all of the stories I\u2019ve told is that a developer wrote the code that did these unethical or immoral things. As a profession, we have a superpower: we can make computers do things. We build tools, and ultimately some responsibility lies with us to think through how those tools will be used. Not just what their intention is, but also what misuses might come out of them. None of us wants to build things that will be used for evil. The Association for Computing Machinery is a society dedicated to advancing computing as a science & profession. ACM includes this in their (https://www.acm.org/about-acm/acm-code-of-ethics-and-professional-conduct#imp1.2) Code of Ethics and Professional Conduct : Well-intended actions, including those that accomplish assigned duties, may lead to harm unexpectedly. In such an event the responsible person or persons are obligated to undo or mitigate the negative consequences as much as possible. One way to avoid unintentional harm is to carefully consider potential impacts on all those affected by decisions made during design and implementation.   So how can we \u201ccarefully consider potential impacts\u201d? Honestly, I don\u2019t have any answers to this. I don\u2019t think that there really is a universal answer yet, because if we had it I have to believe we\u2019d not be building these dangerous pieces of software. I do have a couple of ideas though. One I got from my friend Schneems is to add to the planning process a step where we come up with the worst possible uses of our software. In opting in folks to an email list by default, the worst case might be that we send them a bunch of unwanted email and they unsubscribe. Maybe they even stop being a customer. As Schneems said: \u201cAm I willing to sell my hypothetical startup\u2019s soul for a bigger mailing list, when that might be all that keeps the company afloat? Yeah, no problem.\u201d That makes sense to me. I don\u2019t think it\u2019s the best practice, but in the end it\u2019s not physically hurting anyone. If I had sat down and thought about what the WiFi location app could be used for in the worst case, I would have come to a very different conclusion. Actually, thinking about the worst possible uses of code could probably be a fun exercise. You might come up with some pretty wacky examples like \u201cIf we send Batman an email and he happens to have notifications on his iPhone for new emails, he might be looking at the notification when the Riddler drives by in the Riddler Car and he might not catch him before he gets off his witty one liner at the crime scene. Riddle me this, riddle me that, who\u2019s afraid of the big, black bat?.\u201d This isn\u2019t so plausible, but it shows that these exercises can go down all sorts of different paths that aren\u2019t obvious at a glance. Another, the thing that I think I should have done, and that we can all do more of, is to simply not take requests at face value. The project owner at the Defense contractor I worked at didn\u2019t spell out what the reason for the code was. But at least in retrospect, it wasn\u2019t a big leap of logic. \u201cWe\u2019re going to build an app to find WiFi signals\u201d is all true, but it\u2019s not the whole truth. Asking them, or myself, \u201cwhy\u201d enough times probably would have led me to a much earlier understanding. Why? To find the sources. Why? To go to them. Why? Why? Why? Comedian Kumail Nanjiani, best known for the TV show Silicon Valley and his recent film The Big Sick, took to Twitter recently on this subject. I know there's a lot of scary stuff in the world right now, but this is something I've been thinking about that I can't get out of my head. As a cast member on a show about tech, our job entails visiting tech companies, conferences, etc. We meet people eager to show off new tech. Often we'll see tech that is scary. I don't mean weapons. I mean altering video, tech that violates privacy, stuff with obvious ethical issues. And we'll bring up our concerns to them. We are realizing that ZERO consideration seems to be given to the ethical implications of tech. They don't even have a pat rehearsed answer. They are shocked at being asked.  Which means nobody is asking those questions.  \"We're not making it for that reason but the way people choose to use it isn't our fault. Safeguards will develop.\" But tech is moving so fast. That there is no way humanity or laws can keep up. We don't even know how to deal with open death threats online. Only \"Can we do this?\" Never \"should we do this?\" We've seen that  same blas\u00e9 attitude in how Twitter or Facebook deal with abuse and fake news. Tech has the capacity to destroy us. We see the negative effect of  social media. No ethical considerations are going into dev of  tech. You can't put this stuff back in the box. Once it's out there, it's out there. And there are no guardians. It's terrifying. The end.  Kumail Nanjiani (https://twitter.com/i/moments/930118384225800192?ref_src=twsrc%5Etfw) November 1, 2017   It\u2019s a major problem when we\u2019re given so much power in tech, but we\u2019re not doing anything to ensure that we use it safely. Thinking about what we\u2019re doing and being careful not to build things that can be used maliciously is really important. Make your own decisions. Make your own choices. Make your own judgement. For engineers in particular, we develop systems. But the systems we develop can be used for different things. The software that I was using in Iraq is the same you\u2019d use in marketing. It\u2019s the same tools. It\u2019s the same analysis. I guess technologists should realize that we have an ethical obligation to make decisions that go beyond just meeting deadlines for creating a product. Let\u2019s actually take some chunks of time time and think \u2018what are the consequences of this system? How can this be used? How can it be misused?\u2019 Let\u2019s try to figure out how we can mitigate a software system from being misused, or decide whether or not you want to implement it at all. There are systems that if misused can be very dangerous.  Chelsea Manning in (https://www.wnyc.org/story/chelsea-manning-life-after-prison/) (Chelsea Manning on Life After Prison fron The New Yorker Radio Hour) The New Yorker Radio Hour  (31:55-33:40)    Don\u2019t get distracted by deadlines and feature requests. Think about the consequences of what you\u2019re building. Build in safeguards to prevent misuse, or don\u2019t build it at all because it\u2019s too dangerous. I\u2019m asking you to do something about this. Well, I guess I\u2019m asking you to not do something because of this. It\u2019s only fair that we talk a bit about how and when to take a stand. Let\u2019s say I had a time machine and could go back in time to 2011 and do it all over again. I already have the foreknowledge that this tool is unethical. I\u2019ve accepted this job. I\u2019ve moved across the country from Tempe, Arizona to Brookville, Maryland. I\u2019ve driven the two hour commute to Sterling, Virginia, home of (https://www.governmentcontractswon.com/department/defense/sterling_va_virginia.asp) 395 defense contractors awarded 16.8 trillion dollars in contracts over the past 16 years . It\u2019s my first job out of school, and it\u2019s my first day. I don\u2019t have my clearance so I\u2019m an intern. My new project owner introduces me to the team then pulls me into a side room to give me an overview of the project. What do I say? I think the first thing is to establish a mutual understanding of the task. It\u2019s entirely possible at this point that I don\u2019t understand what the actual thing is, and that I\u2019m overreacting. I ask \u201cWhy are we finding these signals\u201d and the project owner says \u201cWe want to find people\u2019s cell phones.\u201d \u201cWho\u2019s finding them, and why?\u201d I ask. \u201cI don\u2019t know, probably some soldiers in the Middle East.\u201d \u201cWhy?\u201d I repeat. \u201cI can\u2019t tell you that.\u201d \u201cI can\u2019t tell you that\u201d is something I got a lot from this project owner. It\u2019s code for \u201cI have clearance and I know things about this project. I know what you\u2019re asking and I know the answer but I am not allowed to tell you.\u201d At this point, I think we have a mutual understanding. The task is to help soldiers find people\u2019s phones, probably attached to those people. The reason is left unsaid but we both know. This organization is a defense contractor. They build things for the military. It is their core competency. They\u2019re not not going to do this\u2026. On the other hand, I care a lot about not killing people. The company\u2019s goal is to build things for the military. If my goal is not to let this happen, then there isn\u2019t a good fit for me at this company. This probably means that the worst case here is that I\u2019m going to leave today without a job. Either I\u2019ll say no and they\u2019ll fire me, or I\u2019ll say \u201cthat\u2019s not something I\u2019m comfortable with, best of luck\u201d and quit. These are the worst case scenarios, not necessarily what will happen. Before saying no then, I need to consider: Can I afford to leave here without a job financially? Am I likely to be able to rely on my network to get me another job? Have I built up a trust with my employer where I can go to them with this type of thing and feel confident that I\u2019ll be heard out? The answer to these questions was no for me in 2011. Sometimes, something is important enough that you should still do something, but there\u2019s a lot that goes into these decisions. I\u2019d like to think that I would still say no. Let\u2019s look at another situation, where someone did the ethical thing. A developer we\u2019ll call Alice received a strange request. We want to identify weak passwords in the system to notify users to change them. We\u2019d like you to run a password cracking program on the very, very, large password database. This was a long time ago, before aged passwords were common. Expiring old passwords wasn\u2019t a straightforward option. Alice thought this was a weird request, but said that if the appropriate paperwork was completed she would be willing. Alice received the completed paperwork and ran the password crack. The next request was \u201cWe\u2019d like the list of users along with their weak passwords\u201d. Alice knew that her coworkers had a valid desire to help customers improve their passwords. She also knew that users often re-used passwords. Combining the email and password into one report could allow someone to log into the customers\u2019 accounts on other websites. Alice pointed this out to her manager, and together they worked with the CSA team to design an email that didn\u2019t include the password. Customers received notifications about their weak passwords, and there was less risk of the report falling into malicious hands. No one was fired and Alice built up trust within her team. Different scenarios need different ways of analyzing what you should do. In some cases,  the right thing to do say nothing and build the product. It isn\u2019t a simple thing to make this decision. But don\u2019t get distracted by having to think through it. Sometimes your code can kill people. Further Reading (https://www.theatlantic.com/video/index/541797/anil-dash-tech-ethics) Does Technology Need to Be Ethical? Anil Dash briefly talks to The Atlantic about tech ethics. (http://www.bbc.com/news/technology-35639549) Is your smartphone listening to you? The BBC addresses whether tech companies use your phone to listen to what you\u2019re saying while not using their apps, and if they even can. (http://www.hcpro.com/HOM-236942-5728/know-your-ethical-obligations-regarding-coding-and-documentation) Know your ethical obligations regarding coding and documentation A blog post on how to define your ethical obligations as a programmer, some ways of dealing with them, and some real world examples (https://www.nytimes.com/2018/04/04/technology/google-letter-ceo-pentagon-project.html) \u2018The Business of War\u2019: Google Employees Protest Work for the Pentagon Google employees ask Google\u2019s CEO not to build software to help the military build warfare technology (https://www.theverge.com/2015/10/8/9481651/volkswagen-congressional-hearing-diesel-scandal-fault) Volkswagen America\u2019s CEO blames software engineers for emissions cheating scandal VW\u2019s CEO blames software engineers for changing how diesel emissions are reported during tests. Even if they were doing what they were told, someone up the chain can throw the blame back onto the programmers.  Glossary of Terms (https://en.wikipedia.org/wiki/Kernel_density_estimation#A_rule-of-thumb_bandwidth_estimator) Gaussian Estimation Used in the WiFi geolocation algorithm to estimate free space path loss using probability density estimation. It said \u201cit\u2019s less likely to be nearby if you\u2019re looking for it and more likely to be further out\u201d. (https://towardsdatascience.com/introduction-to-genetic-algorithms-including-example-code-e396e98d8bf3) Genetic Algorithm A type of machine learning or searching that is inspired by the theory of evolution. It uses randomization to create populations of individuals and tests their fitness to determine which ones will reproduce. It was used to increase accuracy in the geolocation algorithm. (https://heroku.com) Heroku A cloud platform as a service (PaaS) supporting several programming languages, that is used as a web application deployment model. It supports Java, Node.js, Scala, Clojure, Python, PHP, and Go. (https://schneems.com/2017/06/12/bayes-is-bae/) Kalman Filter A Kalman Filter can be used any time you have a model of motion and some noisy data that you want to produce a more accurate prediction. (https://stackoverflow.com/a/1988826/218211) Memoization Remembering the result of a calculation based on its arguments, and then using that result instead of re-calculating if the same method call is made with the same arguments. Caleb\u2019s team did this with a hash/dictionary/map (different names for the same thing) that contained the location pairs as keys and the distance between them as values. (https://en.wikipedia.org/wiki/Coefficient_of_determination) R2 Algorithm Used in the WiFi geolocation algorithm to measure the difference between expected and actual signal strength for each point in a search grid. The smallest difference is the most likely to be the correct distance from the source.  Fasten was a rideshare service that operated from 2015-2018 and emphasized that they collected only 99 cents of any fare, which was and is a much better deal for drivers than what Uber and Lyft take. Unfortunately they are no longer in business. \u21a9        (/tags/talk) Talk  (/tags/programming) Programming  (/tags/ethics) Ethics   \u00a9 2011\u20132025 Caleb Hearth .   (urn:issn:3068-8345) ISSN:\u00a03068\u200d-8345  Made with \u2665 in Denver, CO. Happy Tuesday!   (/assets/application-792166d82cf3505f57954f280bee808058ab0554ff57828744417a9464e129a1.js) (/assets/turbo.min-f309baafa3ae5ad6ccee3e7362118b87678d792db8e8ab466c4fa284dd3a4700.js)   "
                ],
                "output": "htmltotext.txt",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:01:23.944776+00:00",
                "status": "succeeded"
            }
        ],
        "media": [
            {
                "cmd": [
                    "/usr/local/bin/yt-dlp",
                    "--restrict-filenames",
                    "--trim-filenames",
                    "128",
                    "--write-description",
                    "--write-info-json",
                    "--write-annotations",
                    "--write-thumbnail",
                    "--no-call-home",
                    "--write-sub",
                    "--write-auto-subs",
                    "--convert-subs=srt",
                    "--yes-playlist",
                    "--continue",
                    "--no-abort-on-error",
                    "--ignore-errors",
                    "--geo-bypass",
                    "--add-metadata",
                    "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)",
                    "--skip-download",
                    "--cache-dir=/data/yt-dlp-cache/",
                    "--cookies=/data/yt-dlp-cache/cookies.txt",
                    "--proxy=socks5://tor-socks-proxy:9150",
                    "--no-playlist",
                    "https://calebhearth.com/dont-get-distracted"
                ],
                "cmd_version": "2024.10.7",
                "end_ts": "2026-02-10T06:01:30.766114+00:00",
                "index_texts": [],
                "output": "ArchiveError: Failed to save media",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:01:24.199536+00:00",
                "status": "failed"
            }
        ],
        "mercury": [
            {
                "cmd": [
                    "/home/archivebox/.npm/bin/postlight-parser",
                    "https://calebhearth.com/dont-get-distracted"
                ],
                "cmd_version": "2.2.3",
                "end_ts": "2026-02-10T06:01:23.915287+00:00",
                "index_texts": null,
                "output": "mercury/",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:01:19.989741+00:00",
                "status": "succeeded"
            }
        ],
        "pdf": [],
        "readability": [
            {
                "cmd": [
                    "/home/archivebox/.npm/bin/readability-extractor",
                    "/tmp/tmp0_v3odsi",
                    "https://calebhearth.com/dont-get-distracted"
                ],
                "cmd_version": "0.0.11",
                "end_ts": "2026-02-10T06:01:19.566397+00:00",
                "index_texts": [
                    "Be sure to check out these Sketchnotes from a 15 minute version of this talk from Codeland by Stephanie Nemeth\n\nI\u2019m going to tell you about how I took a job building software to kill people.\n\nBut don\u2019t get distracted by that; I didn\u2019t know at the time.\n\nEven before I\u2019d walked across the stage for graduation, I accepted an offer for an internship. It paid half again as much as the most I\u2019d ever gotten in the highest paying job up to that point. Not to mention that I\u2019d spent years in college with low paid student jobs or living only on student loans.\n\nI\u2019d be joining a contracting company for the Department of Defense. The Department of Defense, or DOD, is the part of the government made up by the military in the United States. The DOD outsources all sorts of things, from P-8A Multi-mission Maritime aircraft to blue, shade 451, Poly/wool cloth.\n\nAt the time, I thought nothing of the fact that I\u2019d be supporting the military. Besides, they\u2019re the good folks right? My dad was in the military. So was my grandfather. It was good money, a great opportunity, and a close friend of mine had gotten me the gig. Life was good.\n\nI showed up for my first day of work in North Virginia, or NoVA as the industry likes to call it. I met the team of other interns, then learned what the team would be building: a tool to use phones to find WiFi signals.\n\nIt seemed pretty cool compared to what I\u2019d built to up that point. The most complicated thing was an inventory management system. It didn\u2019t concern itself overmuch with persistence. Who needs to stop and restart a program anyhow? The data was right there in memory and if you forgot how many Aerosmith CDs you had, who cares? It got me an A on the assignment, and that was all that mattered.\n\nHonestly, the idea of finding WiFi routers based on the signal strength seemed pretty intimidating at the time. The idea impressed me.\n\nBut don\u2019t get distracted by all this; the software was intended to kill people.\n\nI joined the team after they\u2019d already gotten started on the project. The gist of the tool was that it would look at how WiFi signal strength changed as your phone moved around. If the signal strength got stronger, you were getting closer. If it got weaker, you were moving away. To find this information, we\u2019d collect two pieces of information for each WiFi access point in range. The phone\u2019s geolocation information and the WiFi signal strength.\n\nTo predict the actual location of the WiFi signal, we used a convolution of two algorithms. Both of them relied on the Free Space Path Loss equation. For our purposes, FSPL calculates how far away a phone is from a WiFi signal based on loss in signal strength. It assumes that there is only empty air, or \u201cfree space\u201d, between the access point and the phone.\n\nThe first algorithm was R^2. It measured the difference between the signal strength we\u2019d observed and the expected signal strength at each distance in a search grid based on Free Space Path Loss. Locations with the lowest R^2 error rate were the most likely location.\n\nWe\u2019d combine that calculation with a Gaussian estimate. Now I spent two or three days last week trying to understand Gaussian estimates for this talk and couldn\u2019t. The best documentation on them are still research papers. I do know that it creates a probability curve. The high points of the curve are distances where the access point is likely to be, and low points are unlikely. The curve started with a probability hole of low values. They represented low likelihood that the phone is standing right next to the signal. The curve then increased to high probabilities further out. It decreased to near zero even further. The algorithm adjusted the width and height of these two curves by consulting past measurements. It created a heat map of probabilities for the signal source.\n\nWe\u2019d normalize the probabilities for each location in the search grid. A combination of probabilities was more correct than either algorithm itself.\n\nWe stored this probability matrix for each location a phone collected from. Using these, if we collected readings while moving in a straight line, we could tell you how far away the WiFi was. If you turned a corner, we could also add direction, so you could find it in 2D space. If you climbed some stairs, we\u2019d show you altitude as well. The technology was the most interesting project I\u2019d ever worked on.\n\nBut don\u2019t let that distract you; it was designed to kill people.\n\nI mentioned that I had a software engineering degree at this point. My teammates were earlier in their education careers. Most of them were a year or two into their four year programs, also a mix of Computer Science and Math majors. My expertise was in the design and process of building software, while theirs was more in high level mathematics or the theory of computer use.\n\nI helped to translate the working algorithms they\u2019d designed in MatLab to the Java code we needed to run on the phones.\n\nAnd let\u2019s be honest, we spent plenty of time deciding whether we preferred Eclipse or NetBeans. Can I say how happy I am that as a Ruby developer, I\u2019ve not had to figure out where to put a .jar file in over half a decade?\n\nOne such example is calculating distance between two points. As these things go, it was in the deepest level of each loop. We were using great circle distance, which is the way you measure the shortest distance between two points on a sphere, such as Earth. Did we need to use this complicated measurement over the meager distances a WiFi network can operate over? Absolutely not. Did I mention this was over half a decade ago? We weren\u2019t always making the best choices. Anyhow, we needed to calculate these distances. The function doing it was being hit hundreds of thousands of time for each collection point, often with the same two locations. It was a very slow process.\n\nWe solved that by implementing a dictionary of latitude/longitude pairs to distances. This at least meant we didn\u2019t re-do those calculations. This and other optimizations we made sped up the performance from seven minutes to a few seconds.\n\nBut don\u2019t get distracted; that performance increase made it faster to kill people.\n\nThe accuracy of the locations wasn\u2019t fantastic. I don\u2019t remember exactly what it was before we focused on improving this, but an average error about 45 feet sticks in my head.\n\nThat\u2019s a little longer than a Tyrannosaurus Rex nose to tail, or more concretely the length of a shipping container.\n\nThat\u2019s significant when the WiFi range for 802.11n is only about 100 feet. That means we could be up to almost half the range of the router off from where it was.\n\nI talked about the Gaussian estimation, the two curves from the second algorithm. We hard-coded numbers that defined this curve. They were only starting points, but they were starting points every time we made the calculation.\n\nA Genetic Algorithm is a type of program that produces a set of values that optimize for a desired result. It\u2019s a perfect fit for tuning these hard coded values to get more accurate results.\n\nEach of the Gaussian estimation values will is a gene. The set of values is a genome in Genetic Algorithm parlance. The genes were our 3 constants.\n\nA fitness function is what Genetic Algorithms use to measure performance of a genome. For the dataset of readings I was using in the GA, I knew the actual location of the access points. That meant I could run the geolocation algorithm with each genome\u2019s values in place as the fitness function. The result would be the distance between the actual location and the one calculated by the GA-derived values.\n\nGenetic Algorithms take a set of genomes, called a generation, and keep a certain percentage of top performers.\n\nThese top performers \u201csurvive\u201d to the next generation as copies. Sometimes the algorithm mutates these copies by adding a Gaussian random value to each gene. This means that there was a chance that any of the copied genomes would have each gene changed slightly. That way they would have a chance of performing better or worse. New random genomes are created for the remaining spots in the new generation.\n\nWe saved the top performers across all populations. When the GA ended I could take a look at the values and select the best performer.\n\nI let this genetic algorithm run over the weekend. It was able to increase the accuracy from 40-odd feet to about 10.3 feet, 25% of the error from the original. That is less than the GPS accuracy on the smartphones collecting data (which is about 16 feet according to GPS.gov). This is too accurate, so it may have over-optimized against the test data and might not be as accurate against other data sets. This is called overfitting and the way around it is to have separate sets of training and test data. Did I mention this was five years ago? I didn\u2019t even know what overfitting was back then.\n\nI loved this. Genetic algorithms, R^2, and Gaussian estimation are the kind of thing that they tell you you\u2019ll never need to use again once you graduate. But we were using them for a real world project! It was great.\n\nBut don\u2019t let that distract you; this accuracy made it easier for the software to help kill people.\n\nThe tracking now worked accurately and quickly. The next feature was to add tracking a moving WiFi access point. I briefly wondered why an access point would be moving, but that question wasn\u2019t as interesting as figuring out how to track it.\n\nWe made use of Kalman Filters to observe state variables: the position, velocity, and acceleration of the WiFi signal. Given these and the time since the last measurement, a Kalman Filter is able to improve the current prediction with surprising accuracy, filtering out \u201cnoise\u201d data automatically.\n\nEach time we ran the real time algorithm, we\u2019d also feed this to the Kalman Filter.  With only that information, it was able to produce an estimate that is a weighted average of previous data. A new predicted location that was more accurate than the calculated value.\n\nAt the same time, we added the ability to track more than one WiFi signal. We\u2019d filter our collection of readings by the unique identifier of each access point. The filtered datasets each went through the full algorithm to produce predictions.\n\nWe used the APIs on the phone to read the signal strength of all WiFi access points in range. We were able to track multiple hotspots, basically whatever we could see in the WiFi network list. It was all very exciting. These seem like academic problems, but we were getting to use them in a real project! Being a programmer was going to be great.\n\nBut don\u2019t let that distract you; this meant we could kill multiple more accurately people.\n\nWe\u2019d been working with the project owner throughout this process.\n\nHe was laissez-faire about most things. He might check in once a day then going back to his main job in the area of the building dedicated to classified work.\n\nWhenever we hit one of these milestones, we\u2019d tell him. He\u2019d be happy about it, but a question always came up. He wanted it to sniff for the signals put out by phones in addition to WiFi hotspots. This is a much harder problem from a technical perspective. The functionality necessary to do this is \u201cpromiscuous mode\u201d, a setting on the wireless network controller. Neither iPhone nor Android supported that option. We\u2019d need to jailbreak or root the phone regardless of the platform. We looked for packages that we could use that would let us do this to \u201csniff\u201d the packets that devices sent back to routers. The closest we ever found was a SourceForge project that seemed promising. We didn\u2019t fully understand its use and it wasn\u2019t well documented.\n\nWe told the project owner that we\u2019d get to it later. None of us thought it was that important: we had the technology to find WiFi Access Points working. That was the goal right? Each time we\u2019d demonstrate the new exciting tech we\u2019d built though, the same question came up.\n\n\n  We got WiFi hotspots located! Great, does it find phones?\n  It\u2019s taking seconds instead of minutes! Great, does it find phones?\n  We looked into it finding phones, it seems unlikely but maybe! Ok, we\u2019ll come back to it.\n  We got moving targets working! Great, does it find phones?\n\n\nI had been distracted.\n\nAll of the cool problems we were solving: finding nodes, speeding things up, making more accurate predictions. It was all so cool, so much fun. I hadn\u2019t thought about why we were putting all this work into finding a better place to sit and get good WiFi. That doesn\u2019t even make sense if you look at it for more than a few seconds.\n\nDoes it find phones.\n\nThis was never about finding better WiFi. We were always finding phones. Phones carried by people. Remember I said I was working for a Department of Defense contractor? The DoD is the military. I was building a tool for the military to find people based on where their phones where, and shoot them.\n\nI tried to rationalize this then. The military is in place to protect Truth, Justice, and the American Way. But this was the same time that we found out the government had been spying on Americans in the US with drones. They\u2019d also lent out that technology to federal, state, and local law enforcement agencies nearly 700 times to run missions. The military and government do things that I know I don\u2019t agree with pretty often. I didn\u2019t want to be a part of building something used to kill people, especially since I knew I\u2019d never know who it was killing, let alone have a say.\n\nI rationalize it now too. We were interns, and we didn\u2019t even have clearance. The projects this company did for the government were classified Top Secret. I wasn\u2019t allowed to know what they were. My code probably got thrown away and forgotten. Probably.\n\nThis was an extreme example of code used in a way that the creator did not intend it. The project owner conveniently left out its purpose was when explaining the goals. I conveniently didn\u2019t focus too much on that part. It was great pay for me at the time. It was a great project. Maybe I just didn\u2019t want to know what it would be used for. I got distracted.\n\nThere are other examples of when code is used in ways it wasn\u2019t intended, and of code that does bad things.\n\nA year and a day ago, a developer named Bill Sourour wrote a blog post. It opened with the line: \u201cIf you write code for a living, there\u2019s a chance that at some point in your career, someone will ask you to code something a little deceitful \u2013 if not outright unethical.\u201d\n\nBill had been asked to create a quiz that would almost always give a result that benefitted his client. Bill worked in Canada, and in Canada there are laws in place that limit how pharmaceutical companies can advertise prescription drugs to customers. Anyone could learn about the general symptoms a given drug addressed, but only patients with prescriptions could get specific information about the drug.\n\nBecause of this law, the quiz was posing as a general information site and not an advertisement for a specific drug. If the user didn\u2019t answer that either they were allergic to the drug or already taking it, every quiz result suggested this specific drug. That\u2019s what the requirements said to do, and that\u2019s what Bill coded up.\n\nThe project manager did a quick test before submitting the website to the client. She told Bill that the quiz was broken: it always had the same answer. \u201cThose were the requirements,\u201d Bill responded. \u201cOh. Ok.\u201d\n\nA little while later, Bill got an email from a colleague that had a link to a news article. A young woman had taken the drug that Bill had built this quiz for. She had killed herself. It turns out that one of the main side effects of the drug were severe depression and suicidal thoughts.\n\nNothing Bill did was illegal. Like me, Bill was a young developer making great money. The purpose of the site was to push a particular drug - that\u2019s why it was being built. He chalked it up to marketing. He never intended for this to happen. Maybe Bill got distracted too.\n\nAs his conclusion, Bill writes:\n\n\n  \n  As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices.\n  We\u2019re approaching a time where software will drive the vehicle that transports your family to soccer practice. There are already AI programs that help doctors diagnose disease. It\u2019s not hard to imagine them recommending prescription drugs soon, too.\n  The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code.\n  Since that day, I always try to think twice about the effects of my code before I write it. I hope that you will too.\n  \n  \n\nBill\u2019s story isn\u2019t that far off from mine, but there are still other examples.\n\nEarlier this year, a story came out that Uber had built into its ridesharing app code they call \u201cgreyball\u201d. It\u2019s a feature of their VTOS (or violation of terms of service) tool that can populate the screen with fake cars when the app is opened by users in violation of the terms of service.\n\nIn a statement, Uber said, \u201cThis program denies ride requests to users who are violating our terms of service \u2014 whether that\u2019s people aiming to physically harm drivers, competitors looking to disrupt our operations, or opponents who collude with officials on secret \u2018stings\u2019 meant to entrap drivers.\u201d\n\nIn practice, as The New York Times reports, it was used in Portland to avoid code enforcement officers working to build a case against Uber for operating without a license. When triggered by Uber\u2019s logic, it populates the app with cars that don\u2019t exist, with fake drivers who quickly cancel after accepting a ride.\n\nI am not a lawyer, but it seems like this is likely an obstruction of justice, itself a crime outside of Uber\u2019s unlawful operations in Portland. Greyball is used even today, though mostly outside the United States. I\u2019m a huge fan of ridesharing - though I use a competitor in Austin and Boston called Fasten1 rather than the much larger Uber or Lyft. But it\u2019s not uncommon to see in the news these days articles about heinous things these drivers are doing. Greyball may have enabled some of those.\n\nAgain, it\u2019s an unintended consequence of a tool built. Maybe the greyball internal pitch was to \u201cgreyball\u201d users who were in violation of the terms of service. People who were under 18, or who didn\u2019t pay to clean up their late night explosive accidents one too many times for example. Rather than block them, probably causing them to create a new account, they could be put into an alternate dimension where for some reason they just couldn\u2019t ever get a ride. That\u2019s fine, right?\n\nIf these developers had thought about the worst possible case for how this could be used, maybe obstruction of an investigation into Uber\u2019s shady dealings would have come up in that conversation and it could have been addressed early on. Maybe they were distracted by the face value of the request from looking deeper at the purpose and uses.\n\nThere\u2019s all sorts of things as well that aren\u2019t as black and white (if you\u2019ll excuse the pun). Apps that always listen to the microphone to tailor ads to you based on what you say near your phone, websites designed to exploit psychology to take up as much of your time and attention as possible, and any number of apps that opt you into mailing lists when you sign up or purchase something. These aren\u2019t nearly as obviously bad, but at least in my opinion they\u2019re still kind of shady.\n\nThis value system is different for others. We don\u2019t always agree as individuals what is right and wrong, or even with what should be legal or illegal.\n\nThere are actually words for things that society decides are good or bad versus what you or I individually believe: ethics and morals. While modern philosophy more or less uses these terms interchangeably, a common understanding at least between us will be important later.\n\nEthics are imposed by an outside group. A society, a profession, a community such as ours or even where you live. Religions provide ethical systems, as do groups of friends. Societies in whatever form define right and wrong, good and bad, and imposes those on its members. Ethics in societies such as local, state, and national groups are often, but not always, coded into laws.\n\nMorals are a more personal version of the same thing. Society as a whole imposes its mores on smaller communities, and all of that trickles down to the individual level. That\u2019s not to say that your morals can\u2019t conflict with the ethics of society. For example, you might think that freedom of speech is a basic human right, but live somewhere that defacing religious or political objects is considered wrong.\n\nLet\u2019s not get distracted by morals and ethics yet, though. We\u2019ll come back to them.\n\nThe unifying factor in all of the stories I\u2019ve told is that a developer wrote the code that did these unethical or immoral things. As a profession, we have a superpower: we can make computers do things. We build tools, and ultimately some responsibility lies with us to think through how those tools will be used. Not just what their intention is, but also what misuses might come out of them. None of us wants to build things that will be used for evil.\n\nThe Association for Computing Machinery is a society dedicated to advancing computing as a science & profession. ACM includes this in their Code of Ethics and Professional Conduct:\n\n\n  \n  Well-intended actions, including those that accomplish assigned duties, may lead to harm unexpectedly. In such an event the responsible person or persons are obligated to undo or mitigate the negative consequences as much as possible. One way to avoid unintentional harm is to carefully consider potential impacts on all those affected by decisions made during design and implementation.\n\nSo how can we \u201ccarefully consider potential impacts\u201d? Honestly, I don\u2019t have any answers to this. I don\u2019t think that there really is a universal answer yet, because if we had it I have to believe we\u2019d not be building these dangerous pieces of software.\n\nI do have a couple of ideas though. One I got from my friend Schneems is to add to the planning process a step where we come up with the worst possible uses of our software. In opting in folks to an email list by default, the worst case might be that we send them a bunch of unwanted email and they unsubscribe. Maybe they even stop being a customer. As Schneems said: \u201cAm I willing to sell my hypothetical startup\u2019s soul for a bigger mailing list, when that might be all that keeps the company afloat? Yeah, no problem.\u201d That makes sense to me. I don\u2019t think it\u2019s the best practice, but in the end it\u2019s not physically hurting anyone. If I had sat down and thought about what the WiFi location app could be used for in the worst case, I would have come to a very different conclusion.\n\nActually, thinking about the worst possible uses of code could probably be a fun exercise. You might come up with some pretty wacky examples like \u201cIf we send Batman an email and he happens to have notifications on his iPhone for new emails, he might be looking at the notification when the Riddler drives by in the Riddler Car and he might not catch him before he gets off his witty one liner at the crime scene. Riddle me this, riddle me that, who\u2019s afraid of the big, black bat?.\u201d This isn\u2019t so plausible, but it shows that these exercises can go down all sorts of different paths that aren\u2019t obvious at a glance.\n\nAnother, the thing that I think I should have done, and that we can all do more of, is to simply not take requests at face value. The project owner at the Defense contractor I worked at didn\u2019t spell out what the reason for the code was. But at least in retrospect, it wasn\u2019t a big leap of logic. \u201cWe\u2019re going to build an app to find WiFi signals\u201d is all true, but it\u2019s not the whole truth. Asking them, or myself, \u201cwhy\u201d enough times probably would have led me to a much earlier understanding. Why? To find the sources. Why? To go to them. Why? Why? Why?\n\nComedian Kumail Nanjiani, best known for the TV show Silicon Valley and his recent film The Big Sick, took to Twitter recently on this subject.\n\n\n  \n  I know there's a lot of scary stuff in the world right now, but this is something I've been thinking about that I can't get out of my head.\n  As a cast member on a show about tech, our job entails visiting tech companies, conferences, etc. We meet people eager to show off new tech.\n  Often we'll see tech that is scary. I don't mean weapons. I mean altering video, tech that violates privacy, stuff with obvious ethical issues.\n  And we'll bring up our concerns to them. We are realizing that ZERO consideration seems to be given to the ethical implications of tech.\n  They don't even have a pat rehearsed answer. They are shocked at being asked. Which means nobody is asking those questions.\n  \"We're not making it for that reason but the way people choose to use it isn't our fault. Safeguards will develop.\" But tech is moving so fast.\n  That there is no way humanity or laws can keep up. We don't even know how to deal with open death threats online.\n  Only \"Can we do this?\" Never \"should we do this?\" We've seen that  same blas\u00e9 attitude in how Twitter or Facebook deal with abuse and fake news.\n\n  Tech has the capacity to destroy us. We see the negative effect of  social media. No ethical considerations are going into dev of  tech.\n\n  You can't put this stuff back in the box. Once it's out there, it's out there. And there are no guardians. It's terrifying. The end.\n  \n  \n  Kumail Nanjiani November 1, 2017\n  \n  \n\nIt\u2019s a major problem when we\u2019re given so much power in tech, but we\u2019re not doing anything to ensure that we use it safely. Thinking about what we\u2019re doing and being careful not to build things that can be used maliciously is really important.\n\nMake your own decisions. Make your own choices. Make your own judgement.\n\n\n  \n  For engineers in particular, we develop systems. But the systems we develop can be used for different things. The software that I was using in Iraq is the same you\u2019d use in marketing. It\u2019s the same tools. It\u2019s the same analysis.\n  I guess technologists should realize that we have an ethical obligation to make decisions that go beyond just meeting deadlines for creating a product. Let\u2019s actually take some chunks of time time and think \u2018what are the consequences of this system? How can this be used? How can it be misused?\u2019 Let\u2019s try to figure out how we can mitigate a software system from being misused, or decide whether or not you want to implement it at all. There are systems that if misused can be very dangerous.\n  \n  \n  Chelsea Manning in\n  \n  \n  The New Yorker Radio Hour\n (31:55-33:40)\n  \n  \n  \n\nDon\u2019t get distracted by deadlines and feature requests. Think about the consequences of what you\u2019re building. Build in safeguards to prevent misuse, or don\u2019t build it at all because it\u2019s too dangerous.\n\nI\u2019m asking you to do something about this. Well, I guess I\u2019m asking you to not do something because of this. It\u2019s only fair that we talk a bit about how and when to take a stand.\n\nLet\u2019s say I had a time machine and could go back in time to 2011 and do it all over again. I already have the foreknowledge that this tool is unethical. I\u2019ve accepted this job. I\u2019ve moved across the country from Tempe, Arizona to Brookville, Maryland. I\u2019ve driven the two hour commute to Sterling, Virginia, home of 395 defense contractors awarded 16.8 trillion dollars in contracts over the past 16 years. It\u2019s my first job out of school, and it\u2019s my first day. I don\u2019t have my clearance so I\u2019m an intern. My new project owner introduces me to the team then pulls me into a side room to give me an overview of the project. What do I say?\n\nI think the first thing is to establish a mutual understanding of the task. It\u2019s entirely possible at this point that I don\u2019t understand what the actual thing is, and that I\u2019m overreacting. I ask \u201cWhy are we finding these signals\u201d and the project owner says \u201cWe want to find people\u2019s cell phones.\u201d \u201cWho\u2019s finding them, and why?\u201d I ask. \u201cI don\u2019t know, probably some soldiers in the Middle East.\u201d \u201cWhy?\u201d I repeat. \u201cI can\u2019t tell you that.\u201d\n\n\u201cI can\u2019t tell you that\u201d is something I got a lot from this project owner. It\u2019s code for \u201cI have clearance and I know things about this project. I know what you\u2019re asking and I know the answer but I am not allowed to tell you.\u201d\n\nAt this point, I think we have a mutual understanding. The task is to help soldiers find people\u2019s phones, probably attached to those people. The reason is left unsaid but we both know.\n\nThis organization is a defense contractor. They build things for the military. It is their core competency. They\u2019re not not going to do this\u2026. On the other hand, I care a lot about not killing people. The company\u2019s goal is to build things for the military. If my goal is not to let this happen, then there isn\u2019t a good fit for me at this company. This probably means that the worst case here is that I\u2019m going to leave today without a job. Either I\u2019ll say no and they\u2019ll fire me, or I\u2019ll say \u201cthat\u2019s not something I\u2019m comfortable with, best of luck\u201d and quit. These are the worst case scenarios, not necessarily what will happen.\n\nBefore saying no then, I need to consider: Can I afford to leave here without a job financially? Am I likely to be able to rely on my network to get me another job? Have I built up a trust with my employer where I can go to them with this type of thing and feel confident that I\u2019ll be heard out? The answer to these questions was no for me in 2011. Sometimes, something is important enough that you should still do something, but there\u2019s a lot that goes into these decisions. I\u2019d like to think that I would still say no.\n\nLet\u2019s look at another situation, where someone did the ethical thing. A developer we\u2019ll call Alice received a strange request. We want to identify weak passwords in the system to notify users to change them. We\u2019d like you to run a password cracking program on the very, very, large password database.\n\nThis was a long time ago, before aged passwords were common. Expiring old passwords wasn\u2019t a straightforward option. Alice thought this was a weird request, but said that if the appropriate paperwork was completed she would be willing.\n\nAlice received the completed paperwork and ran the password crack. The next request was \u201cWe\u2019d like the list of users along with their weak passwords\u201d. Alice knew that her coworkers had a valid desire to help customers improve their passwords. She also knew that users often re-used passwords. Combining the email and password into one report could allow someone to log into the customers\u2019 accounts on other websites.\n\nAlice pointed this out to her manager, and together they worked with the CSA team to design an email that didn\u2019t include the password. Customers received notifications about their weak passwords, and there was less risk of the report falling into malicious hands. No one was fired and Alice built up trust within her team.\n\nDifferent scenarios need different ways of analyzing what you should do. In some cases,  the right thing to do say nothing and build the product. It isn\u2019t a simple thing to make this decision.\n\nBut don\u2019t get distracted by having to think through it. Sometimes your code can kill people.\n\nFurther Reading\n\n\n  Does Technology Need to Be Ethical?\nAnil Dash briefly talks to The Atlantic about tech ethics.\n  Is your smartphone listening to you?\nThe BBC addresses whether tech companies use your phone to listen to what you\u2019re saying while not using their apps, and if they even can.\n  Know your ethical obligations regarding coding and documentation\nA blog post on how to define your ethical obligations as a programmer, some ways of dealing with them, and some real world examples\n  \u2018The Business of War\u2019: Google Employees Protest Work for the Pentagon\nGoogle employees ask Google\u2019s CEO not to build software to help the military build warfare technology\n  Volkswagen America\u2019s CEO blames software engineers for emissions cheating scandal\nVW\u2019s CEO blames software engineers for changing how diesel emissions are reported during tests. Even if they were doing what they were told, someone up the chain can throw the blame back onto the programmers.\n\n\nGlossary of Terms\n\n\n  Gaussian Estimation\nUsed in the WiFi geolocation algorithm to estimate free space path loss using probability density estimation. It said \u201cit\u2019s less likely to be nearby if you\u2019re looking for it and more likely to be further out\u201d.\n  Genetic Algorithm\nA type of machine learning or searching that is inspired by the theory of evolution. It uses randomization to create populations of individuals and tests their fitness to determine which ones will reproduce. It was used to increase accuracy in the geolocation algorithm.\n  Heroku\nA cloud platform as a service (PaaS) supporting several programming languages, that is used as a web application deployment model. It supports Java, Node.js, Scala, Clojure, Python, PHP, and Go.\n  Kalman Filter\nA Kalman Filter can be used any time you have a model of motion and some noisy data that you want to produce a more accurate prediction.\n  Memoization\nRemembering the result of a calculation based on its arguments, and then using that result instead of re-calculating if the same method call is made with the same arguments. Caleb\u2019s team did this with a hash/dictionary/map (different names for the same thing) that contained the location pairs as keys and the distance between them as values.\n  R2 Algorithm\nUsed in the WiFi geolocation algorithm to measure the difference between expected and actual signal strength for each point in a search grid. The smallest difference is the most likely to be the correct distance from the source."
                ],
                "output": "readability/",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:01:16.366666+00:00",
                "status": "succeeded"
            }
        ],
        "screenshot": [],
        "singlefile": [],
        "title": [
            {
                "cmd": [
                    "/usr/bin/curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--proxy",
                    "socks5://tor-socks-proxy:9150",
                    "--max-time",
                    "60",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "https://calebhearth.com/dont-get-distracted"
                ],
                "cmd_version": "8.10.1",
                "end_ts": "2026-02-10T06:01:16.149129+00:00",
                "index_texts": null,
                "output": "Don't Get Distracted",
                "pwd": "/data/archive/1770703253.631358",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-10T06:01:16.049106+00:00",
                "status": "succeeded"
            }
        ],
        "wget": []
    },
    "icons": null,
    "is_archived": true,
    "is_static": false,
    "latest": {
        "archive_org": "TimeoutExpired: Command '['/usr/bin/curl', '--silent', '--location', '--compressed', '--proxy', 'socks5://tor-socks-proxy:9150', '--head', '--max-time', '60', '--user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)', 'https://web.archive.org/save/https://calebhearth.com/dont-get-distracted']' timed out after 60 seconds",
        "dom": "output.html",
        "favicon": "favicon.ico",
        "git": null,
        "media": "ArchiveError: Failed to save media",
        "pdf": null,
        "screenshot": null,
        "singlefile": null,
        "title": "Don't Get Distracted",
        "warc": null,
        "wget": null
    },
    "link_dir": "/data/archive/1770703253.631358",
    "newest_archive_date": "2026-02-10T06:01:30.819612+00:00",
    "num_failures": 2,
    "num_outputs": 7,
    "oldest_archive_date": "2026-02-10T06:00:58.992135+00:00",
    "path": "/dont-get-distracted",
    "schema": "Link",
    "scheme": "https",
    "snapshot_abid": "snp_01KH326W5BD17149F601VMKX1T",
    "snapshot_id": "65cc60ab-69bc-45df-b810-67a57749f43a",
    "sources": [
        "/data/sources/1770703252-import.txt"
    ],
    "tags": null,
    "tags_str": "",
    "timestamp": "1770703253.631358",
    "title": "Don't Get Distracted",
    "url": "https://calebhearth.com/dont-get-distracted"
}