Self doubt stems from here.

  • pauldfaria@infosec.pub
    link
    fedilink
    arrow-up
    150
    arrow-down
    4
    ·
    1 year ago

    In order for this to save… It needs to use cookies, so by not saving cookies you're guaranteed to see it again.

      • lazyslacker@sh.itjust.works
        link
        fedilink
        arrow-up
        68
        ·
        1 year ago

        it makes sense but the comic is slightly confusing because I think the character should be smiling in the last frame, as if thinking, hey they didn't lie, it really doesn't use cookies

        • wreckedcarzz@lemmy.world
          link
          fedilink
          English
          arrow-up
          13
          arrow-down
          1
          ·
          1 year ago

          make site notification that they don't use cookie actually use cookie but code pages to always display notification be celebrated by users sell tracking data win from both ends

          this is why I'm suspicious of everyone, all the time

    • Vlyn@lemmy.zip
      link
      fedilink
      English
      arrow-up
      44
      arrow-down
      1
      ·
      1 year ago

      Nah, there are also local and session storage, you don't need cookies to save something in a user's browser.

        • Grumpy@sh.itjust.works
          link
          fedilink
          arrow-up
          25
          arrow-down
          9
          ·
          edit-2
          1 year ago

          Besides using session cookies, they can track user agent and IP address. The two in combination will be unique enough. There are further metrics to make a unique identifier, but I think this is sufficient explanation.

          Edit: Seems like people who don't know how to program besides super default methods are downvoting me.

          You don't need cookies to hold session ID. If you programmed in the earlier days, you'd actually even know cookie session wasn't even the most common method before. For example, session ID can be passed around in the URL as another query parameter. You can even literally turn off cookie option in sessions in languages like PHP (ex: https://www.php.net/manual/en/session.configuration.php#ini.session.use-cookies). These kind of practice is still relatively quite common as it allows greater flexibility and not have your session ID bound to a domain.

          Furthermore, you don't have to be restricted by the confines of whatever existing tools you already have. Like in the example I gave at the beginning, you can create your own unique identifiers. You don't have to use preexisting concept of session at all. If you can create any unique key-value pair, you can track and keep data without the use of sessions. Programmers are hired to create things that never existed before, be more creative.

            • Grumpy@sh.itjust.works
              link
              fedilink
              arrow-up
              12
              arrow-down
              2
              ·
              edit-2
              1 year ago

              Session ID is stored by the client. So…? I literally just explained how to hold uniqueness on server side without using session ID.

              • jaybone@lemmy.world
                link
                fedilink
                arrow-up
                1
                arrow-down
                2
                ·
                1 year ago

                Tbf you still have a session ID.

                Either you store it in a cookie which the browser passes to the server for you, or you store it in a url parameter and you (or your html / temp laying Generation framework, or some JavaScript manipulation) needs to ensure all links or other server calls like POST, will need to include that session ID passed back to the server.

                And this talk about IP addresses is complete nonsense because of Proxies and NAT and a ton of other reasons. You can attempt to use it in combination with a session ID, but you certainly cannot use that alone.

                • Grumpy@sh.itjust.works
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  1 year ago

                  First of all, this comment chain is about being able to keep tabs on someone without storing information locally on the user's computer. If we create a new form of session ID equivalent that doesn't store information locally, I have achieved the goal to the problem that was raised. The issue wasn't whether or not we needed concept of something equivalent to a session ID.

                  […] will need to include that session ID passed back to the server.

                  Yes, that's exactly what we used to do in the '00s. Look at softwares like osCommerce v1 and 2. We literally put money behind this method of tracking.

                  And this talk about IP addresses is complete nonsense because of Proxies and NAT and a ton of other reasons. You can attempt to use it in combination with a session ID, but you certainly cannot use that alone.

                  Yes, you can use that alone. Without session ID. The other commenter already addressed why this isn't true. Also context matters. Pretty close is a good enough of a session ID replacement for purpose of tracking whether or not they consented to the cookie policy. If I did a concat of IP, and various fingerprints (and put a hash on it to make it shorter), I can easily reach one in trillion probabilities. I wouldn't build a secure military website on it because it's easily forgeable, but it's more than enough for cookie policy popup.

  • AstridWipenaugh@lemmy.world
    link
    fedilink
    arrow-up
    42
    arrow-down
    1
    ·
    1 year ago

    Dude, I had this exact conversation with our compliance team. They told me I couldn't write literally anything client-side unless the user agreed. They also insisted that I always show the cookie banner if there wasn't a cookie. Dumbest shit ever. Used the litany of user bug reports on day 1 to tell compliance to go fuck themselves.

    • Knusper@feddit.de
      link
      fedilink
      arrow-up
      43
      arrow-down
      2
      ·
      1 year ago

      The GDPR literally does not apply for non-personal data. I don't get why companies are so ridiculous with their cookie banners. Nevermind that they have no qualms violating the GDPR in plenty other places.

      • rifugee@lemmy.world
        link
        fedilink
        arrow-up
        19
        ·
        1 year ago

        Especially the ones that are so fucking obnoxious that you have to go through it to even view the site. I don't bother most of the time. The banner should be unobtrusive AND there should be a button that rejects all. I shouldn't have to go and click edit preferences, uncheck a bunch of check boxes, the click confirm. There are some sites that are doing it correctly, but they are few and far between.

        • Kayn@dormi.zone
          link
          fedilink
          arrow-up
          26
          ·
          1 year ago

          A single Boolean to no longer show a cookie banner is not personally identifying data.

    • MooseBoys@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      Don’t be so quick to dismiss the feedback from compliance teams. It’s possible TOU are written such that you really can’t store data on the client without agreement. It’s also possible that other regulations besides GDPR apply that you may not be aware of, for example those specific to banking or health.

      • AstridWipenaugh@lemmy.world
        link
        fedilink
        arrow-up
        8
        ·
        edit-2
        1 year ago

        We're a global company making enterprise software. We have all the certifications including really nasty ones like FedRAMP and HIPAA combined. GDPR is a walk in the park comparatively. I'm well aware of the details and deal with compliance on a nearly daily basis. The only justification was "just to be safe", which is why they quickly acquiesced to storing the string "false" after pushback.

  • Kowowow@lemmy.ca
    link
    fedilink
    arrow-up
    15
    ·
    1 year ago

    Huh I wonder if you could make a website so simple it could be saved as a cookie

    • remotelove@lemmy.ca
      link
      fedilink
      arrow-up
      17
      ·
      edit-2
      1 year ago

      If the browser follows RFC 2019, 2965 and 6265, it should only be able to accept 300 cookies which are a maximum of 4096 bytes each. So yes. You can store enough data in cookies for an optimized page or two, with or without images. Maybe you could store an 8bit track as epic background music as well as a few dozen links for your Web Ring.

      • jaybone@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        How do you render it? Can javascriot access the cookie? Then you write it to the DOM? You still have to obtain the cookie initially, then have all clicks act like an SPA and not make server calls.

        Interesting idea.

        If they are starting a new session but they already have the cookie, how do you prevent the initial server contact when they open the browser/tab ?

  • Imgonnatrythis@sh.itjust.works
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    Microsoft is the biggest offender of this. Use edge browser at work because have to and this don't show again for password saving never does a damn thing. Why admins in a workplace would ever even allow option of password saving is beyond me as it seems like a risky move.

  • SuperSpruce@lemmy.ml
    link
    fedilink
    arrow-up
    7
    arrow-down
    1
    ·
    1 year ago

    This makes me wonder. How do cookies differ from LocalStorage (the latter of which is used to store saves of browser based incremental games)?