• 0 Posts
  • 34 Comments
Joined 11 months ago
cake
Cake day: August 10th, 2023

help-circle




  • 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: https://www.usenix.org/system/files/conference/usenixsecurity12/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.




    • Encrypt the data at rest
    • Encrypt the data in transit

    Did you remember to plan for a zero downtime encryption key rotation?

    • No shared accounts at any level of access

    Did you know when account passwords expire? Have you thought about password rotation?

    • Full logging of access and activity.

    That sounds like a good practice until you have 20 (or even 2000) backend server requests per end user operation.

    All of those are taken from my experience.

    Security is like an invasive medical procedure: it is very painful in the short term but prevents dire complications in the long term.



  • So you are suggesting forum software that supports single sign-on?

    We are talking about an open source project, not a high school reunion. I don’t want to hang out with people, I want to have a discussion about a focused topic.

    I want to ask a question and get an answer. If the question is not one that anyone online can currently answer, I want to be able to tell at a glance if anyone has talked about my question. If I don’t understand the answer, I want to ask a follow up question.

    In the evening, I want to be able to take a look at new posts from that day, grouped by topic, to see if there is anything I find interesting or can weight in on.

    With Discord (or any real time chat), it is hard to follow a single topic when more than one is being discussed. It is doubly hard to do so after the fact. I am aware that Discord has a forum feature. I have only seen one server ever enable it and no one posts anything to it.



  • It is better to find a developer that has experience with the language features you use rather than one that is experienced in the exact language you use. For example, I work on distributed systems in Java/GoLang/Python. We want candidates that understand how to write concurrent logic and stay away from people who are just Java web developers.

    The big issue is doing a coding interview with candidates. We have a standard straightforward problem that candidates need to solve by filling in a stubbed out method. We have it in Java and have ported it to GoLang. If we have to interview a candidate who does not know either of those languages, we would need to find a language that the candidate knows and we know well enough to port the problem to. We would also have some difficulty digging in to design specifics like choice of concurrency primitives.


  • I have been an individual contributor at large corporations for more than 10 years. Every time I have had a colleague promoted to manager, they always planned to stay technical and keep coding. Every one of them, without fail, stopped coding because they were too busy.

    Thinking back to my managers who left for other roles, only one quit to work in higher management, the rest all went back to working as developers.

    I worked at giant, globally distributed companies (15-25k employees), so I imagine that my experience is not typical.


  • But a floating point issue is the exact type of issue a LLM would make (it does not understand what a floating point number is and why you should treat them differently). To be fair, a junior developer would make the same type of mistake.

    A junior developer is, hopefully, being mentored by more senior coworkers who are extra careful with code reviews and would spot the bug for the dev. Machine generated code needs an even higher level of scrutiny.

    It is relatively easy to teach a junior developer to write code that is easy to read and conforms to the teams style guide.



  • The point of using a cache is to have data in memory and not on disk. From what I can tell, Postge Unlogged tables are still written to (and read from) disk. It is just that the write is done in an unsafe way.

    The article explains how one would go about benchmarking performance but forgets to actually include performance metrics. Luckily they link to another write up that does. Using an Unlogged table vs. a regular table reduces write times about 45% and gives you about 3 times as many transactions per second. It is not nothing but it is probably not worth the code complexity vs. writing directly to a persistent table.

    Even the “no persistence” behavior of a cache is not strictly true: an unlogged table is only truncated if Postgre is shut down unexpectedly (by kill -9 the process or by killing the VM). If you restart if you shut down the process in a controlled manner, the unlogged table is properly persisted and still has data when it starts.


  • I have used Kotlin a bit for a hobby project and it felt like they were 95% done with a 1.0 version. I love the promise of a single code base that can run on the JVM and browser, but it is not all there. Until recently, the API was not guaranteed to be stable. Every one in a while, I hit a feature that is JVM only or does work right in JavaScript. The JS compiler will “helpfully” remove uncalled public functions unless you explicitly mark them with JsExport.

    Also, from what I can tell, only InteliJ is the only supported IDE (which makes sense, since they are the language developers). There is an official Eclipse Plugin, but the last time I tried it, it did not work and tried to take the entire IDE down with it.

    Having said that, it was very close to complete and I have not worked on that project for a few months, so it could all be perfect now.


  • As someone who was a web developer since the mid-2000’s (and not more recently), an HTML first approach speaks to me. I am still of the belief that your contents should be in HTML and not pulled in via JavaScript.

    The article is a bit self contradictory. It encourages specifying style and behavior inline and not using external styles and scripts but also discourages using a website build pipeline or dynamically generated HTML. So how can you maintain a consistent look and feel between pages? Copy and paste?


  • If you are creating an alternative implementation and leaving the old one in place, you are not fixing a problem, you are just creating a new one (and a third one because you have duplication of logic).

    Either refactor the old function so that it transparently calls the new logic or delete the old function and replace all the existing usage with usage of the new one. It does not need to happen as a single commit. You can check in the new function, tell everyone to use it, and clean up usage of the old one. If anyone tries to use the old implementation, call them out in a code review.

    If removing or replacing the old implementation is not possible, at least mark it as deprecated so that anyone using it gets a warning.