> We’re alerted hundreds of times per day. Some are useful and non-invasive, like an oven burner turning orange when it’s hot. Some are needed, like a critical security update, while others are just generally helpful, like a feature suggesting something new. But when they appear at inopportune moments, even the most useful notifications often have detrimental results like anxiety, frustration, and reduced productivity. While a pop-up might be nearly invisible to one person, to another it might stop a critical task completely for hours. We must examine when our communications are helpful vs. harmful.

source: E

> In a world of changing technology, there are few constants - but if there is one constant in security, it is the rhythmic flare-up of discussions about disclosure on the social-media-du-jour (mailing lists in the past, now mostly Twitter and Facebook).

> In this blog post, I would like to highlight a few aspects of the discussion that are important to me personally - aspects which influenced my thinking, and which are underappreciated in my view.

source: grugq

If you don’t have time for the challenges themselves, reading this review a few times until the lessons are internalized may be a good substitute.

> How practical these attacks were. A lot of stuff that I knew was weak in principle (like re-using a nonce or using a timestamp as a ‘random’ seed) turns out to be crackable within seconds by an art major writing crappy Python.

https://cryptopals.com/

source: grugq

> Why we left Medium, and how!

A bit more detail here than just, oh look, we moved.

Also, interesting that they managed to keep almost identical look and feel (for people who like the design of medium), but it loads super fast. Proves medium could be doing a lot better, if motivated.

> Compiling with the GCC sanitizers and then fuzzing the resulting binaries might find real bugs. But not all such bugs are security issues. When a CVE is filed there is some pressure to treat such an issue with urgency and push out a fix as soon as possible. But taking your time and making sure an issue can be replicated/exploited without the binary being instrumented by the sanitizer is often better.

I don’t think anything went wrong here, but some interesting details.

source: L

> Game of Trees (Got) is a version control system which prioritizes ease of use and simplicity over flexibility. Got is still under development; it is being developed exclusively on OpenBSD and its target audience are OpenBSD developers.

source: L

> 7 December 1972

An account of the first computer game tournament.

> The trend owes its health to an odd array of influences: The youthful fervor and firm dis-Establishmentarianism of the freaks who design computer science; an astonishingly enlightened research program from the very top of the Defense Department; an unexpected market-Banking movement by the manufacturers of small calculating machines, and an irrepressible midnight phenomenon known as Spacewar.

> Reliably, at any nighttime moment (i.e. non-business hours) in North America hundreds of computer technicians are effectively out of their bodies, locked in life-or-death space combat computer-projected onto cathode ray tube display screens, for hours at a time, ruining their eyes, numbing their fingers in frenzied mashing of control buttons, joyously slaying their friend and wasting their employers’ valuable computer time. Something basic is going on.

Plus the beginnings of Xerox PARC.

> “You get just a few more agates in that group and you’ll have all the marbles.”

> The chief marble collector is - well, well - Bob Taylor. When he left the newly restricted ARPA he spent a year at Utah decompressing from the Pentagon and then went to Xerox and there continued his practice of finding and rewarding good men for doing pretty much whatever they considered important work. Freedom to explore in the company of talent is an irresistible lure. In two years Xerox had twenty of the best men around working. Toward what? Well, whatever.

A followup from 2016: https://www.rollingstone.com/culture/culture-news/stewart-brand-recalls-first-spacewar-video-game-tournament-187669/

> Many ambulances now have electronic PCRs, which fix a lot of these problems. The report is automatically filed with the hospital. The software can enter timestamps and fill in necessary boilerplate. By spellchecking known medications it saves time at the hospital. Nobody has to guess whether you scrawled “100mg” or “160mg”.

> The ambulance I shadowed had an ePCR. Nobody used it. I talked to the EMTs about this, and they said nobody they knew used it either. Lack of training? «No, we all got trained.» Crippling bugs? No, it worked fine. Paper was good enough? No, the ePCR was much better than paper PCRs in almost every way. It just had one problem: it was too slow.

source: L

> Whether or not a player notices, appreciates, or is able to see these details, everything from a pen on a desk to a chair in a room has to be meticulously made, scrutinized, and tested. But at what cost? How does a developer decide how much time to allocate to set dressing a small room versus a game’s main character? How many polygons should an asset in the corner of a players eye get versus something directly in their face?

source: E

> The Churn is losing a day debugging because a transitive dependency changed a function signature. The Churn is spending a week just to get a project you wrote a year ago to even run. The Churn is rewriting your front-end because a shiny new thing came around.

> Many people are blind to The Churn. They waste days, weeks, months of their lives without blinking, or worse, they get a perverse sense of achievement because the thing which was working fine works again.

source: HN

> git-revise is a history editing tool designed for the patch-stack workflow. It’s fast, non-destructive, and aims to provide a familiar, powerful, and easy to use re-imagining of the patch stack workflow.

source: L

> As part of our continuous commitment to improve the security of the Android ecosystem, we are partnering with Arm to design the memory tagging extension (MTE). Memory safety bugs, common in C and C++, remain one of the largest vulnerabilities in the Android platform and although there have been previous hardening efforts, memory safety bugs comprised more than half of the high priority security bugs in Android 9.

> We believe that memory tagging will detect the most common classes of memory safety bugs in the wild, helping vendors identify and fix them, discouraging malicious actors from exploiting them. During the past year, our team has been working to ensure readiness of the Android platform and application software for MTE. We have deployed HWASAN, a software implementation of the memory tagging concept, to test our entire platform and a few select apps. This deployment has uncovered close to 100 memory safety bugs. The majority of these bugs were detected on HWASAN enabled phones in everyday use. MTE will greatly improve upon this in terms of overhead, ease of deployment, and scale. In parallel, we have been working on supporting MTE in the LLVM compiler toolchain and in the Linux kernel. The Android platform support for MTE will be complete by the time of silicon availability.

source: grugq

> The seccomp() mechanism is notoriously difficult to use. It also turns out to be easy to break unintentionally, as the development community discovered when a timekeeping change meant to address the year-2038 problem created a regression for seccomp() users in the 5.3 kernel. Work is underway to mitigate the problem for now, but seccomp() users on 32-bit systems are likely to have to change their configurations at some point.

The problems inherent in exposing very low level interfaces in one place (seccomp) and high level interfaces in another (libc).

source: HN

> Before proceeding, I want to stress that everything I refer to here relates to mistakes made when using (good) cryptographic libraries. The challenge of implementing the low-level cryptographic primitives themselves (like AES, RSA, ECC and so on) is a very different one, requiring high cryptographic engineering experience and knowledge. As such, this should be avoided whenever possible. In contrast, many software engineers need to just use cryptography in their work, and this cannot be avoided. Unfortunately, even this turns out to be far more problematic than expected.

This rings very true. The recommended solution, use a better library instead of lower level pieces, is also good, but should probably give some names. libsodium for example.

source: green

Time zones, leap seconds, oh my.

I like this much more than the typical falsehoods list because it actually explains the problem and gives a hint about the solution.

> Cisco has agreed to pay $8.6 million to settle a claim it sold video surveillance software it knew was vulnerable to hackers to hospitals, airports, schools, state governments and federal agencies. The tech giant continued to sell the software and didn’t fix the massive security weakness for about four years after a whistleblower first alerted the company about it in 2008, according to a settlement unsealed Wednesday with the Justice Department and 15 states as well as the District.

This is a new wrinkle in the disclosure debate. Refuse to patch, pay out later. But 10 years seems like a very long timeline.

source: white

> It is a regular occurrence to hear about open source developers selling their browser extensions, only for their users to be exploited later on by the new owners.

One of the reasons I’m wary of extensions. Least audited and least controlled code delivery mechanism for many systems.

source: L

> Advocates of any technique or technology can be a bit heavy-handed when it suits them if they’re not being careful–myself included. But I’m not sure if that’s the case here. When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.

> Poor performance can, and does, lead to exclusion. This point is extremely well documented by now, but warrants repeating. Sites that use an excess of resources, whether on the network or on the device, don’t just cause slow experiences, but can leave entire groups of people out.

source: HN

> I’ve noticed when I think about performance nowadays that I think in terms of two different aesthetics. One aesthetic, which I’ll call Never Miss a Frame, comes from the world of game development and is focused on writing code that has good worst case performance by making good use of the hardware. The other aesthetic, which I’ll call Do Almost Nothing comes from a more academic world and is focused on algorithmically minimizing the work that needs to be done to the extent that there’s barely any work left, paying attention to the performance at all scales. In this post I’ll describe the two aesthetics, look at some case studies of pairs of programs in different domains that follow different aesthetics, and talk about the trade-offs involved and how to choose which direction to lean for a project.

source: L

> One answer to what I want out of my window manager is ‘fvwm’. It’s my current window manager and I’m not likely to switch to anything else because I’m perfectly satisfied with it. But that’s not a good answer, because fvwm has a lot of features and I’m not using them all. As with everyone who uses a highly customizable thing, my important subset of fvwm is probably not quite the same as anyone else’s important subset of it.

The 80/20 rule rears its ugly head.