Consider how we use domains at Lucid Software, Inc.

[Tafarez74]

          Consider how we use domains at Lucid Software, Inc. 

We have a set of domains associated with two web apps (Lucidchart and Lucidspark):

• lucidchart.com -- marketing site for Lucidchart
• lucidspark.com -- marketing site for Lucidspark
• lucid.co -- marketing site for the combined "suite"
• lucid.app -- site that hosts the actual apps

This set of domains is desirable for multiple reasons, including security reasons, SEO and discoverability, branding, etc. And even if using a single domain for all of these were a viable option, migrating to a single domain from our existing setup would require significant effort and coordination, and would likely cause confusion and disruption for existing customers, especially since migrating domains would cause them to lose cookies and local storage on the existing domains (thus losing settings, login tokens, etc.)

We currently rely on third party cookies for several user-facing features, including:

• Indicating if they are logged in on lucid.app on the marketing pages by showing their username in a header
• Redirecting to lucid.app from the root path on lucidchart.com and lucidspark.com if they are already logged in
• Using the user's history of browsing the marketing pages to give recommendations on templates they may wish to use when creating a new document
• Ensuring that users are assigned A/B tests consistently across our multiple domains (as well as being able to correlate behaviors across A/B test cohorts).

The storage access api would technically work for this. However, prompting the user for lucid.app to be able to access storage on lucidchart.com (and vice versa) would not be a great experience for the user.

I understand the reasons for wanting to remove third-party cookies, and the concerns with the First Party Sets proposal. However, if third party cookies go away without something like a FPS, it is unclear to me how to maintain our current feature set without compromising the user's experience.

Originally posted by @tmccombs in #19 (comment)

[Tafarez74]

      Consider how we use domains at Lucid Software, Inc. 

[Tafarez74]

          Consider how we use domains at Lucid Software, Inc. 

We have a set of domains associated with two web apps (Lucidchart and Lucidspark):

• lucidchart.com -- marketing site for Lucidchart
• lucidspark.com -- marketing site for Lucidspark
• lucid.co -- marketing site for the combined "suite"
• lucid.app -- site that hosts the actual apps

This set of domains is desirable for multiple reasons, including security reasons, SEO and discoverability, branding, etc. And even if using a single domain for all of these were a viable option, migrating to a single domain from our existing setup would require significant effort and coordination, and would likely cause confusion and disruption for existing customers, especially since migrating domains would cause them to lose cookies and local storage on the existing domains (thus losing settings, login tokens, etc.)

We currently rely on third party cookies for several user-facing features, including:

• Indicating if they are logged in on lucid.app on the marketing pages by showing their username in a header
• Redirecting to lucid.app from the root path on lucidchart.com and lucidspark.com if they are already logged in
• Using the user's history of browsing the marketing pages to give recommendations on templates they may wish to use when creating a new document
• Ensuring that users are assigned A/B tests consistently across our multiple domains (as well as being able to correlate behaviors across A/B test cohorts).

The storage access api would technically work for this. However, prompting the user for lucid.app to be able to access storage on lucidchart.com (and vice versa) would not be a great experience for the user.

I understand the reasons for wanting to remove third-party cookies, and the concerns with the First Party Sets proposal. However, if third party cookies go away without something like a FPS, it is unclear to me how to maintain our current feature set without compromising the user's experience.

Originally posted by @tmccombs in #19 (comment)

#223 (comment)

[cfredric]

Closing, suspecting this is spam since it is copy/pasted verbatim from #19 (comment).