7 ms·

We need to acknowledge also that recognising the user as he moves across pages and domains is sometimes needed to provide valuable services to the user. Theref

We need to acknowledge also that recognising the user as he moves across pages and domains is sometimes needed to provide valuable services to the user. Therefore, I believe, browsers have to provide a volunteer "tracking" functionality - when a web page reqests 3rd party cookies, a popup is shown to the user with the cookie values, description (as set by the owning domain), the list of domains already permitted to access the cookies and their privacy policy links, and options Allow Once, Allow, Deny Once, Deny. So instead of fighting each other, service and the user had a chance to cooperate. Service only needs to describe the need clear enough.

asddubs 6y ago
this exists on safari, edge and FF https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess https://developer.mozilla.org/en-US/docs/Web/API/Document/re... https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API https://developer.mozilla.org/en-US/docs/Web/API/Storage_Acc... on safari, it's basically the only way to get access to third party cookies in an iframe since safari 13. I wish other browsers (chrome) would also enable this when third party cookies are disabled. On FF I think the rule is that you have to interact with the site beforehands and you get access automatically, failing that you can use this API. No idea how it works in edge
- avodonosov 6y ago
  Wow, interesting. So, to access 3rd party cookies I need to access a document DOM object that has that 3rd party origin? But such a document is not always available, is it... Looks like the use cases targeted by that proposal are limited to an embedded iframe that wants to access its own domain cookies. I was thinking also about arbitrary doman. Like requestStorageAccess(targetOrigin, keys...)
  - asddubs 6y ago
    Yeah, it's useful for e.g. embedded like buttons or comment forms on external sites or sites with user hosted content (on a different TLD)
notatoad 6y ago
The "problem" with that solution is that users are very willing to click any button necessary to achieve their goal, and in any dialog that prompts to allow tracking in order to achieve something else, most people will click allow. Personally I don't think this is a problem, and people should be allowed to make that choice. But most of HN seems to disagree with me there, and feels that users need to be protected from making choices that could allow them to be tracked
- rangibaby 6y ago
  It’s not much choice when the site will find some way of forcing or tricking you to allow tracking
  - notatoad 6y ago
    Tracking is the cost. You have the choice to use the service and allow tracking, or not use the service. Websites force you to accept tracking in the same way the store forces you to pay for your groceries
punnerud 6y ago
That is when you have sign in and communication on the server side, not place data in the browser for tracking.
- ForHackernews 6y ago
  How do you suggest implementing "sign in" without setting a cookie?
  - viraptor 6y ago
    Sign-in cookies are always first party. That's completely out of context here where we're taking about tracking cookies.
    - whalesalad 6y ago
      I’m not familiar with a distinct “sign in cookie” either. Do you mean a server side cookie / HttpOnly?
      - viraptor 6y ago
        It's basically a cookie holding your session id, scoped only to the site and used only for auth purposes (or holding the session vars if you're doing client-side sessions)
        ForHackernews 6y ago
        So, just to reiterate, contrary to the comment I replied to, you are suggesting we "place data in the browser for tracking" a user's authentication state and session.
        viraptor 6y ago
        Ah, I think we're stepping on an overloaded term. I mean tracking as in "identifier connecting visits from unrelated pages used for data collection" and not "identifier used by the site you're connecting to for purpose of holding browsing session variables".
appleflaxen 6y ago
Perhaps, but that mechanism doesn't need to persist in the browser across termination of execution.
surround 6y ago
Which valuable services? I’ve had 3rd party cookies entirely disabled for a while now, and I haven’t noticed any services break, not even cross domain logins.
- avodonosov 6y ago
  Maybe your services relied on the "supercookies" thus being immune to 3rd party cookies disabled :) ? An example that I can imagine is a big onlite shopping company that has several domains, and they want a shopping cart that that works across all their domains.
  - Groxx 6y ago
    A big online shopping company that moves you between several domains as part of normal use? tbh I've never seen a single site do this, so I don't feel bad saying "no, I don't think that's a legitimate reason to allow 3rd party cookies". Besides, since they control all the domains, they can do redirects to associate your session across them easily enough. It's basically oauth at that point, which works just fine without 3rd party cookies.
- asddubs 6y ago
  not as common these days, but it's useful for services allowing people to create custom sites like blogger, where you'd want the comment form to be an iframe/embed of some sort that ties to the account of the platform, and the user-content is on a different domain.

asddubs 6y ago

this exists on safari, edge and FF https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess https://developer.mozilla.org/en-US/docs/Web/API/Document/re... https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API https://developer.mozilla.org/en-US/docs/Web/API/Storage_Acc... on safari, it's basically the only way to get access to third party cookies in an iframe since safari 13. I wish other browsers (chrome) would also enable this when third party cookies are disabled. On FF I think the rule is that you have to interact with the site beforehands and you get access automatically, failing that you can use this API. No idea how it works in edge

avodonosov 6y ago
Wow, interesting. So, to access 3rd party cookies I need to access a document DOM object that has that 3rd party origin? But such a document is not always available, is it... Looks like the use cases targeted by that proposal are limited to an embedded iframe that wants to access its own domain cookies. I was thinking also about arbitrary doman. Like requestStorageAccess(targetOrigin, keys...)
- asddubs 6y ago
  Yeah, it's useful for e.g. embedded like buttons or comment forms on external sites or sites with user hosted content (on a different TLD)

notatoad 6y ago

The "problem" with that solution is that users are very willing to click any button necessary to achieve their goal, and in any dialog that prompts to allow tracking in order to achieve something else, most people will click allow. Personally I don't think this is a problem, and people should be allowed to make that choice. But most of HN seems to disagree with me there, and feels that users need to be protected from making choices that could allow them to be tracked

rangibaby 6y ago
It’s not much choice when the site will find some way of forcing or tricking you to allow tracking
- notatoad 6y ago
  Tracking is the cost. You have the choice to use the service and allow tracking, or not use the service. Websites force you to accept tracking in the same way the store forces you to pay for your groceries

punnerud 6y ago

That is when you have sign in and communication on the server side, not place data in the browser for tracking.

ForHackernews 6y ago
How do you suggest implementing "sign in" without setting a cookie?
- viraptor 6y ago
  Sign-in cookies are always first party. That's completely out of context here where we're taking about tracking cookies.
  - whalesalad 6y ago
    I’m not familiar with a distinct “sign in cookie” either. Do you mean a server side cookie / HttpOnly?
    - viraptor 6y ago
      It's basically a cookie holding your session id, scoped only to the site and used only for auth purposes (or holding the session vars if you're doing client-side sessions)
      - ForHackernews 6y ago
        So, just to reiterate, contrary to the comment I replied to, you are suggesting we "place data in the browser for tracking" a user's authentication state and session.
        viraptor 6y ago
        Ah, I think we're stepping on an overloaded term. I mean tracking as in "identifier connecting visits from unrelated pages used for data collection" and not "identifier used by the site you're connecting to for purpose of holding browsing session variables".

appleflaxen 6y ago

Perhaps, but that mechanism doesn't need to persist in the browser across termination of execution.

surround 6y ago

Which valuable services? I’ve had 3rd party cookies entirely disabled for a while now, and I haven’t noticed any services break, not even cross domain logins.

avodonosov 6y ago
Maybe your services relied on the "supercookies" thus being immune to 3rd party cookies disabled :) ? An example that I can imagine is a big onlite shopping company that has several domains, and they want a shopping cart that that works across all their domains.
- Groxx 6y ago
  A big online shopping company that moves you between several domains as part of normal use? tbh I've never seen a single site do this, so I don't feel bad saying "no, I don't think that's a legitimate reason to allow 3rd party cookies". Besides, since they control all the domains, they can do redirects to associate your session across them easily enough. It's basically oauth at that point, which works just fine without 3rd party cookies.
asddubs 6y ago
not as common these days, but it's useful for services allowing people to create custom sites like blogger, where you'd want the comment form to be an iframe/embed of some sort that ties to the account of the platform, and the user-content is on a different domain.