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?
Apple needs a Snow Sequoia
771–780 of 801 posts
Re: Apple needs a Snow Sequoia
#772Re: Apple needs a Snow Sequoia
#773Earlier 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.
The whole point is that secret hotkeys are design dereliction.
Re: Apple needs a Snow Sequoia
#774Re: Apple needs a Snow Sequoia
#775Earlier 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.
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
#776Earlier 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…
Re: Apple needs a Snow Sequoia
#777Earlier 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…
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
#778Earlier 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.
Re: Apple needs a Snow Sequoia
#779Earlier 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.
Re: Apple needs a Snow Sequoia
#780Earlier 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.
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.