Mojave and apple events sandboxing


(Ray Robertson) #21

Thanks for speaking up, Mark. The most perplexing problem is the lack of documentation or any sort of acknowledgement. You and Shane are somehow doing the work that a billion dollar corporation refuses to do, while continuing to provide your own users with a much higher level of customer support.

I typed a lot more, but just erased it. For now, I will just say that AppleScript and automation are so valuable that we will continue to do great things despite the obstacles. Some of us will stick to older OS versions. Eventually, Apple will start listening to users again. Another software company just started doing that this year, after years of ignoring them. Things do happen in cycles. This is a challenging one for us now, no doubt.


(Jim Underwood) #22

Mark (@alldritt), thanks for your guidance.

Please be aware that most of us, or at least me, don’t know how to do most of the things you suggested.

So, may I suggest, that you provide all of the details to:

  1. File a bug report with Apple. (can I do this even if I’m not a developer?)
  2. Provide a detailed suggested text of what to file.
    • Remember, that the easier you make it for us, the more likely that we will actually file.

Thanks.


(Mark Alldritt) #23

My apologies. Of course, I should have explained this.

  • You need to have an Apple Developer account. The free one is fine.

    https://developer.apple.com/bug-reporting/

  • I fear giving boilerplate bug text because that will not be effective in helping Apple see the scope and range of the problems at hand. That said, when reporting a bug you need to answer these questions:

    1. What did you expect to happen (or what happened before)
    2. What is actually happening
    3. How do I reproduce the problem
    4. What is the environment you are using (apps, system versions, etc.)
    5. What is the consequence for you (least important part of the bug report)

    Where possible, you want to provide enough information that the folks within Apple don’t have to do much to see the issue for themselves. When providing sample code, make it the smallest possible example that illustrates the problem with the fewest external (i.e. non-Apple) dependancies possible. Screenshots, screencasts, etc. are all good ways of demonstrating the issue.


(Ed Stockly) #24

I’ve had a developer account since System 7 or 8. I’ve also filed numerous bug reports, and some of my bugs were fixed. One bug was in AppleScript before and after the move to OSX and was finally closed (something about not being able to get month as text or something).

It’s pretty easy to do, but it’s not like here with Mark and Shane. You file a bug report and sometime nothing happens for months, then they respond, and if they didn’t understand you have to start over. Other times they’re right on top of it.


(Phil Stokes) #25

Also, for anyone that ever signed up for the public beta testing program (even if you never actually bothered to take part), you can also report bugs through the built-in app “Feedback Assistant”. Type it in Spotlight to find it (it’s not in /Applications).


#26

Hi, my first post here as I was looking for discussions on the subject.

In my opinion, we should politely ask Apple to reconsider and abandon this approach altogether.

All it does is pesters users with unnecessary annoying dialogs. Nearly all users will dismiss them like annoying flies. Very few users will understand what they mean anyway, and of those few very few would care. And I highly doubt that any kind of additional “security” can be achieved by that.

To the developers it causes a measurable damage by making their products harder to use for no reason whatsoever. An example: user clicks “Don’t Allow” by mistake while using a software trial. As we all know, trial goes to trash to never look at again. And as a developer I sure don’t like any of this.

It makes using Mac yet more complex by adding some obscure unnecessary settings with no benefits to the user.

I’ll submit my suggestion to Apple bug reporter soon. Hopefully Apple will listen if they hear from plenty of users and developers.


#27

The difficulty, I think, is that there is an inevitable tension between security and automation. The balance of forces is bound to favour security – numbers affected, gravity of consequences, visibility in the press etc etc are all much higher on the security side than on the automation side.

Most big systems suffer from gradual bureaucratic encroachment over decades. macOS is still usable and even to a fairly large extent scriptable. We haven’t yet reached the stage of one of those hotels in which every floor has been taken over by administrative offices, and none are left for guests.

( I think Mark is right – a single bug report is worth a thousand impassioned voices in the wilderness. Much more likely to improve the quality of the relationship between automation and security )


#28

May I paraphrase Milton Friedman: A platform that puts security before automation will get neither…


#29

That might turn out to be true …

( but theory and principle never dent the balance of forces very much )