If you allowed third-party components without restraint, there'd be no way to prevent someone swapping out a component.

Lock-in and planned obsolescence are also factors, and ones I'm glad the EU (and others) are pushing back here. But it isn't as if there are no legitimate tradeoffs.

Regarding screw tightening... if they ever completely remove the ability to run untrusted code, yes, then I'll admit I was wrong. But I am more than happy to have devices be locked down by default. My life has gotten much easier since I got my elderly parents and non-technical siblings to move completely to the Apple ecosystem. That's the tradeoff here.

It works via your keychain and your contacts, and the recipient gets a little notification to allow you to view their screen.

That’s it - no downloads, no login, no 20 minutes getting a Remote Desktop screen share set up.

Also, it only seems to work on a local network with hostnames.

It 100% works across the internet: it works with contact names, not just host names.

After you open it, press “Connections -> New” and start typing a contact name.

They get a little notification if they are online, and if they accept you have a seamless screen sharing experience ready to go. It’s honestly magic for the “my parents have an error message and don’t know what to do” situation.

I assume they have you in their contacts as well for it to work.

Glad to see your parents are tech savvy, but this reads like you live in a very different reality from mine.

Your parents don’t need to run the app at all. You need to run the app.

Unless you really do live in a different reality where you want your parents to help you out when you see an error message you don’t understand?

The answer is no, fyi

Some of us are old enough to remember the era of the officially authorised Apple clones in the 90's.

Some of us worked in hardware repair roles at the time.

Some of us remember the sort of shit the third-party vendors used to sell as clones.

Some of us were very happy the day Apple called time on the authorised clone industry.

The tight-knit integration between Apple OS and Apple Hardware is a big part of what makes their platform so good. I'm not saying perfect. I'm just saying if you look at it honestly as someone who's used their kit alongside PCs for many decades, you can see the difference.

Some of us might even be of the opinion that such a competition was beneficial to consumers that wanted more.

Yeah, but this is hacker news.

This is what the vast majority of discourse on these topics has been dominated by on every platform, not just HN. I wonder if there's a shorter term for this, none of 4chan /g/'s crass terms cover this kind of depiction.

Competition-enabled rationalism: https://en.wikipedia.org/wiki/Xserve

Apple gobbling up supply chains and production capacity is not something a hardware startup should be happy with.

Also, startup engineers don't necessarily like "alien technology", which is what Apple is becoming by developing everything behind closed doors and with little cooperation.

Startups don't like to pay 10-30% of their revenue just for running their software on a device someone has already paid for.

There are more reasons to dislike Apple than you can find on Slashdot.

You start with a very good and fair point.

> Also, startup engineers don't necessarily like "alien technology", which is what Apple is becoming by developing everything behind closed doors and with little cooperation. > Startups don't like to pay 10-30% of their revenue just for running their software on a device someone has already paid for.

You ended with one that is pretty much at odds with my experience. Startups value distribution channels, and the App Store has been fantastic for this.

Furthermore, it's one thing to dislike Apple. It's another thing for people to veer off into conspiracy theory, which is what half the threads on here have started to do.

First, this is 100% false. Second, security through obscurity is almost universally discouraged and considered bad practice.

More pragmatic advice would be to not rely solely on security through obscurity, but rather to practice defence in depth.

Widely deployed doesn't mean it's a positive action, and effective ? It just can't be as it's not a security. People really need to pay more attention to these things, or else we DO get nonsense rolled out as "effective".

This is stupid advice that is mindlessly repeated. Security by obscurity only is bad, sure. Adding obscurity to other layers of security is good.

Edit: formatting

Think of some common sense physical analogies: a hidden underground bunker is much less likely to be robbed than a safe full of valuables in your front yard. A bicycle buried deeply in bushes is less likely to be stolen than one locked to a bike rack.

Without obscurity it is straightforward to know exactly what resources will be required to break something- you can look for a flaw that makes it easy and/or calculate exactly what is required for enough brute force.

When you add the element of well executed obscurity on top of an also strong system, it becomes nearly impossible to even identify that there is something to attack, or to even start to form a plan to do so.

Combining both approaches is best, but in most cases I think simple obscurity is more powerful and requires less resources than non obscure strength based security.

I’ve managed public servers that stayed uncompromised without security updates for a decade or longer using obscurity: an archaic old Unix OS of some type that does not respond to pings or other queries, runs services on non-standard ports, and blocks routes to hosts that even attempt scanning the standard ports will not be compromised. Obviously also using a secure OS with updates on top of these techniques is better overall.

For example Intel's Management Engine, it was obscured very well. It wasn't found for years. Eventually people did find it, and you can't help but wonder how long it took for bad actors with deep pockets to find it. Its this obscured cubby hole in your CPU, but if someone could exploit it, it would be really difficult to find out because of intel's secrecy on top of the feature.

That's literally the practical basis of security through obscurity.

> Others, like my comment above, are talking about systems carefully engineered to have no predictable or identifiable attack surfaces- things like OpenBSDs memory allocation randomization,

That's exactly the opposite of 'security through obscurity' - you're literally talking about a completely open security mitigation.

> I’ve found when it is impossible for an external bad actor to even tell what OS and services my server is running- or in some cases to even positively confirm that it really exists- they can’t really even begin to form a plan to compromise it.

If one of your mitigations is 'make the server inaccessible via public internet', for example - that is not security through obscurity - it's a mitigation which can be publicly disclosed and remain effective for the attack vectors it protects against. I don't think you quite understand what 'security through obscurity[0]' means. 'Security through obscurity' in this case would be you running a closed third-party firewall on this sever (or some other closed software, like macos for example) which has 100 different backdoors in it - the exact oppposite of actual security.

[0] https://en.wikipedia.org/wiki/Security_through_obscurity

If you're not understanding how memory allocation randomization is security through obscurity- you are not understanding what the concept entails at the core. It does share a common method with, e.g. using a closed 3rd party firewall: in both cases direct flaws exist that could be overcome with methods other than brute force, yet identifying and specifying them enough to actually exploit is non-trivial.

The flaw in your firewall example is not using obscurity itself, but: (1) not also using traditional methods of hardening on top of it - obscurity should be an extra layer not an only layer, and (2) it's probably not really very obscure, e.g. if an external person could infer what software you are using by interacting remotely, and then obtain their own commercial copy to investigate for flaws.

Specific example of where I did this?

> literally gives the same examples to two of the main ones I mentioned at the very top of the article as key examples of security through obscurity: "Examples of this practice include disguising sensitive information within commonplace items, like a piece of paper in a book, or altering digital footprints, such as spoofing a web browser's version number"

I mean, I don't disagree that what you said about changing port numbers, for example, is security through obscurity. My point is that this is not any kind of defense from a capable and motivated attacker. Other examples like the OpenBSD mitigation you mentioned are very obviously not security through obscurity though.

> If you're not understanding how memory allocation randomization is security through obscurity- you are not understanding what the concept entails at the core.

No, you still don't understand what 'security through obscurity' means. If I use an open asymmetric key algorithm - the fact that I can't guess a private key does not make it 'security through obscurity' it's the obscuring of the actual crypto algorithm that would make it 'security through obscurity'. Completely open security mitigations like the one you mentioned have nothing to do with security through obscurity.

> The flaw in your firewall example is not using obscurity itself, but: (1) not also using traditional methods of hardening on top of it

Sooo... you think adding more obscurity on top of a closed, insecure piece of software is going to make it secure?

> if an external person could infer what software you are using by interacting remotely,

There are soooo many ways for a capable and motivated attacker to figure out what software you're running. Trying to obscure that fact is not any kind of security mitigation whatsoever. Especially when you're dealing with completely closed software/hardware - all of your attempts at concealment are mostly moot - you have no idea what kind of signatures/signals that closed system exposes, you have no idea what backdoors exist, you have no idea what kind of vulnerable dependencies it has that expose their own signatures and have their own backdoors. Your suggestion is really laughable.

> not also using traditional methods of hardening on top of it

What 'traditional methods' do you use to 'harden' closed software/hardware? You literally have no idea what security holes and backdoors exist.

> if an external person could infer what software you are using by interacting remotely, and then obtain their own commercial copy to investigate for flaws.

Uhh yeah, now you're literally bringing up one of the most common arguments for why security through obscurity is bullshit. During WW1/WW2 security through obscurity was common in crypto - they relied on hiding their crypto algos instead of designing ones that would be secure even when publicly known. What happened is enough messages, crypto machines, etc were recovered by the other side to reverse these obscured algos and break them - since then crypro has pretty much entirely moved away from security through obscurity.

If there are advantages to a closed source system, it is not in situations where the source is closed to you and contains bugs, but when closed to the attacker. If you have the resources and ability to, for example, develop your own internally used but externally unknown, but still heavily audited and cryptographically secure system, is going to be better than an open source tool.

Ok, let's start with a 'mathematically secure heavily public audited system' - let's take ECDSA, for example - how will you use obscurity to improve security?

> If you have the resources and ability to, for example, develop your own internally used but externally unknown, but still heavily audited and cryptographically secure system, is going to be better than an open source tool.

Literally all of the evidence we have throughout the history of the planet says you're 100% wrong.

You are so sure you’re right that you are not really thinking about what I am saying, and how it applies to real world situations- especially things like real life high stakes life or death situations.

I am satisfied that your perspective makes the most sense for low stakes broad deployments like software releases, but not for one off high stakes systems.

For things like ECDSA, like anything else you implement obscurity on a one off basis tailored to the specific use case- know your opponent and make them think you are using an entirely different method and protocol that they’ve already figured out and compromised. Hide the actual channel of communication so they are unable to notice it exists, and over that you simply use ECDSA properly.

Oh, and store your real private key in the geometric design of a giant mural in your living room, while your house and computers are littered with thousands of wrong private keys on ancient media that is expensive to extract. Subscribe to and own every key wallet product or device, but actually use none of them.

Nah, you're just saying a lot of stuff that's factually incorrect and just terrible advice overall. You lack understanding what you're talking about. And the stakes are pretty irrelevant to whether a system is secure or not.

> For things like ECDSA, like anything else you implement obscurity on a one off basis tailored to the specific use case- know your opponent and make them think you are using an entirely different method and protocol that they’ve already figured out and compromised.

You're going to make ECDSA more secure by making people think you're not using ECDSA? That makes so little sense in so many ways. Ahahahahaha.

The specifics of an entire situation- including the stakes, and how well resourced the adversary is likely to be- affect how you engineer a real world hardened system that isn’t just an academic example- because different security measures have different tradeoffs.

If you say so.

> Think of some common sense physical analogies: a hidden underground bunker is much less likely to be robbed than a safe full of valuables in your front yard. A bicycle buried deeply in bushes is less likely to be stolen than one locked to a bike rack.

That's not what security through obscurity is. If you want to make an honest comparison - what is more likely to be a secure - an open system built based on the latest/most secure public standards, or a closed system built based on (unknown)? The open system is going to be more secure 99.999% of the time.

> Without obscurity it is straightforward to know exactly what resources will be required to break something- you can look for a flaw that makes it easy and/or calculate exactly what is required for enough brute force.

The whole point of not relying on obscurity is that you design an actually secure system even assuming the attacker has a full understanding of your system. That is how virtually all modern crypto that's actually secure works. Knowing your system is insecure and trying to hide that via obscurity is not security.

> it becomes nearly impossible to even identify that there is something to attack

That's called wishful thinking. You're conflating 'system that nobody knows about or wants to attack' with 'system that someone actually wants to attack and is defending via obscurity of its design'. If you want to make an honest comparison you have to assume the attacker knows about the system and has some motive for attacking it.

> but in most cases I think simple obscurity is more powerful and requires less resources than non obscure strength based security.

Except obscurity doesn't actually give you any security.

> I’ve managed public servers that stayed uncompromised without security updates for a decade or longer using obscurity: an archaic old Unix OS of some type that does not respond to pings or other queries, runs services on non-standard ports, and blocks routes to hosts that even attempt scanning the standard ports will not be compromised.

That's a laughably weak level of security and does approximately ~zero against a capable and motivated attacker. Also, your claim of 'stayed uncompromised' is seemingly based on nothing.

Instead of, for example in your last example simply labeling something you seem to not like as "laughably weak"- do you have any specific reasoning? Again, I'd like to emphasize that I don't advocate obscurity in place of other methods, but on top of additional methods.

Let's try some silly extreme examples of obscurity. Say I put up a server running OpenBSD (because it is less popular)- obviously a recent version with all security updates-, and it has only one open port- SSH, reconfigured to run on port 64234, and attempting to scan all other ports immediately and permanently drop the route to your IP. The machine does not respond to pings, and does other weird things like only being physically connected for 10 minutes a day at seemingly random times only known by the users, with a new IP address each time that is never reused. On top of that, the code and all commands of the entire OS has been secretly translated into a dead ancient language so that even with root it would take a long time to figure out how to work anything. It is a custom secret hacked fork of SSH only used in this one spot that cannot be externally identified as SSH at all, and exhibits no timing or other similar behaviors to identify the OS or implementation. How exactly are you going to remotely figure out that this is OpenBSD and SSH, so you can then start to look for a flaw to exploit?

If you take the alternate model, and just install a mainstream open source OS and stay on top of all security updates the best you can, all a potential hacker needs to do is quickly exploit a new update before you actually get it installed, or review the code to find a new one.

Is it easier to rob a high security vault in a commercial bank on a major public street, or a high security vault buried in the sand on a remote island, where only one person alive knows its location?

'without security updates for a decade or longer' - do I really need to go into detail on why this is hilariously terrible security?

'runs services on non-standard ports,' - ok, _maybe_ you mitigated some low-effort automated scans, does not address service signatures at all, the most basic nmap service detection scan bypasses this already.

'blocks routes to hosts that even attempt scanning the standard ports ' - what is 'attempt scanning the standard ports' and how are you detecting that- is it impossible for me to scan your server from multiple boxes? (No, it's not, it's trivially easy.)

> Say I put up a server running OpenBSD (because it is less popular)- obviously a recent version with all security updates-, and it has only one open port- SSH,

Ok, so already far more secure than what you said in your previous comment.

> only being physically connected for 10 minutes a day at seemingly random times only known by the users

Ok, so we're dealing with a server/service which is vastly different in its operation from almost any real-world server.

> only known by the users, with a new IP address each time that is never reused

Now you have to explain how you force a unique IP every time, and how users know about it.

> On top of that, the code and all commands of the entire OS has been secretly translated into a dead ancient language so that even with root it would take a long time to figure out how to work anything

Ok, so completely unrealistic BS.

> It is a custom secret hacked fork of SSH only used in this one spot that cannot be externally identified as SSH at all

It can't be identified, because you waved a magic wand and made it so?

> and exhibits no timing or other similar behaviors to identify the OS or implementation

Let's wave that wand again.

> How exactly are you going to remotely figure out that this is OpenBSD and SSH, so you can then start to look for a flaw to exploit?

Many ways. But let me use your magic wand and give you a much better/secure scenario - 'A server which runs fully secure software with no vulnerabilities or security holes whatsoever.' - Makes about as much sense as your example.

> Is it easier to rob a high security vault in a commercial bank on a major public street, or a high security vault buried in the sand on a remote island, where only one person alive knows its location?

The answer comes down to what 'high security' actually means in each situation. You don't seem to get it.

You can install whatever OS you want on your computer - Asahi Linux is the only one that's done the work to support that.

You can disable the system lockdowns that "tighten the screws" you refer to and unlock most things back to how they used to be.

But very distinctly, not all. Apple deliberately makes customers buy more than what they need while refusing to sell board-level ICs or allow donor boards to be disassembled for parts. If a $0.03 Texas Instruments voltage controller melts on your Macbook, you have to buy and replace the whole $600 board if you want it working again. In Apple's eyes, third party repairs simply aren't viable and the waste is justified because it's "technically" repaired.

> You can install whatever OS you want on your computer

Just not your iPhone, iPad or Apple Watch. Because that would simply be a bridge too far - allowing real competition in a walled garden? Unheard of.

> You can disable the system lockdowns that "tighten the screws" you refer to and unlock most things back to how they used to be.

And watch as they break after regular system upgrades that force API regressions and new unjustified restrictions on your OS. Most importantly, none of this is a real an option on Apple's business-critical products.

We're clearly talking about Macs for the software parts so I'm not sure why you're bringing in iPhone/iPad/Apple Watch where the status quo has remained unchanged since they were introduced. I'd love those to be opened up but that's another conversation.

Regarding system restrictions on macOS (putting aside the fact it fully supports otehr operating systems on Apple hardware), the ability to disable the system restrictions hasn't changed for years. System Integrity Protection is still a toggle that most users never need to touch.

> Most importantly, none of this is a real an option on Apple's business-critical products.

I don't understand what this means?

Not sure what you mean exactly by this, but to me their Self Service Repair program is a step in the right direction.

They could go out of their way to make things actually easy to work on and service, but that has never been the Apple Way. Compare to framework or building your own PC, or even repairing a laptop from another OEM.

https://git.sudo.is/mirrors/AsahiLinux-docs/wiki/M3-Series-F...

I tested Asahi and I genuinely love it and I’ll probably be happy to use it as my daily driver as soon as it will be mature enough. And I’m impressed by how it works well (outside of what still doesn’t work at all).

But buying a Mac ARM hopping to run Linux on it today without issue is just a wrong move. Just buy a classic PC if you want to be productive on Linux today.

I’m pretty confident it will happen though since the team itself looks pretty confident about supporting what is currently missing and in the past, achieved more than I hoped.

Can you explain what you mean by this? I have been doing software development on MacOS for the last couple of years and have found it incredibly easy to run anything I want on my computer from the terminal, whenever I want. Maybe I'm not the average user, but I use mostly open-source Unix tooling and have never had a problem with permissions or restrictions.

Are you talking about packaged applications that are made available on the App Store? If so, sure have rules to make sure the store is high-quality, kinda like how Costco doesn't let anyone just put garbage on their shelves

Try sharing a binary that you built but didn't sign and Notarize and you'll see the problem.

It'll run on the machine that it was built on without a problem, the problems start when you move the binary to another machine.

edit: also, unless you are the digital equivalent of "off the grid", I would argue most people are going to need some sort of cloud-based identity anyway for messaging, file-sharing, etc. iCloud is far and away the most secure of the options available to most users, and the only one that uses full end-to-end encryption across all services.

"You need some cloud-based identity, and this is the best one," even granting its premises, doesn't make being forced into this one a good thing. I'm an Apple user, but there are plenty of people I need to message and share files with who aren't in the Apple ecosystem.

EDIT: As indicated in the reply (written before I added this edit), it sounds like I was ignoring the first part of the post, which pointed out that you aren't forced to use it. I agree that that is a sensible, and even natural and inevitable, reading. I actually wasn't ignoring that part, but I figured the only reason to include this edit was to say "that isn't true, but if it were true, then it would be OK." (Otherwise, what's the point? There's no more complete refutation needed of a false point than that it is false.) My argument is that, if it were true, then that wouldn't be OK, even if you need a cloud-based identity, and even if iCloud is the best one.

But you're not forced. You completely ignored the other response in order to continue grinding an axe.

I can neither repair nor upgrade my electric car, my furniture, or my plumbing. But they all still belong to me.

Apple taking your data privacy seriously seems a worthy exception to me. You're free to disagree, and buy an Android.

Same with server parts using HBM—won’t let me upgrade memory there either.

That said, the apple ssd situation is abysmal. At least with memory they have reasons.