Best practise for "wanted" third party cookies

privacycg / storage-access

The Storage Access API

https://privacycg.github.io/storage-access/

199 stars 27 forks source link

Best practise for "wanted" third party cookies #66

Closed viktor-morin closed 3 years ago

viktor-morin commented 3 years ago

Hi everyone,

I been reading Introducing Storage Access API and have now implemented a test version to see how it will affect us. We deliver following to our customers:

HTML code which they render on their site
In some rare cases, an iframe which they render on their site

User goes to site A: Inside our HTML code, the user can interact with elements, and make some adjustments (settings) which persist (we usally store this is a cookie, by using another iframe). This iframe is connected to our domain, let's call it X. The communication is done between the main domain A where our HTML code is running and our interal iframe, domain X via Window.postMessage()
User goes to site B: The settings saved at site A is now loaded via an iframe which load the data from the cookie connected to domain X via Window.postMessage().

After implemented Storage Access API: We know have to ask the user to go to domain X and accept our terms (interaction on first-party domain). We then save a "dummy cookie". We then use both hasStorageAccess() and requestStorageAccess() where the user accept the promt question.

All these steps seems fine and preferably, the end-user is always informed on why this access need to be granted.

My question is:

What's the best practise for this type of "work-flow"?
How often would the end-user need to accept the prompt seen from requestStorageAccess() since they rarely (it's not required) visit domain X?
The cookie in this case is not used for tracking, instead for save settings which should remain for all domains using our service. It feels like this constantly confirming would affect our product negatively. In one way, saving the data using third-party cookie is something the end-user want here, how do we give that to them in the best way?

Thanks!

johnwilander commented 3 years ago

Hi everyone,

Hi, and thanks for filing!

I been reading Introducing Storage Access API and have now implemented a test version to see how it will affect us. We deliver following to our customers:

A short note on that blog post. It's for WebKit's/Safari's implementation of the Storage Access API and was published before the API became a work item here.

HTML code which they render on their site

In some rare cases, an iframe which they render on their site

User goes to site A: Inside our HTML code, the user can interact with elements, and make some adjustments (settings) which persist (we usally store this is a cookie, by using another iframe). This iframe is connected to our domain, let's call it X. The communication is done between the main domain A where our HTML code is running and our interal iframe, domain X via Window.postMessage()

User goes to site B: The settings saved at site A is now loaded via an iframe which load the data from the cookie connected to domain X via Window.postMessage().

After implemented Storage Access API: We know have to ask the user to go to domain X and accept our terms (interaction on first-party domain).

This requirement might be browser specific. The browser decides which domains can request storage access.

We then save a "dummy cookie".

This is also browser specific. Safari's 17 year old default cookie policy requires a domain to already have cookies to be able to use cookies as a partitioned party. Technically, that means the domain needs to become unpartitioned party (often referred to as first party) and "seed" its cookie jar as such.

We then use both hasStorageAccess() and requestStorageAccess() where the user accept the promt question.

All these steps seems fine and preferably, the end-user is always informed on why this access need to be granted.

My question is:

What's the best practise for this type of "work-flow"?

Is there something wrong with the flow you just described?

How often would the end-user need to accept the prompt seen from requestStorageAccess() since they rarely (it's not required) visit domain X?

The frequency of the prompt is browser specific. In the case of Safari, an opt in is remembered until either the user or the browser decides to delete website data for the domain. Safari's ITP deletes website data for classified domains that 1) have not received user interaction as unpartitioned party the last 30 days of browser use, and 2) have not been granted storage access through the Storage Access API. Merely being granted access through the Storage Access API (prompt or not) is enough to stay in the green.

The cookie in this case is not used for tracking, instead for save settings which should remain for all domains using our service. It feels like this constantly confirming would affect our product negatively. In one way, saving the data using third-party cookie is something the end-user want here, how do we give that to them in the best way?

In the case of Safari, there's just one prompt to opt in to per top website as long as website data is not deleted. If your partitioned domain is not used under many websites, this should not be a problem.

Also, Safari's ITP doesn't know what cookies are used for and thus doesn't decide which domains are and aren't trackers. It prevents cross-site tracking capabilities.

If you have further questions specific to WebKit/Safari, I encourage you to file them here instead: https://bugs.webkit.org.

johannhof commented 3 years ago

It would be nice if we had some good authoritative examples on how to use the API cross-browser in a little bit closer-to-real-world scenarios like this one. The example on the MDN page is a bit, uh, basic.

johnwilander commented 3 years ago

It would be nice if we had some good authoritative examples on how to use the API cross-browser in a little bit closer-to-real-world scenarios like this one. The example on the MDN page is a bit, uh, basic.

I would agree. Part of the standards work is to get as much interoperability as possible. But policies around prompting are hard to standardize as is how browsers prevent tracking.

viktor-morin commented 3 years ago

Hi everyone,

Hi, and thanks for filing!

I been reading Introducing Storage Access API and have now implemented a test version to see how it will affect us. We deliver following to our customers:

A short note on that blog post. It's for WebKit's/Safari's implementation of the Storage Access API and was published before the API became a work item here.

HTML code which they render on their site

In some rare cases, an iframe which they render on their site

User goes to site A: Inside our HTML code, the user can interact with elements, and make some adjustments (settings) which persist (we usally store this is a cookie, by using another iframe). This iframe is connected to our domain, let's call it X. The communication is done between the main domain A where our HTML code is running and our interal iframe, domain X via Window.postMessage()

User goes to site B: The settings saved at site A is now loaded via an iframe which load the data from the cookie connected to domain X via Window.postMessage().

After implemented Storage Access API: We know have to ask the user to go to domain X and accept our terms (interaction on first-party domain).

This requirement might be browser specific. The browser decides which domains can request storage access.

We then save a "dummy cookie".

This is also browser specific. Safari's 17 year old default cookie policy requires a domain to already have cookies to be able to use cookies as a partitioned party. Technically, that means the domain needs to become unpartitioned party (often referred to as first party) and "seed" its cookie jar as such.

We then use both hasStorageAccess() and requestStorageAccess() where the user accept the promt question. All these steps seems fine and preferably, the end-user is always informed on why this access need to be granted. My question is:

What's the best practise for this type of "work-flow"?

Is there something wrong with the flow you just described?

How often would the end-user need to accept the prompt seen from requestStorageAccess() since they rarely (it's not required) visit domain X?

The frequency of the prompt is browser specific. In the case of Safari, an opt in is remembered until either the user or the browser decides to delete website data for the domain. Safari's ITP deletes website data for classified domains that 1) have not received user interaction as unpartitioned party the last 30 days of browser use, and 2) have not been granted storage access through the Storage Access API. Merely being granted access through the Storage Access API (prompt or not) is enough to stay in the green.

The cookie in this case is not used for tracking, instead for save settings which should remain for all domains using our service. It feels like this constantly confirming would affect our product negatively. In one way, saving the data using third-party cookie is something the end-user want here, how do we give that to them in the best way?

In the case of Safari, there's just one prompt to opt in to per top website as long as website data is not deleted. If your partitioned domain is not used under many websites, this should not be a problem.

Also, Safari's ITP doesn't know what cookies are used for and thus doesn't decide which domains are and aren't trackers. It prevents cross-site tracking capabilities.

If you have further questions specific to WebKit/Safari, I encourage you to file them here instead: https://bugs.webkit.org.

Thanks for taking time to answer my post! To summerize it, this is the new "cookie flow" we had setup for our end-users.

Inside our widget is hasStorageAccess() called, which always return false
Then we show a button where the end-user click to call requestStorageAccess() If the function return true, skip step 3
We open a new tab with our main domain and let the user accept our terms & condition and a first-party cookie is saved and the tab/window is closed.
The user has to click on the same button once moce (updated button text) and the requestStorageAcess() returns true.

I have mostly tested against Safari, will have to do further testing for Firefox. I think these steps are fine, except that requestStorageAcecess has to be called by an user interaction every time? Is that the case? hastStorageAccess never returns true after a page reload even when requestStorageAccess() previously has been granted.

Safari's ITP deletes website data for classified domains that 1) have not received user interaction as unpartitioned party the last 30 days of browser use, and 2) have not been granted storage access through the Storage Access API. Merely being granted access through the Storage Access API (prompt or not) is enough to stay in the green.

Does this mean that the data will be deleted ever 30:th day since they are never interact on our main domain after they have agreed to our terms and condition?

johannhof commented 3 years ago

I have mostly tested against Safari, will have to do further testing for Firefox. I think these steps are fine, except that requestStorageAcecess has to be called by an user interaction every time? Is that the case?

This is up for discussion, see #36 , but if you are requesting storage access for the first time then yes, you need user interaction.

hastStorageAccess never returns true after a page reload even when requestStorageAccess() previously has been granted.

Yes, this is browser-specific, Firefox will persist your choice and return it in hasStorageAccess immediately, see https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API for more information. I feel like we should make another effort to align on that...

Does this mean that the data will be deleted ever 30:th day since they are never interact on our main domain after they have agreed to our terms and condition?

This, again, is unfortunately browser-specific. It also depends on whether your domain is flagged as a tracker.

In Safari, IIUC, if the ITP algorithms classify your domain as a tracker, its data will be deleted after 30 days of browser use (which isn't 30 consecutive days, but days where the browser was actually used) without user interaction on your top-level site.

In Firefox, if your domain is on the list of known trackers, its data will be deleted after 45 consecutive calendar days without user interaction on your top-level site.

johnwilander commented 3 years ago

This may make it easier for you to reason about standard behavior vs browser-specifics: The Storage Access API aims to standardize how you check for and request storage access if the browser has decided to block your storage access. The Storage Access API does not aim to standardize which domains a browser should block, when it should block, for how long it should block, how it should consult the user, or how often it should consult the user.

viktor-morin commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there!

However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

johnwilander commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there!

However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

That’s not true for Safari and I don’t think it’s true for Firefox.

Firefox allows third-party cookies by default and only blocks domains on a curated block list. If your domain is not on the list, it won’t be blocked. (Firefox may change to full third-party cookie blocking down the road.)

Safari blocks all third-party cookies by default. However, the user doesn’t have to interact with your domain as first party continuously. Being granted storage access through the Storage Access API counts as user interaction too and resets the counter. Thus, if the user keeps using your widget, it’ll keep its website data.

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

viktor-morin commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there! However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

That’s not true for Safari and I don’t think it’s true for Firefox.

Firefox allows third-party cookies by default and only blocks domains on a curated block list. If your domain is not on the list, it won’t be blocked. (Firefox may change to full third-party cookie blocking down the road.)

Safari blocks all third-party cookies by default. However, the user doesn’t have to interact with your domain as first party continuously. Being granted storage access through the Storage Access API counts as user interaction too and resets the counter. Thus, if the user keeps using your widget, it’ll keep its website data.

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

If that's true it means that the only "change" that need's to be done is that we continiously need to ask the user by a user interaction for consensus to use our third-party cookie since hasStorageAccess() won't return true for Safari?

johnwilander commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there! However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

That’s not true for Safari and I don’t think it’s true for Firefox. Firefox allows third-party cookies by default and only blocks domains on a curated block list. If your domain is not on the list, it won’t be blocked. (Firefox may change to full third-party cookie blocking down the road.) Safari blocks all third-party cookies by default. However, the user doesn’t have to interact with your domain as first party continuously. Being granted storage access through the Storage Access API counts as user interaction too and resets the counter. Thus, if the user keeps using your widget, it’ll keep its website data.

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

If that's true it means that the only "change" that need's to be done is that we continiously need to ask the user by a user interaction for consensus to use our third-party cookie since hasStorageAccess() won't return true for Safari?

I don’t think it’s wise to think of this as “in Safari” or “in Firefox.” When the browser blocks storage access, you request storage access. If you write custom code for an individual browser, you’ll get into trouble as more and more browsers implement/enable the Storage Access API and as more and more browsers enable full third party cookie blocking.

viktor-morin commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there! However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

That’s not true for Safari and I don’t think it’s true for Firefox. Firefox allows third-party cookies by default and only blocks domains on a curated block list. If your domain is not on the list, it won’t be blocked. (Firefox may change to full third-party cookie blocking down the road.) Safari blocks all third-party cookies by default. However, the user doesn’t have to interact with your domain as first party continuously. Being granted storage access through the Storage Access API counts as user interaction too and resets the counter. Thus, if the user keeps using your widget, it’ll keep its website data.

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

If that's true it means that the only "change" that need's to be done is that we continiously need to ask the user by a user interaction for consensus to use our third-party cookie since hasStorageAccess() won't return true for Safari?

I don’t think it’s wise to think of this as “in Safari” or “in Firefox.” When the browser blocks storage access, you request storage access. If you write custom code for an individual browser, you’ll get into trouble as more and more browsers implement/enable the Storage Access API and as more and more browsers enable full third party cookie blocking.

Yeah agree! But the result of Safari always return false on hasStorageAccess() will prompt the user to always interact with our widget and accept that we load settings via third-party cookie. I personally think that's kind of frustrating if you accept that and then refresh the page and is forced to accept it again.

In my eyes that seems like a bad implementation, that you need to prompt the user continuously like that.

johnwilander commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there! However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

That’s not true for Safari and I don’t think it’s true for Firefox. Firefox allows third-party cookies by default and only blocks domains on a curated block list. If your domain is not on the list, it won’t be blocked. (Firefox may change to full third-party cookie blocking down the road.) Safari blocks all third-party cookies by default. However, the user doesn’t have to interact with your domain as first party continuously. Being granted storage access through the Storage Access API counts as user interaction too and resets the counter. Thus, if the user keeps using your widget, it’ll keep its website data.

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

If that's true it means that the only "change" that need's to be done is that we continiously need to ask the user by a user interaction for consensus to use our third-party cookie since hasStorageAccess() won't return true for Safari?

I don’t think it’s wise to think of this as “in Safari” or “in Firefox.” When the browser blocks storage access, you request storage access. If you write custom code for an individual browser, you’ll get into trouble as more and more browsers implement/enable the Storage Access API and as more and more browsers enable full third party cookie blocking.

Yeah agree! But the result of Safari always return false on hasStorageAccess() will prompt the user to always interact with our widget and accept that we load settings via third-party cookie. I personally think that's kind of frustrating if you accept that and then refresh the page and is forced to accept it again.

Are you saying it returns false in your iframe after that iframe has been granted storage access? Shipping behavior in Safari is per-frame access. When the frame goes away, so does access. Safari will likely move to per-page access as discussed here in the standards process. Safari Technology Preview already has that behavior afaik.

We should fix it if there’s a bug in document.hasStorageAccess(). But if there’s not, my comment stands – there is no reason to think of this as Safari-specific in your code. If your iframe is blocked from unpartitioned storage access, you request storage access. Same for all browsers.

viktor-morin commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there! However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

That’s not true for Safari and I don’t think it’s true for Firefox. Firefox allows third-party cookies by default and only blocks domains on a curated block list. If your domain is not on the list, it won’t be blocked. (Firefox may change to full third-party cookie blocking down the road.) Safari blocks all third-party cookies by default. However, the user doesn’t have to interact with your domain as first party continuously. Being granted storage access through the Storage Access API counts as user interaction too and resets the counter. Thus, if the user keeps using your widget, it’ll keep its website data.

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

If that's true it means that the only "change" that need's to be done is that we continiously need to ask the user by a user interaction for consensus to use our third-party cookie since hasStorageAccess() won't return true for Safari?

I don’t think it’s wise to think of this as “in Safari” or “in Firefox.” When the browser blocks storage access, you request storage access. If you write custom code for an individual browser, you’ll get into trouble as more and more browsers implement/enable the Storage Access API and as more and more browsers enable full third party cookie blocking.

Yeah agree! But the result of Safari always return false on hasStorageAccess() will prompt the user to always interact with our widget and accept that we load settings via third-party cookie. I personally think that's kind of frustrating if you accept that and then refresh the page and is forced to accept it again.

Are you saying it returns false in your iframe after that iframe has been granted storage access? Shipping behavior in Safari is per-frame access. When the frame goes away, so does access. Safari will likely move to per-page access as discussed here in the standards process. Safari Technology Preview already has that behavior afaik.

We should fix it if there’s a bug in document.hasStorageAccess(). But if there’s not, my comment stands – there is no reason to think of this as Safari-specific in your code. If your iframe is blocked from unpartitioned storage access, you request storage access. Same for all browsers.

Yes,

To clarify. Our customers get HTML code which they render on their site. Inside that HTML code is there an iframe which always goes to same url (src). During my testing, that iframe on load check hasStorageAccess() and always return false where we show a button for the user to interact with which call requestStorageAccess()

johnwilander commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there! However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

That’s not true for Safari and I don’t think it’s true for Firefox. Firefox allows third-party cookies by default and only blocks domains on a curated block list. If your domain is not on the list, it won’t be blocked. (Firefox may change to full third-party cookie blocking down the road.) Safari blocks all third-party cookies by default. However, the user doesn’t have to interact with your domain as first party continuously. Being granted storage access through the Storage Access API counts as user interaction too and resets the counter. Thus, if the user keeps using your widget, it’ll keep its website data.

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

If that's true it means that the only "change" that need's to be done is that we continiously need to ask the user by a user interaction for consensus to use our third-party cookie since hasStorageAccess() won't return true for Safari?

I don’t think it’s wise to think of this as “in Safari” or “in Firefox.” When the browser blocks storage access, you request storage access. If you write custom code for an individual browser, you’ll get into trouble as more and more browsers implement/enable the Storage Access API and as more and more browsers enable full third party cookie blocking.

Yeah agree! But the result of Safari always return false on hasStorageAccess() will prompt the user to always interact with our widget and accept that we load settings via third-party cookie. I personally think that's kind of frustrating if you accept that and then refresh the page and is forced to accept it again.

Are you saying it returns false in your iframe after that iframe has been granted storage access? Shipping behavior in Safari is per-frame access. When the frame goes away, so does access. Safari will likely move to per-page access as discussed here in the standards process. Safari Technology Preview already has that behavior afaik. We should fix it if there’s a bug in document.hasStorageAccess(). But if there’s not, my comment stands – there is no reason to think of this as Safari-specific in your code. If your iframe is blocked from unpartitioned storage access, you request storage access. Same for all browsers.

Yes,

To clarify. Our customers get HTML code which they render on their site. Inside that HTML code is there an iframe which always goes to same url (src). During my testing, that iframe on load check hasStorageAccess() and always return false where we show a button for the user to interact with which call requestStorageAccess()

What does document.hasStorageAccess() return after you’ve been granted storage access through document.requestStorageAccess()?

viktor-morin commented 3 years ago

Thanks for the information. In general I think all these new changes is for the better, so all happy there! However, if feels like a function as we use (save settings as a cookie) that should follow you on every site you visit with our widget integrated will be lost in between. I don't really see a good solution to that. Since the user won't visit the main domain, the setting saved will be erased every 30th or 45th day depending on browser?

That’s not true for Safari and I don’t think it’s true for Firefox. Firefox allows third-party cookies by default and only blocks domains on a curated block list. If your domain is not on the list, it won’t be blocked. (Firefox may change to full third-party cookie blocking down the road.) Safari blocks all third-party cookies by default. However, the user doesn’t have to interact with your domain as first party continuously. Being granted storage access through the Storage Access API counts as user interaction too and resets the counter. Thus, if the user keeps using your widget, it’ll keep its website data.

I guess the best way for us is to figure out a way to make our widget work without the need of saving a cookie.

If that's true it means that the only "change" that need's to be done is that we continiously need to ask the user by a user interaction for consensus to use our third-party cookie since hasStorageAccess() won't return true for Safari?

I don’t think it’s wise to think of this as “in Safari” or “in Firefox.” When the browser blocks storage access, you request storage access. If you write custom code for an individual browser, you’ll get into trouble as more and more browsers implement/enable the Storage Access API and as more and more browsers enable full third party cookie blocking.

Yeah agree! But the result of Safari always return false on hasStorageAccess() will prompt the user to always interact with our widget and accept that we load settings via third-party cookie. I personally think that's kind of frustrating if you accept that and then refresh the page and is forced to accept it again.

Are you saying it returns false in your iframe after that iframe has been granted storage access? Shipping behavior in Safari is per-frame access. When the frame goes away, so does access. Safari will likely move to per-page access as discussed here in the standards process. Safari Technology Preview already has that behavior afaik. We should fix it if there’s a bug in document.hasStorageAccess(). But if there’s not, my comment stands – there is no reason to think of this as Safari-specific in your code. If your iframe is blocked from unpartitioned storage access, you request storage access. Same for all browsers.

Yes, To clarify. Our customers get HTML code which they render on their site. Inside that HTML code is there an iframe which always goes to same url (src). During my testing, that iframe on load check hasStorageAccess() and always return false where we show a button for the user to interact with which call requestStorageAccess()

What does document.hasStorageAccess() return after you’ve been granted storage access through document.requestStorageAccess()?

Before requestStorageAccess() has been accepted: pending After reqeuestStorageAccess() has been accepted: resolved (true)

Then after refresh of same page/site I run hasStorageAccess() and Safari returns: pending Seems like a bug?

johnwilander commented 3 years ago

Before requestStorageAccess() has been accepted: pending After reqeuestStorageAccess() has been accepted: resolved (true)

Then after refresh of same page/site I run hasStorageAccess() and Safari returns: pending Seems like a bug?

This is an asynchronous, promise-based API. Pending means the promise has not yet been resolved or rejected. It would be a bug if it never resolves or rejects. If you believe there's a bug, please file at https://bugs.webkit.org.

viktor-morin commented 3 years ago

Before requestStorageAccess() has been accepted: pending After reqeuestStorageAccess() has been accepted: resolved (true) Then after refresh of same page/site I run hasStorageAccess() and Safari returns: pending Seems like a bug?

This is an asynchronous, promise-based API. Pending means the promise has not yet been resolved or rejected. It would be a bug if it never resolves or rejects. If you believe there's a bug, please file at https://bugs.webkit.org.

Just to clarify, so when requestStorageAccess() has been granted, the user does an refresh on the page, that promise change to pendig is correct behaviour? Can't see why the user would have to accept things over and over?

johnwilander commented 3 years ago

Before requestStorageAccess() has been accepted: pending After reqeuestStorageAccess() has been accepted: resolved (true) Then after refresh of same page/site I run hasStorageAccess() and Safari returns: pending Seems like a bug?

This is an asynchronous, promise-based API. Pending means the promise has not yet been resolved or rejected. It would be a bug if it never resolves or rejects. If you believe there's a bug, please file at https://bugs.webkit.org.

Just to clarify, so when requestStorageAccess() has been granted, the user does an refresh on the page, that promise change to pendig is correct behaviour? Can't see why the user would have to accept things over and over?

As mentioned, WebKit/Safari uses per-frame access scope. When the whole webpage is reloaded, so are its subframes which means that access is revoked.

The user does not have to accept things over and over. The browser will remember that the user said "Allow." However, the iframe still needs to request storage access upon a user gesture. If the user has already opted in, there will be no prompt and access will be granted automatically.

viktor-morin commented 3 years ago

Before requestStorageAccess() has been accepted: pending After reqeuestStorageAccess() has been accepted: resolved (true) Then after refresh of same page/site I run hasStorageAccess() and Safari returns: pending Seems like a bug?

This is an asynchronous, promise-based API. Pending means the promise has not yet been resolved or rejected. It would be a bug if it never resolves or rejects. If you believe there's a bug, please file at https://bugs.webkit.org.

Just to clarify, so when requestStorageAccess() has been granted, the user does an refresh on the page, that promise change to pendig is correct behaviour? Can't see why the user would have to accept things over and over?

As mentioned, WebKit/Safari uses per-frame access scope. When the whole webpage is reloaded, so are its subframes which means that access is revoked.

The user does not have to accept things over and over. The browser will remember that the user said "Allow." However, the iframe still needs to request storage access upon a user gesture. If the user has already opted in, there will be no prompt and access will be granted automatically.

Thanks!

Since we use an iframe to store the settings independant on which site (domain) they use our widget (don't know any other alternative) we will have to ask for request each time. Wouldnt it be an idea to have an iframe sandbox attribute which by default allow this? Then the owner of the domain can allow iframe's to have that functionallity if it's needed. I guess my bigger question is. How do you enable good functionallity to work which makes it better for the end-user and still prevent third party tracking where the end-user don't want to participate.

johannhof commented 3 years ago

Is there anything actionable in this issue? I think we should use a different place to track adding usable examples for Storage Access API usage and close this.

Feel free to reopen if there's still something to track here.

viktor-morin commented 3 years ago

@johannhof @johnwilander

So after been live with our implementation now for some days, we have one major issue. This has only been tested on Safari.

I have repetitively been visiting a site where our widget is implemented. Today was all my settings (cookie stored information) removed. And when I was trying to write new data, that data was not stored until I visit my main domain again and got a cookie writen from there. It was then possible to store new data.

How do I deal with the fact that the cookie as removed?
How do I deal with the fact that I once more has to visit my main domain?
What's the implemented time window for these to things to happen?

I was however not prompt with accepting "third-party cookie" to store data, that settings seems to remain.

johnwilander commented 3 years ago

Please file with the individual browser (engine) if you are seeing browser-specific behavior that’s not covered by this spec. In this case: https://bugs.webkit.org, cc’ing me. Thanks!

viktor-morin commented 3 years ago

@johnwilander

I can confirm today that using Safari, our third-party cookies are deleted after 7 days, even when using Storage API Introducing Storage Access API

The Safari policy regarding cookies is not a strict seven-day time limit. It involves a counter for up to seven unused days. That means every time a user opens Safari and visits your website, your seven-day counter for cookies and script-writable storage is reset to another seven days. Empty days don’t count against you when the user doesn’t use Safari.

It’s when they open Safari and browse without visiting your website on a particular day that days are added to your tally. You have seven such days until your cookies and all “script writable storage” is removed. It’s the user inactivity with your site that counts against you. Users will need to revisit your site in order for you to be able to write storage and start with a new counter.

Is there any way for us to solve this? Our service is not working today since our settings are removed every 7-days.

No visit to our main domain is done for the user except first time
Storage API is used

7-Day Cap on All Script-Writeable Storage Trackers executing script in the first-party context often make use of first-party storage to save and recall cross-site tracking information. Therefore, ITP caps the expiry of all cookies created in JavaScript to 7 days and deletes all other script-writeable storage after 7 days of no user interaction with the website. The latter storage forms are:

IndexedDB LocalStorage Media` keys SessionStorage Service Worker registrations and cache

7-Day Cap on All Script-Writeable Storage

It seems to me that if the user has accepted third-party cookies using the Storage API (the user has also been on the main domain), we still don't have a way to save data for more then 7 days in Safari? Is that really the purpose if this?

johnwilander commented 3 years ago

Please don’t file Safari- or WebKit-specific issues here. This is a standards repository. You should use https://bugs.webkit.org for things specific to the WebKit engine. You can CC me directly on the issue once you’ve filed it there. Thanks!

viktor-morin commented 3 years ago

Please don’t file Safari- or WebKit-specific issues here. This is a standards repository. You should use https://bugs.webkit.org for things specific to the WebKit engine. You can CC me directly on the issue once you’ve filed it there. Thanks!

Thanks, see now that this is not the right forum for this question. However, not sure that https://bugs.webkit.org is the right place either. If this is working as intended there is not really a bug to report.

But to relate it to the Storage API, I don't see the issue when asking the user via Storage API to store third-party cookie that the data only can be stored for 7 days. ApplicationS etc. where settings need to be saved cant function properly.

johnwilander commented 3 years ago

Please don’t file Safari- or WebKit-specific issues here. This is a standards repository. You should use https://bugs.webkit.org for things specific to the WebKit engine. You can CC me directly on the issue once you’ve filed it there. Thanks!

Thanks, see now that this is not the right forum for this question. However, not sure that https://bugs.webkit.org is the right place either. If this is working as intended there is not really a bug to report.

But to relate it to the Storage API, I don't see the issue when asking the user via Storage API to store third-party cookie that the data only can be stored for 7 days. ApplicationS etc. where settings need to be saved cant function properly.

Cookies having their expiry capped to a certain number of days has nothing to do with the Storage Access API. It’s part of a WebKit feature called Intelligent Tracking Prevention that is not proposed as a standard and does not exist in any other engine. The Storage Access API is only about getting access to unpartitioned cookies and storage.

Please file your issue at https://bugs.webkit.org where we can talk about it.