Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider how we use domains at Lucid Software, Inc. #207

Closed
cklim24 opened this issue Feb 18, 2024 · 0 comments
Closed

Consider how we use domains at Lucid Software, Inc. #207

cklim24 opened this issue Feb 18, 2024 · 0 comments

Comments

@cklim24
Copy link

cklim24 commented Feb 18, 2024

          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)

@johannhof johannhof closed this as not planned Won't fix, can't repro, duplicate, stale Feb 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants