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. #236

Closed
Dilasapitri opened this issue Sep 17, 2024 · 4 comments
Closed

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

Dilasapitri opened this issue Sep 17, 2024 · 4 comments

Comments

@Dilasapitri
Copy link

Dilasapitri commented Sep 17, 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)

@Dilasapitri
Copy link
Author

          Consider how we use domains at Lucid Software, Inc. 

Kami memiliki serangkaian domain yang terkait dengan dua aplikasi web (Lucidchart dan Lucidspark):

  • lucidchart.com -- situs pemasaran untuk Lucidchart
  • lucidspark.com -- situs pemasaran untuk Lucidspark
  • lucid.co -- situs pemasaran untuk "suite" gabungan
  • lucid.app -- situs yang menghosting aplikasi sebenarnya

Kumpulan domain ini diinginkan karena beberapa alasan, termasuk alasan keamanan, SEO dan kemudahan ditemukan, pencitraan merek, dll. Dan meskipun menggunakan satu domain untuk semua ini merupakan pilihan yang layak, migrasi ke satu domain dari pengaturan yang sudah ada akan memerlukan upaya dan koordinasi yang signifikan, dan kemungkinan akan menyebabkan kebingungan dan gangguan bagi pelanggan yang sudah ada, terutama karena migrasi domain akan menyebabkan mereka kehilangan cookie dan penyimpanan lokal di domain yang sudah ada (sehingga kehilangan pengaturan, token login, dll.)

Saat ini kami mengandalkan cookie pihak ketiga untuk beberapa fitur yang dihadapi pengguna, termasuk:

  • Menunjukkan apakah mereka masuk ke lucid.app di halaman pemasaran dengan menampilkan nama pengguna mereka di header
  • Mengalihkan ke lucid.app dari jalur root di lucidchart.com dan lucidspark.com jika mereka sudah masuk
  • Menggunakan riwayat penelusuran halaman pemasaran pengguna untuk memberikan rekomendasi tentang templat yang mungkin ingin mereka gunakan saat membuat dokumen baru
  • Memastikan bahwa pengguna diberi pengujian A/B secara konsisten di seluruh domain kami (serta mampu menghubungkan perilaku di seluruh kelompok pengujian A/B).

API akses penyimpanan secara teknis dapat digunakan untuk ini. Namun, meminta pengguna untuk menggunakan lucid.app agar dapat mengakses penyimpanan di lucidchart.com (dan sebaliknya) tidak akan menjadi pengalaman yang baik bagi pengguna.

Saya memahami alasan ingin menghapus cookie pihak ketiga, dan kekhawatiran dengan proposal First Party Sets. Namun, jika cookie pihak ketiga hilang tanpa sesuatu seperti FPS, saya tidak paham bagaimana cara mempertahankan rangkaian fitur kami saat ini tanpa mengorbankan pengalaman pengguna.

Awalnya diposting oleh@tmccombsdi #19 (komentar)

@cfredric
Copy link
Collaborator

Spam, closing.

@cfredric cfredric closed this as not planned Won't fix, can't repro, duplicate, stale Sep 18, 2024
@tmccombs
Copy link

Why do people keep opening issues quoting my comment from another issue?

@cfredric
Copy link
Collaborator

As far as I can tell, it's just run-of-the-mill GitHub spam. Brand new accounts with very little activity history, copying comments and commits from other places. I see it on a bunch of repositories.

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

3 participants