<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 14 Jul 2016, at 17:48, Ford Prefect via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div style="font-family: Verdana;font-size: 12.0px;" class=""><div class="">One of the major security flaws of Obj C is</div>
<div class="">the ability to convert a string into a selector, which</div>
<div class="">permits using private methods by constructing selectors</div>
<div class="">at runtime long after the app store review has been completed.</div>
<div class="">Does Swift do away with that? I understand it doesn't</div>
<div class="">use selectors per se but is there an analogous mechanism?</div>
<div class=""> </div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""><div class="">As has been pointed out, Swift selectors are already much safer. I believe you can still convert a string to a selector, but really…</div><div class=""><br class=""></div><div class="">I wouldn’t call it a security flaw. Objects in Obj-C are free to pass messages around fairly loosely - sometimes the method you are trying to call doesn’t even exist but will be dynamically created and hooked up at runtime when you call it. This is a good article to learn more about how powerful Obj-C’s messaging system is: <a href="https://www.mikeash.com/pyblog/friday-qa-2009-03-27-objective-c-message-forwarding.html" class="">https://www.mikeash.com/pyblog/friday-qa-2009-03-27-objective-c-message-forwarding.html</a></div><div class=""><br class=""></div><div class="">It’s only a security flaw if you can somehow perform privileged operations from doing that. I’m not sure how the jailbreak community actually implements it, but I’d assume that to write out to system/non-app files they would need to disable sandboxing, which is what really gives you the security that apps won’t grab your data or make persistent changes outside of their own containers, or talk to the network when they shouldn’t (see: iOS keyboard extensions).</div><div class=""><br class=""></div><div class="">Yeah, you can call non-public APIs. That’s true in basically all software. The reason Apple discourages it isn’t for security - it’s so they don’t have to maintain code they never promised to maintain. It leads to more stable and reliable software.</div><div class=""><br class=""></div><div class="">It’s not really an undocumented API (really an undocumented behaviour), but there’s a famous lesson from Microsoft about this:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. <b class="">If it finds SimCity running, it runs the memory allocator in a special mode that doesn't free memory right away.</b> That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.</blockquote><br class=""></div><div class="">If you like that, Raymond Chen’s oldnewthing is a great source of Microsoft technical war-stories (<a href="https://blogs.msdn.microsoft.com/oldnewthing/" class="">https://blogs.msdn.microsoft.com/oldnewthing/</a>). But anyway, nobody wants that kind of headache, and then having to maintain those hacks for who-knows-how-long? That’s why they’re so strict about using official APIs and documented behaviour - because if you don’t, you’ll have to choose between breaking software and making users unhappy, or maintaining a collection of hacks to present the illusion of the old, never-intended-to-be-final behaviour.</div><div class=""><br class=""></div><div class="">Karl</div></body></html>