I still use my MacBook Air M1 and given my current workloads (a bit of web development, general home office use and occasional video editing and encoding) I doubt I’ll need to replace it in the coming 5 years. That’ll be an almost 10 year lifespan.
At the very least Apple are better than Microsoft, Windows and the vendors that sell Windows laptops when it comes to respecting user experience and privacy.
I switched to iPhone after they added the tracker blocking to the OS.
Everything is a tradeoff.
I’d love to live in the F droid alt tech land, but everything really comes down to utility. Messaging my friends is more important than using the right IM protocol.
Much as I wish I could convince everyone I know and have yet to meet to message me on Signal or whatever, that simply isn’t possible. Try explaining that I am not on Whatsapp or insta to a girl I’ve just met…
Also it is nice to spend basically no time maintaining the device, and have everything work together coherently. Time is ever more valuable past a certain point.
But why do we have to choose between convenient and open? Why are these companies allowed to continue having these protected "gardens"? I don't believe a free and truly open ecosystem for mobile devices would actually be less convenient than iOS or Android. If anything it would be vastly better.
Has it occurred to you that the stronger control of the ecosystem is a feature that supports the convenience and integration that's possible?
This is just the "Why not Linux desktop" argument from the past two decades. Sure, in theory it can be configured to do a lot of different things. But you're probably gonna have to work out the details yourself because the downside of theoretically supporting everything is that it's impossible to just have it work out of the box with every single scenario.
They have big numbers. Big numbers tell that 95% of people would need to be in closed protected gardens rather than getting slaughtered by open source wolves.
It’ll depend per person, but I subscribe to around 30 podcasts. For some podcasts (like The NY Times Daily) I’ll skip 29 out of 30 episodes. For a select few I’ll listen to 9 out of 10. For the others, something in between.
Apple Podcasts is the absolute worst for this use case. Even if I listen to all released episodes, I’m still lost to where my unplayed episodes are and what my listening queue looks like. Let alone if I want to exclude episodes from said queue.
I’m so happy Castro has new owners. For me it has the best interaction model of all podcast apps (inbox + queue), it had a beautiful design and now it’s also getting the backend + tech debt love it requires.
Me too. I switched to Overcast when Castro had its huge hiccups, but followed the new owners and the updates with great interest. The forward momentum seems great. I can see myself switching back home, when my new iPhone arrives.
My ideal podcast client would be something like Castro with additional playlist queues. I never could build a good triage model in Overcast. But sometimes you'll want some organization. (And a real Mac app)
I wonder if Marco Arment will ever reconsider designing the Overcast app himself. He seems to be the only who is convinced that he doesn't need one. As a fellow indie I get wanting to do everything yourself, but as a Apple fan I feel he should value design way more than he does now. The Castro app is so much better, it's like comparing iOS to Windows Mobile.
Do you mean create a team behind the app? What element of design do you mean? There are things with the Overcast design that I like and dislike, but they fall into multiple categories.
Marco seems like a very independent individual who wants to minimize dependencies on other people. He has mentioned in the past that he does get outside help on things, but this doesn't extend to other people taking ownership. At that point, he is managing people which doesn't seem something he wants to do.
Similarly, I switched away from Castro when it was melting down, and I tried out PocketCasts and Overcast.
PocketCasts is pretty great, but has one crucial flaw that makes it unbearable to me: at the time I was using it it was fairly slow to update feeds automatically, and you can't force an update of a specific feed. This got really annoying with subscriber-only feeds, because I'd know an episode had been released and had to wait a few hours for them to decide to actually let me see it.
Overcast is good at what it does (the audio boost features are the best of any client I've tried), but it's opinionated about a certain workflow in ways that don't play incredibly well with people who want to subscribe to a lot of podcasts and only listen to occasional episodes that catch their eye. Previous statements by Marco suggest that he likes Overcast's workflow and doesn't really want to adjust it to support inbox/queue users. In some ways the recent rewrite helped (the UI no longer locks up regularly when you have a lot of subscriptions), but in other ways it hurts (there's no way to give it a global episode-limit setting, and the default limit now actively wrecks playlists).
I'm inclined to say that if Overcast's workflow fits you, it's probably the best client to use. But if it doesn't, you have to make some choices...
For people with large numbers of podcasts as well as many paid subscriptions there is a lot that can be done to better manage the situation, including deduplication. This falls into the power user bucket so it's less valuable to these apps than the basic and mid-level users.
Same. It always had the nicest UI and interaction model, but the bugs ruined it for me over time.
There was a particularly annoying one where if I got to 31:20 on Show A on my phone, then play Show B on my Watch, the playback in B would jump to 31:20. This was brutal if you were somewhere around the 2-hour mark in Show B and have to find your place again.
Really hope the new owners can make everything work again.
I totally agree. I’ve always liked Castro’s inbox/quick action method of dealing with new episodes a lot better than other apps. I’m glad it’s back and am glad to subscribe again.
Does anyone know how well it works on the Apple Watch? I have Overcast but am very frustrated with my experience on the Apple Watch because it doesn't sync properly even though the watch supports cellular connections. Nonetheless, it was the best of the podcast apps out there for that purpose. Has Castro made some progress on this front? It would be enough to convince me to switch if it works well on both the phone and the watch.
I used Castro for 5 years and loved it. But when it had the ownership meltdown I switched back to iCatcher. It’s quirky, but easy to set up an Inbox and Downloaded queue which is the Castro USP. I haven’t missed Castro and can’t say the news entices me back.
Haven’t tried iCatcher myself. It has that utilitarian look that usually either means it’s a power user app that can be configured to behave exactly like you want, or it is a hobby project of a single person without UI/UX talent. Going by your comment it’s the former ;-)
I’m lucky Castro fits my workflow (or rather, my podcast workflow came to be by using Castro since forever), and as it looks pretty as well I have no reason to switch apps.
That's cool, but the last thing I would want my mom to have to manage is a portable open source encrypted database shes's in control of and can back up and secure as needed.
There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such "open" passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.
The spec allows for hardware attestation as well, to ensure passkeys are being provided from blessed computing environments. Hopefully implementers continue to ignore this anti-feature, because it's entirely stupid to lock out users who want to control their own security; at the same time, letting anyone with an Android phone restore passkeys from the cloud with one of their device PINs.
Pretty telling thread. Tim Cappalli, one of the spec writers drops by to criticize the export feature and suggests that the attestation feature should be used to punish them for not implementing the fully locked in version.
The credential exchange changes nothing IMO, the rod to punish anyone who doesn't want their credentials stored on a tech giants servers is still there.
I halfway expect a v2 specification where keys are only stored on a few "Certified Attestation-capable" providers (i.e. facebook, google, apple, amazon)
Then watch them get hacked through a systems management plugin like Clownstrike, or Solarwinds.
That's not what happened. He said quote "which would allow RPs to block you, and something that I have previously rallied against".
This is something that has been proposed that Tim fought against but mentioned in the thread to provide context of the types of kneejerk reactions the spec authors have had to push back against.
Currently it is not. It was created provider centric so far, and in my reading of the spec, a thinly veiled lockin. The ability to move around should have been built in from the beginning but it was more beneficial for the providers to start without.
Historically, the spec was written for hardware security tokens. Keys on those tokens can't be moved around by design.
The whole "platform authenticator" thing enabling passkeys came later. Extending the spec that way was easy: a platform authenticator works just like a hardware authenticator, it just uses a different channel for communication.
The spec the providers built upon just wasn't designed for software authenticators that allow moving around credentials. The original spec assumed credentials are stored in a non-extractable manner in HSMs.
Edit: thinking about it, platform authenticators may have been in there pretty early, but under the assumption of also using an HSM and not allowing extraction of credentials.
Providers compromised security for usability, removed the HSM and made passkeys synchronizable – the spec had to adapt.
The attestation anti-feature which is part of the spec. And the portability feature which is conspicuously not. The former makes the enforcement of the later possible.
The attestation is part of the webauthn spec, and it's up to the relying party to decide whether or not to use it. The whole reason it's there is to give some contexts the ability to narrow their users down to specific webauthn storage implementations (which is useful in some corporate / gov contexts).
Are there any examples of any widely-used sites that are enforcing attestation?
- Cloudflare had a "captcha" POC called "Cryptographic Attestation of Personhood" where you need to use a FIDO-approved token. It's reusing U2F just for the attestation part only. I don't think it ever go to production as most people don't have a token (but perhaps in the future hardware-locked passkey may serve as one...)
- Okta do have an option to enforce attestation. By default it is off, but in my Okta production I can limit the list to FIDO-approved vendor only, or to even a subset of them. They also have a beta feature flag for blocking Passkeys but allowing physical keys (which they do not guarantee success)
OK, so you gave two examples of systems that do NOT enforce attestation (one that is not in production, one that has an option to enforce attestation but is not apparently in use).
Are there any widely-used sites that actually enforce attestation?
People already do have issues with e.g. banking apps on mobile devices requiring OS attestation, so we can expect that once they know they can do the same for the most of their web clients (so probably once most people have moved onto Windows 11 which requires a TPM), they will.
It’s absurd, really. Attestation is clearly a feature intended for high security environments, where you want to ensure all employees use their corporate hardware authenticators and those only, yet people act like it’s big techs secret, evil mind control back door.
As a sibling comment explains, attestation isn't processed by common web browsers unless explicitly configured. Your bank can require attestation from you and limit you to a number of supported authenticators... But I don't quite see what that would get them, other than loosing customers? And to what end, to foster ecosystem lockin on behalf of Apple or Google? It doesn't make any sense. Hence: absurd.
Given the chance, why wouldn't companies abuse that feature like every single anti-user feature in the history of them? Surely this time it will be different?
The regulatory universe that banks operate in means that they're not like other companies. They don't share the same overall incentives, and aren't a useful point of comparison.
Non-default as in browsers should not provide any attestation information unless configured to via a setting in about:config (which can be automatically enabled by IT on a managed device), and mobile OSes should not provide attestation info to apps unless configured via some similarly buried setting that MDM can enable.
Basically put it there for nerds and IT where the device owner wants that extra security and coordinates with (or is) the service provider to set it up. For everyday use, it should be unavailable so that it's not used for lockin.
It's only a matter of time when it's this easy. Some essential service, most likely a bank, will inevitably turn it on in the future. And it only takes one of those to make all freedom respecting providers non-viable for someone. For our safety, of course. :)
My mum has a password notebook which is locked away in a drawer in her house, she knows to use either passphrases or random string that her browser generates for her. For her threat model this is better than any software thing.
Certainly a password manager like keepass would be no more complicated than trying to explain to her that she can no longer access her account because she broken her phone.
On the one hand I love single-focus nicely designed hardware. On the other hand I have a https://getfocustimer.com/ gathering dust, because a timer is just easier to set from the computer + screen I am already looking at...
Yes, my experience as well. That's why having an alternate small display (8" or smaller) for your laptop/desktop is better. You can then drag any application on it and use it as a timer or busy sign or whatever. It's way more convenient than an extra device you have to reach and fiddle with.
Maybe a dumb question, but why do consumer microwaves have all these power settings (600W, 800W, 1000W) if apparently they are useless? I don't really know how microwaving works on a physical level - do I achieve the same effect by microwaving something for 30 seconds at 1000W or 1 minute at 500W?
The waves are only heating specific parts of the product. By reducing power you let heat propagate more evenly. You can avoid explosion, for instance if the middle of a butter is melted and boiling while the outside is still cold. Or better defrost without cooking.
You can achieve the same by heating full power and doing regular pauses (which is often how this is implemented anyway).
This is like asking "Why does a kitchen stove have a range of settings on a dial when simply having the burner be on or off would also be able to cook food?"
And the answer is simple: Because they can be useful settings.
The food being warmed does conduct heat, but it is not an ideal conductor of heat.
And microwave ovens (just as any other kind of oven I can think of) heat from the outside. And they're supposed to make things easier and simpler.
So let's make an example: Leftover refried beans, still cold from the fridge.
I can put them in a bowl at 100% power for three minutes, and they'll probably explode and make a mess and still have parts that are cold. This "works" but it's obviously not very good. (I can mitigate some of the mess by using a cover of some kind, but that's also kind of shit.)
Or: I can put them in for a minute or two at 100%, and then stir them, and then run them for a another minute, and then stir them again, and maybe then do another minute. This "works" but it's enough work that perhaps I would be better off to skip the bowl and warm them up in a pan on the stove instead.
Or: I can set the microwave to (say) 40% duty cycle, and put them in for whatever I think is a reasonable time for the volume of beans at that duty cycle. Let's say 5 or 6 minutes.
It's slower, which prevents layers from getting stupid-hot and explodey, and gives the beans more time to reach thermal equilibrium. It's completely hands-off once the buttons are pushed. I'll probably still give them a stir before serving, but they'll be fine.
(I'm a fan of simplicity, but I'm not a fan of lack of control like OP's microwave offers as a primary selling point.
The microwave oven that we had when I was growing up was simple and functional: It had mechanical timer switch with a mechanical bell to set the cook time and announce the end of a run, which is about as simple as it can get while retaining any aspect of automation. It also had an analog dial with which the duty cycle could be continuously set, from somewhere between ~5% to 100%, and this duty cycle could even be changed while the machine was running. No computers, and nothing particularly electronic at all. Just a timer and [what was probably] a heated bimetallic switch (just like a common, cheap electric range uses).)
The difference is amazing. 1kW uninterrupted is the "dry my food" setting. Reheating chicken like that basically dries and cooks it again. At half the power and twice the time you can have an actual warm, soft chicken again.
Try heating something you cooked yourself recently and you'll see the difference clearly.
Lower power levels are great when heating things that are prone to boil over. The pause between heating cycles gives time for the heat to "soak" into the interior of the food, avoiding excessive heating on the outside.
reply