This is what I find so fascinating. Yes, it cannot be intercepted in transit. But nothing is stopping the keyboard on which I type or the text box in which I type from collecting all the things and sending those things where ever they want. In-transit interception, in this context, seems like a fruitless threat model when compared to the keyboard/text box vector.
With respect to facebook in particular, they have had the means of reading the messages on either side for ages, even before it was required by law. iOS and Android both have "leaky sandboxing", where certain apps from the same publisher can read each other's data and memory, and Facebook added WhatsApp to its sandbox almost immediately after acquiring it, allowing the main Facebook and Messenger apps to read all the messages received by WhatsApp.
Yup, I self-cite quite a bit. But not to demonstrate productivity or some other arbitrary metric(s). I self-cite because the images I use in my research are really difficult to make and I'm in a niche enough field that using the images really helps people who are not familiar with the area understand what is going on. These images were arduous to make, so I reuse them. (I should note, that I've gotten in "trouble" for reusing them without a citation).
I'm curious if this SPoF theory stops at computer/real world interfaces (such as the control surface <-> computers). Or if this generalizes into purely computational models. In my mind I can't find any purely computational model using distributed techniques that succumbs to the SPoF "theory." But the computer/real world interface is trivially obvious in just about every context.
I'm slightly annoyed that this only describes the implementation. It would be very helpful for those beginning to study this area to see the formulations of these problems in mathematical notation. (Yes, some of them are trivially identified. Others, however, not so much.) Seeing the translation from S{M|A}T into the implemented formulation (on, in my case, the reverse) was helpful in my understanding of how this whole sub-field works. Otherwise, though, this is a remarkable resource for understanding problems and how to translate them into S{M|A}T
My goal when interviewing candidates is to ellicite this response at least once. I want someone who is honest that they don't know the answer and won't bullshit me about it. Also like to hear how the candidate would go about figuring it out, e.g. what resources they would use. I'm also fine with speculative answers as long as they're clearly stated as such, "I dont know, but I think it'd be something along these lines..."
Yeah, in an interview, I would certainly expand on that succinct motto; and attempt to do exactly this. But, as others have suggested, people respond too much instead of just thinking about a problem/issue/comment/etc. from all the angles (this skill was natural for me; but honed during the Ph.D. process.)
That same nugget was in The Pragmatic Programmer which I recently have been reading. In regards to estimates or questions about things you don't know, if you can't give a good answer on the spot the second best answer is "Let me get back to you.". The bad answer or estimate will just cause pain for your team/org.
The only way I've been able to make any sense of CMake docs is in conjunction with examples -- searching on Github/enormous open source projects using it (e.g. LLVM). Just reading CMake docs to understand how to use directive x almost always leads to failure.
Whatever medicine I give the school to administer to my child at the appropriate times has to be observed; the school cannot wantonly withhold the medications I provide them, especially when provided a Dr's note.
If I send my child to school with an "off-brand" epipen with a doctor's note and direct the school to use this instead, they have to observe it -- a nurse is in no way capable of making a drug administration decision without the consult of a licensed medical doctor.
But what if they fuck it up and your kids dies? That's the (not totally irrational) fear - parents want the nurse using something they are already familiar with.
In England the protected title is "Registered General Nurse" or "Registered Mental Health Nurse" - a registered nurse is qualified to a certain standard and has a professional registration.
Nurse isn't a protected title, so it's possible a school nurse has minimal qualification and no professional registration.
I had an EpiPen and various other stuff when I was in 5th grade. I was taught to use it. If a nurse is incapable of administering it properly that person needs to find a new line of work.
I would envision this system to be something such as:
We have a set of standards that define what negligence looks like for data breaches, security, etc. If a company is found to not adhere to these standards they would be found negligent and assessed some financial penalty.
If a company is found to be adhering to the standards, and is hit by a 0-day, the financial penalty would be negligible or 0.
This is a huge unsolved problem in journalism: reporting whether a company was wildly negligible and deserved to be punished, or did the right things and fell victim to “no org can be bulletproof”
Some standards like PCI attempt to do this, but to date they have no real teeth. GDPR may be the change we need.
I have deep concern that C-levels will learn that breaches don’t matter, just have a CISO you can behead and replace when it does.
There are certain things that are, collectively, patently negligent: storing passwords in plain text, not salting passwords, not using, at a minimum, software firewalls, etc. Those are fairly boolean. It's also fair to assume that any company that is hit with a 0-day is not negligent; even the best prepared companies are susceptible to them. So there is some decent guidelines to rely upon to demonstrate negligence or not on the extremes. Of course, in the middle it does, admittedly a bit gray. But the teeth that come into play would look exactly like GDPR.
Yes, I agree completely, that C-levels will see that the CISO is a replaceable widget that is nothing more than a scapegoat.
