> wage theft

Like when you poop on the clock?

I’d like to know your reasoning for answering “no” to all of the above.

I guess we'll just have to find someone who answers no to all of that and ask them!

I think my point was obvious. What is your justification for answering no to any of them?

Alright, I'll explain. I don't think violence is bad against someone who's about to kill my family, because:

* I care about my family more than I care about a stranger.

* I care about people who don't kill people unprovoked more than I care about people who kill people unprovoked.

* My family are more than one person, versus the one killer.

That's why I answer no to that one.

Sure, I care about certain people more than others and I’d be willing to use violence to defend myself or my family. But that’s not the same as cheering on or advocating for an attack on someone else that may or may not have done something to harm someone totally unrelated to you.

It gets much more complicated when the person being harmed is someone who made and sold AI targeting systems that might be used against my country.

I’m pretty sure you can setup without broad host permissions, you just probably wouldn’t like it. You’d have to click a button to trigger the behavior, which I think requires you to click another button to approve access. Or configure the extension to allow access to specific domains after install, which will also have a permission prompt.

Isn’t it exactly the same on iOS? If you select a folder, the app gets a security scoped URL for the folder and can read/write the entire tree. The app can also then create a bookmark to persist the security scoped url and use it whenever in the future.

That URL should expire after a relatively short time.

This rules out entire classes of app and would make using a computer a miserable experience.

For example let's say you want to make an app that every day writes a backup to a particular location e.g. 1Password can do a daily backup of your encrypted passwords to a backup location.

Or, let's say you want to make a GUI around a command line program that stores its config as a dotfile.

Without a way to save access to file system locations persistently, apps would be forced to constantly shove open panels in your face all the time.

Expiration depends on how the app has implemented the request for access. Granting access creates a security-scoped bookmark. The app can store it and use it the next time access is required which will bypass the prompt and the bookmark will remain valid in perpetuity (or until tcc reset), or the app can not store it and request permission every launch.

IIRC the bookmark is a base64 encoded plist containing bunch of data about the file/folder. A quick search got me this: https://www.mothersruin.com/software/Archaeology/reverse/boo...

“Should” meaning “I believe it currently does expire after a short time”?

Or “should” meaning “Apple should change this to expire after a short time”?

It doesn’t expire, you can even move the file and you can update the bookmark to follow the move.

There are legitimate reasons to give an app persistent access to a file or directory. Maybe you want it to write to a particular directory in your iCloud storage or whatever so it syncs without having to select the directory every time. A note taking app for example.

No, it shouldn’t. There are real reasons to give persistent access to a particular directory. Maybe you want your note taking app to put all notes in a directory for iCloud/dropbox/google drive/some other sync service.

I am baffled that anyone thinks implication-of-action ambiguity and hidden security states without obvious controls, are acceptable security practices.

You could just install one of those chain things so the door won’t open more than inch. The toddler isn’t tall enough to reach it. There’s non chain ones too, you see them in hotels, a little metal thing you flap open.

Thanks. The front door is a wood grain textured fiberglass double door, so I want to avoid drilling into the door face. It's an interesting challenge.

Trying two of these between the levers for now: https://www.amazon.com/U-Shaped-Proofing-Cabinets-Adjustable...

Plus, I found this, hoping it will work for me without too much damage to the door: https://www.snappower.com/pages/huglock

That would certainly be an easy off-the-shelf solution... Although if the door opens a crack, that also means a reckless toddler (is there any other kind?) could slam it on their own fingers.

There are some which are just hinged metal that can lock at a right-angle, one of those would give tighter no-finger-gap tolerances, while also being structurally weaker in case of emergency.

Yep, those thingies. They're also easier to remove afterwards without too much door-scarring, since the contact-portion is on the inside frame.

They don’t need to change how they bill. Your subscription is for Claude app/code. Otherwise you pay per token. It’s always been this way.

Claude Code is a subscription tier explicitly designed for agentic, automated, heavy usage. So the 'subscriptions are for human use, API is for automation' line is already blurry by their own offerings.

If the actual concern is use pattern, enforce that directly. What we have instead is metered usage + behavioral restrictions + product fragmentation across three separate offerings.

That's not a clean billing philosophy, it's layers of control stacked on top of each other with no coherent logic tying them together.

If subscriptions are for humans and API is for automation, fine. But then don't meter the human product arbitrarily and don't sell a subscription tier for automation while also restricting automation. Pick a lane.

> Claude Code is a subscription tier explicitly designed for agentic, automated, heavy usage

Except it's not. It's a desktop, web, mobile, and CLI subscription product built on top of a usage-based API with a generous token allowance bundled with it. That generous allowance comes with the restriction that those tokens can only be spent through Claude product surfaces. Why would Anthropic offer their API at a loss and subsidize the profits and growth of other businesses?

They did figure out how to structure an offering that accommodates that type of usage: pay for your tokens.

We don’t have wealth taxes, only income taxes. So all wealth is untaxed.

What is property tax?

Rent.

Then income tax is rent too. In fact both are taxes, the rest is meaningless rewording.

It seems pretty clearly ai written.