Linked List: October 17, 2024

Thursday, 17 October 2024

The European Union’s Interinstitutional Style Guide on Boldfacing for ‘Emphasis’ 

Here’s an interesting bit of follow-up. Last month, when linking to the European Commission’s announcement of “two specification proceedings to assist Apple in complying with its interoperability obligations under the Digital Markets Act”, I wrote a sidenote on the EC’s seemingly willy-nilly use of boldface text:

Honest question: Can someone explain to me the Commission’s use of boldfacing? In the first 265 words of the press release, 66 of them are bold, across 13 different spans. They seemingly use boldfacing the way Trump capitalizes words in his tweets: indiscriminately. I find it highly distracting, like trying to read a ransom letter. It’s not just this press release, they do it all the time.

It turns out, the EU publishes an Interinstitutional Style Guide, and it has an entire entry on emphasis:

Bold type is often used in titles and headings. It can also be used in running text to show changes of subject, to highlight keywords or for emphasis in the same way that some other languages use italics. However, it should be used sparingly.

If the text is already in bold roman, words to be emphasised should be in light roman characters.

Do not overuse typographical variations for emphasis. It can have a detrimental effect on getting the message across quickly and clearly, as shown in the following examples.

Their examples, showing how overuse of boldfacing makes text harder to read, look exactly like the announcement that prompted my sidenote. Whoever writes these announcements from the Commission should read the EU’s own style guide and follow its advice.

See Also: The EU style guide’s entry on italics, which they reserve for purposes other than emphasis.

FIDO Alliance Is Working on Making Passkeys Portable Across Platforms 

Tim Hardwick, reporting for MacRumors:

The FIDO Alliance is developing new specifications to enable secure transfer of passkeys between different password managers and platforms. Announced on Monday, the initiative is the result of collaboration among members of the FIDO Alliance’s Credential Provider Special Interest Group, including Apple, Google, Microsoft, 1Password, Bitwarden, Dashlane, and others.

Passkeys are an industry standard developed by the FIDO Alliance and the World Wide Web Consortium, and were integrated into Apple’s ecosystem with iOS 16, iPadOS 16.1, and macOS Ventura. They offer a more secure and convenient alternative to traditional passwords, allowing users to sign in to apps and websites in the same way they unlock their devices: With a fingerprint, a face scan, or a passcode. Passkeys are also resistant to online attacks like phishing, making them more secure than things like SMS one-time codes.

The draft specifications, called Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF), will standardize the secure transfer of credentials across different providers. This addresses a current limitation where passkeys are often tied to specific ecosystems or password managers.

This initiative would address one of David Heinemeier Hansson’s primary complaints about passkeys, in a post I linked to earlier today.

Hardwick mentions un-phishability as an advantage of passkeys, and that’s very true. In fact, I think that was one of the primary selling points Apple emphasized when they introduced passkey support at WWDC two years ago. A scammer who gets a victim on the phone can’t trick them into revealing a passkey like they can with passwords or one-time numeric codes. But that use case is optimized for non-technical users.

A friend texted me with another argument for passkeys: it’s somewhat common for websites to break password autofill. Maybe it’s deliberate, in the name of fighting bots? But whether deliberate or not, with passkeys, they have to work with your browser’s connected password manager. So maybe passkeys are a net win for convenience, even for technically-knowledgeable users who are unlikely to fall for phishing scams.

Apple Passwords’ Generated Strong Password Format 

Speaking of passwords, Ricky Mondello — who has long been a leading member of Apple’s “Authentication Experience” team — has an interesting blog post describing the algorithm Apple uses when it suggests new strong passwords:

To make these passwords easier to type on suboptimal keyboard layouts like my colleague’s game controller, where the mode switching might be difficult, these new passwords are actually dominated by lowercase characters. And to make it easier to short-term have in your head little chunks of it to bring over to the other device, the passwords are based on syllables. That’s consonant, vowel, consonant patterns. With these considerations put together, in our experience, these passwords are actually a lot easier to type on a foreign, weird keyboard, in the rare instances where that might be needed for some of our users.

And we weren’t going to make any changes to our password format unless we can guarantee that it was as strong or stronger than our old format. So if you want to talk in terms of Shannon entropy once again, these new passwords have 71 bits of entropy, up from the 69 from the previous format. And a little tidbit for folks who are trying to match our math — [note that] we actually have a dictionary of offensive terms on device that we filter these generated passwords against and we’ll skip over passwords that we generate that contain those offensive substrings.

I’ve noticed some of these details, like that the passwords are comprised of little “fake words” and are dominated by lowercase letters, but I hadn’t noticed all of them. It’s a bunch of clever little touches, all in the aim of making strong passwords that are convenient in odd situations (like typing them with a game controller).

DHH Argues Against Passkeys 

David Heinemeier Hansson:

Yes, passwords have problems. If you’re using them without a password manager, you’re likely to reuse them across multiple services, and if you do, all it takes is one service with awful password practices (like storing them in plain text rather than hashing them with something like bcrypt), and a breach will mean hackers might get access to all your other services.

But just because we have a real problem doesn’t mean that all proposed solutions are actually going to be better. And at the moment, I don’t see how passkeys are actually better, and, worse still, can become better. Unless you accept the idea that all your passwords should be tied to one computing ecosystem, and thus make it hard to use alternative computers. [...]

Bottom line, I’m disappointed to report that passkeys don’t appear worth the complexity of implementation (which is substantial!) nor the complexity and gotchas of the user experience. So we’re sticking to passwords and emails. Encouraging opt-in 2FA and password managers, but not requiring them.

Passkeys seemed promising, but not all good intentions result in good solutions.

I don’t have strong feelings about passkeys, but I am vaguely unsettled by them. There’s no way to use passkeys without using a proper password manager, like Apple Passwords with iCloud Keychain, or 1Password. But if you’re using a proper password manager, your passwords should all be unique and random, and you should have convenient access to 2FA codes. So what’s the point of passkeys if they can only be used by people who are already using a good password manager? Perhaps the thinking is that too many users just can’t be budged from the risky habit of using passwords they have memorized, and passkeys are a way to break that habit because they can’t be memorized.

Also, I really dislike the practice of replacing passwords with email “magic links”. Autofilling a password from my keychain happens instantly; getting a magic link from email can take minutes sometimes, and even in the fastest case, it’s nowhere near instantaneous. Replacing something very fast — password autofill — with something slower is just a terrible idea. For people who actually prefer email magic links, it’s fine as an option, but it shouldn’t be the default, and it certainly shouldn’t be the only way to sign into an account.

Things Are Not Going Well at Automattic 

Samantha Cole, reporting for 404 Media:

In July, before the latest WP Engine blowup, an Automattic employee wrote in Slack that they received a direct message from Mullenweg sending them an identification code for Blind, an anonymous workplace discussion platform, which was required to complete registration on the site. Blind requires employees to use their official workplace emails to sign up, as a way to authenticate that users actually work for the companies they are discussing. Mullenweg said on Slack that emails sent from Blind’s platform to employees’ email addresses were being forwarded to him. If employees wanted to log in or sign up for Blind, they’d need to ask Mullenweg for the two-factor identification code. The implication was that Automattic — and Mullenweg — could see who was trying to sign up for Blind, which is often a place where people anonymously vent or share criticism about their workplace.

“We were unaware that Matt redirected sign-up emails until current Automattic employees contacted our support team,” a spokesperson for Blind told me, adding that they’d “never seen a CEO or executive try to limit their employees from signing up for Blind by redirecting emails.”

That does not seem compatible with a culture of trust within a company. Cole also reports that Mullenweg has made another buyout offer this week, and is threatening employees who leak to the press. This very report from 404 Media, under the headline “Employees Describe an Environment of Paranoia and Fear Inside Automattic Over WordPress Chaos”, is not going to help. The whole situation is just very depressing.