• rtxn@lemmy.world
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    2
    ·
    3 months ago

    Clone it before the Glowy Boys declare it a weapon of mass destruction and preemptively nuke the repo.

    • karmiclychee @sh.itjust.works
      link
      fedilink
      arrow-up
      14
      ·
      3 months ago

      Served as “flat files” - filesystem, object store, what have you. No server logic generating content, just passing around of strings and binary data. Files are the representation are the source of truth. Counter to a web app, where the content response is ephemeral and the “source of truth” is scattered across a writeable DB and recombinated (potentially) on every request.

      Interesting question though, I (a web dev) just take the term for granted.

    • thingsiplay@beehaw.org
      link
      fedilink
      arrow-up
      10
      ·
      3 months ago

      It depends what static refers to. In this case, it refers to static file creation without PHP (or Python) on the server. The content itself can stay static, JavaScript and its dynamic nature is just used to encrypt and decrypt.

    • adr1an@programming.dev
      link
      fedilink
      arrow-up
      6
      ·
      3 months ago

      It’s been always the same. Backend, server logic, database… dynamic content; on one hand. JavaScript runs on the browser for almost anything, sometimes for dynamic content. But it’s not tied. You could have an in-browser button with a counter for the numbers of times it was pressed (that’s actually an entry-level programmer exercise) and that’s a static site. If you saved the counter value to the server (e.g. database) then it’s not static anymore.

    • ReversalHatchery@beehaw.org
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 months ago

      I think they mean taking a static site, and encrypting that with an attached JS. It could be done with a browser extension too (probably), but that way it would be less portable

    • delirious_owl@discuss.online
      link
      fedilink
      arrow-up
      3
      ·
      3 months ago

      No, static sites are usually more js heavy because they offset all the processing to the client.

      This is one reason I avoid static sites, and just heavily cache the server.

    • 𝕸𝖔𝖘𝖘@infosec.pub
      link
      fedilink
      English
      arrow-up
      2
      ·
      3 months ago

      Have you used any of these? Are you able to compare you this one or to the others on your list? Maybe a better question, which one/s would you recommend?

  • elliot_crane@lemmy.world
    link
    fedilink
    arrow-up
    10
    arrow-down
    3
    ·
    3 months ago

    This seems like a cool idea, but also somewhat questionable from a security standpoint? Isn’t distributing the encrypted content alongside the means to decrypt it (i.e. bundling this all in one file which is sent to the client) essentially equivalent to providing physical access to an encrypted drive? Like an attacker with enough time and effort could bypass the encryption.

    • Mike1576218@lemmy.ml
      link
      fedilink
      arrow-up
      10
      ·
      3 months ago

      It is not a problem to distribute the decryption algorithm. The question remains against what this will protect. Normal https encrypts the traffic safely during transit. With this, the data is also encrypted on the server. But if you can access the server, you can modify the javascript code to send the password back to a server.

      It could be used on something like IPFS, where all data is basically public but you can be sure it hasn’t been modified.

    • CosmicTurtle0@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      7
      ·
      3 months ago

      Exactly. This shouldn’t be used to store your taxes, for example. But it might be good if you want to post details about your baby shower without your parents getting the details.