sylver_dragon

I'm not going to defend everything the TSA does. And they do have a lot of problems. But, the lines at the checkpoint are the result of trade-offs in security. For all things security related, it's about managing risk. You will never eliminate risk, so you need to pick and choose where to apply controls to reduce the worst risks and accept some risk in other areas.

Think about the possible outcomes from terrorist attacks on airports. There are several possible scenarios:

1. The attacker kills a few people in the airport using a direct weapon (gun, knife, etc.)
2. The attacker kills a lot of people in a small area with a area weapon (bomb, gas, chemical, etc.)
3. The attacker destroys an airplane in flight, killing everyone onboard.
4. The attacker hijacks the airplane and takes everyone onboard for ransom.
5. The attacker hijacks the airplane and uses it as a weapon, killing everyone on board and more people on the ground.

We could probably come up with other cases, but I think this covers the bulk of it. So, let's dive into managing these risks. What are the effects of such attacks, if successful?
Looking at case 1, how many people are likely to be killed? Well, that depends on the police response time and the effectiveness of the attacker's weapon. But, based on other mass casualty events, this probably falls into the range of 10-30 people. It could move outside this range, but this is pretty typical of such situations. To pick a number in the middle, will say they the expected loss for such an attack is around 20.
With Case 2, again there is variability. But, it's also something we have analogs for and may be able to put a range of casualties on. The Boston Marathon bombing in 2013 killed 6. The attack on Kabul Airport in 2021 during the US evacuation killed 182, though that also included multiple gunmen attacking after the explosion. Let's put the loss rate around 50 for as single bomb, assuming a very packed area and a very effective bomb.
For Case 3, the numbers are a bit easier to get a handle on. Typical airliners carry anywhere from 100-200 passengers. The 737 MAX 8-200 is designed for 200, while the Airbus A200-100 carries around 100 passengers. We'll pin the loss rate here at 150, as attackers are likely to target larger aircraft for this sort of attack.
Case 4 is basically Case 3, but with an optional loss of only money. For that reason, I'm going to remove this case, but wanted to mention it to avoid the "well akshuly" crowd, since this is a historic problem.
That leaves Case 5. And it's Case 4's situation, plus some number of people on the ground. Certainly, not every such use of an airplane as a weapon will be as successful as the attack on 9/11. And that also involved multiple successful attacks. But, let's assume that such attacks will hit populated buildings and cause significant damage. We'll pin the expected loss at 200, This is 150 for the airplane and 50 on the ground, somewhat equivalent to Case 2 with a bomb in a crowded area.

Ok, so we have expected losses, now lets talk about how often we expect such attacks to happen? And yes, this is a rough guess. But, since terrorists are unlikely to publish their plans, it's the best we can do. We also face a difficulty in that these are still (thankfully) pretty rare events. And trying to extrapolate from a small set of data points is always a fraught exercise. So, fell free to quibble over these numbers, but I don't think any numbers which fall into a reasonable range will change things much.
Case 1 - This attack as a pretty low barrier to entry. If a person can be found to perform the attack, arming them isn't terribly hard. So, we let's assume we get 2 of these attacks a year. I don't think we're actually getting that, but out goal is just to get into the right ballpark.
Case 2 - This attack takes a touch more work, bomb making isn't that hard, but making a really effective one isn't easy either. This type of attack does have the advantage that it doesn't always require the attacker to die in the process. So, it might be easier to find someone willing to engage in such an attack. Let's call this 1 per year.
Case 3 - This also requires a bomb, but it may not need to be quite as big to be effective. Granted, modern aircraft can be amazingly resilient (see Aloha Flight 243). This attack also results in the attacker dying, so that can be a bit harder to source. So, lets say this happens once every other year, or 1/2 per year.
Case 5 - So, no bomb this time, but you have to have an attacker not only willing to die in the process, but also go through enough flight training to fly the aircraft to it's target. And you need the training itself. Plus, the attacker needs to get a weapon onto the aircraft. And since they need to overpower 100-200 people who might just take exception to the hijacking, you probably need multiple attackers willing to die in the attack. This is a pretty high bar to clear; so, let's say that these attacks happen at a rate of 1 every 5 years.

Ok, so let's consider our Annualized Loss Expectancy (ALE) with what we have:

| Case | Loss Expectancy | Frequency | ALE | |

|

|

|

| | 1 | 20 | 2 | 40 | | 2 | 50 | 1 | 50 | | 3 | 150 | 0.5 | 75 | | 5 | 200 | 0.2 | 40 | | Total| - | - | 205 |

Alright, so lets start talking about controls we can use to mitigate these attacks. By raw numbers, the thing we should care about most is Case 3, as that has the highest ALE. So, what can we do about bombs on airplanes? Making them more resilient seems like a good start, but if we could do that, the military would have done it long ago. So, really the goal is to keep bombs out of airplanes. And that's going to mean some sort of screening. We could just say "no carry on, period" and move the problem to the cargo hold. This would reduce the frequency of Case 3 and Case 5, as it would be much harder to get a bomb or weapon onto an airplane, without a bag to hide them in. But, travelers are not likely to give up all carried on bags. So, that really leaves us with searching bags and controlled checkpoints to do it. Of course, as has been noted, this would likely mean that Cases 1 and 2 become deadlier. Let's put some numbers to it. Let's say that checkpoints reduce the frequency of Cases 3 and 5 by a factor of 4 and increase the Loss Expectancy of Cases 1 and 2 by 1.5.

| Case | Loss Expectancy | Frequency | ALE | |

|

|

|

| | 1 | 30 | 2 | 60 | | 2 | 75 | 1 | 75 | | 3 | 150 | 0.125 | 18.75 | | 5 | 200 | 0.05 | 10 | | Total| - | - | 163.75 |

And we could push the numbers around for the effect of the checkpoints. And we could look at other controls or controls in combination. But, this is the sort of risk analysis which would need to be done to make such decisions. And, ideally, the numbers chosen would be done with a bit more care than my rectal extraction method. Can I say that anyone at the TSA/DHS/etc did this sort of analysis? No, but I suspect there has been some work on it. And it probably does lead to the conclusion that the expected loss is lower for airports with checkpoints than airports without. Though, that doesn't excuse the TSA's abysmal track record for tests done by the FBI.

So, folks have had two years to change their passwords and/or do anything proactive to not get breached? And they have apparently done fuck all in that time? The old saw, "a fool and his money are soon parted" comes to mind. Though, two years isn't exactly "soon".

It's right there in the article:

Reviver's $29.99 monthly subscription fee.

What, you thought this was supposed to help the customer?

Reviver's $29.99 monthly subscription fee.

Someone, somewhere is making money on these and probably providing ~~kickbacks~~ campaign contributions to get laws passed to allow this sort of stupid.

Woohoo! Take that haters. Fusion is no longer perpetually a decade away. It'll just be ten years now!

/s - 'cause, this sounds like a VC funded pipe dream with lots of aspirations and zero evidence.

Bit of a mixed bag:

Sony is not acquiring FromSoftware parent company Kadokawa Corporation after all.

but...

Sony Group become Kadokawa’s largest shareholder with 10% of its shares
The alliance will also see Sony distribute and publish Kadokawa’s anime and video games.

So, not complete control, but Sony is defiantly going to dick around customers.

There are a lot of Linux based hand-held devices which may be a better form factor for you. For example, something like this (I have not used this device, just picked an example) might not be a bad fit. At 12cm on it's long axis, it's not terribly big, and lacks a joystick. Looking out at reviews, the battery life seems to be in the 8-10 hour range.

Others in this community may have other, better recommendations. But, there are a lot of choices in this area. I recently bought two of these for my kids for Christmas. And after playing with them to set them up, I was impressed for what it was, at the price point it was offered.

I don't know of anything that fits your requirements. But, if you don't mind a tangent, it appears that Pokémon: Infinite Fusion has both Windows and Linux releases, would it be acceptable to run it under one of those OSs and use the applicable version of the application? There are a lot of Linux based handhelds on the market, and it should be possible to find something which works for you using Linux.

My list of items I look for:

• A docker image is available. Not some sort of make or build script which make gods know what changes to my system, even if the end result is a docker image. Just have a docker image out on Dockerhub or a Dockerfile as part of the project. A docker-compose.yaml file is a nice bonus.
• Two factor auth. I understand this is hard, but if you are actually building something you want people to seriously use, it needs to be seriously secured. Bonus points for working with my YubiKey.
• Good authentication logging. I may be an outlier on this one, but I actually look at the audit logs for my services. Having a log of authentication activity (successes and failures) is important to me. I use both fail2ban to block off IPs which get up to any fuckery and I manually blackhole entire ASNs when it seems they are sourcing a lot of attacks. Give me timestamps (in ISO8601 format, all other formats are wrong), IP address, username, success or failure (as a independent field, not buried in a message or other string) and any client information you can (e.g. User-Agent strings).
• Good error logging. Look, I kinda suck, I'm gonna break stuff. When I do, it's nice to have solid logging giving me an idea of what I broke and to provide a standardized error code to search on. It also means that, when I give up and post it as an issue to your github page, I can provide you with some useful context.

As for that hackernews response, I'd categorically disagree with most of it.

An app, self-contained, (essentially) a single file with minimal dependencies.

Ya...no. Complex stuff is complex. And a lot of good stuff is complex. My main, self-hosted app is NextCloud. Trying to run that as some monolithic app would be brain-dead stupid. Just for the sake of maintainability, it is going to need to be a fairly sprawling list of files and folders. And it's going to be dependent on some sort of web server software. And that is a very good place to NOT roll your own. Good web server software is hard, secure web server software is damn near impossible. Let the large projects (Apache/Nginx) handle that bit for you.

Not something so complex that it requires docker.

"Requires docker" may be a bit much. But, there is a reason people like to containerize stuff, it avoids a lot of problems. And supporting whatever random setup people have just sucks. I can understand just putting a project out as a container and telling people to fuck off with their magical snowflake setup. There is a reason flatpak is gaining popularity.
Honestly, I see docker as a way to reduce complexity in my setup. I don't have to worry about dependencies or having the right version of some library on my OS. I don't worry about different apps needing different versions of the same library. I don't need to maintain different virtual python environments for different apps. The containers "just work". Hell, I regularly dockerize dedicated game servers just for my wife and I to play on.

Not something that requires you to install a separate database.

Oh goodie, let's all create our own database formats and re-learn the lessons of the '90s about how hard databases actually are! No really, fuck off with that noise. If your app needs a small database backend, maybe try SQLite. But, some things just need a real database. And as with web servers, rolling your own is usually a bad plan.

Not something that depends on redis and other external services.

Again, sometimes you just need to have certain functionality and there is no point re-inventing the wheel every time. Breaking those discrete things out into other microservices can make sense. Sure, this means you are now beholden to everything that other service does; but, your app will never be an island. You are always going to be using libraries that other people wrote. Just try to avoid too much sprawl. Every dependency you spin up means your users are now maintaining an extra application. And you should probably build a bit of checking into your app to ensure that those dependencies are in sync. It really sucks to upgrade a service and have it fail, only to discover that one of it's dependencies needed to be upgraded manually first, and now the whole thing is corrupt and needs to be restored from backup. Yes, users should read the release notes, they never do.
The corollary here is to be careful about setting your users up for a supply chain attack. Every dependency or external library you add is one more place for your application to be attacked. And just because the actual vulnerability is in SomeCoolLib.js, it's still your app getting hacked. You chose that library, you're now beholden to everything it gets wrong.

At the end of it all, I'd say the best app to write is the one you are interested in writing. The internet is littered with lots of good intentions and interesting starts. There is a lot less software which is actually feature complete and useful. If you lose interest, because you are so busy trying to please a whole bunch of idiots on the other side of the internet, you will never actually release anything. You do you, and fuck all the haters. If what you put out is interesting and useful, us users will show up and figure out how to use it. We'll also bitch and moan, no matter how great your app is. It's what users do. Do listen, feedback is useful. But, also remember that opinions are like assholes: everyone has one, and most of them stink.

I think it depends on what you want to print. Personally, most of my prints fit within a much smaller footprint. So, I don't usually need my first layer to be perfect across the full bed. However, when trying to print something larger, I can absolutely tell how terrible my first layer is. It sucks to end up reprinting the first layer half a dozen times, because one small area keeps failing to adhere.

A large part of my issue is the printer I have just isn't all that good. And, when I get less lazy, I'm going to just build a Voron. At that point, I'll probably be one of those folks tweaking it until I get a perfect first layer. Because I want to be able to start a print and not spend the next hour fighting first layer problems.

This educational bot will be a continuing lesson to kids on why you don't buy "cloud driven" shit. It's also a great conversation starter for teaching kids about corporate greed, designed obsolescence and enshitification.

Make sure those tablets get baked by a fire when your city is pillaged and burned. Raw clay doesn't stand up well to water.