Apple aren't using that model just for security, but also so they can tightly control the platform and restrict what the device owner can do on it.
apple -> system preferences
security + privacy
General tab
Under "allow apps downloaded from:"
* Anywhere
Why is it ok on mac? Because many computer users are still dependent on non-appstore distributed software. Particularly developers. Nobody has evolved that dependency on ios, so it's not necessary.
It does not require "Click here to get owned" level of work around. I'm perfectly fine with needing to boot into the equivalent of single user mode and entering some security key. But if I want to break the security model on a device I own I should be able to.
> Why is it ok on mac? Because many computer users are still dependent on non-appstore distributed software. Particularly developers. Nobody has evolved that dependency on ios, so it's not necessary.
That is circular reasoning. The "dependency" doesn't exist on iOS because Apple tries very hard to prevent non-appstore distribution being a viable avenue for app developers.
You are misinformed. Right click -> Open instead of double click overrides my current signing requirements and executes the app anyway.
* The Mac App Store's business model, i.e. no upgrade pricing, no trial versions; content-wise, nothing that you wouldn't sell in Disneyland
* Paying $99/yr for a developer account, even for free apps
* App sandboxing
And even then, this still doesn't mean that all apps on the App Store are safe. Because you used to be able to submit unsandboxed apps; as far as I know, they have never been removed? Sigh...
But at least many of the currently un-sandboxed apps are moving to the browser (MS Office & Skype being my biggest worries).
But here's the thing: if you want a secure platform usable by the majority of people, the best choice (by a lot) is ios, followed by osx. The app store is certainly imperfect, but hopefully that will get tightened up over the next couple years.
Relatives who've been hacked ask for how not to get hacked, and my best answer is the above: use ios, particularly for banking. For a laptop, use osx and buy programs either from well known brands (adobe, microsoft) or buy app-store apps.
The "Selinux is too hard for mortals" thing is a relic from the early days of its inclusion into linux, and turning around this attitude is important.
I don't recall the last time I had to do a full relabel on a production system. Not saying it hasn't happened, but I can't recall an instance.
Overall, I spend less time managing SELinux (and that includes the custom policies I maintain) than I do managing IPTables. It's really not the nightmare it's made out to be.
Whereas on Android, people expect the barrier, and developers don't expect to be able to disable it.
I'm really worried that Linux has become a liability. The lax security practices of the culture its part of are obvious. What now? Do we migrate to OpenBSD? I've been considering this at work. It just seems that the culture surrounding OpenBSD just takes security more seriously.
The idea that we can just put a application on the internet sounds dangerous to me. If its isn't hardened by something like apparmor/selinux and also behind some kind of application-level firewall (or at least snort), then we're just asking for trouble. Something has to change. The status quo is now failing us. How many high-priority patches have there been in the FOSS world this year?
Sadly, I worry more about my linux machines than my windows machines.
Ubuntu has Mandatory Access Control in the form of AppArmor (https://wiki.ubuntu.com/AppArmor). It's switched on with a set of policies on the desktop (do sudo apparmor_status to see) and on the server.
On the mobile side a lot of work has been done to confine individual applications in a manner similar to Android. That's future work that could go into mainstream Linux eventually.
On the traditional server side both RedHat and SUSE have MAC on by default - for them SELinux I believe.
I’m running Yosemite 10.10.1; according to Activity Monitor, Dropbox, VimR and Terminal aren’t sandboxed.
Of course, many low-level processes aren’t sandboxed either.
In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach.
As with ANY language, if you write it badly, bad things will happen. The language choice doesn't mean bug-free code.
So, in essence this would mean to many that Rusts safety focus happens too late for it to be a big enough benefit for having to give up the investment in modern C++? As in, memory safety is a solved problem with modern C++?
The addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors.
It's a difficult habit to break though!
See Stroustrup's "The C++ Programming Language Fourth Edition" (the blue book) section 3.3.3 Resource Management and 3.2.1.2 "A Container", where in this early part of the book Stroustrup explicitly directs to 'avoid "naked" new and delete operations" and to "use resource handles and RAII to manage resources".
See std::move to force moving where it isn't clear that you're moving things.
Further reading: http://en.cppreference.com/w/cpp/language/move_operator http://stroustrup.com/C++11FAQ.html#default2
Only greefield projects can benefit from modern C++ and there are very few out there.
After reading the updated version of Effective C++, I doubt the average C++ developer will be able to deal with a mixed codebase of pre-C++98, C++98, C++03, C++11 and C++14.
But it helps to learn the new stuff and apply it within my own projects as best I can.
Though it seems that some languages, or at least how they are used, are more disciplined when it comes to treating things like SQL queries/commands; that they don't treat them as plain text, and instead assign some kind of structure/typing to the query command. Or don't they? I don't really know how SQL injections are handled in such languages, but I do know that some like to be more principled when it comes to SQL queries/commands in the source code text; like using macros to ensure that an SQL query doesn't have a typo in it. Maybe that kind of practice extends to validating user input.
Conceptually there are a ton of different string types. File names, path names, SQL query templates, SQL query strings, URLs, URL query parameters, command line arguments, full command lines, human-readable text.... Yet just about everything gloms them together into one "string" type. Even APIs that allow for structured construction of SQL queries tend to rely on the programmer not to put arbitrary data in the template bits. These really should all be completely separate types requiring conversion.
Or more recently and widely publicised, ShellShock.
Rust can't save you from that; pulling in libraries makes it way too easy to increase the surface area of your code by several orders of magnitude. Even assuming rust offers an order of magnitude better security than C/C++, it still can't keep up. Sure, it mitigates things a little, but only until the next whiz-bang library gets linked in (even if it's written in rust, it will have some flaws).
In other words, the security of a program is based on the absolute number of bugs in it; but a programming language can't do much more than reduce the ratio of bugs to program size.
The OS is in a much better position to address the problem.
Can you expand on that?
just one example: https://news.ycombinator.com/item?id=3191021