Fidonet127

maltz said:

Fidonet127 said:

There is only so much power you can pull out of a car outlet.

Your math is correct, but I'm not sure why you reach the conclusion that this device might be a problem.  These power outlets are capable of 15-20A in any relatively modern car I've seen, which is actually closer to 200-275W when the engine/alternator is running (~14v), again, not accounting for conversion losses.  Even at 10A, that would probably be enough to fully power this device, though it might be borderline when the engine isn't running.  But charging/running a laptop at 100W with the engine off probably isn't a great idea in the first place.

avon b7 said:

Fidonet127 said:

avon b7 said:

Fidonet127 said:

avon b7 said:

lkrupp said:

Wait. What? Ohh, I thought this was a current exploit. My bad. But this should end the argument over whether Apple should allow users to downgrade iOS versions, whether Apple should should be so aggressive in promoting upgrades to the latest versions, and end the “planned obsolescence” claims. But we all know it won’t so whatever.

What? Just fix the problem in the same lineage it exists in! 

Have you ever considered the fact that yearly major updates are part of the problem? 

Have you considered major yearly updates are part of the solution? Some people assume yearly major updates are part of the problem without any evidence. Look at Windows 10, had none of what people consider major updates, yet some of those minor updates caused major issues. Windows 10 has had printer issues after updates. The March 2023 mandatory security update has caused blue screen of death and performance issues. With major updates, users expect changes that will likely cause problems and minor updates could but should not cause problems. With major updates, Apple has the opportunity to dump old code, enact new security and privacy methods that would be too drastic for point updates. Another example, been trying to get the manufacture of my favorite game to support Macs better by moving to Metal and when ASi Macs came out, support native ASi code. They supported iPads and iPhones, so it wouldn't be that heavy lift. Then one day they came out with a point update that used Metal and ASi native code, trouble was they dropped support for previous Mac OS versions that didn't support ASi Macs. So you had people who bought that major version of the game, who can run Metal apps on their Mac, and the easier versions of that major release, but not the latest versions of that major release because they couldn't run the newest versions of Mac OS. It was a weird situation, however they have a new major version, which makes it clearer. Major versions bring in the funds and the excitement. Minor versions do not.

There is little to consider. 

We are talking major, zero click exploits here. They should be fixed within the same lineage. They are bugs after all. 

Major updates on a yearly cycle are beyond most companies. They introduce deadlines that cannot be met reasonably. Apple is no exception and code quality has probably suffered badly over the last decade even with the improvements. Only Apple can know for sure but external evidence points to some very buggy iOS releases.

Trying to flip the tortilla by saying it allows Apple to eliminate crud doesn't resolve the problem. 

I've seen some drafts from the EU which cover software support in an upcoming directive. If approved as is, device manufacturers will have to state on the box how long software support will be and the EU will set a minimum. Software/firmware updates that add new functionality will be user reversible as will updates that reduce performance. 

It's worth pointing out that in terms of security updates Apple is pretty good at getting solutions out but making them part of major updates has always been a problem. It is by definition because major updates introduce major plumbing changes. Apple also took way too long to introduce bug bounty programmes. 

Your rant has nothing to do with this bug. You keep saying bugs should be fixed within the same linages, yet this bug only was only confirmed with the 14.4 series of iOS and suspected of other versions. This spyware was only confirmed infecting between January and November of 2021. 14.5 had fixes for root level exploits. 14.8 had a fix for the Pegasus spyware exploit. Where is the evidence that this wasn’t fixed in the same linage? Apple does security point updates, not just for the current major version but several previous versions also, not all but some. Moreover, the current version has a mechanism to implement quick security updates. You keep saying major yearly updates are the problem and yet you conclude only Apple really knows. Sticking with point updates for a bit is no guarantee of fixing bugs. What deadline was Microsoft up against that caused them to BSOD and performance issues in March 2023? Apple has delayed major releases due to bugs. Yet Apple still has to release new software to enable new hardware. People expect new major software updates. I buy a new iPhone, I expect so many years of major updates. It is precisely those major plumbing updates that allow Apple to introduce new security and privacy features and cut the crud. This is a benefit as well as a curse. 

 Getting rid of crud is a major improvement, not a minor. There has been many bugs that have been exploited due to old software, even old open source software. Part of the problem is old software was built with old tools that didn’t enforce variable types and other methods that reduce potential problems which increases security. People didn’t program with an eye toward security as much. People didn’t think of security as much so long ago. 

It doesn't matter when bugs are confirmed. That is irrelevant. Once discovered, they are applicable going back in lineage until such a point where they are not applicable. 

Implying 'I don't know for sure how buggy Apple’s coding is so I can't have a relevant opinion' doesn't alter what I am saying. 

Major yearly updates are definitely part of the problem. Complexity is another. From API's, general frameworks, compilers, security etc. 

ALL security frameworks are based off decades old security models. I'm not sure why you say people didn't code with an eye for security. Operating systems have had security as a major foundational objective for years. App development using OS APIs can have bugs but at worst you know they should not impact security at a deeper level. We obviously understand that bugs can punch big holes into security but uninstalling an app is easy. That isn't really possible at OS level. 

The shorter the development process, the more likely bugs will be present. The development process itself is a balancing act of bugs vs usability, threat vs risk, cost vs performance etc.

I haven't seen Apple’s security model so I don't know what goals or level of certification it aspires to but for modern operating systems we can consider that basically moot unless they actually have a formal design review and testing process as part of it. That is unlikely given the outward facing nature of its operating systems in the consumer realm. I imagine Apple aspires to something like B2/EAL-5.

Software gets released with 'known issues' as a result. It is also released with unknown issues, some of them are potentially disastrous for security. Lack of development time (pushed by deadlines) means lack of testing, lack of security research etc. 

Yes, there are trade-offs involved in bringing software to market but zero click security issues should always be fixed on the original lineage and the mere suggestion of fixing something as part of a major upgrade should be scoffed at. Yes, that is only my opinion. 

The problem is that with yearly major update cycles there is a huge reason to do just that.