• 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle
  • This forces my team to find creative ways to keep them working while also taking measures to isolate them as much as possible. I also use them to teach old exploits that have been patched in more recent versions, walking people through how it worked and why it existed.

    I am interested in learning more about this. I know a fair bit about networks but exploit history and modern attack / defense strategies and server hardening are not my main specialty. Do you have any good links or resources that you can share?



  • Excellent, thankyou! I was just going to throw ubuntu at it unless I really needed something else because of the potato specs, so hopefully drivers are already sorted.

    especially the WiFi/Bluetooth chipset

    Noted. I would be pissed to not have that working.

    Don’t try anything fancy

    No chance, I’ve been burnt by my unix arrogance enough times to not want to try it on proprietary hardware. Until now I assumed even getting Linux on there was too fancy, I still remember other people fighting for weeks with their hackintosh a decade ago.







  • People have already mentioned testing and abstraction, but what about other developers and security?

    Spaghetti code all you like in solo projects. But if someone else is coming along to debug a problem in their toppings, why would you make them remember anything about baking or the box when it’s completely irrelevant?

    And why should the Box object be able to access anything about the Oven’s functionality or properties? Enjoy your oven fire and spam orders when someone works out they can trigger the bake function or access an Order’s payment details from a security hole in the Box object implementation.

    It’s not just about readability as a narrative, even if that feels intuitive. It’s also about memory management, collaboration and security.




    • When writing new code: make a good faith attempt to DRY (obviously not fucking with Liskov in the process). First draft is very WET - deleting things is easiet at this stage anyway and accidentally prematurely DRYing causes headaches. Repeat the mantra “don’t let perfect be the enemy of good” to prevent impulsive DRYing.
    • When maintaining existing code I wrote: Refactor to DRY things up where it’s clear I’ve made a conceptual misjudgement or oversight. Priority goes to whatever irritates me most in the moment rather than what would be most efficient.
    • When altering other people’s code: Assume they had a reason to WET (if you’re lucky, read the docs that discuss the decision) but be a little suspicious and consider DRYing things up if it seems like a misjudgement or oversight. Likely realise 50% of the way through that this is going to take much longer and be way more painful than you hoped because of some esoteric bullshit compatibility issue. Curse yourself for not letting sleeping dogs lie but still start engaging in sunk cost fallacy.
    • When reviewing PRs: Attempt to politely influence the writer to DRY it up but don’t take too much offence to WET if it has a decentish reason in context. Throw in an inline one-liner to not make other maintainers question their sanity or competence when they realise they’re reading duplicate code. Also to more reliably establish git blame rather than blaming the next poor fool who comes along and make a minor reformatting revision across the file. Include a date so that someone can stumble across it in 10 years as an archaeological curiosity and their own personal esoteric bullshit compatibility issue.
    • Long term maintenance: Live with your irritatingly damp mouldy code. There’s new code that needs to be written!

  • We used post-it notes on a wall at a previous workplace to aid a truly useless manager. It didn’t make him a better manager, but it did have upsides. It felt great to crunch completed tasks up into little balls and throw them in the recycling when we did standups. The extra visibility in the room was really helpful too, other colleagues would ask us about our work or when we might be free for their whims, and we could just point at the wall and say “after all that shit is done?”. Usually they would see the mountain in the to-do columns and say “oh.” and then walk off dejectedly. It stopped a lot of bullshit requests with the mere presence of colourful papers fluttering in the aircon, including incompetent managerial scope creep.

    The fridge would work well for this with some little magnets and/or a whiteboard marker, like people do with reward charts for kids.


  • Even as someone who declines all cookies where possible on every site, I have to ask. How do you think they are going to be able to improve their language based services without using language learning models or other algorithmic evaluation of user data?

    I get that the combo of AI and privacy have huge consequences, and that grammarly’s opt-out limits are genuinely shit. But it seems like everyone is so scared of the concept of AI that we’re harming research on tools that can help us while the tools which hurt us are developed with no consequence, because they don’t bother with any transparency or announcement.

    Not that I’m any fan of grammarly, I don’t use it. I think that might be self-evident though.


  • How will we be making WASM-based UI accessible for people using screen readers, screen zoom applications, text to speech and voice input users, etc.?

    The Web is hostile enough to people with disabilities, despite its intent, and developers are already unfamiliar with how to make proper semantic and accessible websites which use JS. Throwing the baby out with the bathwater by replacing everything with WASM in its current form seems about as good an idea as Google’s Web Environment Integrity proposal.




  • Honestly, I’m not sure. Privacy has always been a spectrum, but we’re now living in a world where it’s near impossible to get close to 100% privacy for any action from the start. I suspect the current possible remedies are “ensuring the people and organisations which use/abuse surveillance are heavily regulated and compliance heavily enforced” which ironically requires transparency.

    Realistically there needs to be lengthy legal procedures to grant authorities and companies use of such techniques. Legislation like that is complicated and slow to develop though. It also risks pinning the core privacy concepts to specific versions of specific tech, which complicates its enforcement over time.

    Even if it is very illegal to do this to someone though, there will always be people who use it for whatever purposes. Obviously making it illegal under wiretapping laws without explicit opt-in consent to do it is something that would need to happen. I’d also like to see mandatory source attribution laws.

    That won’t stop everyone though. Which means we maybe need to start looking into comstruction legislation to ensure RF blocking materials are used in external wall construction. If that is an effective remedy to Van Eck phreaking at all. I have no idea what resolution information can be determined from devices that aren’t purpose built broadcasting and receiving devices.

    And all of that requires good-will and sensible decisions from the existing legal systems and legislators. Which can’t be completely achieved, and in many cases is… currently very poor.

    Tl;dr A very hard problem which will need work from a bunch of different parts of society and likely cannot be completely solved for all people. The only solution for this specific technique right now I think is to go fully off-grid with no electricity. Even then though you’ll still have satellites and drones to intrude.