hishnash

In much of the world the laws have not been updated to consider the possibility of rotating root keys to do data destruction. So if you are destroying it to comply with the law you commonly are looking at doing full physical destruction.

Most video decoders these days are not as fixed function as you might think. https://asahilinux.org/2024/01/fedora-asahi-new/#hardware-video-decode The HW itself, even the firmware, does not know how to decode any video. The instructions on how to decode the video are provided by use-space applications (the sys lib) when you call the apis to decode a video. There is a good reason for this, once you look into all the differnt permutations for a given video coded (including color formats etc) you very quickly sendup with a huge permutation of possible sequences of tasks, having dedicated HW pathways for all of these would take up a massive amount of silicon. Some other SOCs do the same but they do not have it on a co-prososor they have these units within the GPU or within the CPU (see intel cpus) and in those cases some of the compute is offloaded to the cpu or GPU (or cpu's vendor engines) were that is possible.

Not all HW decoding is equal, sometimes only a small fraction of the entier steam is HW accerated and the rest is done on the GPU or CPU/Vector units. On other systems the video decoder is a full seperate co-prososor with its own min OS and it is passed a point to the video data in memory and a program (set of instruction it its own private instruction set) that describes the decode and it does this providing the raw output to another memory address. The Power draw between these to approaches can be very different, (key part being if you have a seperate video decoder co-prossors the main cpu cores can call go to sleep for most of the time with the decoder providing raw frame data to the GPU or even directly to the display controller meaning the cpu only needs to wake up a single core for a tiny fraction of time on each frame. Of course the downside of this is die area. The power draw of running the raw CPU decode is huge (even for a lower bit rate 480p) compared to a dedicated decoder.

With SSDs unless there is a root encryption key that can be re-set to a new random value the BIOS SSD wipe does not destroy all the data and it can be recovered by a data recovery lab. (on PC many of the root keys can't be fully rotated you can change the user-portion but if someone has a backup of this then they can still decrypt the data, root keys need to be private and need to never leave the device sec enclave to be considered as a method for whipping the drive). The reason lots of companies now insets of full device distraction is they do not trust the recyclers (or the sub-cotnracter that the recyclers will use) to bother even with un-screwing it and standing or shrewd the M.2... There have been to many cases of companies just not doing what they said they would do in the contract or sub-contracting to someone else to do this and not checking up on it. This is no considered so common that it would not be a legal defence in court to if data leaked that was under a protected status. You need documented evidence of destruction and best to also have a witness who can testify that they were there when it was shredded. The laws need to be updated such that if there is a cyrptogrphicly signed report of the root key being rotated then this is evidence. Then we could put pressure on vendors like apple to provide this feature to DFU reset mode such that the sec-enclave could sign this when it re-sets the key and provide it as a report or even upload it to apples servers so that anyone with the SN can validate the time and date that the device was fully wiped. But currently in most of the world the laws around data destruction (think schools with child data) are such that this is considered a grey area by lawyers and your advised to just destroy it.

It is a crime for them to break a contract, if they were paid to shred and then recycling raw materials then it is a crime if they break that contract and do not shread. Why do lots of companies insist on used phones (and other tec) being shredded? Well the laws about data destruction are very badly written, while we can re-set the root encryption key making it impossible to retrieve existing data most laws about data retention do not consider this one explicit permitted method, many talk about full physical destruction. This is why most companies and schools etc will pay a recycling company to shred the phones, I have envelopes seen companies pay to have perfect working (just 2 year old OLED high end TVs) destroyed since the liability that someone gets them then someone (through burn in or other methods) extracts even a single line of text is not something your avg IT manager wants to take. Those companies ands schools would love to just sell these phones to a recycler but they would only every dream of doing this if there was a clear legal easy pathway to absolve them of any legal resposiblty for the enviable data breach when someone forgets to properly wipe them. Many companies require the recycling firm to turn up on site with a shredder and then have a staff member witness the shredding as they no longer trust the recycling firms to properly destroy them and there have been multiple instances of company HW (including medical and even defence contractors data) ending up in devices being re-sold. As an IT manager for some of these companies you might even end up in jail if you did not take the needed steps to ensure the data was destroyed (the corporate protection does not apply to medical, child or defence data in most of the world). Companies would be more than happy to click the single button in MDM to release the find my locks, (and get some payment form the recyclers or at least not need to pay them as they currently do) on all they reyclinged devices if this did not increase the chance the they recyclers just lie to them and sell them on as is whiteout wiping the data.

The reason memory is soldered on the M* chip lines is the same it is soldered on a PCIe dGPU... bandwidth in addition to saving power. Soldering SSD will be about power draw.

This is exactly what the press release is, you can know use parts from other device (so long as those devices are not iCloud locked). The fact that apple keep the calibration profiles servers side rather than embedding them on the parts is the protection against this. The change in this press release has nothing at all to do with that. Apple considers any iPhone that is iCloud locked as not being authorised to be used for parts. This is very clear. I really don't get what your issue with this is? Under the new rules apples calibration database servers will provide calibration profiles for: * New OEM parts from apple (that thus have not been paired do any SOC yet) * Use used parts from another apple product so long as the product is not iCloud locked (thus transferring the lock to the new device) --- Third party parts, or parts that fall of the production line, QA rejections etc do not have calibration profiles stored in apples servers so its rather impossible for these servers to provide said calibration, and it would be extremely odd for any OEM to do this even if they had the profiles. It is a completely seperate question as it if apple should document the calibration profile formats and provide a method (over USB diagnostic DFU to provide them to the phone so that third parties could make and provide profiles). But such a method would never permit QA rejects or stolen parts either but only light third party OEM parts.

If your a store your not going to be buying stolen parts directly from thieves your going to be buying them in large shipment from re-sellers. It is already the case that many of them get court up being part that pretend to be OEM but are not so completely feasible that if it were possible to re-use stolen parts they would also be buying shipments containing stolen parts. Currently there is no market for stolen iPhone parts as you cant use them as assemblies (you need to spend a LOT on breaking down to raw panels), but if you could there would be a good bit of value in stealing an iPhone and selling it for parts, when you look at the cost of a display assembly or a main camera assembly there is a lot of value there and if your a gang that can capture 100 to 1000 phones a day in a city this would be a very nice source of revenue (back before device locking was a thing there were many street gangs epxliclty targeting early smart phones due to the high value, small size, and rapid snatch and grab low risk mechanic). Stealing a car takes a LOT more skill and is much riskier (with lots of the world have dedicated laws around auto-theft and entire police departments focused on this).. snacking phones from people as they walk down the street is tribal and very low risk. --- I don't see the issue with stopping the use of stolen parts.

This is about selling parts from stolen devices.

No you cant do that.

You can read the change yourself, it has nothing at all to do with apple repair partners. However it is not going to have a big impact on component level board repair that vendors like Rossman group. Boar level repair does not benefit from these changes at all. These changes are all about doing component assembly level repair. Eg taking a full display assembly from a water damaged phone and using it on a phone that has a broken screen. This is low-skill/no-skill repair jobs, if you a vendor like Loius you likly have a de-lamantion and re-lamnation machine that would let you remove the broken glass from a display assembly, and re-attach new glass to the original. So this change that will open up a load of used displays, camera modules etc might well be back thing for him economically as the price he can charge for doing a board level repair will go down as he is no longer competing with users that must buy a new parts assembly. It stops the display, camera and battery from being re-used on a stolen device. The display and battery of a modern smart phone is 1/2 of the production cost (if not more).

It used to be the case that parts were more or less the same as they came of the factory production line so did not need per unit calibration to work. These days (with OLED and modern smart phone cameras etc) if you just take the raw output from a factory and attach to to a chip you will in most cases have a very very poor quality display and camera as it is full of defects. (I would be surprised if any OLED display ever made was fully defect free) so you have per pixel (per brightness) calibration profiles crated in the factory for each display etc to mitigate these defects so that you can use the HW that comes of the production line. If your buying a generic part (like many mid range android phones) this calibration profile it typicly stored on the display controler chipset that is sodlred to the display assembly. So swapping displays is not an issue as the HW comes with its profile, but for semi custom and fully custom productions were much of that logic moves onto the SOC (for power and cost savings) it has been proven simpler to just store these profiles servers side and have a diagsntic mode that the SOC boots into to fetch them from a server.

iCloud locked to an account other than the account attempting to pair the part to a new SOC.

It has always been based on calibration profiles,. the SN binding was done sever side when a device requests the profile the server would only provide the profile if the part has not been connected to another SOC. This change is just a server side change that now will check if the currently assigned SOC is iCloud locked and if not it will re-assigne the part to the new SOC and provide the profile. Again this change is not about new parts but about used part. The reason for that is that these stolen parts are of very low value as you cant sell them as repayment parts. A stolen iPhone screen will not get you much at all as it is e-wast. The metal case for the phone (if it is not scratched up) will likly get you more money.

From reading through the rule change to me it reads as if this only applies to the mini app category. That means you cant load games from disk to run etc. All mini-apps much come from the app developer and they must have the rights to them. So this rule change will let catalog vendors like those that created legal mini consoles publish apps that continue 100s of old titles but it will not let community emulators be on the App Store letting you load your own disk images.