Michael TsaiVerified account

@rosyna Why not? Isn’t that part of why the Mac App Store requires sandboxing, as a backstop against malware?

@mjtsai No, it's so the developers can define the resources they need up front. This prevents bugs/bad coding from accessing other resources

@rosyna I don’t remember that being presented as the main motivation. I don’t think anyone’s worried about apps accidentally printing.

@mjtsai That was the only motivation when sandboxing was added to OS X for system services, which was before the Mac App Store existed.

@rosyna I’m not sure how the original reason the technology was developed is relevant to the policy decision about using it now.

@mjtsai Because it's never been used to protect against malicious apps. As I said, those apps can always ask the user which files to destroy

@rosyna Apple’s docs says "Enable App Sandbox to Minimize Damage from Malicious Code". https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AboutEntitlements.html …

@mjtsai @rosyna the last point is awful. “The sandbox is no good because Adobe didn’t use something that would have prevented the issue!“

@jimmyjamesuk123 @rosyna The point is that it’s perfectly understandable Adobe didn’t want to use the sandbox because of all its problems.

@mjtsai @rosyna no, his point was that the sandbox didn’t offer security when it in fact does.

@jimmyjamesuk123 @rosyna In this case it didn’t offer security because it failed to convince the developer that it was worth adopting.

@mjtsai @rosyna come on. This is a terrible argument. Developer doesn’t use a security feature: therefore feature doesn’t offer security!

@jimmyjamesuk123 @rosyna Consider a feature that prompts for every FS access. No security in practice b/c users will turn off or not read.

@jimmyjamesuk123 @rosyna You could blame the user. But I would say it’s a poorly designed feature that failed in the real world.