On 28 May 2012, at 4:30 PM, Shawn Bakhtiar wrote:

> First off (as much as I agree with the sentiment) isn't WTF profanity?

Yes it is. Personally, I never use it, but I'll pass it unaltered to preserve 
mail threads or to quote accurately.

> Second, and more to the point of my sentiment, and I hope someone on the 
> Apple development team is reading this, have you people gone absolutely mad!

1. Sentiment isn't really what a technical mailing list is about. It's for 
mutual technical assistance, not torches and pitchforks.

2. There are some people from Apple who read these lists. They do so in their 
spare time. They are not in a position to influence policy. They do not 
generate bug reports from postings (go to bugreport.apple.com and file a report 
yourself). They are often very helpful, and flooding them with sentiments will 
just drive them away.

3. You're waking up nearly a year late. Apple documented this requirement last 
June. Apple has already been subjected to all the sentiment anyone can muster, 
and has made sandboxing entitlements more flexible in response. Sentiment, 
without documented use cases and concrete (I will add _informed_) suggestions 
for improvement, won't accomplish anything at this late date.

> Thankfully I write apps for custom in-house applications so no big deal to 
> me, but even if I had too, why in God's name would I distro via the app 
> store, when I can simply setup an old fashioned download on an e-commerce 
> site for my app?! 

Sandboxing isn't for everybody. Apple never said otherwise. As in so much of 
engineering, you choose your tradeoffs. If you can't sandbox, don't submit the 
app to the MAS. 

The tradeoff is that most developers don't have the resources to handle 
publicity, distribution, updates, or worldwide payments, and the MAS does those 
things for them. (You can afford time and money to do those things for 
yourself? Fine. Not everybody can eat cake.) The MAS makes more money for most 
developers. With sandboxing, it also provides customers more assurance than 
they otherwise would have that the apps they buy won't damage or steal their 
data.

> it's a WHOLE other idea to have no technical users dealing with app signing 
> issues, et al...

Eh? The app is signed by the developer. Apple countersigns it. The user never 
sees a signature, except that breaking a signature will break the app. As far 
as it goes, that's a good thing.

> how many Windows, Linux, etc, users actually get hacked via downloaded 
> applications VS. going to some malicious website that uses OS/browser level 
> vulnerabilities (how does sandboxing prevent, for example, flashback)? When 
> 99% of all security breaches in companies are as a result of a disgruntled 
> employee (from the inside), or sabotage (from the inside) what does 
> sand-boxing REALLY prevent?
> 
> Nothing. It prevents nothing.

Sandboxing does not prevent determined attacks from hostile insiders. It is 
also COMPLETELY USELESS at promoting sound practices of regular oral hygiene. 
Suggesting a system is 100% useless if it isn't 100% miraculous is a strawman.

My guess is that most of the real-world exposure Apple customers have is to 
Trojan applications, or applications that provide more capabilities to exploits 
than the apps themselves strictly need. Sandboxing an application mitigates the 
exposure through that app.

Sandboxing isn't 100% miraculous. Individual developers will have perfectly 
legitimate reasons to do things that would be serious security holes if those 
things were allowed to everybody. Those legitimate features will be frozen out. 
The implementation will have bugs for years to come, and it is alarming that 
Apple saw nothing wrong with making it compulsory before completely thinking it 
out. 

Sandboxing can be an annoyance. But on its own terms, it's not an outrage. If 
you can't live with it, you're thrown back on distributing and selling your 
application yourself. Which is no worse than the position you were happy to be 
in a year ago.

        — F


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to