I’m not sure how you prove by negation in this case just via modus ponens. Care to enlighten me? I opened with something that doesn’t follow so that would be a great place to start.
Give me a consistent formal system with a list of theorems to prove OP’s conjecture and I’ll show you how we have gaps in the system. My analytic philosophy is pretty rusty; I think there are a few 20th century folks you can start from for this.
My degree is in combinatorics. All of the fancy words you’re not a fan of are core ideas (the Petersen graph is really neat). I view The Art… as an academic work for academics who aren’t necessarily excited about the real world (which is my approach to combinatorics). If you’re not one of those people, you’re not interested in becoming one of those people, or you don’t work/research something that needs incredible optimization, you can safely skip it. Once you go into heavy proofs, the utility is very debatable.
Speaking from 10+ YoE developing metrics, dashboards, uptime, all that shit and another 5+ on top of that at an exec level managing all that, this is bullshit. There is a disconnect between the automated systems that tell us something is down and the people that want to tell the outside world something is down. If you are a small company, there’s a decent chance you’ve launched your product without proper alerting and monitoring so you have to manually manage outages. If you are GitHub or AWS size, you know exactly when shit hits the fan because you have contracts that depend on that and you’re going to need some justification for downtime. Assuming a healthy environment, you’re doing a blameless postmortem but you’ve done millions of those at that scale and part of resolving them is ensuring you know before it happens again. Internally you know when there is an outage; exposing that externally is always about making yourself look good not customer experience.
What you’re describing is the incident management process. That also doesn’t require management input because you’re not going to wait for some fucking suit to respond to a Slack message. Your alarms have severities that give you agency. Again, small businesses sure you might not, but at large scale, especially with anyone holding anything like a SOC2, you have procedures in place and you’re stopping the bleeding. You will have some level of leadership that steps in and translates what the individual contributors are doing to business speak; that doesn’t prevent you from telling your customers shit is fucked up.
The only time a company actually needs to properly evaluate what’s going on before announcing is a security incident. There’s a huge difference between “my honeypot blew up” and “the database in this region is fucked so customers can’t write anything to it; they probably can’t use our product.” My honeypot blowing up might be an indication I’m fucked or that the attackers blew up the honeypot instead of anything else. Can’t send traffic to a region? Literally no reason the customer would be able to so why am I not telling them?
I read your response as either someone who knows nothing about the field or someone on the business side who doesn’t actually understand how single panes of glass work. If that’s not the case, I apologize. This is a huge pet peeve for basically anyone in the SRE/DevOps space who consumes these shitty status pages.
I thought it was jiff
If every request is an emergency that needs to immediately interrupt everything else, then your throughput is drastically reduced. The extra cognitive load that comes from the interrupts also affects throughput. If you constantly have to watch DMs/channels/email for work that might pull you away from your existing work, you’re not hitting a deep work state.
Unless your role is intentionally interrupt-driven requests, it’s much better to drop items in a queue to be processed regularly. The tighter the deadlines, the more important moving from interrupt-driven to queue-driven is. The last 30+ years of workflow research coupled with neuroscience have really highlighted the efficacy of queues.
The letter cites an ADL study that conflates antisemitism with anti-Zionism and doesn’t differentiate attacks on someone for being Jewish from valid criticism of Israeli apartheid. I’m not entirely clear how they reach their 73% number unless it’s the summation of several categories. If we remove Israel from the equation, there’s still a large percent, >40%, experiencing antisemitism and that’s not okay. I do think there’s something to look at here, given that the number of Jewish students feeling safe actively declined. I also think everyone will continue to conflate criticism of the Palestinian genocide with bigotry.
But it’s not public. It’s a private blockchain. The immutable ledger aspect only matters if everyone can see the ledger. Otherwise we take at face value all of the things you said. Assume they run one node and that one node is compromised by a malicious actor. The system fails. Extend it to a limited number of nodes all controlled by SREs and assume an SRE is compromised (this kind of spearphishing is very common). The system fails again.
Sure, you can creatively figure out a way to manage the risks I’ve mentioned and others I haven’t thought of. The core issue, that it’s not public, still remains. If I’m supposed to trust Proton telling me the person I’m emailing is not the NSA pretending to be that person (as the Proton CEO suggested), I need to trust their verification system.
This is how I read digitally ¯\_(ツ)_/¯
Spend a little bit of time writing out pros and cons when this happens. The important thing is to actually write it down; don’t just leave it in your head. If this is a regular conversation you have, keep that list handy and keep it updated. Make sure you’re taking into account time and resource considerations (eg running your own Mastodon instance requires money or time and effort) as well as soft considerations like social impact (eg you gotta convince all your friends to join Signal). Make sure to keep moving things around.
For me, the time and effort involving in running certain things just isn’t worth it to me. I have limited time available and I don’t often want to spend it fucking with servers. Convenience also plays into some of my comms choice because it’s just easier to use certain things to do the kinds of things I need to do.
I cannot stress enough that you should write this down. Getting stuff like this out of your head and onto paper has a lot of helpful benefits. You move the problem from your working memory and onto paper which helps reduce cognitive load (see Programmer’s Brain and sources). You have a discrete problem you can update without having to constantly rebuild the whole thing in your head (see How to Take Smart Notes and sources for the idea of the zettelkasten). And eventually you’ll be able to tell yourself why you do one or the other.
Can you help me understand which political petitions meant to document real constituent desires don’t require doxxing yourself? I don’t believe I’ve ever participated in any citizens initiative that didn’t require personal information.