> If you are not involved directly with any of that professionally, it is better to treat it the way non-developer treat the OS. Assume it will work as intended because loads of highly trained professionals take care of it. Added benefit ehen it comes to aviation: strict and sensible regulation (the MAX disaster notwithstanding).
Allow me to chime in and respectfully disagree with this sentiment and the metaphor.
As the saying goes - the aviation (just as the automotive) industry saves lives (as in "advances security") one accident at the time. It would make sense that close calls like this Austin near mass casualty event should contribute to the future safety as well. In that context, it's absolutely legitimate to be suspicious and ask safety-related questions, including in a HN comment or in real life - instead of shutting someone down.
Speaking of the developer-OS metaphor - any non-rookie developer should be aware of not only the security and vulnerability of one's own software but also of the security and vulnerability of the underlying OS, infrastructure and even hardware. The number of building blocks gets larger by the day and nearly each building block is becoming increasingly complex. Yes, there are professionals working on each those blocks yet there are new CVEs and associated attacks all the time (incl. ransomware). If we add 0-days into consideration (a.k.a. "the unknown unknowns" in the software context) IMHO we should be able to conclude that the used developer-OS metaphor is not helpful.
The older and more experienced we all become, the more should we be cognizant of the potential risks (not only in our particular industry niche) and we should welcome and consider a normal, widely accepted practice to challenge the status quo and pose questions that should overall increase the number of brains and eyeballs on the problem and (unknown) unknowns - be it vulnerabilities or security risks, especially to our bare lives.
Speaking of Android and its derivatives prior to the upcoming Marshmallow release (version 6), the permission model was based on all-or-nothing approach ("all" accept all permissions and STFU; "nothing" meaning not installing an app). There's a huge difference between informing user at install-time about all permissions an application requires and (not) knowing when they're used in run-time. In the Android world of cca hundred permissions and this all-or-nothing permission model, overall UX has suffered and caused tension between users and developers. As the latter keep adding features to their apps, sometimes requiring new permissions, some (aware and tech-savvier?) users will not feel comfortable about and even decide to uninstall the app just like some Spotify Android users already have.
In this regard I've had a good experience with Privacy Guard feature on CyanogenMod 11 (based of Android 4.4 KitKat) and later. It allows you to control each app's access to a permission - allowed, ignored (disallowed), or "always ask". The last one triggers a popup whenever an app X wants to user permission Y (e.g. "Skype wants to modify your contacts" - wait what?!) where you can allow or ignorile it, and also set it as a future default to prevent being nagged with the popup. Although I personally very much like the option to opt-in or opt-out, I understand that even Privacy Guard UX is not for everyone. Luckily, you can choose if you need Privacy Guard and activate it per app, or have it automatically activated for every newly installed app with the "always ask" option for each permission.
According to their FAQ it is very much possible to swim in the canal under certains conditions that they mention as well.
https://schwimmvereindonaukanal.org/FAQ-en-1