Live data from Hacker News

Apple needs a Snow Sequoia

reviews.ofb.biz

771–780 of 801 posts

Re: Apple needs a Snow Sequoia

#771

Earlier quoted context omitted.

My advice for web browsers is to use Flatpak. You can limit the file system permissions of the app, like giving only access to downloads, so that if/when there’s a sandbox leak you’re fine. You can also disable various things, like webcam or mic, this way. In addition, you can get perpetual updates to the latest version of your browser even on old, stable distros like Debian.

Running a new browser on an old distro would be a strong reason for me (if I somehow couldn't update the distro - but I can and I do.) Regarding security, the added work and complication outweighs the added security for me. I can't really disagree with having a different preference. More security on this wild internet is better, right?

IMO it's not much added work. In KDE you can navigate to settings and edit flatpak permissions, and flatpaks are available to download via discover. I haven't noticed any weirdness for firefox or chrome.

Re: Apple needs a Snow Sequoia

#772
I think we're at the point where it'd be better if OS's were just a thin platform, and the updates to user facing features came piecemeal to different apps instead. IE, update Finder or Safari but leave the core functionality alone outside of bug fixes or very rare major upgrades. I'm so sick of having to update my OS every year.

Re: Apple needs a Snow Sequoia

#773
post #757

Earlier quoted context omitted.

In all fairness, secret hotkey BS may as well not exist. Are you supposed to mash every modifier key and every combination thereof on every screen and in every menu, looking for hidden goodies? Absurd.

No: you are supposed to read the documentation to learn about power user features. Microsoft also doesn’t shove the advanced keyboard shortcuts in your face; you need to read the manual to learn stuff like this.

Showing WHERE things are found when you do a search is not a "power-user" feature. It's an essential aspect of what the user is trying to accomplish.

The whole point is that secret hotkeys are design dereliction.

Re: Apple needs a Snow Sequoia

#775
post #769

Earlier quoted context omitted.

There’s a middle ground. Get the appropriate stakeholders involved in the decision, including security. Let security be the ones to keep the system down, if it cones to that. Or, let the business operations folks make the decision to go over security’s head. Either way, this is not something an engineer tasked with fixing an outage should be making the decision on.

> this is not something an engineer tasked with fixing an outage should be making the decision on I don’t get this at all. I’d much prefer a team of highly empowered and highly responsible engineers than impotent engineers who need hand holding in case they make a mistake.

Well, good thing that wasn’t what I suggested.

Engineers _should_ have leeway in how they resolve issues. As I read, though, you have a company policy which explicitly disallows the action you needed to take to fix the problem (if I misread, my apologies). Getting the stakeholders involved is the responsible thing to do when policies need to be broken.

Ideally, the way this kind of situation gets handled should be documented as part of a break-glass policy, so there’s no ambiguity. If that’s not the case, though, the business should get to decide, alongside the policy maker (e.g.: security), whether that policy should be broken as part of an emergency fix, and how to remediate the policy drift after the crisis.

If you’re all tight enough that you’re allowed to make these kinds of decisions in the heat of the moment, that’s great, but it should be agreed upon, and documented, beforehand.

Re: Apple needs a Snow Sequoia

#776

Earlier quoted context omitted.

There's extensive documentation. Examples: https://developer.apple.com/documentation/security/code-sign... https://developer.apple.com/documentation/security/notarizin... There are dedicated sections of the developer web forums: https://developer.apple.com/forums/topics/code-signing-topic https://developer.apple.com/forums/topics/code-signing-topic... ...and there's an apple developer support person, Quinn, who appea…

Can you sign and notarize your own software made for internal use with your own infrastructure? If so, then this is a valid response. If not, then this is an irrelevant response because the issue is going through Apple, not the process being difficult or undocumented. If I own the device, then I should be free to decide what the sources of authority over it are. Edit: I haven't tested it yet, but it does seem that yo…

Anecdotally, I was not able to find any way to notarize software for internal use, without paying for a $99 developer account. Though I would have been willing to pay, I know that others who might want to build the software wouldn’t, so I abandoned my project. I suppose I could have maintained it as open source with the developer account required to build, but it seemed disingenuous to me at the time.

Re: Apple needs a Snow Sequoia

#777

Earlier quoted context omitted.

My group makes a custom executable to reflash a hardware device we produce. We build it for Linux and Darwin. Trying to get the program to work with our Mac users has become harder and harder. These are all internal developers. Enabling developer mode and allowing Terminal execution isn't enough. Disabling the quarantine bit works - sometimes - but now we're getting automated nastygrams from corporate IT threatening…

There's extensive documentation. Examples: https://developer.apple.com/documentation/security/code-sign... https://developer.apple.com/documentation/security/notarizin... There are dedicated sections of the developer web forums: https://developer.apple.com/forums/topics/code-signing-topic https://developer.apple.com/forums/topics/code-signing-topic... ...and there's an apple developer support person, Quinn, who appea…

> I mean, come on. Is that really necessary? Obviously there are enough people who did not know about, or find helpful, the resources you’re referring to, that we have people complaining on Hacker News. This isn’t exactly a novice’s forum. Perhaps the problem lies with visibility and accessibility of the support resources, rather than all of the people who have seen notarization as a hurdle to getting real work done.

btw, for those who don’t want to search, Quinn’s signature states:

“ Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Re: Apple needs a Snow Sequoia

#778
post #179

Earlier quoted context omitted.

The principle is what matters. The amount is not the issue. The issue is that there is a cost at all. "It's so cheap" is never an excuse for charging for something that should be free. In this case, running software you have no intent to charge for, on your computer. It's as if someone started charging $0.01/month for breathable air. "But $0.01 is trivial," would not excuse it.

The commenter I replied to employed by a business, develops software and distributes it within a team of engineers with Macs. For your personal needs, you do not need to pay anything for building and using apps locally.

Untrue. There are specific APIs which require notarization , regardless of usage. Credential autofill is one such API.

Re: Apple needs a Snow Sequoia

#779
post #96

Earlier quoted context omitted.

Adding signing as a requirement can easily make what was once a very simple distribution mechanism into something much more complex - now you need manage signing certificates and keys to be able to build your thing. The cost is far far higher than the price.

But it doesn't in practice. I develop and distribute few free apps for macOS, and building / notarising is never a problem.

Do you distribute OSS software which requires notarizing? If so, have you found a way to let the community build the software without a paid developer account? I would be very interested in a solution which allows OSS development, relying on protected APIs without requiring that anyone who builds the app to have a paid developer account.

Re: Apple needs a Snow Sequoia

#780

Earlier quoted context omitted.

Where? And how is that option displayed to the user? I also just tried it in Spotlight and Finder, and it did nothing. Which I consider a relief, because undiscoverable bullshit is worse than the feature not existing.

It's in the documentation for Spotlight: https://support.apple.com/en-gb/guide/mac-help/mchlp1008/mac I agree that discoverability could be better, but macOS has pretty consistently had hidden power user shortcuts and modifiers, to keep the basic workflow streamlined/simple for those who don't need it.

Seeing where stuff is in a search function is not a "power user" feature; it's the whole point of what you're doing.

And I don't buy the "keeping things simple" excuse for secret hotkeys in other areas. Falling back on gimmicks like undisplayed hotkeys and "long presses" and "gestures" is lazy abandonment of the design task.

I hate this "saving the user from complexity" lie. It's hypocritical: The "non-power" user isn't going to go looking for these options in the first place.

Finder search is a great example. A "non-power" user isn't going to right-click on the column headings in the results and try to add "path" as a column. So how does it help that user to deny everyone else the ability to add it?

Apple mocked IBM for needing a thick user manual back in the day. To suggest that anyone (especially anyone on this site) should have to read documentation to use perform a basic file search (in a GUI, no less) is apologism to the extreme.

Post reply on HN