I'm not so sure. If you could rebuild every human space and tool from scratch, you are probably right. However, we live in buildings filled with stairs. We've got tall cabinets with things tucked in them. We've got lawn mowers and snow blowers and leaf blowers and cars. Making a humanoid robot is a much harder problem if you want a cool demo. If you actually want to deploy robots in billions of homes, it might just be the only answer.
Rebuilding and replacing tools doesn't sound that big of an issue to be honest.
I'm starting from the assumption the vast majority of people won't want a robot in their home, even just on principle. Then most people will not need it to do every possible action an human does.
For the remaining people in the target, having adapted/compatible cabinets or furniture is probably less of an issue. If someone requires assistance for instance, they'll probably also don't want hard to access shelves or crazy weird stairs.
The same way people have started choosing furniture that can accommodate a roomba(RIP irobot), we'll adjust our newer homes to whatever makes sense when we get the next wave of home robots.
Why wouldn't everyone want a robot that does all your chores, given that it is affordable? Everyone I know uses a washing machine. Do you wash your clothes by hand?
For better or worse, there is a fundamental difference between a tool that does a specific task under command (e.g. a washing machine), nothing else, never by itself, and a general purpose machine with some autonomy (a "robot") .
Many people will want full control over what happens in their house, and potentially feel unsafe having things that move on their own. Where's the line is for "full control" will be personal.
That’s a flawed assumption. Everyone wants a live-in bangmaid. They’re just normally too expensive. If you could buy one for 30k, they would fly off the shelves.
While Hollywood may portray the whole fuckable-robot thing as a male-dominate field, reality suggests the reverse. It's mostly not males that the current generation of powertool-like sextoys are marketed to...
Why not just robo-dog? They can go pretty much everywhere a human can. You just add a strange neck/arm thingy as head and it can do pretty much everything. It's not accident that that became one of the best known robots.
I was thinking that too, but then the article mentioned at the very end that Canada isn’t experiencing the decline and its mass market paperbacks never ballooned in price. That one fact could prove the entire thesis of the article but wasn’t really explored.
Out of curiosity, why couldn't property taxes be progressive? What stops Texas from having different tax rates based on the value of the property?
It even seems like it avoids a lot the pit falls the uber-wealthy use to avoid most progressive income taxes. Its easy to disguise income as something else. Property, though, is right out in the open. The state can easily audit and value property and send the bill. No matter how fancy the accounting, that bill will eventually reach the person "consuming" that property.
In practice, at least from what I've read, in TX, the largest/wealthiest companies get the biggest/best tax breaks (eg Tesla), and end up paying proportionally less, so it's somewhat regressive.
In Texas, like Florida, you get a bill for all improvements within your neighborhood or development as they come. Just because the tax may appear low on the front end, that doesn’t mean you don’t pay for the same relative lifestyle as everybody else in the United States of America.
Even though all the states have their differences they all live relatively the same, in short, if you are an average person, you pay pretty much the same as any place else. It’s only the wealthy who get to hopscotch and dance over the top of all the bodies of the (working class) below.
OpenID Connect actually has all the machinery needed to support federated login as part of its dynamic discovery and dynamic registration specifications. The issue is that absolutely no one uses them or implements them.
Smaller tech companies don't want federated login to happen. They are, as a rule, far to happy to rely on the SSO tax to up-sell enterprise customers. The major authentication companies don't want federated login to happy because it invites more competitors and threatens their absurd margins.
Until someone manages to solve the business side, no amount of improved technology will change a thing. I'm pretty sure the few small interoperability gaps OpenID Connect has could be corrected in a matter of months if the stakeholders actually cared.
As someone with a vested interest/being/been many of the parties you mention... Do you think support for "federated login via OIDC" would _not_ fall under the SSO tax?
Who do you think would host the "federated login" system that would replace the major authentication companies?
You can already stand up a SAML or OIDC provider using OSS and run the IdP for your company. I have many customers that do! And you bet we still charge them for SSO, and that they're every six months asking how bad the migration to a "big auth company" would be.
With dynamic client registration, I could host my own IdP server at home, or with a provider of my choice, and it would just work everywhere without any coordination work for anyone, manual signups to be assigned a client id/secret, etc. The entire point is that you won't let me do that because you want to charge extra for better, simpler, cheaper security for everyone. That is the SSO tax.
I should be able to just give my email or domain name, and it kicks off an oauth flow to that domain no matter who I use for my email/identity. In the same way that I can give you my email address and you'll just email me without me having to pay extra for enterprise email.
There is nothing left from the OpenID 1.0 and 2.0 protocol in OpenID Connect, except for the core features (identity federation, identity information encoding and updates).
OpenID Connect is basically OpenID reimagined on top of OAuth 2.0, with using JWT for the identity data.
The core OpenID Connect spec is still purely a federated identity standard. There are many other standards pushed by the OpenID foundation, but OpenID Connect itself was never meant to be anything more. The main feature differentiator from the OG OpenID is that it's built on top of OAuth, so you can add other features supported by OAuth (like authorization) ad-hoc.
Federation sounds like decentralization to me. Decentralized is like a dirty word when you’re in the business of either selling SaaS or pushing private citizens to go all in on the GOOG/AAPL/MSFT ecosystems. And everyone with any influence over what gets adopted and used, is in those categories.
They are being used. Workload Identity Federation is often used to assign oidc identities to workloads and the Client ID Metadata Document (basically dynamic client registration) is used in protocols such as MCP and atproto
I think the key thing you are missing here is that most successful open source maintainers don’t lack expertise, they lack time. They are generally capable of improving their projects in any direction they want without help. Mentoring new contributors is basically always a loss in the short term as far as the maintainer is concerned. The project does get improved, but it generally takes longer than if they did it by themselves from scratch, and the improvements might be in an area they don’t much care about. The payoff for the maintainers only ever happened in the long term if the mentorship succeeded and they get a viable independent long term contributor.
For me, the primary issue with it is that I have zero intention of getting locked in to AWS. All the marketing looks great, but I don’t invest energy learning tools I can’t run locally. I’m happy to use AWS but only if I can see the exit. This doesn’t offer near enough to make me break that rule.
I think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package.
None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.
The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level.
There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a ton of value with very little downside if people implement a one week cooldown period.
To answer your question directly, though. If everyone else moves to a one week cooldown, I would absolutely suggest a two week cooldown is a good idea. Being the "slow" moving organization is a good security trade-off so long as you don't take it to extremes and have escape hatches when you actually need to be moving quickly.
There's a really bad implicit assumption in there: Microsoft's scanners have solved the halting problem, so they can tell if a package update will ever flip to malicious mode, or has an intentionally inserted security hole in it.
Of course, this also assumes that Microsoft's internal scanners are much better than the scanners available to the attackers, since any reasonable attacker is going to just run their obfuscated code through a scanner as part of their CI job. (And maybe even use the MS scanner as an oracle by submitting fragments to NPM to see which pieces of their exploit chain get flagged.)
Waiting until everyone else canaries is much stronger, but even that doesn't work on a targeted attack.
Thank you for the thorough response. I got the following from yours and other responses:
* The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread.
* This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user canaries as well.
* Maybe NPM should run scanners before distributing malware?
* If the ecosystem by any chance adopts a week-long quarantine period, you'd be safer if you applied a longer quarantine period.
> Maybe NPM should run scanners before distributing malware?
I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited.
So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.
Look, nobody requested fully automated scanners that are never wrong. A scanner that asks the project owner to sign in with 2fa and confirm the release in case it's been flagged is going to be more than sufficient.
I’m not on X, so it’s good to know I don’t matter in tech. I always suspected. Since I’m a paying GitHub customer, though, I should probably matter to them. The right forum for GitHub to post this is with their status page, their blog, their website, or an email to all their customers. Using any sort of social media for this kind of thing is either incredibly sloppy or very intentionally quiet. Given that my tiny employer has a better incident communication plan than this, my guess is this an attempt to downplay things.
reply