HN user

emarsden

106 karma

https://risk-engineering.org/

Posts1
Comments32
View on HN

They have an open issue concerning a SIGILL when loading the pgvector extension that hasn't been fixed or seen any activity in a month.

   https://github.com/pgEdge/pgedge-docker/issues/20

This is debatable. Perhaps the poor quality management issues and lack of rigour that have been seen in various Boeing production facilities are a case of normalization of deviance. However, the original problem with the 737 MAX was the top management decision not to invest in a new airframe design for cost/strategic reasons, to oblige designers to implement various unsafe workarounds to accommodate larger and more fuel-efficient engines that made the plane unstable, and to ruthlessly silence engineers who argued that this was unsafe. This problem was compounded by the FAA's move to increased delegation of safety oversight to designer-manufacturers, which left it with insufficient ability independently to assess the new design. These are both big, important decisions made by top leaders of the two organizations, rather than the slow progressive evolution driven by people's efforts to optimize their bit of the workplace which characterizes drift to danger.

"Being cheap" is a pressure from management to increase production in order to avoid economic failure. "Being lazy" is an effort from frontline workers to improve efficiency and avoid being swamped by production demand. One of the points of the diagram is that these partially cancel each other out, but the net effect of the addition of these two "vectors" is to push the system towards the failure boundary.

I have a smartphone app that scrapes replay TV listings for a few shows that I like to watch at the gym and allows me to download the low-quality media stream to the phone to view offline ad-free.

I released the Rust library that downloads and reassembles media segments from a DASH stream (https://github.com/emarsden/dash-mpd-rs). Won't release the web scraping bits because they are against website terms and conditions, and because annoying countermeasures will be implemented if too many people use them.

It seems that there is some missing tooling to make this convenient.

You can run a local bundle of HTML/JS/WASM in a web browser instance that you isolate (for example with firejail) to prevent network access. You distribute as a zip/tgz, but it's not obvious how to handle updates without a full redownload. Distributing with a full Electron-like interface is obviously overkill.

If you're running a web app that's hosted elsewhere (which will be much more convenient for most people), your web browser or the software isolation functionality (or firewall/proxy) needs to distinguish between the initial resource loads (approve) and later sneaky logging requests (ban).

There are Android applications such as TrackerControl that have related functionality (operates as a local VPN to filter all network requests and block tracking) but I don't know of convenient tools for the desktop (Linux, in particular).

Sure, but these types of applications are running in a web browser sandbox, which benefits from enormous engineering resources to protect the host computer from malicious actions by the remote code. I'm wondering whether this execution environment (augmented with some policy mechanism to allow apps to declare their URL access needs, a little like an AppArmor or network firewal policy) could also provide some guarantees concerning privacy or information security.

From the README: “Stirling PDF does not initiate any outbound calls for record-keeping or tracking purposes”. Beyond auditing the code, how could a potential user verify this claim in advance, and how can a web-based app help support such a claim (in particular when the app does need to make some web requests to operate, but only to a restricted list of URLs that might be listed in a manifest along the lines of a Content-Security-Policy for instance)?

This is a concrete problem when deploying apps that need the user to “upload” some sensitive content.

Historically, the fact that lives of the public are clearly on the line was part of the argument for allowing partial delegation of safety oversight. The idea has been that any engineer/manager making these decisions will be regularly flying themselves/loved ones, so is going to be suitably cautious. This differed from the situation in coal mines for example, where the miners exposed to the risk were socially/culturally disjoint from engineers/managers.

There are several good reasons for allowing it. One is that it's difficult for a public inspectorate/regulator to maintain the necessary levels of expertise to assess such complex systems (and increasingly so with technological progress). Furthermore, people working inside the industry have much better access to information about the risks than an outside inspector has.

A second reason is simply costs to the public. In 2019, the interim FAA director Dan Elwell testified to the US Senate after the 737 Max disasters that bringing all delegated oversight back into the FAA would require 10000 extra staff and USD 1.8B in costs. There are fairness/democratic arguments to having the costs borne by the industry (and thus indirectly by the privileged portion of the taxpayers who consume air traffic) rather than by all taxpayers.

There are indeed several other examples of this partial delegation of authority for decisions concerning safety, either to industry players or to third parties, though the FAA "ODA" mechanism is probably the most prominent. EASA's mechanism is similar in many respects, but more focused on properties of the oversight entity within the designer-manufacturer firms than on properties of the individuals doing the work. I wrote a discussion paper on precisely these issues a few weeks ago, which discusses some of the questions related to independence from commercial pressure, access to expertise, and so on:

https://onedrive.live.com/?authkey=%21ALZ0IuyZGHImolY&id=D37...

That's pretty much the objective of SICL, which is "intentionally divided into many implementation-independent modules that are written in a totally or near-totally portable way, so as to allow other implementations to incorporate these modules from SICL, rather than having to maintain their own, perhaps implementation-specific versions".

   https://github.com/robert-strandh/SICL

In the 1600s, educators in Nuremberg (Germany) were proud of a pedagogical technique that they had developed, called the "Nuremberg funnel" (https://en.wikipedia.org/wiki/Nuremberg_Funnel). In this "hydraulic" model of learning, they were proud to have developed an effective technique for "pouring" knowledge into the empty brains of students. Centuries of research have shown that this model is flawed in many ways (as many commenters here have pointed out): people never have an "empty" mind and learning involves effortful integration of new concepts with existing knowledge; for the most important types of learning it requires application, exercises and social interactions.

This author seems to believe in the Nuremberg funnel and the hydraulic model of learning, but simply with a limited "flow rate" for the brain. It's disappointing to see such as simple-minded idea, which has been so profoundly debunked by huge amounts of research, on the front page of HN.

A ”best effort” summary of this article: if thousands of people die in once place, it’s one of the great tragedies in American history. However if thousands of people die in thousands different places, it is ignored and considered a fact of life.

In economics, this is called catastrophe aversion: as a society, do we prefer accidental deaths to be "clumped together" or not (the total number of people killed being equal). Though the question is very important in regulating certain industries that can produce major accidents, we don't really know much about social preferences in this regard (the limited studies undertaken so far suggest that Americans and Europeans do not want regulators to adopt catastrophe-averse policies for safety risks). For an approachable introduction to this question, see [1].

[1] https://www.foncsi.org/en/publications/collections/industria...

If you're an "accidental American" (holding US citizenship due to having being born in the US, though never having resided there as an adult) in a French-speaking European country, you may be interested in the "accidental Americans" association

   https://www.americains-accidentels.fr/
They organize various legal challenges concerning the consequences of FATCA legislation for EU citizens (in particular, difficulties in having a bank account) and the principle of extra-territorial taxation, as well as challenging the difficulty and unreasonable cost of renouncing US citizenship.

It's this sort of regulatory boom and bust that makes me feel humans shouldn't be allowed to do anything that's dangerous on a really large scale (such as nuclear power).

For more thinking along these lines, see the book “Normal Accidents: Living with High-Risk Technologies” (1984) by sociologist Charles Perrow (concerning nuclear power), the book “The Limits of Safety — Organizations, Accidents and Nuclear Weapons” (1993) by Scott Sagan concerning nuclear weapons, and the work of philosopher Hans Jonas on the “imperative of responsibility” (1980s).

The Value of Life 6 years ago

However, models of "value of life vs. other-thing" are almost always useless. Why? Because you don't care about that question. You care about other questions.

The “value of a statistical life” (or to use a better term, “value of a prevented fatality”), is weighed against other things in a large number of public policy choices. For example: environmental pollution, biodiversity, quality of landscapes, noise pollution, economic activity. It’s also important to aim for reasonable levels of prevention of different risk categories: food safety, road safety, air transport safety, medical safety in hospitals, industrial safety, etc. If public policy (via regulatory obligations for instance) uses very different implicit values for a prevented fatality, it means that more statistical lives could have been saved by allocating prevention effort in a different way.

The notion that "the more minor things happen, the greater the probability of a major incident", a common interpretation of the Heinrich-Bird pyramid, is often criticized nowadays concerning complex high-hazard systems (as in fact argued in the risk-engineering.org page that you linked to -- I know this because I wrote it).

I'm not familiar with Tesla assembly lines, but my understanding is that they are highly automated with complex robotics. This would be a typical example of a system where many safety risks are systemic and more strongly dependent on design errors than on worker safety behaviours, which is exactly the type of system in which the structuralist interpretation of the Heinrich-Bird pyramid ("reduce the small stuff at the base of the pyramid and the stuff up the top will drop down and disappear") is really inappropriate, as it can reduce attention paid to safety at a system design level.

My work concerns safety in high-hazard industries, where lessons learned analysis (also called operational experience feedback) is a very important organizational process. It's also well-known to be difficult, not so much related to the technical tools used for recording/sharing incidents and lessons, but mainly in terms of organizational culture (learning, blame, psychological safety and speaking up). Some references from this area:

https://risk-engineering.org/learning-incidents-accidents/

https://risk-engineering.org/barriers-learning-experience/

https://risk-engineering.org/concept/psychological-safety

There are three answers to this:

- Do you really want to be using important models in such an error-prone and difficult to test environment as Excel? There's a whole Spreadsheet Risks Interest Group (http://www.eusprig.org/horror-stories.htm) that collects tales of billion-dollar errors that are attributable to (poor use of) Excel.

- A simple sensitivity analysis such as a tornado plot (while clearly much better than the common practice of reporting nothing on sensitivity of uncertain model inputs) is a local approach: it's telling you which variables are important around one specific point in the input space (generally the median for each input). A global sensitivity analysis method such as implemented here gives you information on the entire input space (which can be quite different if your input model has non-linear features).

- A tornado plot corresponds to a "one-at-a-time" sensitivity analysis (modifying each input variable individually), whereas a global method varies all inputs simultaneously and can reveal potential interactions between inputs, potentially very important if your model is non-linear.

Some background material on these points from a course that I run: https://risk-engineering.org/sensitivity-analysis/

Nice demo! It's perhaps a little confusing if you're using uniform probability distributions for the sensitivity analysis inputs, but normal distributions for the uncertainty analysis (shown at https://causal.app/buy-to-rent).

A previous comment mentions you are using SALib in Python, which can (even if it's not documented) use normal probability distributions for the inputs: here's a notebook with an example: https://risk-engineering.org/notebook/sensitivity-analysis.h...