We all know that Apple has nice built-in password management in
macOS and iOS. But very, very few people know that Apple’s
passwords can also:
Autofill any 2FA verification codes, which you easily can add by
scanning QR codes!
Keep a “Notes” field where you can add extra data, like 2FA
backup codes, for each password!
Import passwords exported from another app, like 1Password!
(And it all syncs across your devices, for free?!)
Very few people know these things because Apple tucks all of
their important password features away in weird little Settings
panels, instead of in a Proper Real App. I think this is a
mistake.
Passwords are productivity, not preferences.
I understand the tension within Apple on this front. iOS already has so many apps that many people complain about how many apps are in the system, so Apple is very conservative about adding new apps. But password management is really important, and Apple’s password/security team has done an outstanding job over the years building a reliable trustworthy system. Effectively, there already is an Apple Passwords “app”, but it’s buried inside Settings. There are a lot of nerds who don’t even know that Apple’s built-in password manager can handle 2FA verification codes, because people have a totally reasonable assumption that Settings, as sprawling as it is, only contains ... settings. Not features.
So count me in with Sasser: Apple should break these features out into a discrete Passwords app, and they should launch a marketing campaign to raise awareness of it. I’ve been using the built-in password management in iOS and MacOS (and iCloud for syncing) for years, and last summer I switched all of my 2FA verification codes to it too. It’s a great system, especially if you use Safari as your web browser. But the biggest reason it isn’t used more is that zillions of people don’t even know it’s there.
If Tips is worth a standalone app, surely Passwords is too.
(As a postscript, it’s also possible that you know this feature exists within Settings, but don’t know that it offers full import and export options, because those commands are tucked away in a “···” menu. You can import from, say, 1Password, and export everything back to 1Password.)
People experience a variety of problems with USB-C. I’ve asked people online about their negative experiences with USB-C, and got a wide variety of responses, both on Twitter and on Mastodon. In addition to that, communities like r/UsbCHardware keep a lore of things that make some people’s experience with USB-C subpar.
In engineering and hacking, there’s unspoken things we used to quietly consider as unviable. Having bidirectional power and high-speed data on a single port with thousands of peripherals, using nothing but a single data pin – if you’ve ever looked at a schematic for a proprietary docking connector attempting such a feat, you know that you’d find horrors beyond comprehension. For instance, MicroUSB’s ID pin quickly grew into a trove of incompatible resistor values for anything beyond “power or be powered”. Laptop makers had to routinely resort to resistor and one-wire schemes to make sure their chargers aren’t overloaded by a laptop assuming more juice than the charger can give, which introduced a ton of failure modes on its own.
When USB-C was being designed, the group looked through chargers, OTG adapters, display outputs, docking stations, docking stations with charging functions, and display outputs, and united them into a specification that can account for basically everything – over a single cable. What could go wrong?
Of course, device manufacturers found a number of ways to take everything that USB-C provides, and wipe the floor with it. Some of the USB-C sins are noticeable trends. Most of them, I’ve found, are manufacturers’ faults, whether by inattention or by malice; things like cable labelling are squarely in the USB-C standard domain, and there’s plenty of random wear and tear failures.
I don’t know if the USB-C standard could’ve been simpler. I can tell for sure that plenty of mistakes are due to device and cable manufacturers not paying attention. Let’s go through the notorious sins of USB-C, and see what we can learn.
Omitting The Resistors, One Cent At A Time
No USB-C resistors in sight, and the pins aren’t even soldered
Yep, you got it. The first, honorary entry is omitting 5.1 kΩ pulldowns on a USB-C port intended for charging your device. “Why does my device charge with a USB-A to USB-C cable, but doesn’t charge with a USB-C to USB-C cable”, asks the user? The answer is simple – because your device’s designer decided to save one cent while building your device, and didn’t care about testing the device before selling it to you. In other words, your device is supposed to have two resistors connected to the USB-C plug, yet it does not, and USB-C power supplies are unable to detect that they ought to provide power. Remember, the resistor detection is fundamentally a safety mechanism, and by now, information about this problem is omnipresent.
Omitting these resistors is one of the most infuriating Type-C mistakes for users, and often results in people debugging the problem for hours on end. Here’s just an example of a developer who was working with a WCH RISC-V board using a USB-C connector for power, and spent a good few hours due to WCH not bothering to add these resistors. If you buy an USB-C-equipped Arduino Pro Micro or TP4056 board on Aliexpress, it is likely to be resistor-less. Everywhere you look, you’ll find a resistor-less device or two. The sheer volume of this problem is, honestly, ridiculous.
Murderous “USB-C” PSUs At Your Local Lidl
Remember the power article, specifically, how you get to higher voltages? Let’s recap: you get 5 V first, and then only after resistor detection. Higher voltages require negotiations over a digital protocol. This is a safety rule – it’s how you can use the same USB-C charger for your laptop, your phone, your wireless headphones, your devboards and whatever else.
Now, what happens when someone builds a power supply with a fixed higher-than-5 V output, say, 12 V, and puts a USB-C plug on it? The answer is – seriously bad things happen. Such a power supply isn’t safe to be used on actual USB-C devices – it’s likely to destroy your phone or laptop, and it’s at a glance indistinguishable from an adapter that follows the USB-C rules laid out for everyone else. If you must use such an adapter for something every now and then, you ought to mark its cable with red tape in a way that covers the connector plug, so that you (or your loved one) don’t grab it to charge something else. Seriously, it’s easy to make a mistake, and the more you get comfortable with USB-C, the more likely you are to make it.
Who does this? Well, many no-name manufacturers do, but also Lidl Parkside tools, for one. CrowPi does this too, in their recently released CrowPi L laptop. Both of these come with dumb “USB-C” 12 V power supplies, and neither of them should be sold to consumers, especially given that the CrowPi laptop is designed for kids and educational purposes, and Parkside tools are designed for non-tech-savvy people. When your kid burns a $500 smartphone or your granddad burns his laptop due to a $2 power supply, that’s when the gravity of this standard violation really sets in.
Blaming Companies? It’s Not That Simple
The resistor omission is by now a thorn in consumers’ sides, and the murderous PSU designs are unforgivable. Designers should not do these things. There is, however, an area where I can forgive mistakes happening, and that’s the USB-PD protocol – specifically, the compatibility mistakes, especially in early USB-C tech.
The PD specification is 800 pages – this is, no doubt, intimidating. If you’re getting paid to implement USB-C, however, it’s your job to be familiar with it. On the other hand, when you’re an early adopter implementing a complex specification, it’s quite likely you’re going to screw it up through no fault of your own. You don’t have as many implementations to work with, you’re going to work with (and around) similarly early adopter low-level hardware like ICs, and other devices around you are going to be similarly crooked in subtle ways. The gist is – early adoption of is more of a tricky engineering problem than we might recognize.
In addition to that, there’s two early adopter routes for a wide-reaching interfacing technology like this. One route is – you build a device that is engineered to be specifically compatible with the pricey peripherals that you manufacture, despite being based an open standard being aimed at intercompatibility, and don’t really test the device with other things. I call this the Nintendo Switch route, for no particular reason.
The other early adopter route is – you design a device, then test it with other devices. It’s the early adoption stage, so other devices are often similarly broken, and you end up adding a slew of workarounds and bugfixes piled up on top of each other. New devices keep getting released, and for a while each of them brings a slightly more broken implementation. At best, you spend plenty of time testing when hardly anyone else around does, ensuring tip-top compatibility – provided you can throw developers at the problem. At worst, your fixes create a whole new kind of buggy device.
With this “blaming companies” disclaimer in mind, let’s move to the next point, where I will spend time blaming companies.
Not Testing PD Implementations Enough
Nowadays, there’s no excuse to release a poorly tested USB-C product. If an open-source project can have an array of power supplies to test a USB-C PSU with, large companies have no excuse. If you bought a hefty powerbank that doesn’t put enough effort into figuring out power roles and ends up getting charged from the laptop when you need the opposite, that means it’s not been tested on laptops like yours, and chances are, yours isn’t special. Let’s face it – a company developing powerbanks can afford to buy a few laptops with different OSes and test the behaviour until it works well.
The PD compatibility problems are out there, and you might stumble upon them eventually, especially when it comes to charging. There’s laptops that don’t work with specific chargers, for instance – my Framework laptop doesn’t work with a Xiaomi laptop 65 W charger, in a way where the battery keeps cycling from 10% to 30%, and the charger keeps doing connect/disconnect cycles. I also have a dock where charger passthrough works only for half of laptops. Of course, there’s ways to mis-manage specifications, but let’s face it – there’s gotta be a more fundamental cause for this.
Part of the problem is lack of information sharing. When a large open-source project solves a tricky compatibility problem and adds a workaround, it goes onto GitHub for everyone to see and make use of, with a searchable description of the problem in the commit message.
When a commercial entity fixes the same bug, it is thrown into /dev/null for all other informational intents and purposes, except for the binary blob they push as a firmware update – if even. In this case, each company implementing PD-talking stuff, has their own database of PD quirks, working around peculiarities of devices they tested with. Those PD quirks ought to be openly available information, but they’re not.
Proprietary solution developers aren’t paid to share things, whereas in open-source project, the sharing happens naturally, through no extra effort, once again exposing the fundamental inferiority of proprietary processes. Large part of the reason you have buggy USB-C devices, is that companies would rather make you overpay and suffer incompatibilities, than put effort into sharing information between themselves. Whether it’s security vulnerability information or designing standards together, large corporations are slowly learning to do things the right way, domain by domain, but the general concept never really seems to stick – the fundamental blinders of profit motives and greed are just that strong.
Microcontrollers with PD peripherals are often tough to work with, too. Again, this is a lack of effort put into making those peripherals friendly for developers, whether through better design or better documentation – often, more open code, as you might be able to guess, sadly. This factor alone makes it more likely that the end-user will encounter mistakes, purely because a peripheral that is harder to work with will be harder to write reasonable code for.
Don’t Add, Don’t Tell
You can buy a $1000 laptop, and find out that its USB-C port only does USB3 – no charging or DisplayPort. Or, you can buy a mid-tier $500 smartphone, and find out that it can’t charge and do OTG at the same time, despite USB-C making it so that devices can easily do precisely that in a standardized manner, killing off all those MicroUSB splitter adapters with weird resistors on the ID pin.
In laptop space, Asus is one of the worst offenders, having had a long streak of devices with only USB3 output on USB-C – no DisplayPort, no charging, not to even mention Thunderbolt. What’s worse – when looking at documentation, you might not find any mention of what the USB-C port is capable of, no matter if it’s capable of something or not. And of course, lack of clear labeling of ports makes it worse.
The cherry on top is a single USB-C port on a laptop – and nothing else — you might have seen Macbooks like this. You’re basically required to carry a dongle with PD passthrough around, there’s nowhere to plug your wireless mouse receiver in, and the USB-C port becomes the living definition of the word “bottleneck”. When it comes to right to repair, having a single USB-C port for absolutely everything means adding a giant failure point that will leave you laptop-less if you accidentally use too cheap of a charger and end up melting the only port’s plastic. If it’s not a Macbook, good luck finding a replacement port; custom-made small-batch USB-C ports can be quite literally impossible to find for a hobbyist.
Still, Workarounds Exist
Remember: if your USB-C cable is broken or wonky, you should stop using it and buy a replacement. Mark devices that misbehave, and talk online about them; name and shame liberally. Read online reviews if compatibility is what you worry about, scroll down on Aliexpress, or search the product name to see if the device you’re buying has the resistors it needs. When buying a USB-C power supply or an expensiveish dock, it can be good to test it with your device and make sure you can return it or exchange it for a different one. With time, the sharp edges will smooth out, and whenever it is that USB-D visits our households, you will find a lot of people feeling nostalgic about just how simple USB-C was.
Ice and water might not seem very exciting to most of us, but they’re actually super strange from a scientific standpoint. Researchers have now discovered a brand new type of ice that’s described as being a true “snapshot” of water, and may be found on alien worlds.
By activating the "walk" light for pedestrians a few seconds before the traffic light turns green reduces the likelihood of pedestrian collisions by 15%. The main reason: it's easier for drivers to see walkers in the middle of an intersection than walkers stepping into the street from the curb. — Read the rest
Log in
Part of the problem is lack of information sharing. When a large open-source project solves a tricky compatibility problem and adds a workaround, it goes onto GitHub for everyone to see and make use of, with a searchable description of the problem in the commit message.
