About 10 years ago, I read a paper that suggested mitigating a rubber hose attack by priming your sys admins with subconscious biases. I think this may have been it: www.usenix.org/system/files/…/sec12-final25.pdf
Essentially you turn your user to be an LLM for a nonsense language. You train them by having them read nonsense text. You then test them by giving them a sequence of text to complete and record how quickly and accurately they respond. Repeat until the accuracy is at an acceptable level.
Even if an attacker kidnaps the user and sends in a body double, with your user’s id, security key, and means of biometric identification, they will still not succeed. Your user cannot teach their doppelganger the pattern and if the attacker tries to get the user on a video call, the added lag of the user reading the prompt and dictating the response should introduce a detectable amount of lag.
The only remaining avenue the attacker has is, after dumping the body of the original user, kidnap the family of another user and force that user to carry out the attack. The paper does not bother to cover this scenario, since the mitigation is obvious: your user conditioning should include a second module teaching users to value the security of your corporate assets above the lives of their loved ones.
Smart. I like the idea of replacing biometrics with something that can’t easily be cloned - learned behaviour. Perhaps with a robust ML approach you could use analysis of gait, expressions, and other subtle behavioural tics rather than or in addition to facial/fingerprint/iris recognition. I suspect that would be very hard to fake - although perhaps vulnerable to, idk, having a bad day and acting “off”.
I am well aware of learning, but people tend to learn by comprehension and understanding. Completing phrases without understanding the language (or the concept of language) is the realm of LLM and Scrabble players.
Having read the paper, there seems to be a glaring problem: nothing is stopping the attacker from forcing the trusted user into replicating the “password”.
Sure, the user can’t tell them the password, but they can still be forced into describing the system well enough into making a mock-up, then forced to enter their password on it.
Stack Overflow isn’t a tutor site. It’s a wiki. Its usefulness would plummet if duplicate questions are allowed, since that would scatter all the answers.
Then it should allow to connect duplicates as sub questions to main question which they keep as original, Wikipedia allow additions to articles after all, i mean if you comment your question under main question, who gonna look at that?
It’s also weird to me that people seem to primarily use it to ask questions (and get butthurt about getting duplicates). It’s really rare that I ever don’t find an answer there (which often is buried in responses, but still). Like I’ve virtually never been motivated to post there.
This does seem like a potential issue if the PR is itself implementing more than one vertical slice of a feature. Then it could have been smaller and there might be wasted effort.
If the patches are small and well-organized then this isn’t necessarily a bad thing. It will take more than one day to review it, but it clearly took much more time to write it.
Right but it’s pretty rare that a tiny PR actually accomplishes a valuable user story.
So my point is just that lines of code is mostly irrelevant as long as it’s organized well and does no more than necessary to accomplish the agreed upon goal.
It’s harder to review. As a reviewer it’s difficult to know which code change is related to which task.
It’s harder to verify. Did you really test every change you made?
You might end up with a “hostage” situation. There might be a few code changes in the PR that looks good and is really wanted, but other code changes in the same PR of lower quality. As a reviewer, should you just let these lower quality code changes slide so you can bring in the code change you really want? Probably not, but you’re going to let it slide either way.
He’d have like a pretty normal PR to do something like change a field to be read only in some API. But then snuck into the pr there’d also be something like “change application to run locally different than prod for entirely selfish reasons” or “lower global coverage requirements” or “disable type checking in this whole folder”
I also worked with a guy like that. Impossible to predict what he was going to do in his next PR. Always a nightmare to review. Also exhausting to argue with, so let some things slide because I was so done dealing with his bs.
This guy was also difficult to argue with. He was always professional, which I guess is worth something.
One time he tried to remove all the types from a bunch of code “because they were all going to change later.” I refused to allow this. We went back and forth in the comments for hours. I think eventually the lead or boss got involved. Thankfully people sided with me.
His “later” project that was allegedly going to change all the things was rejected by the team. The code in question is still used and properly typed a year later.
Refactoring in PRs just makes it more difficult to review. “Do these lines belong to the goal nor not?”. Also, we’re human and miss things. Adding more text to review means the chance of missing something increases.
Especially if the refactored code isn’t just refactored but modified, things are very easy to miss. Move an entire block of code from one file to another and make changes within = asking for trouble or a “LGTM” without any actual consideration. It makes code reviews more difficult, error-prone, and annoying.
Code reviews aren’t there to just tick off a box. They are there to ensure what’s on the tin is actually in it and whether it was done well.
In my experience I haven’t had an issue because usually the refactorings are small. If they’re not I just hop on a call with the person who wrote the MR and ask them to walk me through it.
In theory I’d like to have time to dedicate solely to code health, but that’s not quite the situation in basically any team I’ve been in.
I haven’t had any trouble separating refactors PRs from ticket PRs. Make the ticket PR, make a refactor PR on that ticket PR, merge the ticket PR, rebase refactor PR on master, open ticket PR for review, done 🤷
I have a rule about this (not that I don’t break it at times). I only refactor in an unrelated story if it doesn’t delay deliverables and existing tests cover the code.
And you’re generally right about tech that not being prioritized, but you should have a talk with your product manager/owner to strike a deal for some small percentage of your work to include tech debt. We were able to convince ours that it was otherwise affecting our velocity.
I hear you, but they should MVP the ticket, close it, then concisely collar the PM/lead and say “I know how to make this better and am hungry to do it. Let me address some tech debt next sprint. I got this and will keep it timeboxxed. I’ll also ensure my changes pass QA before coming to you”
ChatGPT is give you general answer not the right ones from my experience
Sometimes you get the right answer if you fine tune your question…but sometimes don’t
As a half-joking response to this half-joking admission, I got started with the Usborne programming books as a kid, and they laid some excellent foundations for my later study. They’re all available online for free these days, so grab an emulator and user manual for your 80s 8-bit home computer of choice, and dive in!
Modern programming languages and IDE’s are so complex it’s enough to put a lot of people off ever learning to program - it seems such a massive learning curve. There’s something to be said for learning Basic then assembly on an 8-bit computer, where everything is so much sampler and direct. Writing a value to memory and seeing a blotch of pixels change on the screen gives such a direct understanding of what’s going on inside the machine. And if you only have 48k of memory, you can genuinely understand everything the computer is doing.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.