It's the same never-ending war as anti-cheat vs cheat.
Another example: my grandma doesn’t have WiFi, and I bought her an iPhone, but iOS updates can’t be done on 4G, which can only be bypassed by internet-tethering a computer (which she doesn’t have), downloading the full IPSW, and installing it. She was on iOS 14.0 until 2 weeks ago when I fixed it. And with Safari being, according to security researchers, much less secure than Chrome, that makes me shudder. This isn’t an “anecdote” or an edge case, not everyone lives in a developed country and millions are just like my grandma, and Apple’s poor security design leaves her vulnerable for zero good technical reason, where Android wouldn’t. (They just dropped Google Play Services support for Jelly Bean a few months ago, so even an old Android phone would be reasonably secure). Caring about security requires thinking of details like this.
Print Nightmare was part of a risky call in the printing subsystem design which was recognized as such when they made it in the 90s. That specific vulnerability was disclosed to Microsoft in 2020, accidentally disclosed in public in June, flailed at with incomplete patches and bad documentation all summer while ransomware gangs exploited it, and has theoretically finally been patched in the September release following multiple incomplete patches.
The Exchange auto discover bug announced yesterday had previously been reported with Microsoft telling the reporter that it wasn’t a bug. Oops.
This is hard but it’s also important to remember that this is an industry-wide failure because it’s been cheaper to clean afterwards than invest in proactive cleanup of old “stable” code, and it will likely continue as long as there are no financial consequences for a breach. Adding consequences would change that dynamic but would also be a massive change to the industry. It could endanger open source and would almost certainly make everything more expensive.
Ransomware has already changed this somewhat: now the cost is halting operations for a potentially lengthy period of time, and that has spurred a lot more awareness that the current model is insufficient but not from what I've seen significant efforts to change it.
Having attempted (unsuccessfully) to write a resumable HTTP/HTTPS downloader, which is what I suspect nsurlsessiond is using behind the scenes - it's really hard to get it right. Meanwhile I expect to be able to start a BitTorrent download, throw the laptop down the stairs, take out the hard drive and be able to successfully resume it on a different computer because that's a protocol that was actually designed for it.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requ...
And if they need to get more clever than that, why not have a BitTorrent-like map of chunk hashes. So you download the update, check the hash of the whole thing and if it fails the hash check, download the chunk hashes which will be say a 256 bit hash for every individual 32 MB chunk of the file. And for any chunk that fails the hash check, use a HTTP range request to download it again.
We are pretty heavy Internet users at home (Starlink), but the cell plan is 2GB per month, shared between me and my wife. We rarely overrun that.
I think that there are a lot of retired people with small phone plans and no WiFi. All they do is a few phone calls and a bit of email with the family. So, updating those phones frequently is problematic. They probably take them to the phone store where they bought them.
Tech workers have difficulty taking into consideration lifestyles they don't know exist, which is understandable. At the end of the day this comes as another consequence of the lack of diversity in tech, I guess.
All these groups have different needs and expectations to the products they buy or lease. And development teams and their business cannot expect to understand that by having a more diverse development team. They have to do better requirements engineering, they have to listen better to their customers and they have to decide and prioritize those needs and expectations. E.g. A/B testing has abysmal consequences for the needs and expectations of minorities.
We are in the B2B/B2EDU space so the "As a grandmother, I think..." line of thought does not apply. However, she has frequently had insights and observations that none of us would have come up with. Once implemented, they have been very successful/profitable.
So yes, absolutely, unless your company wants to be in a very specific niche, the lack of true diversity in your company is a drag on your success.
PS - my grandfather had a tech job in Sunnyvale. He passed away last year at the age of 92. Point is - everyone alive has lived in a world with pervasive technology and computing. "They're old and can't understand this stuff" is pure BS.
> However, she has frequently had insights and observations that none of us would have come up with
> So yes, absolutely, unless your company wants to be in a very specific niche, the lack of true diversity in your company is a drag on your success.
The conclusion you are drawing here, does not follow from your two observations above. The fact that your product manager has had insights, that nobody else had in team, does not mean a "lack of true diversity in your company is a drag on your success." Some diversity may help in certain situations and in others not. The above mentioned insights and observations might just be the result of competence and more experience of the product manager or incompetence of the rest of the team. There may be many other reasons. We don't know. We have one observation and should refrain from generalizing. That this is because of more diversity is just a speculation. A speculation that fits an often repeated narrative, but that doesn't make it a logical conclusion.
Once you have that you create a user journey map for each of those personas - in this case they need a user journey map for updating. Your test teams then have to take each persona and run through testing with those constraints and capabilities in mind.
They don't have a high-speed network or are using a cellular network? One or more personas should have accounted for that. Color blind? One or more personas should have accounted for that and there's software available that can make your screen as it appears to those who are colorblind.
These personas should be corporate-wide - these are your customers after all. I would be shocked if Apple isn't doing something like this, but then again, after getting a glimpse at how the sausage is made I've come to the conclusion Big Tech isn't any better at creating and testing software (well, not that much better) than anyone else.
Before Apple or any other customer company describes personas, there is an explicit or implicit decision of which personas to consider and which not. But most consumer targeted companies hide which personas they consider and which not.
When I mentioned diversity, what I actually had in mind was that all tech workers in California have wifi, and probably find this so normal to connect your phone to wifi that they expect any normal user will do this on a daily basis.
I'm not a grandma but I'm a tech worker with a very different life style. Like the person I was replying to's grandma, I have no wifi. Like her, I have to fake it from time to time so that my Android phone will backup photos, accept to download Google drive documents, etc.
So the diversity I had in mind is rather a diversity in location and lifestyle.
You may love cars. You might think Tesla’s are amazing. But if you live on a small island without an electrical grid, it might not be the car for you just because it doesn’t come with its own solar panels.
I think its more a legacy thing, when iPhones first came out this made somewhat sense, to spare the mobile networks the load.
If you have a 5G iPhone you can set it to download updates over 5G but its just plain stupid you can't do it over 4G. Over 2G or 3G it makes a little bit sense.
but then u not need to read it. and who would given all the exquisite experiences with M$ and/or Goo compared to nightmares Apple delivers to u, overpriced, ofc
in a sense it is good reading tho after all in that it indicates that exactly those are not the one's one does meet in Apple-communities
If Apple really cared, it would have changed this scenario by now. A 7year old android device which can download/sideload latest Firefox is technically more secure for web browsing than an latest iOS device which is yet to receive an OS update with the critical patch for the Safari.
But as Tim Cook proudly claims, People who use Apple products are those 'don't want to take risky decisions themselves' maybe they'd be willing to wait for that OS update however long it takes.
Written five years ago but sadly still relevant: https://steveblank.com/2016/10/24/why-tim-cook-is-steve-ball...
> This isn’t an “anecdote” or an edge case, not everyone lives in a developed country and millions are just like my grandma
In too many countries, mobile data is incredibly expensive. If Apple were to allow over-the-air OS updates, you can bet it would take only a week until the first class-action lawsuit by people having their data caps blown through because they did not understand that updates are huge.
They don't see a need for a modem hooked to a wired line necessitating a second subscription and procedures to follow when you move apartments, when in any case you will have a 4G connection that follows you around on your smartphone.
Is there a better way than providing a wifi hotspot with your mobile phone?
I hear that Android lets you enable updates-over-4G, but allows carriers to block the feature. That's detestable! Surely, if I pay for data, I should be able to use it for anything (legal) I deem important? I don't like corporations making those decisions for me.
I'm German, and ... wtf, I'm envious. We have three carriers: O2 (which is cheap, but their network is horrible), Vodafone (which is expensive, has a good network, and is constantly plagued by issues with its customer service) and Telekom (expensive, good network and decent customer service).
Telekom's cheapest plan is 40€ a month which has 6GB, and the biggest plan before flat-rate (at 85€) is 24 GB for 60€ a month...
14 GB for 13€ (https://www.handyvertrag.de - it's a brand of Drillish, reseller of the O2/Telefónica/E-Plus network)
40 GB for 19€ (https://bestellung.vitrado.de/offer/index/2b5pv1)
Your comment seems to be implying that Apple could simply ship the delta in the source code: i.e. something like `git diff --minimal --word-diff=porcelain head^1`. Would this not require iOS to be compiled on the device, and store its own source code, à la `.git`? How would you address the issue of the compiler itself needing to be updated as part of this process?
Or are you suggesting they would ship the diff for the binary? For one, I don't think the delta in the resulting binary would be as small as the delta in the source, due to addresses changing, etc. There are tools like bsdiff which can 'intelligently' handle this, but I believe they aren't widely used for operating system updates, as opposed to standard userspace binaries.
In addition to this, the diff shipped would be relative to whatever version the device is currently using, which would necessitate storing a very large number of diffs, especially for binaries, or else computing it on the fly (which simply shifts the burden from disk space to CPU cycles).
Or have I misunderstood you entirely?
In particular, bsdiff has been around for a very long time and is an industry standard binary diffing tool.
Indeed, Apple used to distribute patches this way in the past.
You also could ship a list of updated system files hashes, compare to the installed files and just download the changed ones, like rsync.
Better than shipping a whole new disk image every small update they do.
It's the same lazy dev culture that gives us Electron apps, or the lazy sysadmin culture that gives us docker.
It's cheaper to create massive incomprehensible and unmaintainable edifice that requires massive storage / processor / network inefficiency to maintain versus well thought-out and "clever" systems that work efficiently.
Personally, I wish the days of optimizing for low-resource machines, slow network connections, and expensive storage weren't gone. As an end-user I think the results of moving away from a culture of optimization haven't been good. I think the ship has sailed, though.
The reason Apple doesn’t is because they like to ship updates as bootable disk images. This makes it easier to roll back from than an in—place update, since you can just boot the old image if the update fails.
Sure, there are always going to be problems you miss. I can forgive them shipping with zero-days, it happens. Failing to respond to reports is just that: failing.
In case there is any confusion, there has been at least one of those a year for the past 3 years.
It’s extremely common for an attacker to find a way to exploit a maliciously crafted image. Take a look at libpng, https://www.cvedetails.com/vulnerability-list/vendor_id-7294...
This is hard for me to believe for a company the size of Apple. They were recently the wealthiest company on the planet and are worth over a trillion dollars IIRC. They could slow down their software development process, focus less on adding new features, and prioritize fewer security holes. It seems like such a huge risk to them that their devices are basically always vulnerable. But the general public never really hear about these 0-days so they may have some ability to ignore the problem.
The cynic in me imagines that someone at Apple knows about these bugs and they are shared with spooks for exploitation. One could imagine that even for a responsible disclosure program, they could share details of every new vulnerability with some three letter agency who could have months of use out of them before a patch is finally released.
My inner cynic¹ has a slightly different take on that: You don't get to be the wealthiest company on the planet by doing the right thing at the expense of the profitable things.
¹ He says, pretending it isn't also his outer and all-consuming cynic!
Or at least that's what I just realized.
I've had this conversation too many times. Security isn't hard, it's just that nobody has respect for it. The guy who understands software security isn't getting the respect he deserves. The situation is so bad, some companies are literally hiring people who know the equivalent of script kiddie "penetration-testing".
Pay security engineers enough and listen very carefully to what they have to say. Literally the only companies who seem to understand this basic concept seem to be the intelligence agencies, and a few other high profile companies.
I think it’s less about disclosure handling but more about being motivated to pay for or build a black magic code analysis tools.
I don't believe that. Making perfectly secure software at large scale is indeed very hard, but a lot of security issues we see every day have little to do with lack of perfection. There's a ton of low hanging fruit out there.
> The junior to senior developers are just using existing frameworks with poor documentation.
Yes, I do believe that the modern way of quickly ducktaping junk together while paying little attention to security does make for lots of security issues, which might give someone the impression that cybersecurity is ridiculously hard.
Security requires proactive effort. It's not ridiculously hard, but it needs to be done, it requires time (just as anything). Leaving it for "hope you don't write buggy code" and "does colleague notice the gaping hole in code review" is not doing security, it's just winging it.
And I've never really been asked to do security, even when literally working on a security product. Everyone just seems to assume security is an automatic byproduct of skilled programming, but it's not when the pressing concern is "how many hours/days/.. does it take to ship this new feature oh and we have three dozen other features that need to be implemented soon" and "can we get it sooner?" and "why is it taking so long, it's not that hard!"
It needs to be discussed, planned, designed, reviewed, tested, verified, questioned, audited. Just like anything else, if you want quality. None of this is ridiculously hard, but it needs to be done for it to be done. If it's not being done, it's that the organization doesn't care about it.
In a lot of ways it's similar to technical debt. Are you taking the time to avoid it, reduce it, get rid of it? No? Then you're accumulating it. Security issues accumulate just like technical debt when ignored. And even the most skilled programmers do generate technical debt (because they don't jump into a problem with perfect knowledge of what needs to be done). Depending on the organization, they may or may not get to fix it. Many organizations just don't care and would rather have the devs work on something "more productive."
Building secure software and building anti-cheat are nothing alike.
Anti-cheat is fundamentally impossible (on a true general purpose computer) because you’re building software that has to run in an environment where it can be dissected and modified.
Building a secure device (something which has to satisfy certain security properties for all inputs through a constrained API) is fundamentally possible. We’re just too lazy and cheap to do it. I don’t even think it’s “ridiculously hard” - we would just have to spend more money on correct by construction designs, formal methods, etc instead of spending money on flashy UIs and random features no one cares about.
The number of employees at Apple working on security is vanishingly small compared to the number of employees, say, working on random siri features. And the way they approach security in many apps is also wrong. Instead of having people with formal correctness backgrounds designing the APIs against which apps are built, they just have developers with no security background putting everything together and then have a few security people trying to pick up the pieces.
(1) We used safe languages like Go, Rust, C#, Java, and Swift instead of 1970s YOLO languages like C and C++.
(2) Our operating systems were designed from the ground up to be secure in a modern environment.
Unix (all flavors) and Windows were both built long before security was anywhere near as much of a concern as it is today. Their security posture is very lax by modern standards. Applications have a ton of permissions by default including seeing the whole network and filesystem. Everything runs with only basic memory isolation. Everything has access to an enormous system call surface area.
It is extremely hard to apply security in retrospect to an insecure system, especially a complex one with lots of legacy support requirements. You are going to be playing a whole lot of "whack a mole."
A modern secure OS would begin with the principle of least privilege and be built from the ground up to isolate applications as much as possible from anything they are not entitled to access.
Oddly enough the web browser might be the best attempt. When you browse the web you are basically swimming in malware, and you are relatively safe.
This is why I wonder why "minimize your data exposure" is such a controversial opinion.
Security is challenging, but there are lots of things we know how to do better that many software developers still aren't doing. For example, if you're still writing application-level software in an inherently dangerous programming language in 2021 and that application handles important data in a connected device, you're part of the problem. If you ship a networked hardware product with a standard password for all devices or forget to disable the backdoor access used during development, if you use encryption or hashing methods that are known to be weak, etc. These things obviously won't solve all security problems, but they are low-hanging fruit that is still being left on the tree far too often.
it’s more likely they’ve considered which security issues they’re personally concerned about and decided the other choices are as bad or worse.
once we actually dig into the specifics of an issue–especially one as complicated as personal threat models combined with actual usability–it’s rarely a “my device is now unhackable” cartoon caricature.
like you know, shitty performing algo can be always rewritten, leak or 0day cannot be reverted
even some of the sharpest security/privacy minds on the planet, who work for organizations who exist purely to make secure software or hardware stumble often.
now add in that we actually expect our devices to also be usable, and yes, security is very very _very_ difficult.
if someone hasn’t learned by now that every device will eventually be cracked, we should question their ability to reason.
now again, we should absolutely expect more from apple/google/$company than we do, but we also can’t hand-wave away that security is very hard.
Does anyone knows the technology stack Apple uses?