This does not help at all for the drubbing that macOS High Sierra has been getting recently. Long term OS X users have been waiting for a Snow Leopard like release, but it seems like Apple isn’t taking as much care as required on security and stability on the Mac. Something has to give — either Apple’s organizational structure needs a change or Apple needs to abandon certain things completely instead of releasing sub-standard products that aren’t expected from it.
As a long time Mac user, I keep hoping that Apple will decide to double down on better and deeper focus on all its products, including the Mac, its OS and ecosystem, and make the changes necessary across its organization and its teams.
> it seems like Apple isn’t taking as much care as required on security and stability on the Mac
It's even worse than that according to[0] Mark Gurman[1]:
In another sign that the company has prioritized the iPhone, Apple re-organized its software engineering department so there's no longer a dedicated Mac operating system team. There is now just one team, and most of the engineers are iOS first, giving the people working on the iPhone and iPad more power.
> "there's no longer a dedicated Mac operating system team"
That took some time for me to sink in. I can fully understand the aversion towards dedicated teams á la Jobs, but we are talking about an OS that is used keenly by developers, an ecosystem essential to maintain. I was baffled by Apple not pushing ZFS further, the clear lack of interest in developers by not working on e.g. virtualisation, e.g. containers, a polished OpenSolaris or similar with tools we could make MacOS even greater. Like they couldn't afford it.
Under a different lens, that implies that previously iOS-only engineers now must also become familiar with the macOS codebase, and so more able to contribute to it. Given the large number of those engineers compared to the previous size of the macOS team, this may help more than hurt macOS (as long as you assume the engineering teams are of equivalent quality.)
While it's tolerable to have engineers jumping between projects in, say, web frontend, I'd imagine that operating system security work is incredibly sensitive to programmer context-switching - you can't dive deep into the security model of a desktop system in your 20% time when you're working with an entirely different system (with a different CPU architecture) in your 80% time. Of course there will be some specialization on this team, but it doesn't seem to be nearly enough. Unfortunately, it will take something like a botched release (not just a security problem) and heads rolling to reverse this trend.
Not sure if you're familiar with how iOS/OSX works.
For the Darwin team which is the actual core OS they would have to deal a lot with CPU architectures. But they again they have always dealt with this since back in the NeXT days. ARM and x86 isn't a big deal to manage and there isn't much evidence that something is wrong in that area.
For the UI teams i.e. System Frameworks, Cocoa, WindowServer etc. They are abstracted away from worrying about CPU architectures and they are the ones responsible for all the bugs we are seeing today. You can argue context switching is an issue here but again we don't have much visibility that iOS/OSX engineers are jumping back and forth every day.
A few years ago there was a noticeable increase in the frequency of point updates at the expense of quality. In agile, testing either (a) relies heavily on automation or (b) only tests that particular story. In highly complex systems that's often not sufficient and rarely do security teams for example involve themselves on a per story basis.
Personally I think the industry as a whole needs to sit back and realise that Agile wasn't the panacea it was made out to be.
Most of the codebases of both iOS and macOS are fundamentally the same kind of (low-level but architecture-independent C and Objective-C) code, and encouraging team unification will make that even more true—if the same people are working on both AppKit and UIKit, for example, it's a no-brainer to unify them rather than maintaining that duplication.
The exception is the kernels and drivers of each OS, which have to consider things like architecture, but I would expect that it'll still be the same individual engineers working on these who always have, no matter what their team structure looks like now. Whether or not Apple has a formal "macOS kernel team" or "iOS kernel team", those groups definitely exist and have rather static membership.
(In fact, one main benefit you might see from this is that Apple has hardware hires—many from Intel[1]—who have stepped up to apply their knowledge of formal verification methods to the iOS kernel and drivers, but haven't necessarily had the flexibility to spread that love to macOS. That can change now.)
It isn't just "we coded it twice" (which I would still argue is bad from a security perspective with respect to making sure both are actually correct), but "we both designed an API to solve the same kind of problem... different... so now the world has two APIs to learn on these weirdly different platforms when, by all rights, we should have just designed one".
This reassignment and movement of people to the iPhone/iPad side has been happening for a long time. That's why I referred to the organizational structure, because the company is not equipped to handle so many things quite well (which has its advantages and disadvantages). One write up about this topic, which I share somewhat often is on Stratechery. [1]. That's worth a read.
I'm also a long-time Mac user, but I've really had about enough of this. Between the seemingly constant stream of security problems and the dumbing down of OSX (MacOS, whatever), I'm not sure I'm willing to pay a premium for this product anymore.
At the same time the Apple seems to be dropping the ball, some of the more noob-friendly linux distros are starting to look very attractive. And while Apple still seems to have the best hardware overall, a Lenovo Carbon X1 seems like a very decent option. I'm by no means a "pro" user (I have a decent understanding of computers, can get around on linux command line, some basic experiences in programming, etc), but I'm probably going to start making the switch, at least for my laptop.
Slightly off topic, but one of the only software issues holding me back previously was 1Password compatibility on linux, but apparently, it is now available (1). Anyone tried it? It's not a stand-alone application, but I'm probably okay with that.
> Apple still seems to have the best hardware overall
The example comparison you gave, an X1 Carbon, has a more reliable keyboard with more travel, a matte-screen option without fragile glass, a user-replaceable battery, a user-replaceable NVMe drive, a variety of ports new and old, a docking solution, security cable lock etc
As always, the mousepad can't yet be beaten. While it sounds trite - and I've long since switched away from my original Macbook Retina, IMO the height of Mac's hardware dominance - I still pine for it compared to everything I've used since.
I haven't used one, but newer machines use Microsoft's "Precision Touchpad" standard which is supposed to close the gap and support fancy gestures. Personally I just use the ThinkPad nipple and as many shortcut keys as I can memorise :)
I'm another one who much prefers the nib in the middle of the keyboard to the touch pad. I use a Thinkpad keyboard on my desktop machine for this reason. No mouse on my desk at all and I'm not constantly moving my arm back and forth to reach for it.
I was right there with you for a long time, but the touchpads on PC flagships have largely caught up. I switch between a Dell XPS 15 and a late-model MBP daily, and while I still give a slight edge to the mac, the Dell works well too and doesn't cause any frustration/pining.
I thought the same thing but I switched from a MacBook running Bootcamp to the new Surface Laptop and I actually prefer the latter. It's absolutely phenomenal. Microsoft is kicking ass lately and WSL lets me do all the Linux stuff I need to do (build scripts, etc.).
As a counterpoint, the display inverter on my 3433CTO failed after 18 months. It's a $19 part - Lenovo wanted $400 to repair it. I moved to the Dell XPS 9350. The display failed. The wifi card is a $5 part in a $3000 machine and failed.
My X1 Carbon came with a 3 year on-site repair warranty as standard, included in the price (contrast this with AppleCare which is very expensive). Did you buy yours from Lenovo?
Yes, and I'm also covered by the excellent Australian Consumer Law. They ran me around for 6 months, sent invoices and logs with the wrong name on it and I eventually gave up.
All the other ultrabooks are 16:9, right? It's so hard losing that extra screen real estate, you really get used to it after a while. I'd rather even go 3:2, but the options there are only the Surface Pro or Pixelbook.
3:2 is the best. It drives me fucking insane that all the laptop manufacturers have capitulated to the idea that everyone's spending time watching movies on their laptops more than anything else, which strikes me a complete nonsense but I suppose it must be true, otherwise they wouldn't make that decision... I hope.
A wider screen on a laptop has the advantage of allowing a wider keyboard-- so smaller laptops (12"-13" and below) can have full size (or closer to full-size) keyboards, and larger laptops (15" or so) can fit things like a full numeric keypad (15-inch 16:10 doesn't even quite leave room for one, but 15-inch 16:9 does without inflating the screen bezel too much).
It's also probably not coincidental that a wider screen ratio allows the manufacturer to sell less screen (in terms of area or total pixels) at the same diagonal size.
I'm buying a new computer and keep seeing hints of crosvm (real containers!) for the Pixelbook. If they could even say 'yes, this will be released at some point' I would just buy one, but instead they stay tightlipped and I'll have to buy another MBP.
> Slightly off topic, but one of the only software issues holding me back previously was 1Password compatibility on linux, but apparently, it is now available (1).
Well, it's a Chrome extension. For some people (including yours truly), it's a deal breaker.
I would suggest `password-store`[0] if you don't need to share your vault with anyone.
Actually, pass has great support for teams. Dropping one or more GPG keys in ".gpg-id" will encrypt the passwords for the various identities. This works globally or per sub-folder.
I use dedicated subkeys for work and mobile so that I don't have to share my main key, or indeed every password with every device.
I don't have direct experience with 1Password on Linux, but customers have complained about how AgileBits has treated the Windows and Android builds as third class citizens and not put in a lot of effort into those. So I'd be cautious, try it out and then decide instead of taking someone else's word for it.
For multi-platform password managers with browser extensions, Enpass (enpass.io) is an option. Dash lane is another, though it's about as expensive (or more) than the 1Password subscription that AgileBits pushes (the dark pattern on the AgileBits website about completely hiding the standalone license is something I don't like).
On top of all these the touchbar, the new, ridiculously large trackpad and the loss of magsafe are a step back in UX from previous iterations of the MBP. I can't realistically switch to a platform that doesn't run Sketch but I used to look forward to new Apple hardware and I can't say that's true anymore.
1Password was also an important app for me, but after they moved to a service, I switched to keepass. 1password was a great app done right, but keepass is much more extensible (while being quite ugly) and with all the recent "security debacle" I'm happier with an open source solution.
This is not true in general. Linux Desktop UIs like Gnome 3 have taken a lot of criticism precisely because they have not been copying Windows and have deviated considerably (due to patent concerns). Of course, there are some fringe "garage effort" Linux distros that don't care about patents and do just give some part of the community what they want.
As for innovation, Linux desktop UIs had virtual desktops and window tiling features long before Windows and MacOS.
Yes I remember the CDE desktop had virtual desktops, but they go back even to Xerox Parc (according to Wikipedia). There are many minor aspects that have been tweaked and are perhaps newer ideas though. For example, on my desktop, I can search for a window title and get a list of windows across virtual desktops that are matches, and jump to the relevant desktop and window.
> This is not true in general. Linux Desktop UIs like Gnome 3 have taken a lot of criticism precisely because they have not been copying Windows and have deviated considerably
The criticism towards Gnome 3 is due to the reduced usability, customizability, constant breaking of backwards compatibility (especially when it comes to parts that allow customization), treating the desktop like an overgrown tablet and a general tendency of its developers to treat their users like they don't know what they are doing - if not outright ignore them. For examples, check out Reddit's /r/linux whenever anything towards Gnome is posted to get an idea of what people are actually saying about it (both positive and negative).
> (due to patent concerns). Of course, there are some fringe "garage effort" Linux distros that don't care about patents and do just give some part of the community what they want.
Sorry, but this phrase is incredibly loaded. Are you affiliated with Gnome? Let me try to break it down:
"due to patent concerns" - this is textbook FUD that tries to present Gnome as a project that cares about patents (why would Gnome care about patents any more or less than other projects?) and create the impression that other desktops do not care. Moreover it implies (but doesn't explicitly say so that it can be denied later on) as granted that patents are indeed a concern for an open source desktop environment to the point that not only it is worth mentioning but actually Gnome making an active effort towards avoiding patents by redesigning their UI.
"there are some fringe "garage effort" Linux distros" - implying that any distribution that does not share Gnome 3's concern (assuming they exist and isn't just an excuse) is a fringe and garage effort. BTW i've noticed this with several Gnome developers: they tend to downplay anyone and anything that doesn't fit in their worldview as unimportant (for fun, try to ask them about Wayland and X11 and suggest that Xorg will continue to exist after -say- 5 years - some cannot even fathom the idea that even if all Xorg developers lose their senses, others can fork the project and continue its development just like the Xorg devs forked XFree86 and just like XFree86 was forked from X386).
"that don't care about patents" - again the implication that patents are something that Gnome alone cares about and that only unimportant, fringe garage effort distributions can ignore them, but Gnome - being the big and serious project that it is - has to abide by the patent masters and...
"just give some part of the community what they want." - ...being unable to give to the community what they want. Although i have to say, i like the backhanded "some part" here and the implication that it is only a small part of the community that wants something better.
Of course the entire phrase is based on the assumption that a) patents matter so much that Gnome has to design their UI around them and that b) everything else that does something closer to what the users actually want can only do it because it is fringe and unimportant. Both being false of course since there are tons of other efforts that are as important as Gnome while giving to users all sorts of options - with KDE being the obvious elephant in the room, but also with efforts such as Cinnamon, Budgie, elementaryOS/Panteon, etc. Also avoiding working on stuff because they might be patented (and honestly, most of the stuff users want - like a desktop, icons, a start menu, etc - are things that even if they were patented would have their patents expired by now - again assuming these patents are even valid and enforceable) is a fool's errand since patents exist for pretty much everything and the best an open source project can do is simply ignore them unless someone comes after a project at which point you can try to change the specific part that is a problem. It isn't like anyone can even kill a project or anything, otherwise even Linux would be dead.
Honestly i dislike this sort of "implied mudslinging" towards a ton of other projects and efforts, trying to paint them in a negative way in an attempt to both give excuses for why Gnome is the way it is today and downplay not just the concerns of its users but the users themselves as unimportant.
Try to avoid it please. I don't know if you are a Gnome developer or just an overenthusiastic user, but attacking every single other project that isn't Gnome on nebulous and arbitrary grounds is not the best way to make a good impression.
I'm not a Gnome 3 user or affiliated with Gnome. Personally I find it rather too bloated and sometimes buggy. I use i3, polybar and Rofi for my desktop. I think you are reading rather too much into my words, my point was only that, in general, Windows is not being copied by Linux desktops. And that only "some part" of the community want a Windows clone.
I take your point that Gnome 3 is criticised for many additional reasons other than deviating from Windows.
Gnome is basically controlled by RedHat, a billion dollar company and they absolutely do care about software patents, they are not like most projects. Linux Mint is what I had in mind as a "garage effort" providing, IMHO, a Windows clone.
Amen to this. A stickler for me personally is the universal menu bar at the top of the screen rather than separate menu bars inside windows.
I know that older versions of KDE could be configured to do this, but not sure if more recent ones can do it, or if other DEs can do it. Every now and then I do some research on it, but the results are never promising. (From what I remember, the Ubuntu/Unity bar gets close but still feels weird.)
This is really not true at all. The most popular desktop in Linux, GNOME, has always drawn heavy inspiration from Mac. The latest version is really polished.
But there are so many options! Including IMHO the best one on any platform for a developer: no desktop environment and a tiling window manager.
There are even NeXTStep clones with binary compatibility! So saying Linux GUIs copy Windows is nonsense.
Two of the three most popular DEs (Gnome and Unity) both don't look like Windows. I'd say only KDE does, and most major distros have Unity or Gnome as the default. So I think you're a bit off with your assessment.
Dells and Lenovos both have a lot of their hardware supported in most major Linux distributions.
I run Gentoo on two Dells without any major issues. I really prefer Linux over MacOS and have been lucky that at my last three jobs I've been able to use Linux natively on my work laptops/desktops. Using a tiling window manager like i3 also make things so much easier as well. It may not look as pretty, but from a utility standpoint, it's far above the usability of MacOS for developers.
I never understand this line. How is MacOSX being dumbed down ?
It's largely the same OS since back in 10.0 DP1. Sure they try to lock down applications to those that are signed. But it's trivial to override and is great for OSX users that can't immediately identify malware.
The thing that I don't understand, as a developer, is how these types of bugs even make it in to these releases. Was the "lock" functionality in System Preferences changed at all in any meaningful way for the App Store panel. It doesn't seem like anything about that functionality is sufficiently different so how did this break? Did they bypass the check in order to work on the panel and forget to re-enable it or something? I just don't see how these things happen...
Edit: I just checked an old work machine that we have and the lock isn't even included on the App Store pane in Sierra. This leads me to believe that the only bug here is the inclusion of the lock icon and prompt without the actual code behind it to do the authentication. Seems like the bug is that someone put a lock where it wasn't supposed to be or it was added for a future addition to this panel. Either way, definitely not as major as I first thought.
Maybe Apple has embraced one of these "Agile" methodologies where you basically eliminate your QA group in the promise that developer created unit and integration tests can cover the quality gap.
QA and dev approach software with different mindsets, and I've noticed in Agile projects where QA is mostly or entirely missing, there is a skill gap.
Edit:
People - I'm not trying to be flippant. I really have seen a decrease in quality in the transition to Agile. We use Scrum or Kanban where I work, and while overall the approach to estimation and the smaller scheduling and estimating increment is better, in many projects where I work there is no _separate_ QA group. A few project do retain it (though re-branded as "Performance, Stability, Reliability" - PSR) and it does help, but generally this PSR doesn't cover everything our old QA groups used to cover.
In any case, I have no insight in to what is happening inside Apple. I'm really just suggesting that given the prevalence of Agile methodologies these day, perhaps a non-ideal transition to Agile is a contributing factor to their quality issues.
I agree with you, the lack of QA skills in a team is a dangerous thing. But I disagree with the notion that the agile methodologies are the problem, more like an excuse from the same people that would use any other excuse to cut corners[0]. A QA column (or set of columns) fits perfectly with Kanban.
Years ago I started seeing companies combining QA and product teams[1]. It required product people with a bit of technical background but, when done right, worked incredibly well. Nowadays not only I've stopped seeing that trend, but most product teams I see are completely ignorant of technical matters. QA teams seem to be more or less missing or seriously understaffed.
---
[0] Not to speak of the need to be "agile" without changing a single thing in the process. I can't count the number of times I've seen teams using what is, essentially, a waterfall process (including long development cycles with no contact with the customer at all) self-describing themselves as agile.
[1] So the same team defining the new features also creates the tests, both automated and manual, and checked the results.
I am sure we have both spent time in Agile projects. Let me ask you. When stories end up in the QA column do they just test the story or everything the story could possibly touch ? Be honest.
Because that right there is the problem when you are dealing with systems with lots of interconnected components. There just isn't enough time for the "randomly try to break anything" phase.
Yes, they usually only test the feature and you are right, when you are dealing with plenty of interconnected components, it's more difficult to do complete tests and there's a higher chance of something slipping by unnoticed.
However, on every build the unit, integration and acceptance tests should run and should alert if something is not right[0]. Automated testing can't cover all the use cases, but there's no reason they couldn't catch most of the issues we've seen with OSX lately (a good example of a system with plenty of interconnected components). On top of that, the good QA people I know always run some random manual tests not related with the story itself on every feature release just to make sure everything is still as expected.
The time is there if it is, along with the expectations, managed correctly. Only in smaller chunks instead of a big, single block of time at the end.
Even though, there's always the chance that there's a completely unforeseen side effect (a test can prove that there's an error, but can't prove that there are no errors), all of this is to try and minimize that chance. In general, I think that these issues appear more often related to specific systems (lots of interconnected components) or environments (lack of proper testing), rather than with specific methodologies (back in the non-agile methodologies days, programs still had bugs).
[0] Like, for example, an edge case of a method being fixed. That can have knock-on effects if other parts of the system were relying on that method failing.
This seems like a legitimate point. This is true. OS development is typically too large to run through a single monolithic team.
It is possible that the team in this area is applying a methodology that has different QA best practices. It could be a poorly applied Agile methodology at fault here.
Although it's impossible to know without more information.
I think it has more to do with the complete lack of testing infrastructure and tooling that Apple has produced over the years, despite the explosion of APIs and developers on their platforms.
Even on iOS, which rumors have being more of a focus compared to macOS, still has a long way to go to catch up to other platforms. If they required these tools internally, no way would they be this far behind.
Can you elaborate on what's missing? I do a lot of graphics work, and their macOS debugging tools for OpenGL were terrible, but the ones for Metal (which came out first on iOS) are pretty cool! I also use Instruments a lot and some of the other more esoteric tools supplied with Xcode. Not to mention the static analyzer, Address Sanitizer, and lately the Undefined Behavior Sanitizer. But I'd love to have even more tools! What else is out there that they don't supply?
I am talking specifically about unit testing, ui testing, integration testing and then supporting those tools in some type of ci system.
And to be clear, they provide these things in the form of XCTest, XCUITest, and Xcode bots, but they aren't good enough. Tons of resources have been spent by the community and major corporations trying to fill in the gaps and offer useful alternatives, but the closed nature of Xcode and its build environment make this difficult.
> Maybe Apple has embraced one of these "Agile" methodologies where you basically eliminate your QA group in the promise that developer created unit and integration tests can cover the quality gap.
WTF are you talking about, there is no Agile methodolgy about getting ride of QA. Sounds like you have a problem with Agile, so are looking for some reason to drag it in. You might as well blame the keyboards they use.
Not agile methodologies. The “omg we must do a release with splashy features once a year” mindset.
They released exactly one version (Mountain Lion IIRC Edit: Snow Leopard) which was just fixing bugs and improving system stability. Everything else was “oh look another shiny toy” where toys are increasingly inane, iOS-like and unfinished (hell, they can’t even fix Photos).
> Was the "lock" functionality in System Preferences changed at all in any meaningful way for the App Store panel.
I don't know about local authentication, but iCloud account authentication was changed a couple of times in recent macOS versions (from 1FA to optional pseudo-2FA to real 2FA.) I know that parts of the App Store prefpane (e.g. "remember password after purchases") require the iCloud auth flow. That might have affected the local auth flow somehow.
I disagree, I think Apple can continue to release sub standard products for macos with little or no consequence as long as people are willing to hand them $1000 for an iPhone.
This was the last good MacOS in my opinion. Starting with Lion they removed Expose, and they removed the workspace grid and replaced it with that shitty Mission Control rubbish. I hated I couldn't down-grade (or really upgrade depending on how you look at it) my Lion laptop back to Snow Lepord. It was so unusable I actually went back to Linux and tried a bunch of different tiling window managers. I've been on i3 ever since.
The first couple release of Mission Control were total ass, the window grouping pissed me off to absolutely no end. I don't know when they fixed it since I missed Yosemite and El Capitan, but they finally brought back the old-style expose layout for windows at the very least which makes me much happier.
Now if only they would put full screen on a separate button again, I HATE that the zoom button was been hijacked and I have to hold down option just to zoom a window. Why can I not change the default behavior? That would be a nice compromise at least.
The yearly release cadence doesn't seem to be good for software quality of iOS or MacOS. iOS 11 is one of the buggiest releases they've had in a long time. A year really isn't very much time to develop, test and debug a new operating system release.
> Something has to give — either Apple’s organizational structure needs a change or Apple needs to abandon certain things completely instead of releasing sub-standard products that aren’t expected from it.
Or you know, apple users can start acting like concious beings with agency, and start buying better products. It's not like there is a lack of choice out there. If you absolutely hate M$ Windows, dell has a laptop that ships with Ubuntu now. Vote with your wallets.
On one hand you have massive data loss, a big issue for sure but something well understood, well known, that you can and should be prepared against in any case; you're never protected against: your computer being run over, or your house being on fire, or your HD suddenly dying. If I lose files by lack of backup, I can be angry at myself for not having done proper backups, whatever the source of the deletion, this is something I can remedy.
On the other you have giving access to your data to people who shouldn't have access, be it making them root, giving your encryption password in the hint field, ... You're not prepared against that, you have no mitigation and no remedy other than picking the right tool; either the tool you're using is secure or it is not.
Better everything gets deleted than someone not meant to have access getting it. And better something happens that I could insure myself against, than something against which I cannot do anything to protect myself.
The parent's point is that SL was almost explicitly a performance/optimization gain and not a feature release. It literally give you ~8GB (IIRC) of extra disk space for just installing it.
I would fork over money to Apple for them to do another SL-like OS release.
High Sierra was lots of new changes under tho hood whereas Snow Leopard was lots of improvements to existing stuff.
High Sierra switches solid state drives to the new APFS file system and the WindowServer is now rewritten to use Metal2.
So I would suggest that High Sierra is far from a stability release like Snow Leopard was. It was about ripping out the foundations and building new ones. The APFS transition, to Apple’s credit has been mostly painless while the WindowServer changes has been hit miss depending on your hardware.
These were things Apple had to do and they benefit all their platforms.
That was my experience too... but after clicking around for a while & then going back to the App Store prefpane, I did see a padlock (unlocked) on the App Store prefpane. I haven't been able to reproduce it again, but it seems there's some kind of bug there even on El Capitan.
The interesting implication from this is that while it works for the App Store preferences, it doesn't work for the others, showing that there is a manual check that each pane is doing. Why aren't all of these calls identical? If each has to be handled manually, it's no wonder that there are bugs like this appearing.
My guess is that the App Store preferences isn't even meant to have the padlock. iCloud prefs doesn't have it, so I can only assume it's there by mistake.
If you try the same thing with say "Time & date prefs", it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password. With the App Store prefs, it just instantly closes the authentication dialog, even with a blank password.
I don't really understand the logic as to why some panels in preferences have padlocks and others don't... Why does date/time need admin rights whereas Network (delete/add/reconfigure networking), Internet Accounts (delete/add any accounts?), iCloud (do all manner of things), Time Machine (back a machine up elsewhere?) don't require it?
Most OS's require admin rights to change the date/time because of the ability to mess with things like kerberos ticket TTL's, and other security issues.
I can understand why it would be there for date & time. I guess I more don't understand why it's not there for networking - you can add a proxy in (or even a whole new network adapter) for all network traffic without admin rights!?
I don't think "sharing-only" accounts can; only regular accounts. Keep in mind that a non-"sharing only" account is an account with a special privilege: it can log in through the local-framebuffer LoginWindow. This translates to an assumption that the computer is–at least temporarily—in the physical possession of said user. They're at least sitting down in front of it; they may have been leased it by their employer.
The global prefs that can be reconfigured by "regular users" (i.e. non-"sharing only" users) are precisely those prefs required to keep the system in a working state if you're physically in possession of it and doing the things that possession of a computer implies. For example, you can move a computer you physically possess to a new location–at which point the same wireless networks won't be available, and maybe you won't be able to get online without a proxy. So, in order to ensure that just going places doesn't necessitate a call to corporate IT, the default† is to let any non-"sharing only" user configure networking.
† "Default" because these prefs can be locked down using a configuration profile (like a windows Group Policy Object) by corporate IT if they need a computer specifically secured against these changes, such as a public-use kiosk.
It's concerning there's a UI element that displays as a padlock and shows the standard auth dialog but then doesn't actually do any auth. If this is easy to do by mistake, where else is this hiding?
To further support your point, if you switch to a pane that does require the padlock and then switch back, the padlock is gone. Looks like someone forgot to set the padlock bar to invisible on that perf plane. It's a minor UI glitch, nothing to see here.
I would imagine it's because changing the system date/time could be used nefariously whereas iCloud, Internet Accounts, and Network would all require passwords for the individual accounts/networks to do anything with them.
I have a feeling this isn't actually that High Sierra is that much worse, but more that people are now actively pen-testing macOS to find the next embarrassing bug.
And that scares me even more because of the unknown of how long such bugs must've existed in the system.
Is this Apple's Windows XP moment? (Like when MS stopped everything and did massive security training that resulted in XP SP 2 being worlds more secure?)
Most of the recently discussed High Sierra bugs were not there on Sierra, while the features were there, like this one.
So it's not that much pen tensting, but Apple making changes and not validating them correctly. Maybe they have their Vista moment with High Sierra, maybe we forgot previous buggy versions.
For security-related bugs, maybe. When I file bugs with Apple (which I've mostly given up on), they are usually marked as a duplicate of another still-open bug. So it seems that people actually file bugs -- free QA works! -- but there's not enough time to fix them.
Well, the root account password bug and this bug both do not reproduce on Sierra, so they were both introduced in High Sierra. Unless you’re arguing that Apple fixed a bunch of undisclosed vulnerabilities when they introduced these, High Sierra is definitely worse.
High Sierra and Sierra both have enough disruptive bugs in them that I had to downgrade my 2012 Macbook Pro to El Capitan, which did not have those bugs. The most notable one for me was the massive regression in video drivers, that not only made many previously smooth-running games unplayable, but also caused several of the ordinary desktop apps I used to become unacceptably slow.
For me they broke automount (/etc/auto_master). It just... randomly takes root ownership of my smb shares. So I can't get to them. Then it randomly gives me ownership back. Crazy-making. Writing a Cocoa app right now to watch for kCFURLVolumeIsAutomountedKey errors and fix this bug myself.
That makes an awful lot of sense, in which case the bug is just not checking that the login is 'cached' before displaying the dialog. In a similar vein to another comment, though, why doesn't that dialog detect the state of the 'login cache' consistently across all occurrences?
I'm on 10.12.6 and a local admin account, and it only unlocks to my actual password. That might mean it's a recently-introduced bug (assuming someone else can reproduce my result).
sorry if this is a dumb question, but: why is it unreasonable for a local admin to have the power to change AppStore preferences? without knowing much about the osx security model, this sounds like not a big deal?
For certain features, they want you to reconfirm that the user presently at the keyboard is the real admin at the moment that you do it.
This prevents a situation where the actual admin logs in, their attention is taken away from the computer, and someone sits at their chair and does awful things with the computer.
If they have "'Always Require' Password for Purchase" enabled, you could disable that and buy apps from the app store without a password.
For example you could let your kid use your Mac, but you don't want them spending your money via your app-store linked credit card. If they have access to the App Store Preferences panel they can disable the requirement and do so.
Good point. Clearly with sudo, aside from it following the UNIX convention for sudo, it is just a consciously made tradeoff between security and ease of use. Whereas with the security pane, the lack of checking of the password that is entered is most likely a bug.
Maybe you already saw this but I see they also made the same security/ease of use tradeoff for the (non-buggy) locks in the other preference panes. After unlocking, it stays unlocked for a period of time while you are in preferences, even if you visit different areas within preferences and come back.
You have the power, but the system would like to check that it is actually you and not a malicious script. It is the compromise between running as non-admin and running sudo for ever friggin’ thing and running wide open to the world as admin.
On OS X, administrative accounts still need to authenticate with their passwords to perform administrative tasks. This is to avoid (presumably) someone using your computer and changing settings without your consent if you have automatic login enabled, and to make sure you pay attention to what you're doing (similar to the UAC prompts on Windows, and sudo on Windows)
I don't believe it is, necessarily. The issue is that doing this action requires the admin to re-enter their credentials.
In this case, any credentials work, meaning that if a "guest" user (semi-trusted by the account owner, obviously using the owner's credentials. ) were attempting to change these settings, they could bypass the prompt with a bogus password instead of the alternative which requires the guest to ask the owner to enter their password.
this isn't a dangerous bug itself, it matters because it exists at all and raises concerns that similar bugs might exist in places where security might actually matter.
If an Apple developer is reading this, your team should consider system-wide input testing. It'd be worth the developer time. Who knows how things can break if long, crazy strings are inserted.
What do you get when you tell everyone that “MacOS and desktop computing are as important to our company as ever” when in reality you barely give a crap about it.
This is a fairly minor bug, since, apparently, it’s only happens when already logged in as admin (and it’s “just” App Store prefs). (I get that you can come up with scenarios to exploit this, but come in.)
But, wow, how many bugs is this for High Sierra where a password prompt can be bypassed?
It’s like password prompt flu is going around Apple.
Was there bad sample code distributed or some change in the default behavior of some key API? (In addition to the obviously inadequate testing.)
I guess it would make more sense to me if there was something connecting all these issues. (Besides the inadequate testing.)
Installing a Mac OS update could be considered a security risk? That makes little sense since the security risks you're alluding to were solved by updates. 10.13.2 partially fixed the Intel problem in December and 10.13.3 will have more fixes. If you were still running 10.13.1, you'd have both the root login bug and the Intel security issues.
The Mac OS version out right now is more secure than the previous minor or major version. There really isn't any credible evidence to the contrary.
It's irresponsible to not update your system. I understand not moving up to a new version of an OS because of compatibility issues (i.e. audio interfaces often are sluggish to update, libraries you need might not work, etc.,) but not updating because of security fears -- that's just ridiculous. 10.13.3 is more secure than 10.12.2.
Also, in order to "exploit" the reported bug, you would have to already be signed into the computer AS AN ADMIN. Which means that you could already change the updating behavior. So unless you are sharing your admin login/account with non admin users, the risk you cite is pretty trivial.
If you are in a higher risk computing environment, it would be logical that you would sign out of your account after you've finished using the system -- you would essentially have to provide an unauthorized person access to your Mac while you were signed in before this would be an actual threat. That doesn't make the bug less "real," but it does make the real-world security ramifications much less dire than being implied.
>If you are in a higher risk computing environment, it would be logical that you would sign out of your account after you've finished using the system -- you would essentially have to provide an unauthorized person access to your Mac while you were signed in before this would be an actual threat.
So, the most that can realistically happen is that if you leave your Mac unattended while logged in as Admin, a co-worker or friend might get in and install some app to play a prank on you.
I mean, unless somehow a malicious app has been approved on the Apple store and is available to download through the changed setting (and the "evil" co-worker/friend knows about it), but still the base security risk remains leaving the device unattended and making it phisically accessible by smeone else while still logged in as Admin.
I don't know if I'm doing it wrong or maybe the problem has been fixed in the latest beta, but I can't replicate the problem on 10.13.3 Beta (17D34a). I lock the App Store preference pane and can't unlock it with anything except my real password. And yes, I am logged in as an Admin user.
Maybe it's Apple's strategy - let macOS slowly disintegrate and then give iOS to frustrated desktop users as the only right way? Last time I've seen that strategy was when Nokia had a mole as CEO installed, though the outcome wasn't very nice to either Nokia nor MS...
macOS High Sierra is such a disaster. Did Apple has any quality control over software at this point? No security vending? How could they have customers' trust if they keep making such idiotic mistake?
Kind of a silly title "AppStore Preferences lock is a lie" -- it isn't a "lie" unless Apple intended for it to not lock correctly. But obviously, it's a bug. It isn't like Apple is trying to deceive users.
Interesting bug, unnecessarily hyperbolic title for it.
As a long time Mac user, I keep hoping that Apple will decide to double down on better and deeper focus on all its products, including the Mac, its OS and ecosystem, and make the changes necessary across its organization and its teams.