I always had a keybind to toggle gaps. sometimes certain layouts just feel congested, and the gaps put spaces between the windows and helps them feel like they are in their own space (even though it makes them even smaller). It's purely psychological and often doesnt make sense, but it's not just "show off the wallpaper and waste real estate", it's for mental processing.
And same goes for the icons. I've personally never gotten there. but also, I don't look at the icons. They could be hidden. I know if I need to get to slack or email, it's on workspace one. So if the workspace badge says "1" or "1: Comms" or "" ... it doesn't really matter, because the keybind is muscle memory anyway. But on the flip side, because all of that is muscle memory... I might go "Where was my email at again? Workspace 1, or 2?" and having an envelope as the label makes it easier to find.
Different people have different workflows. And yes, some people are doing those things to sacrifice usability in the name of aesthetics, but some people may be GAINING usability by doing these things. People are vast and diverse.
Even this only reviews "Smart Detections" and I have smart detections turned off on my Unifi cameras, because it enables cloud AI. Having the ability to have an AI key to process detections locally would be great.
Also, having to buy extra hardware kinda stinks. Would love to be able to have a self hosted Unifi OS server that can do AI key abilities if the hardware supports it.
There is indeed a fine line between desktop environment and complete DE ecosystem.
Having spent a long time on i3wm, I learned a lot about how to build your own DE effectively. These days I'm on KDE but definitely don't just assume that I want to use the kTool for everything, I've brought a lot of things from my i3wm days with me.
> I, like many hackers, hated school because they just threw one-size-fits-all knowledge at you
"This specific knowledge format doesnt work for me, so I'm asking OpenAI to convert this knowledge into a format that is easier for me to digest" is exactly what this is about.
I'm not quite sure what you're upset about? Unless you're referring to "one size fits all knowledge" as simplified topics, so you can tackle things at a surface level? I love having surface level knowledge about a LOT of things. I certainly don't have time to have go deep on every topic out there. But if this is a topic I find I am interested in, the full talk is still available.
Breadth and depth are both important, and well summarized talks are important for breadth, but not helpful at all for depth, and that's ok.
In the coming years, you will be paying AI companies a cut of your salary. It will be the cost of doing buisness. People will be so dumb they wont be able to tell whats an AI halluciation or not. We will continue to enter our every thought into the AI until it can replace us at that task. Your job will become AI slop input -> AI slop output. Everyone will conform on a natural optimisation point.
This all discounts how human variation and thinking is critical to the advancement and survival of the species being adaptable as possible to the climate and conditions of the given day. We didnt get to moon on the back of one person or race. The AI can only emulate what it sees, it cant have ideas of its own. The dawn of AI will never be seen again, all AI will suffer from the collective delusion to the point your freedom will be defined by not truth.
I once had an employer that required us to use passworded SSH, and disallowed SSH keys, because they couldn't enforce that the SSH keys were passphrase protected, so just turned that option off.
PCI DSS from 4.0 actually have something called customized approach for everything. If you can prove and the QSA agrees that you fullfill the goal of a requirement, you can be quite flexible. Example i am doing things like not using passwords at all and only passkeys, or only ssh keys protected by hardware security key etc. Together with agents trying to verify the devices connected are company owned and hardened in different ways.
Your milage might vary depending on how good your auditor is but PCI DSS standard do have quite a bit of flexibility in it.
Presumably at some point in your environment you are doing MFA? Just not at every step?
Ie If someone broke into your office, opened computer, inserted the hardware security key, would they get in? Or is there something else non-physical going on? Like the initial login is password + security key, and you can demonstrate the ssh keys never leave the secured PCs etc.
It is not about MFA or not but to demonstrate the process is secure for the purpose.
It can be complicated but a example. TOTP that is very common used with passwords is regarded as MFA (tho most of the time software based on phone) but have many problems regardless
- many time replayable
- can be intercepted
- implementations look different
- recovery code reuse problems
etc.
On the other hand, using only passkeys dont have those problems but with passkeys, many times you cannot decide on what device a user have registrated the passkeys in a enterprise setting. example they could be apple passkeys, chrome passkeys, windows, hardware key(yubikey) etc and all of them behave different when it comes how they ex can be copied/ synced between users devices. So from where they can be used.
So for any authentication flow, you need to look at the full picture. What is the process when credentials are lost? How do user onboard etc.
Is a good entry point to say. We should use MFA or similar but the details matter.
Yes, via PAM, and this works fine with OpenSSH. But the couple of OTP implementations I've used are the same, you can either provide password and PIN or passwordPIN. In the end they get concatenated, passed to the next layer, and taken apart for checks. This lets it work with brain-dead http basic auth too, if you're unlucky enough to have to use that...
This is not as illegitimate as it may sound to you. You may not hear about "getting someone's SSH keys" very often, because we only hear about "vulnerabilities" on places like HN and this isn't a "vulnerability" in any software.
But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems. It's one of the first things an attacker will check for, precisely because it's high likelihood they'll find one and high reward if they do. It's an extremely serious threat that you don't hear about very often, just like you may not hear about "the sudoers file left something open with passwordless access it shouldn't have and the attackers lifted themselves up to root from there" even though it's a major part of many actual incursions. I'm aware of multiple cases in which someone's passwordless SSH key played a part of the process.
So that really is a legitimate problem and turning them off is not security theater but can have a real impact on your security posture. The problem is solved nowadays with adding other auth to the process like proving possession of a physical token as part of the login process.
> But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems.
Though, if someone gets that far, couldn't they also install a key logger on the users system? At that point - whether it's just password or a password enabled SSH key, anything the user does is all compromised regardless.
"Though, if someone gets that far, couldn't they also install a key logger on the users system?"
There are a ton of situations where that is not the case. They may be using directory traversal from something else to read a key without even necessarily being on the system. They may be on the system at 1am local time, and want to get in and get their job done before the user is even there. They may be on a server somewhere where someone left a key they shouldn't have. The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held. They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger, depending on how the system is set up and how the user accesses it. These are examples and not even remotely a full enumeration of all the possibilities. I won't tell you which ones, but some of these are things I've personally seen attackers take advantage of, so they're not just theory, either.
When you're under personal attack, not just getting popped by some vuln scanner scanning over the entire Internet, the situation becomes very different than a lot of people here on HN are used to. Ever been locked out of a system accidentally, then thought for a moment and strung together three other things to reach back into the system you were locked out of, like "oh yeah, I can push a software update to this automatic deployment system, which will run a bash script that checks the IP address and if it is this system restarts the ssh server, and so after 10 minutes we should be in"? Imagine someone who does that every day, all the time, as their full time job, and then imagine they're on a team of other people who also do it every day as their full time job, then imagine they've gotten a foothold into your system. Which, by the way, they immediately used to put a command-and-control client on your system, loaded with all kinds of exploits, and the ability to push arbitrary code to any number of systems at a time and all the tooling to use that as if they've been developing it for 20 years, which they have. What's the transitive closure of what they could work out how to access? The answer would probably surprise you.
I appreciate the additional insights, but the premise I'm pushing back on is whenever a SSH key is read, then the user account is by necessity compromised in order to do so. Given that level of a breach, there are myriad ways for an attacker to escalate privilege and exploit their access without worrying about a password on the SSH key. Namely, at that point, cracking the password on the SSH key is a tractable problem.
> They may be using directory traversal from something else to read a key without even necessarily being on the system.
At least on linux - to read the directory containing a SSH key requires the ability to also write to that directory, as the user. Therefore you can also write to '.bashrc' and all sorts of other places. I suspect Windows might have a larger attack surface, but nonetheless, a directory traversal that is able to read and write is also able to install a keylogger.
> They may be on a server somewhere where someone left a key they shouldn't have
Private key should never be transmitted over a network boundary. SSH key passwords can be bruteforced as well. Having a password on the SSH key, when the SSH key is somewhere it really should never have been, is closing the barn door after the horses have left.
> The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held.
Again, getting access to the secret is enough to also have write access and be able to install a key logger. A password on the SSH key still does not help.
> They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger
If a person has enough access to read a SSH key, they can also install a key logger for at least that user account. They are equivalent levels of compromise, a user account having its SSH key read is already compromised.
edit: addendum: There are certainly attacks that can only read the contents of a system, with root that can read the full system. It's just odd to think about, since at that rate the SSH keys being on a prod system is already such a big no-no. SSH keys really need to live exactly just on the personal devices of the people who own those keys - EG: it should never be the case that say a SQL injection attack that gains root level read permission over everything on a filesystem can then ever read SSH keys - cause those keys should never be on the remote system to begin with. Putting a password on private keys that are then copied to servers _is_ security theater; the keys ought to never be copied to a remote server to begin with.
I can tell you've not been involved in defending against an active attack. You, as the defender, do not get to play the game of "well, if I squint and read it that way, that attack wouldn't work". The attackers get to play "well, hey, if it turns out I do this and that and push it through the other thing, I get access". They are the ones who get to flow through any crack they can find. They are the ones who get to do logic chopping like you're trying to do. You don't get to argue "Well gosh, that team shouldn't have left that one permission open on that one system, that's not a best practice, if they'd followed best practices 100% of the time the attackers couldn't have gotten in...". Your job is to pick up the pieces.
> I can tell you've not been involved in defending against an active attack.
Um... I'm really happy you can mind read dude.
The whole premise here is whether passwords on SSH keys actually help.
SSH keys tend to live in two places: (1) a developers laptop, (2) some sort of CI/CD machine.
The passworded SSH key helps in case (1) only when a person walks away from the laptop and leaves it unlocked. An attacker can't simply then open up a SSH terminal and then SSH to whatever they see in the history. Or, it helps in case a person has a laptop that never locks and the org is simply trying to buy enough time to rotate the persons public keys before the SSH key password is cracked. The SSH key password can buy time, yes - but it does not change the actual security posture.
In case (2), all sorts of considerations need to be made. Though, any password would need to be encoded in a way that is just as accessible as the secret key itself. In case (2), the password really does nothing.
So, yeah, passwording a SSH key does not really help very much. If the keys are left around, then it is the fact they are left around that is a problem. The solution is not to create a scanner that all SSH keys have a password on them, but instead be sure that no SSH keys are installed on systems where they do not belong.
> They are the ones who get to flow through any crack they can find.
I would agree, that is why defense in depth is a good principle just as zero trust security.
So.. passworded SSH keys are kinda really security theater. Please give an attack vector on a persons laptop where the password SSH key is going to stop an attack that is otherwise unachievable. I'll steel man the counter position and mention that physical access is one case (except in that case we are only buying time). AFAIK, that is really it, that is the one place where a password on a SSH key helps.
To hack a persons laptop and read contents in the .ssh directory is a full compromise. To pick up the pieces after that, you need to do things like make sure the compromise can be observed, that privilege escalation is limited. If it comes down to the password on a SSH key being last line of defense - it's game over.
Keep in mind, your burden of proof is to show cases where SSH password actually provides a true increase in real security. The meta conversation of "well, you obviously never have.." is not interesting.
I'll note, if it is the case that SSH passwords are actual security - then, presumably you would feel comfortable stating "yeah, the SSH key was stolen, but nothing needs to be done because the SSH key had a password on it!" It's like the locks on doors, it is for the honest people, the criminals are only slowed down but not stopped by most door locks.
Much of the gaming population doesn't replay games. Why should I care if Major Game doesn't work any more, I've been playing Major Game 2. I had no intention of playing Major Game 1 again. The fact that their old game doesn't work anymore doesn't "burn" them, and they genuinely might not even notice. As long as they keep the game servers up and running long enough for the vast majority of people to get their enjoyment out of the game, no one feels robbed, and no one stops buying games as a result. The average person is not that savvy of a consumer.
Can I play CoD4 on xbox 360 anymore? Single AND multiplayer? I genuinely don't know the answer to that because I haven't tried within the past decade(+). Should I be able to? Absolutely yes. But I have a sneaking suspicion all the multiplayer servers are shut down.
There is also the caveat that some companies tried things that work now, but didn't work back then. I don't remember the specific company, but something like Uber was tried back then. and it just didn't work. "Internet is available" is not the same as "internet is ubiquitous" and some ideas require the ubiquity for it to work out, even if the execution was otherwise fine. "LLMs are pretty neat" is not the same as "AGI is ubiquitous." So there are some AI products that people will try, that will fail horrendously, and it won't be because it's a bad idea or executed poorly, but it's because the AI behind the idea isn't ready yet.
Yeah that's true, but I would still categorize it as an execution problem. If your product (or your AI feature) doesn't work because the models aren't ready yet, it means you failed at design and implementation imho. It doesn't mean there's no plausible AI integration that would make the product more valuable.
It's like if you choose the wrong database and it makes your product slow. It probably doesn't imply you shouldn't be using any database; you just need a different one.
This is why when you're sea sick they tell you to watch the horizon, because if you watch the horizon, you can tell that the horizon is going up and down and your brain can correlate that to the motion.
Have you ever watched a video of a highly skilled tetris player? Where they fill the screen most of the way to the top and then suddenly they just combo the whole thing down and everything wraps up cleanly, and then they start fresh.
The feeling of "oh yeah, that was nice watching that mess turn into something clean and squared away" is where I get a lot of my joy from math.
But also, there are uses to math that you might be able to play with through every day, but you've never thought of those scenarios in a mathematical way.
I was walking today, and on the street there is a right angle turn. The inner portion of the turn is just a square right angle, but the outside of the turn is a radius. I started wondering to myself, if I want to be on the outside of the turn going into and exiting the turn, what would be different ways I could walk this, and what would the distance differences be.
Crossing directly across, to the inner corner and crossing directly across to the outer side again, would be 2w (for the width of the road w). Following the edge of the radius would (assuming perfectly circular), be 1/4 of a circle, so 1/42piw = 1/2 pi * w. The shortest route is a straight line, which would make a right triangle, so w^2 + w^2 = c^2, 2w^2 = c^2, sqrt(2) w = c
So crossing twice is 2w, following the edge is 1/2piw, and shortest path is sqrt(2)*w. Not super applicable, and I didn't need to do math to figure it out, but I was walking and bored, so I found joy in it. The fact that they all boil down to having w as a factor means I could figure out a nice ratio between all of them. And then I needed to mentally figure out what 1/2 pi was. 3.14/2 = 1.57... And I know that sqrt(2) is roughly 1.41 ish.
So now I know that crossing twice has a cost of 2, following the edge is 1.57, and direct line is 1.41. Following the edge is vaguely close enough to the ideal path to warrant not walking into the street to optimize the route, 1.57 / 1.41 is about ~110%. Whereas by defintion, a cost of 2 is going to be sqrt(2) times sqrt(2), so ~141% more than shortest path.
A few things to note here. First off, I'm aware that not everyone finds the same joy in doing simple mental math and thinking about problems mathematically even when there is no need to do it, but trying to think of things more minor trivial things mathematically may cause you to at least appreciate it more, which can grow into joy. And second, I wasn't doing any complicated math in my head. I just thought to myself "is it faster to cut to the inside corner and then cut back out... of course not, right?" and I was able to answer that definitively to myself. Did it matter? Was the answer probably obvious anyway? Probably, but I was able to _prove_ that. And I value facts. Finding joy in the simple things lets you build up more of a familiarity and view it more as a problem solving tool than a tedious thing to rote memorize.
A great way to build up math familiarity and see how other people find joy in mathematics would be to watch Numberphile videos on YouTube[0]. It's a bunch of mathematicians sharing things they find interesting about math. Some times are REAL hard to grasp, but some are just very interesting puzzles[1]. The puzzles don't always have clear immediate usefulness, but can often be described as "a mathematician wanted to know an answer, so they did some math to find out and prove something to themself."
Sorry, end of spiel.
tl;dr - find the joy in the simple things and use math as a tool to answer (even simple) questions to help highlight the usefulness.
Women didn't think they needed to hide their periods from the government. Until the rules changed and suddenly period tracking apps become a vector for lawsuits against women.
You don't always know what you're doing now that seems perfectly normal that will suddenly be used against you in the future. Or which data will mark you as a target.
The point is what one wants or needs to keep private can change day to day. Tracking womens' menstrual cycles was a joke in The Office under Roe v. Wade. Today, it's much more serious.
That's because we are so weak as a nation we can't come together and say "fuck that" to companies owning any bit of data they can collect about us without permission. Could be solved by laws, but we are far too divided for that.
Regulations exist around handling this kind of data. As long as you have privacy of medical decisions, the government or third parties shouldn't be able to access them.
I'm not sure why you're being downvoted. What you are saying is correct.
Now yes, society can make laws about private information to reduce the spread, like GDPR, but fundamentally that just stops the data spreading (a bit). The root data is no longer "private" - it's just shared with fewer people.
There are compelling reasons to share data. Whether or not it's enough to compel you isn't really the point.
Most companies that are harvesting data are using it to offer some sort of service to the users' benefit, on top of using it to advertise to them. Sometimes the benefit is just "it syncs across devices and I don't have to run my own server." Not everyone is technical enough to do that.
And sometimes, things just see very straightforward, and not worth hiding. Different people have different levels of tolerance for things. For some people, period tracking is very much health information. Some may just find it very personal and view it as such and not use an app, or some may be trying to get pregnant, so it's explicitly health related but worth the risk... but for others, is just something you do, and it's not "health information," it's just trying to keep things predictable.
Everything comes down to "if things change, what are the odds this could be used against me?" when it comes to privacy. Maybe talking about privacy online becomes a negative thing under a totalitarian government that wants to quash that kind of speech, and this conversation we're having right now is a terrible idea. Probably not, but just sharing your opinions on things (literally any topic) is private information that could used against you, if you construe it properly.
But we consider that scenario unlikely, so we have the conversation and share our thoughts and express ourselves online. And a little bit of data about us is added to the pool.
The legislature tried to pretend they weren't criminalizing abortion, by declaring that totally uninvolved randos can sue anybody for having or somehow helping in an abortion, and take thousands from the defendant(s) as a reward.
It's crazy because the usual rule is that you can only sue for harm that happened to you, but Karen McBusybody stalking your Facebook feed wasn't hurt, she just wants to strike out at "evil harlots" while making $10,000.
And same goes for the icons. I've personally never gotten there. but also, I don't look at the icons. They could be hidden. I know if I need to get to slack or email, it's on workspace one. So if the workspace badge says "1" or "1: Comms" or "" ... it doesn't really matter, because the keybind is muscle memory anyway. But on the flip side, because all of that is muscle memory... I might go "Where was my email at again? Workspace 1, or 2?" and having an envelope as the label makes it easier to find.
Different people have different workflows. And yes, some people are doing those things to sacrifice usability in the name of aesthetics, but some people may be GAINING usability by doing these things. People are vast and diverse.