• 0 Posts
  • 402 Comments
Joined 2 years ago
cake
Cake day: December 29th, 2023

help-circle


  • adjacent YSKs:

    • there’s soluble and insoluble fibre. you need both, and psyllium only has soluble fibre so it’s part of a larger fibre intake (carrots are pretty okay sources of insoluble fibre - snacking carrots, perhaps with hummus is great!)
    • peanut butter also has surprisingly decent fibre in it: honestly insoluble fibre is everywhere
    • if you plan on adding psyllium (or any fibre) to your diet, build up slowly! it can cause literally constant diarrhoea for weeks or more if you just whack 30g/day (RDI) straight into your diet all at once
    • add some to pancake batter! you’ll want to add about 10-20% more liquid because it gels up, but it’s real easy to add and is basically unnoticeable










  • and these browsers are specifically not that… these browsers are intended to do things like categorise tabs, complete forms, etc automatically without your interaction

    of course they’ll ask before they do things they consider destructive, but what they consider destructive and what a malicious actor can use are very different things

    some of that is certainly benign, but the point with prompt injection is that it can take benign things and make them plausibly malicious




  • the vuln afaik is for remote code execution via basically a mechanism that’s kinda like a transparent RPC to the server (think like you just write frontend code with like a “getUsers” and it just automatically retrieves and deserializes the results so you can render the UI without worrying about how that data exists in the browser)

    i’m not a front end engineer, and haven’t used react server components, but i am a principal software engineer, i do react for personal projects, and have written react professionally

    i can’t think of a way it’d be exploitable via purely client-side means

    i THINK what they mean is that you can use some of the RSC stuff without the RPC-style interfaces, and in that case they say the server component is still vulnerable, but you still need react things running on your server

    a huge majority of react code is client-side only, with server-side code written in other languages/frameworks and interfaces with something like REST or GraphQL (or even RPC of course)



  • most things scale if you throw enough resources at them. we generally say that things don’t scale if the majority case doesn’t scale… it costs far fewer resources to scale with multiple repos that it does to scale a monorepo, thus monorepo doesn’t scale: i’d argue even the google case proves that… they’ve already sunk so much into dev tooling to make it work… it might be beneficial to the culture (in that they like engineers to work across the entire google codebase), but it’s not a decision made because it scales: scale is an impediment



  • that’s a good and bad thing though…

    it’s easy to reference code, so it leads to tight coupling

    it’s easy to reference code, so let’s pull this out into a separately testable, well-documented, reusable library

    my main reason for ever using a monorepo is to separate out a bunch of shared libraries into real libraries, and still be able to have eg HMR