Security through obscurity is bad when obscurity is the only thing stopping an attacker. It's a meme because obscurity is not a substitute for stronger security mechanisms. That does not mean it cannot be an appropriate compliment to them, however.
If I wanted to hide a gold bar, sticking it in an open hole behind a painting on the wall wouldn't be particularly great security. As soon as a robber found the hole, the entirety of my security is compromised.
If I put it in a safe on the wall, it's much more secure. The robber has to drill through the lock to get the gold bar.
If I put it in a safe behind a painting on the wall, the robber has to discover that there's a safe there before they're able to attempt drilling through it. Bypassing the painting is trivial compared to bypassing the safe, but the painting reduces the chance of the actual safe being attacked (up until it doesn't!)
Security should be layered. Obscurity will generally be the weakest of those layers, but that doesn't mean that it has no value. As long as you're not using obscurity as a replacement for stronger mechanisms, there's nothing wrong with leveraging it as part of a larger overall security posture.
I was kind of shocked by just how gosh-darned reasonable it is when it came out a couple of years ago. It's my absolute favorite thing to cite during audits.
"Are you requiring password resets every 90 days?"
"No. We follow the federal government's NIST SP800-63B guidelines which explicitly states that passwords should not be arbitrarily reset."
I've been pleasantly surprised that I haven't really had an auditor push back so far. I'm sure I eventually will, but it's been incredibly effective ammunition so far.
Alas, in Australia one of the more popular frameworks in gov agencies is Essential Eight, and they are a few years away from publishing an update with this radical idea.
The option is not a binary between "let it fail" and "no strings attached bailout."
If things get bad enough for Intel, the precedent that makes the most sense is to follow the model that was used with GM: the company enters bankruptcy, existing investors and creditors are wiped out, and a new corporate entity backed by the fed.gov steps in and assumes the assets and operations of the company. Once things have sufficiently stabilized, the government can then divest its ownership in the company.
Intel is economically and strategically important enough that just letting it collapse without a plan to pick up the pieces is a serious footgun. We have a framework for handling this kind of situation that has been shown to work without rewarding those who caused the problem. It'd be silly not to use it.
It's not just the investors and creditors that need to be wiped out. Above all else the managers need to be fired, with no bonuses or golden parachutes.
The 'the only reason a company exists is to make money for the stockholders' is why we're in this mess right now. Because that's the regime management is operating under. And they are delivering what's demanded. Yeah management is looting companies to the detriment of their long term health. But that's allowed because it aligns their incentives with predatory capitalists.
I don't understand why they discontinued the bolt before the new one comes out. Who does that? You have a cash cow, the assembly lines are already running, just... do nothing.
Conrail might be a better alternative model. It really did succeed well enough to re-float and become a competitive endeavour.
The state probably did a better job than a private takeover could have because:
- They had effectively infinite backstop-- they could afford to spend years and front load a lot of costs to fix the mess
- They had a mandate to restructure the sector beyond a single company. I'd expect a nationalized Intel would have an easier time pivoting to new models, while private investors might be too afraid of killing their current golden geese for, say, a full fab spin-off or becoming a more aggressive x86 licensor.
Sigh, I'm sure there is zero consideration for a antitrust-style breakup. All I saw on a quick scan was "hey does any other company want to acquire parts of them" which is just another way to say "does anyone want to reduce competition even more".
I get that there is probably only one top-end fab in Intel and that would be hard to split across two entities.
But if you split Intel into three entities, they might (gasp) hire a bunch of the engineers that have steadily fled intel or be chopped off in shortsighted layoff rounds. You might get (gasp) innovation.
If you give all three the access rights to Intel's IP, things would probably be FINE in the long run. Give three separate companies a couple fabs and the IP, and see what happens. Intel has FIFTEEN fabs. So hand five to each of them.
Intel is a shell because existing management is financial "wizards" and war-on-labor MBAs that are trying to manipulate the stock price to hit options targets.
If you split the companies, they have to compete on engineering, or they die. You can probably also wipe away a lot of the management because the companies will have to do "real work" in the medium run and their "skillsets" won't really apply.
The MBA types will all say that's impossible. IMO that's why we should do it, because all the people that failed the industry and company are opposed to it.
Admittedly my language was deliberately more inflammatory than it had to be, because I wanted to challenge folks to basically post what you just did. Rather than an endless reform-a-palooza, seizing upon current apathy to champion “let it fail” forces folks to reckon with the reality that nothing is permanent, and if the status quo is unworkable, how do we destroy and rebuild in a constructive way?
Excellent response, gave you the upvote so others will hopefully read it.
The point I'm making is that people are making a point out of ignorance.
People think it will be a problem, so make ignorant commentary about it being idiotic, yet in practice it's fine, and not the worst aspect of a terrible mouse.
>Anthropic is doing fine for technical or business customers looking to offer LLM services in a wrapper
If there's an actual business to be found in all this, that's where it's going to be.
The consumer side of this bleeds cash currently and I'm deeply skeptical of enough of the public being convinced to pay subscription fees high enough to cover running costs.
Especially when Google is good enough for most people. Most people just want information not someone to give them digested info at $x per month. All the fancy letter writing assistants they get for free via the corporate computer that likely has Microsoft Word
If inference cost is so cheap and negligible, then we'll be able to run the models on an average computer. Which means they have no business model (assuming generosity from Meta to keep publishing llma for free).
I think they mean running inference. Either more efficient/powerful hardware, or more efficient software.
No one thinks about the cost of a db query any more, but I'm sure people did back in the day (well, I suppose with cloud stuff, now people do need to think about it again haha)
I just looked and I can't find any option to localize results more specifically than "United States." I'm not finding anything in a KB search either. If the option is there, it has really poor discoverability.
I love the service, but poor local results is definitely one of its weak points and basically the only reason I ever fall back to Google anymore.
The push for the 8 hour work day over a century ago was often accompanied with slogans to the effect of "8 hours work, 8 hours rest, 8 hours for what we will."
5 hours round trip commuting a day is giving up over half of your prerogative time to simply shuffling from one place to another.
The Bay Area is lucrative monetarily and all, but there's just no world where that's worth it for me.
That's because having children in SF is not "normal," a huge fraction of new workers are single male tech workers. SF is the city with the fewest children per capita in the country, Daly City is #6.
Well, OK, there are ways for a young tech family to avoid the 2+ hour commute:
- Be extremely well paid, and don't mind buying a $1.5m house that would go for $500K in, say, Pittsburg CA.
- Squeeze into an apartment.
- Buy near one BART station and find a job near another, e.g. if you buy right next to the Pittsburg station and work at Uber HQ it's 1 hour each way. This mostly rules out Apple, Meta, Google, etc.
Another way of course is if your colleagues bought homes at around the time of the market lows, but that was ~15 years ago, so they would not be young families.
>I really wish that what we got instead of "Hey, your device can connect to smart-things.com and do stuff, ain't that need!" we had "Hey, this device speaks Protocol 1.2.3 over bluetooth which you can import to smart-things.com or other services".
I made a conscious decision to build out absolutely everything HA-related that I could using Zigbee and Z-Wave devices. I intentionally avoided anything based on wifi and proprietary apps. It's basically what you're describing. I switched from SmartThings to Home Assistant about a year ago, and everything flipped over without any real drama.
As others have said, Matter is another step in this direction with the end goal of making setup a little bit easier; it's still incredibly immature at the moment, though. But Z-Wave and Zigbee are both here now and work fine.
I'm currently doing home assistant + zigbee/zwave as well for everything. The main issue I have is it seems like the amount of those devices being released is fairly limited. It can be hard to find devices for some applications (like high current switches, for example).
Be that as it may, the issue is also that you can't take your phone and hook up directly to these devices which is the bigger issue for wider adoption, IMO. It's fine for someone like me that has a home server laying around where I can plop in HA. But what about the average consumer who's only device is probably their phone and maybe a smart speaker?
That's more the problem I was talking about that needs addressing.
Yeah, that's specifically what Matter+Thread are intended to address. The intention is that most devices that aren't battery powered and have an internet connection can act as a Thread border router and build out a mesh from there. The controller can be practically anything from that point.
Same here, when I was getting started I bought some wifi light bulbs, realized they expected you to have them connected to the internet and immediately returned them, instead getting zigbee ones. Has been working for years with zero issues, was great when Philips started going cloud focused for their Hue bulbs since I didn't have to worry about it affecting me.
I bought a bunch of zigbee light switches years ago. A couple of them have failed and I replaced them with dumb switches. For my use case I found I was rarely using them as anything other than dumb switches anyway.
There have been many, many times where we've considered an application where we could justify the spend at, e.g., the departmental level for the limited user base that needed it, but where SSO being bundled into higher price tiers combined with minimum user counts took a potential solution from "very easy discretionary spend" to "not happening, full stop."
I'm often the one having to make these decisions. It's absolutely exhausting having to explain to non-technical department heads that "yes, this would solve your problem at a price that fits budget, but the vendor bundles a vital security feature into a tier that inflates the price to a point that it makes this unfeasible."
Curious: Are SaaS sales unrepentant on pricing in these cases? I would think with a bit of spice on your side in procurement you could probably negotiate enterprise for a small premium over the middle tier. Knowing enough software sales people when given the choice between “Teams + $5/user/head” and “no sale at all” suddenly options open up. But maybe the people I know don’t support too much SSO stuff…
Mixed bag, IME. Some vendors will work with you, some stick to their guns.
Either way, it's a surefire way for a potential vendor to automatically get lower priority from me as a potential buyer. Needing to haggle over what is, for us, a baseline security feature starts things off on the wrong foot.
>This is a solid objection that I hadn't considered before!
To be quite frank: this strongly suggests that while you put a lot of effort into writing a long article in defense of the SSO tax, you didn't perform more than the most cursory research about why it's a topic of discussion.
This argument is literally above the fold on the two top search results for the term.
>In short: SSO is a core security requirement for any company with more than five employees.
And the other explicitly makes the car-safety analogy:
>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power. Not offering security features if they already exist in your product means a vendor doesn’t care about your security. Our aim is to spotlight vendors who overcharge for security features, in hopes of instigating a change in the industry.
And to be franker: the word "security" appears exactly once in your entire piece. That's a near-complete avoidance of the actual issue that people are highlighting.
I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
>>In short: SSO is a core security requirement for any company with more than five employees.
This is from a random website with no credentials that makes no arguments to back up its claim. It's meaningless.
>>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power.
And this is a fatally flawed analogy that renders it useless. The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Neither of these quotes support this position.
> The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer.
As to this - is there any actual empirical evidence that missing SSO meaningfully weakens security for small businesses, which are the ones that would actually care about forking over the extra for the enterprise tier? That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage. I find it unlikely that missing SSO matters that much from them, and I'd like to see empirical evidence otherwise.
Also, there's nothing wrong for charging different amounts for different levels of security, assuming that that cost translates into actual effort (which it does for SSO). Normal people pay small amounts of money for physical door locks that are woefully insecure - the proposition that lock manufacturers should make their industrial and home locks cost the same would be pretty ludicrous.
>This is from a random website with no credentials that makes no arguments to back up its claim. It's meaningless.
Appeal to authority. Meaningless.
All I was pointing out with those links is that literally Googling the term "SSO tax" and clicking the first link at least hints at some of the reasoning behind people making an issue of this. The fact that TFA doesn't address any of the actual concerns people have in any meaningful way makes it of incredibly limited usefulness in the overall discussion.
> The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Then charge for the support. The issue is that the only way to purchase a core security feature is bundled in with other features that the user doesn't necessarily want or need, very often at several multiples of the price for the features they do want.
>That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage.
This is working from the faulty assumption that potential customers only exist in a binary between the nebulous "enterprise" and "small business with barely any IT competency."
I live in the enterprise healthcare world. It's routine for us to consider software purchases at the departmental level to fill a specific need for a particular team. We have hard requirements for SSO. Some of it's driven by internal policy, some of it's driven by auditors increasingly demanding MFA everywhere.
I have personally killed deals over this exact issue on a more routine basis than I'd like. Department head thinks cost is going to be Y. Cost is actually 5-10Y because the only way to purchase SSO support is via an "enterprise" bundle with additional features they don't need and an inflated minimum seat-count buy. We'd happily pay some middle ground for SSO support, but the option to buy it doesn't exist.
The issue is not charging for things that have support costs; it's forcing a customer into drastically higher pricing tiers under the assumption that running SSO is a signal that a potential customer has a super sophisticated environment and bottomless pockets. That was the world of 15 years ago, sure, but it's not today.
The reality is we live in a world where there are increasingly strict security requirements in many industries and any business paying, e.g., $6/user/month for Microsoft 365 has SSO available as an option.
>I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
I made this comment the last time the SSO Tax question came up: We routinely deploy our platform to large customers for 6 or 7 figure contracts.
The number of them who actually deployed SSO (without just asking if we comply with it) is less than 20%.
FWIW, I've mentioned elsewhere in the thread, but I'm in healthcare. SSO (and MFA) have only really become hot topics in the past 5 years or so.
In the past? People with enough weight would absolutely blow right past implementing SSO if it was slowing them down or adding to their cost.
These days it's a hard requirement for us: if it's not SSO it doesn't go into the environment. That's becoming the norm across the industry.
This is one of those very, very rare cases where healthcare is probably ahead of the curve relative to a lot of other industries. Consequence of being highly targeted by attacks and insurers starting to get very particular about how the ship is run.
This is not a valid criticism on its own.
Security through obscurity is bad when obscurity is the only thing stopping an attacker. It's a meme because obscurity is not a substitute for stronger security mechanisms. That does not mean it cannot be an appropriate compliment to them, however.
If I wanted to hide a gold bar, sticking it in an open hole behind a painting on the wall wouldn't be particularly great security. As soon as a robber found the hole, the entirety of my security is compromised.
If I put it in a safe on the wall, it's much more secure. The robber has to drill through the lock to get the gold bar.
If I put it in a safe behind a painting on the wall, the robber has to discover that there's a safe there before they're able to attempt drilling through it. Bypassing the painting is trivial compared to bypassing the safe, but the painting reduces the chance of the actual safe being attacked (up until it doesn't!)
Security should be layered. Obscurity will generally be the weakest of those layers, but that doesn't mean that it has no value. As long as you're not using obscurity as a replacement for stronger mechanisms, there's nothing wrong with leveraging it as part of a larger overall security posture.
reply