Add vivenu shop domains to private section

[MrMarvin]

Public Suffix List (PSL) Submission

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _psl TXT record in place in the respective zone(s).

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• none

• This request was not submitted with the objective of working around other third-party limits.

• The submitter acknowledges that it is their responsibility to maintain the domains within their section. This includes removing names which are no longer used, retaining the _psl DNS entry, and responding to e-mails to the supplied address. Failure to maintain entries may result in removal of individual entries or the entire section.

• The Guidelines were carefully read and understood, and this request conforms to them.
• The submission follows the guidelines on formatting and sorting.

• A role-based email address has been used and this inbox is actively monitored with a response time of no more than 30 days.

Abuse Contact:

• Abuse contact information (email or web form) is available and easily accessible.

  URL where abuse contact or abuse reporting form can be found: https://vivenu.com/imprint

---

For PRIVATE section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies and cause other issues, and the rollback timing is acceptable. Proceed anyways.

---

Description of Organization

Organization Website: https://vivenu.com/

vivenu's web based solution offers while-label online shop functionality with a focus on event ticketing. Our customers include event organizers, venues, sports clubs or similar organizations.

Reason for PSL Inclusion

vivenu seeks inclusion of its customer-shared domains for end-user web security reasons.

Our customers are mutually distrusted and operate online shops that may include ticket buyer login / authentication in advanced ticket sale setups.

From our platform's perspective we are interested in allowing each shop to be hosted on a sub-domain, without compromising on end-user (i.e. the person browsing and buying tickets) cookie separation.

Currently shops are required to point their custom domain (e.g. tickets.example.com) to our platform, for which we then validate domain settings and issue a custom host name certificate. In the near future we will start issuing complimentary sub domains to existing and new customers, e.g. exampletickets.vivenushop.com.

The .dev domain will be used for sandbox, pre-production and test shops, while the .com domain will host our customer's production shops.

Number of users this request is being made to serve:
More than a hundred thousand end users, over multiple thousand individual customer shops.

DNS Verification

dig +short TXT _psl.vivenushop.com
"https://github.com/publicsuffix/list/pull/2796"

dig +short TXT _psl.vivenushop.dev
"https://github.com/publicsuffix/list/pull/2796"

[pencilnav]

Requirements Checklist

• _psl records (note: Must STAY IN PLACE)

• Expiration (note: Must BE >2y)

• Organization description

  • Vivenu's offers online shop functionality with focus on event ticketing.

• Email address

  • ops@vivenu.com is a role based email

• Abuse contact

  • Abuse contact information (email or web form) is available and easily accessible. (An abuse report link is provided https://vivenu.com/imprint)
  • Added PSL domains should redirect to company site or abuse report link for easier abuse contact discovery (see Add choreoapps.dev to private section #2680 (comment))

@MrMarvin

[pencilnav]

@MrMarvin i was unable to find any active sites on vivenushop.com and only one site on vivenushop.dev. Are all your customers getting a subdomain from these two zones?

More than a hundred thousand end users, over multiple thousand individual customer shops.

Could you provide more information for this? (Note: The "number of users this request is being made to serve" means the amount of customers that receives a subdomain of the submitted entries. The user counts should be per entry so please provide seperate numbers for both vivenushop.com and vivenushop.dev.

And also, there are standard security practices that work immediately without waiting months or years for PSL propagation. Have you considered implementing this? (Quoted from #2743 (comment))

Additionally, cookie isolation between subdomains can be effectively achieved through standard security practices that work immediately, without waiting months or years for PSL propagation: use the __Host- cookie prefix (which enforces Secure, Path=/, and no Domain attribute), implement proper SameSite attributes, and ensure HTTPS across all subdomains.

[MrMarvin]

Thanks for the review, @pencilnav. Much appreciated!

Redirect for contact

We've got the redirect on the zone root in place now:

• https://vivenushop.com/ -> https://vivenu.com/
• https://vivenushop.dev/ -> https://vivenu.com/

Same for plain http.

Questions

I was unable to find any active sites on vivenushop.com and only one site on vivenushop.dev. Are all your customers getting a subdomain from these two zones?

A large portion of existing customer shops as well as all new shops being created moving forward.

Are you using certificate transparency listings for determining the sites under this domain? If so, please note that we are explicitly using a wildcard certificate for public ingress here.

The user counts should be per entry

While I cannot publicly share our exact customer numbers, here are some calculation as part of our migration efforts to provide each such customer shop with its own domain. This excludes certain customers, for example ones on specific types of contracts as well as shops that have a custom domain already setup via other means.

• *.vivenushop.com - Roughly 2200 in initial wave.
• *.vivenushop.dev - About 1900 in initial wave.

Going forward each customer shop will be assigned a sub-domain during creation. Most customers opt to use an additional .dev shop for testing or other non-production evaluation or training.

Have you considered implementing [__Host- prefix cookies]?

Yes. In a secondary work stream we are currently rebuilding a major part of our shop rendering functionality, including improved and secure cookies management. There are some uses of vendor cookies - for example ones set by the Stripe SDK used along a ticket buyer's checkout journey - that we do not have immediate control over.

[pencilnav]

Are you using certificate transparency listings for determining the sites under this domain?

I use results from multiple sources and CT logs are one of it. Reason I'm asking is because they all returned results that are relatively low (to almost nothing).

As for the PR, overall seems good and the provided user count numbers looks legit based on some checks I've performed.

LGTM. Waiting for @simon-friedberger to check.

[simon-friedberger]

From your website it looks like you supply software for ticketing which would put the software under your control, as does your statement about introducing host cookies.

Combined with the fact that people who have events and sell tickets generally want to use their own domain I don't really understand why this should be on the PSL. Can you elaborate on why you are switching to this new system?

[MrMarvin]

Hi @simon-friedberger 👋

you supply software for ticketing which would put the software under your control,

Correct, we operate the software on a multi-tenant shared infrastructure, much like, for example, Shopify does control their e-commerce software.

Following on with the above example, this is very close to what Shopify does for their merchants with customername.myshopify.com - issuing a default sub-domain for each new shop that signs up. Their domains was included in #1179.

as does your statement about introducing host cookies.

While we do manage cookies via our SaaS platform functionality across all shops, as well as including third party (the Stripe SDK example from earlier), there is functionality where shop operators (i.e. our customers) can include their own client side java script to run on their shop web presence.

Can you elaborate on why you are switching to this new system?

The decision to host third part shops via our primary domain in the past has been revisited and deemed not viable for both technical and security reasons.
Interestingly your assessment about "people who have events and sell tickets generally want to use their own domain" is not what happens in reality in all cases. Similar to many shops existing on the Shopify platform that continue to use the complimentary auto-generated sub-domain, we do have customers that are not necessarily moving towards custom domains on their own.

Quick update from our rollout

We have created custom sub-domains from the two zones mentioned in this PR as of roughly two weeks ago and will be starting to actively switch over shops to those soon. We do understand that the PSL is not a fix-all and not an immediate effective measure, yet decided to move forward with this as a long-term strategy.