Screenshots and faded memories

A couple of weeks ago, Chance Miller wrote about a new bit of security theater in the betas of macOS Sequoia: a permissions prompt that asks you to authorize an app to record your screen, e.g., if it takes screenshots. This doesn’t sound so bad until you learn that the permission you give isn’t permanent; you have to reauthorize the app every week. And since you probably have at least a few apps that need this authorization, it seemed likely that you’d be getting prompted to authorize one app or another almost every day.

In a more recent beta, the prompt frequency has changed from weekly to monthly, which is better (by a factor of about four), but still annoying, especially for those of us who have many apps that need to record the screen, whether as a video or a still image. This includes apps that you might not think of as recording your screen. For example, Default Folder X takes screenshots to prevent screen flicker when it puts up its Open and Save dialog enhancements.

Unsurprisingly, serious Mac users like Jason Snell and John Gruber are pissed about this. Apple seems to have forgotten that it made fun of this behavior on Windows in the I’m a Mac/I’m a PC commercials. More important, Apple seems to have forgotten that the user experience is what’s supposed to set Apple products apart.

The writing of the permissions prompt is as bad as its frequency:

App name is requesting to bypass the system private window picker and directly access your screen and audio.

This will allow App name to record your screen and system audio, including personal or sensitive information that may be visible or audible.

As Jason and Myke Hurley said on this week’s Upgrade, who knows what a “system private window picker” is, other than programmers?

I know it’s a dangerous world out there, but there must be a better way to protect us than this. And Apple used to spend a lot of effort figuring out that better way.

I had a vague memory of how the original Macintosh OS handled a similar situation. I mentioned it on Mastodon, and asked if anyone remembered it the way I did:

After reading stories about the weekly warning for apps that do screenshots in the macOS beta, I remembered that in the very early days (1985, say), certain apps would put up an alert when you were about to do something “dangerous.” If you repeatedly dismissed the alert by telling the Mac to go ahead and do the “dangerous” thing, it would, after a few such instances, stop showing the alert and just do what you wanted, albeit with a beep.

Do any of you remember this? Can you point to any documentation that talks about it? (I skimmed the old MacWrite manual but didn’t find anything.) Was there something similar that I’ve twisted? Or am I all wet?

A couple of days later, Russell Finn came to my rescue:

As I recall, you could specify a value n the ‘alrt’ resource such that the first 0-3 calls for that resource would simply beep instead of opening the alert window. So if the user tried an operation that wouldn’t work just then, it could just beep a couple times before opening an alert to explain why the action was invalid.

Is that what you’re remembering? I don’t have my Inside Macintosh handy at the moment but it ought to be documented in the Dialog Manager chapter.

My copy of Inside Macintosh (I had the hardcover with Volumes I–III bound together) was given away during a move back in the 90s, but it’s not hard to find PDFs online. I downloaded Volume I, which had the Dialog Manager chapter, and started reading.

In the original Macintosh OS, warnings were conveyed to the user through a specific type of dialog box called an alert. Here’s an excerpt from Inside Macintosh (p. 401) introducing alerts:

Alert description

The last paragraph of this excerpt spells out how alerts could change with each occurrence and gives an example of how Apple expected this mechanism to be used.

The alert mechanism also provides another type of signal: Sound from the Macintosh’s speaker. The application can base its response on the number of consecutive times an alert occurs; the first time, it might simply beep, and thereafter it may present an alert box. The sound isn’t limited to a single beep but may be any sequence of tones, and may occur either alone or along with an alert box. As an error is repeated, there can also be a change in which button is the default button (perhaps from OK to Cancel). You can specify different responses for up to four occurrences of the same alert.

So there was a way of changing warnings with each occurrence, but it was exactly the opposite of what I remembered. The idea was to give you a gentle warning the first time you screwed up, then more annoying warnings if you kept it up. Not at all what we’d want for a screenshot warning.

By the way, the example alert in the excerpt above is a Caution alert. Later in the chapter, Apple shows us all three standard alert icons—Stop, Note, and Caution—which brought back fond memories:

Standard Alert Icons

You may recall that Russell mentioned the ALRT resource. For those of you who are ResEdit fans, here’s the excerpt that covers the structure of that resource:

Alert Template

Here’s the text. The code is in Pascal, because that’s how routines and data structures in the Macintosh Toolbox were defined.

The data structure of an alert template is as follows:

TYPE AlertTemplate =
       RECORD
         boundsRect: Rect;  {becomes window's portRect}
         itemsID: INTEGER;  {resource ID of item list}
         stages: StageList  {alert stage information}
       END;

BoundsRect is the rectangle that becomes the portRect of the window’s grafPort. The itemsID field contains the resource ID of the item list for the alert.

The information in the stages field determines exactly what should happen at each stage of the alert. It’s packed into a word that has the following structure:

TYPE StageList =
       PACKED RECORD
         bolditm4: 0..1;     {default button item number minus 1)
         boxDrwn4: BOOLEAN;  {TRUE if alert box to be drawn}
         sound4: 0..3        {sound number}
         bolditm3: 0.. 1;
         boxDrwn3: BOOLEAN;
         sound3: 0..3
         bolditm2: 0..1;
         boxDrwn2: BOOLEAN;
         sound2: 0..3
         bolditm1: 0..1;
         boxDrwn1 : BOOLEAN;
         sound1: 0..3
       END;

Notice that the information is stored in reverse order—for the fourth stage first, and for the first stage last.

There’s nothing in the definition that says the alerts have to get more annoying with subsequent occurrences, but that was certainly the intention and, now that Russell reminded me of it, that is how apps like MacWrite used to work.

(By the way, it’s been ages since I programmed in Pascal, but I’m pretty sure there should be semicolons ending the lines that define sound4, sound3, and sound2. No semicolon on the line that defines sound1 because that’s the last one in its clause.)

So the upshot is that although the original Mac OS had a mechanism for changing alerts with each occurrence, it wouldn’t work for the screenshot warning that we’re seeing in the Sequoia betas. But it’s clear that the Mac software designers back in the 80s thought an awful lot about user interface. The four-part alert system was more complicated than absolutely necessary, but it made the Mac more comfortable to use. The current OS designers could learn something from Inside Macintosh.


Octagons and the silver ratio

For reasons I don’t recall, I was looking at this post recently and realized that I’d missed something. Let’s rectify that.

The post was about octagonal houses and how much more area they enclose than a square house for a given length of wall. The result was this ratio:

A octA sq=12cot22.5 ∘=12(1+2)

What I missed when writing the post was that the quantity in the parentheses is the silver ratio, δ S. The silver ratio is one of a number of “metallic” ratios, of which the golden ratio, ϕ, is the one you’re likely to know. While the golden ratio is the positive solution to the equation

1ϕ=ϕ1

the silver ratio is the positive solution to

1δ S=δ S2

(In the spirit of the just-closed Olympics, I’ll mention that the bronze ratio is, as you might expect, the positive solution to

1x=x3

As far as I know, the bronze ratio doesn’t have a commonly used symbol.)

You may recall that if you remove a square from a rectangle whose side lengths are in the golden ratio, the remaining rectangle is also golden.

Golden rectangle and removed square

Similarly, if you remove two squares from a silver rectangle, the remainder is also silver. The number of squares removed matches the constant terms in the equations above.

Silver rectangle and removed squares

The silver ratio is related to octagons in a more fundamental way than the area ratio mentioned at the top of the post. The “middle” rectangle in a regular octagon1 is silver.

Regular octagon and middle rectangle

This goes back to the silver ratio being the cotangent of a 22.5° angle.

There’s another interesting connection between the silver ratio and octagons. Just as the golden ratio is the limit of the ratio of consecutive Fibonacci numbers, F n,

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89,…

the silver ratio is the limit of the ratio of consecutive Pell numbers, P n,

0, 1, 2, 5, 12, 29, 70, 169, 408, 985,…

What does this have to do with octagons? You can make a pretty accurate drawing of a regular octagon using only integer coordinates if you use the Pell numbers to place the vertices. For example, if you draw an octagon with vertices at

(±P n,±P n+1)

and

(±P n+1,±P n)

you’ll get an octagon that’s not quite regular but is awfully close, at least if n is relatively large. Similarly, if you draw an octagon with vertices at

(±(P n+P n+1),0), (0,±(P n+P n+1))

and

(±P n+1,±P n+1)

you’ll get a “tilted” octagon (one that isn’t oriented like a stop sign) that’s also very close to regular.

Here are some nearly regular octagons drawn using those rules:

Nearly regular octagons drawn using Pell numbers

They look pretty regular, even though we haven’t gone very far along in the Pell numbers.

I’m not sure how valuable this construction method is, but it’s pretty cool. I learned it from the Wikipedia article on Pell numbers, which says you can find it in this 1994 paper by Donald Knuth. I’ve seen other discussions of this rational octagon approximation that reference the same paper, but I don’t see the connection. The paper is concerned with the paths you get by jumping around on a rectangular grid, and there’s a section where he considers Pell numbers, so the pieces are there; but I don’t see where the paper does what the articles that reference it say it does. If you see the connection, let me know.


  1. I’ve been talking about regular octagons all this time but have dropped the “regular” for brevity. I assume you’ve figured that out, but if not, now you know. 


Tot shopping redux

A couple of days after the post about my Tot shopping list was published, I got this request on Mastodon from roguewolf:

I wonder if it’s possible to create a shortcut to delete only the completed / checked off lines (haven’t checked yet, just thinking out loud)? If I don’t get everything on my list, it would be good to keep the unchecked lines.

Personally, I don’t want to reset my shopping list this way. When there are items left on my list that I didn’t buy, it’s generally because I looked them over and decided I didn’t want them. Items like that should be wiped out, which is why I wrote my original Shortcut the way I did.

But I can see how others would like to manage their lists like roguewolf. So I made another Shortcut, named Delete Purchases, that does just that. You can download it or build it yourself from these steps:

StepActionComment
1 Delete Purchases Step 01 Get the current text of Dot 1. Call it “Original list.”
2 Delete Purchases Step 02 Show the current text of Dot 1 in an alert that asks if the user wants to reset it. If the user taps the Cancel button, the Shortcut is aborted. This protects against accidentally resetting a list that’s partially written.
3 Delete Purchases Step 03 Delete all lines beginning with a filled box (■). Call the result “First pass.”
4 Delete Purchases Step 04 If a store name (which is bold) is followed by a blank line, insert an open box and a space (□ ) to initialize the list for that store. Call the result “Second pass.”
5 Delete Purchases Step 05 Replace the current contents of Dot 1 with “Second pass.”

Further explanation of Step 3: If you’re like me, you might be expecting to see the regular expression start with a caret (^) to indicate the beginning of a line. That’s how Unix tools like grep, sed, awk, and Perl work. But in Shortcuts, the caret represents the beginning of the entire input string, so I had to use linefeeds immediately followed by a filled box to indicate a checked-off item.

If you think this Shortcut fits your shopping habits better than the original, thank roguewolf.


Watermelons and soil

I meant to write this post a couple of weeks ago, right after Presh Talwalkar published this video:

It’s the only mathematical brain teaser I’ve run into for which being a civil engineer made the solution a snap. I solved it in my head almost immediately.

Normally, this is where I’d encourage you to watch the video, but 10+ minutes is too long for this puzzle. You don’t need to hear Talwalkar go through incorrect and inefficient solutions. Here’s the problem statement:

I carried 100 kg of watermelons in the summer by train. In the beginning, their water content was 99%. By the time I reached the destination, the water content had dropped to 98%. In the end, how much did the watermelons weigh?

The key to solving it is to focus not on the mass and percentage of water in the watermelons, but on the mass and percentage of solid material. Why? Because the mass of solid material doesn’t change during the drying process. Only water evaporates away.

So we start with 1 kg of solid material (1% of 100 kg). We also end with 1 kg of solid material, but now it’s 2% of the total mass. And 2% of what is 1 kg? 50 kg. Done.

What does this have to do with civil engineering? Most civil engineers have to take at least one soil mechanics course (I took two and there was also a lot of soil mechanics in a pavement design class), and one of the first things you learn in such a class is how to quickly and accurately do calculations regarding the relative amounts of air, water, and solid material in soil. You need this ability because certain aspects of soil behavior—things like drainage, consolidation, and bearing capacity—depend to a large extent on these quantities.

A common technique is to use what’s called a block diagram to visualize the amounts and assist in the calculations. Here’s a generic block diagram from the book used in my first soil mechanics class, Introductory Soil Mechanics and Foundations by George F. Sowers.

Soil block diagram from Sowers

(Note that this is Figure 1.1 in the book. I told you it was one of the first things you learn.)

Volume figures are kept on one side of the diagram and mass or weight figures are kept on the other. Certain quantities are always known:

Why would you put soil in an oven to dry it? To insure that when you then weigh the soil, all you’re weighing is the solid material—all of the water has been driven off. You then use this information along with the weight of the sample before it was dried to figure out how much water was in the soil originally. Do these sorts of calculations enough times and you won’t be fooled by a watermelon problem.

I did say, though, that I solved the watermelon problem almost immediately. The “almost” part also comes from my soil mechanics classes.

Look back at the problem statement and you’ll see that the 99% and 98% figures are called the water content of the watermelons. And we took the water content to be mass of the water divided by the total mass, which is a perfectly normal way to think of water content. But in soil mechanics, water content has a specific and different definition. It’s the mass of the water divided by the mass of the solids, not the total mass. My best understanding is that it’s done this way because there are advantages to keeping the denominator constant. While the amounts of air and water can change with the seasons and with loading, a given amount of soil will always have the same amount of solids.

So as I read the problem, I remembered the soil mechanics definition of water content, and it made me hesitate. Could they be using that definition? No, I decided, that would be silly, and I went on to solve the problem.

Suppose, though, that we were supposed to use the soil mechanics definition of water content. What would be the final weight in that case? I leave that as an exercise for the reader.