Scenario Validation (Embedded Component (Tableau) )

[privacycg]

Scenario Validation (Embedded Component (Tableau) )

[johannhof]

Hi @LGraber, thanks for opening this issue. If I understand correctly you don't actually require cookies for authentication with your service, because of the shared identity provider concept, you simply require cookies to "work" in order to save your session state and run the application, correct?

I might not fully understand this sentence:

The only information we need shared across sites is IDP related and seems to be getting addressed

Does that mean that your integration flow does not yet work in Firefox Strict Mode (which does partitioning) or that it does? :)

[LGraber]

Partitioned Storage actually has not shown any problems for us (in my testing). Like I said, I picked a topic but maybe should have picked StorageAccess API since that does not work (and is the option being pushed by Safari).

Our cookie (session and csrf) is used for maintaining an Authenticated Session. If we lose the cookie, we have to ask to re-authenticate. In our cases, this can involve going back to an IDP (which might just work if their cookies are still valid/working). Storage Partitioning right now was the one case that appears to be 'just working' (as outlined in my writeup) but I am continuing to try and test 'corner' cases.

Would you recommend I put this in a different repo?

[johannhof]

It's great to hear that Partitioning is working out well for you! If you encounter any bugs/strange behavior/bad developer experience on Firefox side, we'd love to hear about it on Bugzilla

If you have issues with the Storage Access API specifically, yes, please file them in https://github.com/privacycg/storage-access/. However, note that not all of Safari's restrictions and behavior are necessarily captured in the Storage Access API specification.

For example, Firefox and Edge do not require prior 1st party user interaction to be able to call requestStorageAccess, and (I think both) will allow for requesting storage access without a prompt on the first 5 origins. So that might work better for you. Some of these differences are intentionally left open in the spec, to allow browsers to differentiate on privacy features, but generally we'd like to avoid having a bad developer experience because of it. Again, if you have any specific use cases where the Storage Access API is making things really difficult for you, feel free to open an issue there :)

(cc @johnwilander)

Thanks!

[LGraber]

Thanks! I will copy this over to there. I have tested the StorageAccess API on different browsers and have documented our behavior and the differences in an internal table. Some implementations appear to be able to work with our scenario but others are practically a dead end and it is difficult to tell what to expect because in the end, we want to work in all the browsers our customers use. Thanks for the response and I will continue to test out Partioning