ragefury32 wrote on 2020-11-26, 23:02:

Soldered RAM and storage is getting common for the cheap laptops, crap chiclet keyboards are around, and TPMs are rolled out to prosumer machines like Lenovo Yogas or HP Envy/Spectres as well, and who knows what issues they might have.

Ironically, it's the most expensive and desirable laptops that are getting this treatment. The cheaper (and thicker) options still have RAM slots, some even come with HDD bays... combined with shitty plastics and terrible screens.

ShovelKnight wrote on 2020-11-26, 23:26:

ragefury32 wrote on 2020-11-26, 23:02:

Soldered RAM and storage is getting common for the cheap laptops, crap chiclet keyboards are around, and TPMs are rolled out to prosumer machines like Lenovo Yogas or HP Envy/Spectres as well, and who knows what issues they might have.

Ironically, it's the most expensive and desirable laptops that are getting this treatment. The cheaper (and thicker) options still have RAM slots, some even come with HDD bays... combined with shitty plastics and terrible screens.

I saw soldered down RAM and eMMC on the 300 dollar Thanksgiving-special Atom jobbies (cheap) and the expensive XPS13s (because thinness). At least Apple use aluminum in their chassis to resist minor dings and scratches.

The decade old CQ62 I just received is in great condition and relatively scratch free. It hadn't been jumped on like this 1 made by two unit I am posting this from and every thing is readily available and replaceable. It hadn't been jumped on like this monitorless one made by two CO62 Unit I am posting this from and every thing is easy to get hold of , easy to work on and replaceable. Being thick does have advantages.

Also great and readily available documentation. Being matte black is an advantage as well.

Caluser2000 wrote on 2020-11-27, 02:55:

The decade old CQ62 I just received is in great condition and relatively scratch free. It hadn't been jumped on like this 1 made by two unit I am posting this from and every thing is readily available and replaceable. It hadn't been jumped on like this monitorless one made by two CO62 Unit I am posting this from and every thing is easy to get hold of , easy to work on and replaceable. Being thick does have advantages.

Also great and readily aviabile documentation.

Yeah well, I can say the same thing about my 2010 MacBook Pro 13 (similar vintage, except I have a C2D/2.4GHz), and unlike later iterations, I have a pair of DDR3-1066 RAM slots (the nvidia MCP89 chipset can take up to 16GB), an optical drive, a standard SATA drive slot, removable battery, a large glass touchpad, an aluminum unibody chassis, and the whole thing can be easily taken apart and repaired - (nothing glued). iFixit already documented the crap out of it. It’s definitely a thicker machine than the later Retina MBPs, but there is such a thing as making the machines too thin.

Didn't those uni body units have cracking issues around screw mounts ? Or was that later on?

Caluser2000 wrote on 2020-11-27, 03:39:

Didn't those uni body units have cracking issues around screw mounts ? Or was that later on?

Eh, maybe on the polycarbonate models, but the aluminum Unibody models? I’ve never encountered it dealing with a fleet of 15 2009-2011 MBP13s, 40 MBP13/15 Retinas and 80 MBA13s from dating from 2010 to 2017 (mostly in the 2013-2017 Haswell/Broadwell models). It doesn’t mean it can’t happen - it’s just that I’ve never seen it in person. If anything I am more likely to see screws missing from chassis that were pushed apart via bloated/out gassed batteries rather than chassis mount damage. The usual modes of damage for the Unibody/MBP retina/MBAs were either LCD damage, component failures, battery outgassing or water spills - the machine themselves are actually fairly resilient to normal dings and minor drops.

ragefury32 wrote on 2020-11-27, 05:21:

Caluser2000 wrote on 2020-11-27, 03:39:

Didn't those uni body units have cracking issues around screw mounts ? Or was that later on?

Eh, maybe on the polycarbonate models, but the aluminum Unibody models? I’ve never encountered it dealing with a fleet of 15 2009-2011 MBP13s, 40 MBP13/15 Retinas and 80 MBA13s from dating from 2010 to 2017 (mostly in the 2013-2017 Haswell/Broadwell models). It doesn’t mean it can’t happen - it’s just that I’ve never seen it in person. If anything I am more likely to see screws missing from chassis that were pushed apart via bloated/out gassed batteries rather than chassis mount damage. The usual modes of damage for the Unibody/MBP retina/MBAs were either LCD damage, component failures, battery outgassing or water spills - the machine themselves are actually fairly resilient to normal dings and minor drops.

Cool thanks. Looks like it's may be possible to get a partner for my old Mas SE.

ragefury32 wrote on 2020-11-26, 23:02:

The T2 is known to do some really strange things - Ever since I witness a T2 on a Mac crap the bed and lose the ability to decrypt the APFS volume right before a major trade conference I had been less than complementary towards it. When you are asked to put all eggs in a single basket, you better make sure that the basket in question is sturdy, and Apple...does not extol that trait.

Do you have any idea what caused it to lose the ability to decrypt the volume? Could it have been user error or tampering during pre-flight inspection (assuming a flight to the trade-show)?

ragefury32 wrote on 2020-11-26, 23:02:

Let’s not kid ourselves - security by obscurity coupled with “trust us, we know what we are doing” does not scream confidence.

To me, that is an admission by Apple that they aren't sure they know what they're doing, or that they knew something was wrong with it, and they hoped nobody would notice or take the time to do the research. This reminds me of a leaked presentation from CSE (formerly CSEC) a few years ago that said something to the effect that "if it's an Android device, we can probably access its data. If it's an iPhone, we know we can access its data". So much for "what happens on iPhone stays on iPhone"; convincing marketing for those who don't know any better, and not much more than that. With Apple, it's barely security through obscurity, and more like security by marketing. First the "gotofail" embarrassment, now the T2 disaster, and who knows how many in between and yet to come. For a company that arrogant, you would at least expect them to try harder.

Lastly, before the Apple-faithful try to rush to their defence, I am not being unfairly critical of Apple. Firstly, they deserve the criticism, and secondly, it's only because this is the issue that was recently in the news. If/When Pluton suffers the same fate, I won't hesitate to start or participate in a discussion of that.

640K!enough wrote on 2020-11-28, 22:16:

Do you have any idea what caused it to lose the ability to decrypt the volume? Could it have been user error or tampering durin […]
Show full quote

ragefury32 wrote on 2020-11-26, 23:02:

The T2 is known to do some really strange things - Ever since I witness a T2 on a Mac crap the bed and lose the ability to decrypt the APFS volume right before a major trade conference I had been less than complementary towards it. When you are asked to put all eggs in a single basket, you better make sure that the basket in question is sturdy, and Apple...does not extol that trait.

Do you have any idea what caused it to lose the ability to decrypt the volume? Could it have been user error or tampering during pre-flight inspection (assuming a flight to the trade-show)?

ragefury32 wrote on 2020-11-26, 23:02:

Let’s not kid ourselves - security by obscurity coupled with “trust us, we know what we are doing” does not scream confidence.

To me, that is an admission by Apple that they aren't sure they know what they're doing, or that they knew something was wrong with it, and they hoped nobody would notice or take the time to do the research. This reminds me of a leaked presentation from CSE (formerly CSEC) a few years ago that said something to the effect that "if it's an Android device, we can probably access its data. If it's an iPhone, we know we can access its data". So much for "what happens on iPhone stays on iPhone"; convincing marketing for those who don't know any better, and not much more than that. With Apple, it's barely security through obscurity, and more like security by marketing. First the "gotofail" embarrassment, now the T2 disaster, and who knows how many in between and yet to come. For a company that arrogant, you would at least expect them to try harder.

Lastly, before the Apple-faithful try to rush to their defence, I am not being unfairly critical of Apple. Firstly, they deserve the criticism, and secondly, it's only because this is the issue that was recently in the news. If/When Pluton suffers the same fate, I won't hesitate to start or participate in a discussion of that.

If I have to point fingers - the end user was supposedly doing a MacOS upgrade (which can include firmware updates) when the T2 freaked out - either:

a) The end user did the update unsupervised and didn't plug the machine in, the battery ran down, and this somehow that messed up the T2.

b) The machine was bound to onprem ActiveDirectory with a mobile profile, but the user was traveling and not synching back to the domain controller regularly via VPN, so the FileVault password is likely desynchronized between the cached one, the AD copy and the previous AD copy. AD/LDAP binded machines have been problematic with MacOS ever since High Sierra due to subsystem changes Apple made. The password might’ve simply have been forgotten, although the fact that I also couldn’t get into the admin account on the machine was also a bit...troubling. I didn't really care enough to investigate too far. I dispatched a spare, the end user sent the busted machine back to me, I sent it to my AppleCare guy to see if there's a hardware fault (they can't find any), and once it's cleared up I recovered as much as I can and handed it back out.

I do not trust the T2 chip entirely, but that's more based on its nature as a single point of failure for multiple systems, and how it sits in a chain of trust. Basing your current security scheme off old silicon and making it difficult/impossible to patch it was just hubris. Just imagine what happens if the MS Surface Pro uses the SoC from a Zune music player to implement its security enclave...

Let’s not forget that while the Apple haters had a field day with gotofail (which dates back to Mountain Lion/Mavericks 6 years ago) there was a very similar GnuTLS slip-up involving dead code (CVE-2014-0092) - both of them involving a duplicated goto state that caused the goto conditions to be executed by default rendering checks redundant.

Apple GotoFail:
https://www.synopsys.com/blogs/software-secur … ulnerability-2/

GnuTLS GotoFail (read the patch file for an idea of what happened):
https://www.openembedded.org/pipermail/openem … rch/208670.html

Note that Apple had one condition bypassed with a duplicate goto statement - GnuTLS had 3.

The GnuTLS issue impacted nearly every Linux distribution out there in early 2014 (RHEL/CentOS 5/6, Debian 6/7 and other similar distress) and I had to scramble to get production servers patched. In my mind, that's even more of a screwup. In both cases the code is open source and the issue was quickly found and fixed.