|
|
Subscribe / Log in / New account

Design for security

Design for security

Posted Feb 21, 2019 3:41 UTC (Thu) by fest3er (guest, #60379)
Parent article: Design for security

The real problem can be illustrated by a quote from the movie, Cool Hand Luke: "What we've got here is failure to communicate." After 40 years in the field, I *still* find evidence of far too many software professionals who either can't or won't clearly communicate their thoughts to other people.

It gets down to the most fundamental characteristic of inter-human communication: the fact that *all* human languages are programming languages because human language is the effort of one person to program others' neural nets to think her thoughts. Some day I'll challenge all software people to master English (or at least master their native languages). The internet is rife with examples of ambiguous human programs. Shoot, a reading of NHRA's carefully-prepared rule book will reveal lots of ambiguities; some rule is intended to prevent injury A, so the racer must do Q but the rule, as written, allows lesser X, Y, and Z actions as well. (As much as I try to write clear English, I often still fail to communicate my thoughts to others; I'm sure this missive will be no exception.)

The BeyondCorp security model was mentioned, in that it opened one's private internetwork to the universe. Something that isn't quite as bad is TLS because it bypasses the private internetwork's perimeter firewall. Once the encrypted link it established, the firewall cannot block malware or theft. IMO, the time of SSL/TLS is long past and it should be largely retired; the recent push to shove TLS everywhere is misguided at best. The proper solution is host-to-gateway and gateway-to-gateway opportunistic encryption. Prevent deliberate, casual or incidental observation of private/confidential data, but allow perimeter firewalls to block trojans, viruses, ransomware, phishing, data theft, and other 'crimes'. (People who are terrified that someone might see what they're doing on an internetwork probably shouldn't be using the net in the first place. IMO.) VPNs must be allowed, but all network traffic other than the VPN should be forced through the business/SOHO/personal firewall so that it can be filtered and inspected for malware. Most people don't use VPNs because most software engineers and programmers make it too hard to use.

Basically, I generally agree with Miss Chen. Usability and security must go hand-in-hand. Engineers, programmers and coders nede to learn to think like ordinary people; they need to crawl out of their virtual universes and learn to communicate with non-technical people. And non-technical people need to learn some of the tech terminology so they can more readily learn how to best use the tech they own. Many smart phones have multi-GiB RAM because people don't know or don't care that they have 500 apps open. When I finish using an app on my phone, I close it; I think the most apps I ever had open at one time was 8. When I need the net, I turn WiFi or cell data on. When done, I turn them off.


to post comments

Design for security

Posted Feb 22, 2019 15:16 UTC (Fri) by nix (subscriber, #2304) [Link]

The proper solution is host-to-gateway and gateway-to-gateway opportunistic encryption. Prevent deliberate, casual or incidental observation of private/confidential data, but allow perimeter firewalls to block trojans, viruses, ransomware, phishing, data theft, and other 'crimes'. (People who are terrified that someone might see what they're doing on an internetwork probably shouldn't be using the net in the first place. IMO.)
And what do you do when you work, as I used to, for a megacorp with a centralized, out-of-touch, uncontactable security department that listens mostly to expensive consultants and flatly refuses to allow things that entire national divisions need to do their jobs? Just sit there all day and do no work?

People bypass security when it impedes them. Otherwise, they mostly ignore it. You can't get rid of that by saying "but nothing should be encrypted except via gateways operated by the Right People": if the Right People are idiots, this will not help, and it makes the gateways into a huge target that attackers will naturally penetrate, and now they have everything so you are paying the cost of security for nothing.

Many smart phones have multi-GiB RAM because people don't know or don't care that they have 500 apps open. When I finish using an app on my phone, I close it; I think the most apps I ever had open at one time was 8.
This seems utterly bizarre to me. I just leave things open and let the phone transparently close things in the background when memory is short. Usually the only visible effect of this is having to go back in via the home screen, and a slight delay on switching back as the app reloads its state. Why do you care if the app is being persisted in normal use, any more than you care which pages are in the page cache in normal use? Why on earth would you try to kick things out, unless you like making your own life harder?

Design for security

Posted Feb 22, 2019 19:36 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

One does not have to believe oneself to be a Designated Undesirable to prefer that one's internet traffic be end-to-end encrypted rather than per-hop encrypted.

My ISP's gateway, my bank's ISP's gateway, and the six other gateways between my ISP's gateway and my bank's ISP's gateway have no business being able to know my access credentials for my bank's online services.

Design for security

Posted Feb 23, 2019 17:34 UTC (Sat) by jezuch (subscriber, #52988) [Link] (1 responses)

In addition to what others said...

How do you guarantee that the gateways do not cheat and are not sending data unencrypted? How do you verify this? It's like today's email: how do I know that my mail provider is not broadcasting my poorly written and utterly embarrassing (but really sweet to the addressee) love letters to other mail exchanges as plain text? (An obvious response to an obvious retort: mail encryption is rubbish and my girlfriend refuses to use it.)

BTW, you may be confused that when you "close" an app it is in fact closed. More likely it is just removed from the list of recent apps, unless you're going to the settings > applications > particular app > stop process > yes, I really want to kill it and I know it may break the app. It gets tiresome really quick.

Design for security

Posted Feb 23, 2019 23:59 UTC (Sat) by excors (subscriber, #95769) [Link]

> BTW, you may be confused that when you "close" an app it is in fact closed. More likely it is just removed from the list of recent apps, unless you're going to the settings > applications > particular app > stop process > yes, I really want to kill it and I know it may break the app. It gets tiresome really quick.

The "Recents" screen shows activities and tasks (which I think correspond to certain Java objects), not apps or processes. When the user closes something from that list, I think it does destroy the activity if it's still alive, per https://developer.android.com/guide/components/activities..., so it's doing more than just hiding it from the list. But it still probably won't terminate the process if that was its last activity - it just increases the likelihood of it being chosen by the Low Memory Killer when someone else wants the memory.

Conversely, an activity can remain in the Recents list after its process has been terminated by the LMK. A new process can be started and told to resume that activity. So there's little correlation between process lifetime and activity visibility.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds