Enabling Multiple Minor Modes

Timo Geusch has a nice quickie post on setting multiple minor modes for a buffer. Often it’s convenient to have several minor modes associated with a buffer. For example, when I’m writing blog or prose text I like to have

  1. visual-line-mode
  2. wc-mode
  3. flyspell-mode

turned on and auto-fill-mode turned of. That’s enough modes that it’s inconvenient to set them by hand. The normal solution is to turn them on in the local variables list at the top or bottom of the file.

# -*- eval: (visual-line-mode 1); eval: (auto-fill-mode -1); eval: (wc-mode 1); eval: (flyspell-mode 1;) -*-

That works well and is what I do for non-blog writing but you have to take some sort of action to get it into each buffer such as including it or copying it by hand.

Geusch has another solution. He wrote a simple function to turn on the minor modes he needs and then runs that function in a hook for the type of buffer he’s interested in. That’s really easy if you use the use-package macro to configure your packages because you can use its :hook keyword to cause the function to be called. See Geusch’s post for the details and sample code.

It’s a simple idea and easy to implement but it can make your workflow a bit easier. Definitely worth taking a look at.

Posted in General | Tagged | Leave a comment

Embedding Images in Text Files

Yuan Fu likes to take notes in which he can embed images. You can do that with Org, of course, but Fu doesn’t like that Org’s solution boils down to a link to a file. That means you have to keep the file paths in sync. He wanted a solution that embedded the image in the file and made it easy to resize the image on the fly.

To a first approximation, his solution is simple: Embed the image as a Base64 string at the bottom of the buffer and put an internal link to it at the point to where it is to appear. Of course, there are complications. First, there’s handling the resizing. That’s not too hard but there are also display issues such as having reasonable scrolling. Fu has some animated screenshots that show this in action. It appears to work well.

The code does not appear to be in Melpa and Fu doesn’t say whether he plans to submit it but it’s a single file and should be easy to load and try out. If you have a need to permanently embed images in a file and don’t want to have to worry about keeping file paths in sync, this is a good solution.

Posted in General | Tagged | Leave a comment

The Technical Problems with Apple’s CSAM Scanning

I’ve written several posts (1, 2, 3, 4, 5, 6, 7) about Apple’s planned CSAM scanning project but those posts have always focused on how Apple was betraying their long held promise to protect our privacy and not allow random snooping through our iPhones. To me, that’s the most important aspect of the controversy: it’s really important—at least to me—to feel secure that your smartphone is not collecting information about you and reporting it to the government or anyone else.

This post is a quick look at the other reasons to be against Apple’s plan. I’ve collected them under the rubric of “Technical problems” but, strictly speaking, they aren’t all “technical.”

The first issue is that the matching is based on hashing CSAM images and comparing the hash against images on the phone. The problem is collisions. Hashing is a way of reducing any sequence of bits, say \(n\) long, to a sequence of \(m ≪ n\) bits. That necessarily means that more than one sequence of bits will reduce to the same \(m\) bit value. In terms of Apple’s system, that means that more than 1 image will have the same hash value.

Hashing algorithms generally deal with these collisions by comparing the two values that were hashed to make sure they’re a match but that’s not possible here because it’s illegal a have a copy of the actual CSAM image, let alone to download it to billions of iPhones. To a first order of approximation, Apple treats identical hash values as a match. It protects against ambiguity by two means:

  1. The number of matches have to exceed a threshold (\(≈30\)) before Apple even looks at the results.
  2. Even when the threshold is exceeded a human being looks at the potentially matching images to make sure they really are child porn.

Apple’s protocol is more robust than I’ve recounted here (see this technical summary and this paper detailing the theoretical details). Among other things it’s resistant against hackers generating false matches or pedophiles discovering offending hashes so they can bypass them. In addition, Apple is prevented by technical means from seeing any of the potential matches until the threshold is exceeded. Despite some folks generating images that hash to the same value (1, 2), Apple’s protocol seems to me to be pretty robust against such attacks.

That’s bad news for Apple’s hope of refining and reintroducing their plan. It’s hard to see how anything like the current plan could be more secure so any changes are likely to be eyewash.

But the real danger with Apple’s plan is something out of their control: that the machinery for CSAM scanning will be repurposed for other, less savory purposes. Apple. of course, says that they will refuse to let it happen but that claim is empty. When presented with a court order or law demanding that they scan for, say, terrorist images or content, they will have no choice but to comply. And that doesn’t begin to address what they will do when China and others bring economic pressure to bear. Apples CSAM scanning machinery is easy to adapt for other types of content monitoring. It’s really not something you want on your phone.

This isn’t just paranoid ravings. The developers of the algorithm that Apple uses have written a WAPO op-ed in which they say that they concluded the algorithm was too dangerous to be used precisely because of its potential for abuse. If you read none of the other links from this post, you should read that one.

The takeaway from all this is that Apple should, once and for all, abandon this project. The dangers are manifest and the benefits few. Those dealing with CSAM images can easily work around Apple’s scanning and the rest of us will be paying with our privacy for nothing. Part of problem is that Apple’s protocol is clever and a nice piece of engineering. Those involved with its development are doubtless in love with the result and will hate to throw it away but that’s the right thing to do.

Posted in General | Tagged , , | Leave a comment

Apropos Library

Recently a post by jao, who’s written a whole bunch of excellent software, popped up in my feed inbox. It’s just a very short (15 words) mention of apropos-library, a function that lists all the variables and functions in a library. It can also be configured to show the keybindings for the functions.

Apparently it’s been around since Emacs 23 but neither jao nor I were aware of it. It seems like a useful facility. Even though you won’t need it often, it’s easy to see how it could be really useful in certain circumstances. It’s already installed so give it a try to see how it works.

Posted in General | Tagged | Leave a comment

Covid Warnings

Another datum for those of you following the origins of COVID-19 debate. Josh Rogin, writing over at Politco notes that US diplomats were warning about problems in the Wuhan labs as early as 2017, a good two years before the first cases of COVID-19 appeared. The diplomats were concerned that, according to its own accounting, the Wuhan labs lacked enough trained staff to operate the BSL-4 laboratory safely. They sent cables to the state department warning of their concerns about another possible SARS outbreak.

Of course the chuckleheads in the State Department ignored the warning—probably for geopolitical reasons—and there was an outbreak much, much worse than the previous SARS episode. In the US, the question took on a political flavor when Trump suggested the virus may have been manmade causing his political opponents to feel duty bound to deny the possibility. As a result, a year went by with partisans furiously denying the “conspiracy theory” of a lab leak and no investigation into the wisdom of gain-of-function research being done.

As a final, sad note, Rogin writes that

just months into the pandemic, a large swath of the government already believed the virus had escaped from the WIV lab, rather than having leaped from an animal to a human at the Wuhan seafood market or some other random natural setting, as the Chinese government had claimed.

It’s telling that we still can get them to admit this.

Posted in General | Tagged | Leave a comment

Some Prerequisite Reading

As I said in my last post, I’m planning to write a bit about some of the technical aspects of Apple’s CSAM scanning project. Happily, Apple listened to the avalanche of criticism and put their plans on hold. I hope this hiatus will be permanent but it probably won’t be. Irreal will never accept any surveillance system that runs on individual phones. Apple can, of course, do what they like on their own servers but they better stay out of my phone because it’s, you know, mine not theirs.

After their initial announcement and the furious reaction it provoked, Apple got busy assuring everyone that their system was perfectly safe and respected privacy. The second assertion is, of course, false on its face but the first is almost certainly false too. My upcoming post will address some of the reasons why the system isn’t as secure as apple claims but if you’re completely unfamiliar with how the system is supposed to operate, Josip Rezić has a useful post that gives an overview of Apple’s system. The best resource is, of course, Apple’s own technical summary, which is longer and has more technical details. It’s definitely accessible so is also worth reading for an understanding of how the proposed system would operate.

If you own an iPhone or are just concerned with Corporate/Government surveillance, you have a stake in this controversy and should familiarize yourself with what’s going on. Every single proposal like this needs to be resisted and beaten back.

Posted in General | Tagged , | Leave a comment

Apple and Backdoors

In the ongoing Apple CSAM saga, Irreal has mostly been concerned with Apple’s betrayal of their promise to protect their users’ privacy but there’s also the issue the long term security consequences of Apple’s decision. We’ll take a look at the security of Apple’s plan in a later post. This is a sort of meta-post on the dangers of introducing backdoors.

Before we begin, it’s worth noting that Apple has delayed the rollout of their clientside CSAM scanning. The optimistic reading of their words is that, “Yes we know we screwed up and this is our way of abandoning the program without admitting we were wrong.” If they’re still not convinced, here are some reasons why it’s a really bad idea.

In the early 2000’s, the NSA had a clever plan. They devised a random number generator (DUAL_EC) that would allow them access to encrypted messages and pressured industry to adopt it. Almost immediately, security researchers pointed out the RNG had serious vulnerabilities but the NSA and its apologists pressed on. They claimed that even if that was true, only the NSA had the key to exploit the vulnerability so all was well. Unfortunately, the NSA had been too clever by half because hackers—unidentified to this day—managed to rekey Juniper Networks implementation and gained access to sensitive government communications for three years. Irreal has written about DUAL_EC before [1, 2]. Matt Green has an excellent Twitter thread (unrolled here) that recounts a brief history of the disaster.

This is the NSA, whose raison d’être is devising secure communication protocols, trying to introduce a secure backdoor and failing. What reason is there to believe that Apple would do any better? Indeed, security researchers have already pointed out problems. Apple insists that there’s no backdoor and, trust us, everything is under control. If Apple persists, they and the rest of us will find out just how naive that view is.

Posted in General | Tagged , | Leave a comment

Yet Another Win For Open Access

For those of you, like me, interested in open access, there’s more good news. There’s good evidence that the scales are finally tipping to the side of open access. If things continue, we could soon see open access considered the default choice and paywalls considered an anachronism.

The proximate event is the decision by the American Astronomical Society to open source all of its journals. One could argue, of course, that it’s easier for a professional society such as AAS to open source its journals than it is for commercial publishers such as Elsevier to do so because their business models depend on people paying to read the material they publish.

Still, professional societies tend to publish some of the most prestigious journals in their respective fields so if most of the societies adopt open access, researchers will still be able to find top notch open access homes for their papers. Once a majority of researchers stop publishing in the commercial journals with paywalls, those publishers will have to fall in line and offer the same type of deal that AAS is.

That deal boils down granting unlimited access to the papers in exchange for the researchers—or really their institutions—paying a publishing charge. That’s what’s known as a page charge in today’s system. It turns out that publishing a commercial journal can be outrageously profitable—Elsevier, alone, makes billions every year—so in a sense the party will be over for them but there’s no reason they can’t make a reasonable profit while still doing the right thing.

Whether it’s government and the funding agencies insisting on open access or competition from the already free journals, it seems like the days of the academic paywall are coming to an end.

Posted in General | Tagged | Leave a comment

Melpa Reaches a Milestone

As regular readers know, I’m a big fan of Melpa and its proprietor Steve Purcell. It’s an extraordinary resource run strictly as a public service. The site is not monetized and yet Purcell devotes huge amounts of time to running it. Melpa is an unofficial repository so some GNU purists may spurn it but as a practical matter it’s the most important and useful repository and it’s hard to imagine configuring Emacs without it.

Recently, Melpa passed 5,000 packages, everyone of which is curated and kept up to date. It’s a pretty significant achievement so I say again: if we can coax Purcell out of New Zealand and you’re lucky enough to meet him, be sure to buy him a beer. Until then, I can only say, Thanks and well done.

Posted in General | Tagged | Leave a comment

Go

A funny thing about human beings is that once they’re out of their young adult years they tend to like things the way they’ve always been. In the tech world, that often takes the form of preferring the text editor and languages you’ve always used. Even those of us who take the plunge and, say, switch between Vim, Emacs, or VS Code don’t want to give up our programming languages.

I’ve been a C user for most of my career and although these new-fangled languages, like Rust or Julia, are intellectually interesting, most of us have no urge to change. The languages that do have a chance of seducing us away from our go-to languages are those that represent a limited extension to the one we’re attached to. For C, until recently, that would have been C++ but many C programmers found C++ too baroque and full of bad ideas to be a real successor to the crown.

Fredrik Holmqvist has a different candidate for the successor to C: Go. C++ grew out of Bell Labs so it seems a natural choice but as I said, many of us don’t like the language. As I’ve written before, C++ does away what’s good about C and introduces things that are demonstrably worse. Go, on the other hand, comes out of Google so its provenance is already suspect. The thing is, though, it was designed by folks with the same sensibilities and taste that gave us C. Dennis Ritchie is no longer with us but Ken Thompson and Rob Pike, who were early C users, influenced its development, and shared those sensibilities, are and, more to the point, are principal developers of Go.

Holmqvist makes a strong case for giving Go a chance. If you’re a programmer who grew up with C, you might want to give it a try.

Posted in General | Tagged | Leave a comment