Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

People aren't going to like me for saying it but this article is right more than it's wrong. I was a provider of paid, private alternatives to ad-driven services. There were tons of us in late 90's and many in early 2000's. Almost all that didn't switch to ads went bankrupt. Customers seemed to universally want more content/service/everything... for free (or near-free)... while being OK with being spied on & sold out. They also got what they asked for: more articles, games, search, socializing, videos, and so on than have existed in all of history. Huge benefits willingly obtained by giving up privacy and control to anonymous, greedy organizations at a cost they didn't [and mostly still don't] care to think about.

Apple, on the other hand, was fine with lying to customers about security ("immune to malware!"), building leaky clouds, suing those that put Mac OS on cheaper hardware, locking in users with software toolchain choices, keeping low income users out due to high prices, discriminating against competitors in App Store, and even charging for updates. On top of that, despite tens of billions in profit, they also sold customers out to advertisers. They are one of the least trustworthy companies in existence for privacy-conscious individuals.

So, Tim Cook is full of shit. Apple has enough profit to build inherently private/secure OS's, toolchains, and services. This is obvious given that small to midsized firms with a tiny fraction of the money have outdone Apple in many areas of privacy and security by simply putting in effort. Most likely, Tim Cook is merely doing P.R. work to position Apple's image (not reality) as more trustworthy compared to ad-driven services. Those services can't do this because they'd go bankrupt by not invading privacy.

So, let's rehash. Users have more cool and useful stuff than ever before due to ad-driven model. Users got there by repeatedly choosing to be spied on instead of paying or investing time in a private alternative. Apple's past and current track record on privacy/security are terrible. They also do advertising, although not dependent like competition. Apple's CEO says they believe in privacy/security despite them hardly practicing it. Conclusion: our situation is the from users' demand, their massive use of such services maintains our situation, a niche want private alternatives, and Apple is doing PR to make money off those people (while still selling them out).

Capitalism in action! ;)



> Apple has enough profit to build inherently private/secure OS's, toolchains, and services.

That does rather imply that such a thing is possible and the entire history of computer science would indicate that it isn't (yet.)


There's been many examples in the past enforcing specific types of properties or immune to entire classes of attack. A few survived years of NSA pentesting. I'll give a simple example: Burrough's 1961 product with a tag on memory words. One bit said it's a pointer that processor hardware protects against forgery or improper modification. Array's were bounds-checked by hardware. One bit said something is code, execute but don't modify, enforced by processor. Function calls arguments were validated by compiler during installation and hardware during procedure call. This combination makes almost every code injection attack I've ever heard of fail while using very little hardware overhead. One exception to overhead is runtime procedure checks. Leave it out & you still knocked out almost every way to take over systems with software vulnerabilities.

There's dozens of designs doing similar things in academic literature, on the web (see crash-safe.org or Cambrige's CHERI), in government (see Sandia Secure Processor), and even commercial (see CodeSEAL architecture). Yet, the tiniest modifications (pointer/array/code protection) would give attackers considerable headaches. This must be integrated with other security methods, of course, along with toolchains (esp compilers) modified to use it and any custom software (esp assembler) modified to use it. Those changes are well within Apple's budget. They also bought an ARM license and a fab deal, meaning they can do the hardware mod.

At this point, there's no excuse for our machines to be vulnerable to pointer, buffer, or memory-based attacks given 1960's technology was immune to these by design. And we could adopt such methods relatively inexpensive today. And academic prototypes running FreeBSD and Linux only cost a few mil versus Apple's tens of billions available. Yes, it has been done, can be done, and is simply not done as usual.


> I'll give a simple example: Burrough's 1961 product

But the key there is "simple" - I imagine that's a tiny fraction of the size and complexity of a modern smartphone ecosystem. Scaling it up to a device that can be manufactured at a profit and will sell hundreds of millions is surely more involved than "we could adopt such methods relatively inexpensive today".


That was a mainframe, actually. They're quite complex. The mechanism is simple. I have designs that apply it to a smartphone by a tiny change to the processor and its I/O system. Far as the hardware, that's it. For the software, the C (or Objective-C) compiler just has to use the appropriate tags or instructions when generating the binary. Any hand-written assembler, a tiny portion of the program, must do the same. That's it for the pointer & code protection. On a smartphone, this is the main SOC, drivers, part of the compiler, and any assembler functions. That's it.

There's no need to speculate, though. Several academic projects involving a few amateurs with six to seven digit funding have (a) modified processors for security, (b) modified toolchain to support it, and (c) ported BSD/Linux to it. Others did it for embedded systems. Their schemes are usually much more complex (see Cambrige CHERI processor). Unrealistic to think Apple can't do with 9+ digits less than what academics do with 6-7.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: