4 ms·
On what the article claims: my understanding is that the sandbox restricts all non-user initiated actions. That is, if a user initiates it by clicking, dragging
by voxmatt 15y ago
On what the article claims: my understanding is that the sandbox restricts all non-user initiated actions. That is, if a user initiates it by clicking, dragging, OK-ing, etc., then all the old system interactions are still allowed. If you want to take a screenshot, of course you can so long as the user hits a keyboard combo to do it.
Where it's a real hurdle, however, is for those programs who have to monitor and interact with files outside its sandbox without user interaction. Take fantastical, it has to check the user's iCal calendar (or iCloud, or whereever that file is these days) persistently. If it can only do that when the user tells it to, it loses a lot of its appeal and functionality.
That being said, I think these rules actually make a lot of sense on the balance. But it would be nice to allow the user to authorize complete access in some sort of double-verified-super-secure-foolproof way.
- JonLim 15y agoIn that situation, would the user be able to enable a persistent permission? Whereby I allow the app to check as often as it needs to?
- pavlov 15y agoOn what the article claims: my understanding is that the sandbox restricts all non-user initiated actions. That is, if a user initiates it by clicking, dragging, OK-ing, etc., then all the old system interactions are still allowed. If you want to take a screenshot, of course you can so long as the user hits a keyboard combo to do it. How would that work? How does the system determine that the user intended for this particular action to take screenshots of other applications' windows?
- voxmatt 15y agoI'm certainly no expert here, so take my thoughts with a large, large block of salt. By way of example, I do know that the typical action of dragging a file on to the application's icon in the dock will allow an app to open that file, just as would the open file dialog. Not allowing this would be, obviously, unworkable. Similarly, I believe (although I don't know) that a key-combo associated with that app (as is usually used to invoke screenshots) would signal that the user is acting on the application and, hence, authorizing the action. Although, I'm not sure screenshots would be inhibited by the sandboxing to begin with...
- halostatue 15y agoThere's APIs to interact with the calendar store; no calendar application should ever be accessing the calendar files directly—so apps like Fantastical are probably already OK. I haven't deeply examined the sandboxing rules and capabilities, but I think that this could improve application interoperability because they will need to work through APIs directly rather than through filesystem backdoors.
- flomo 15y agoThe prominent API for this type of data exchange is AppleEvents, which apparently won't be allowed without special permission. (Perhaps there is some other sandbox-friendly way to get calendar info ... I don't know.)
- deleted 15y ago[deleted]