Adding scoreapp.me domain name

[stevenoddy]

• Description of Organization
• Reason for PSL Inclusion
• DNS verification via dig
• Run Syntax Checker (make test)
• 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

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)
• This request was not submitted with the objective of working around other third party limits
• The Guidelines were carefully read and understood, and this request conforms
• The submission follows the guidelines on formatting

Description of Organization

Organization Website: https://www.scoreapp.com
ScoreApp (owned by Hyper Targeting Marketing Limited) is a quiz / microsite builder. We issue scoreapp.me sub-domains to our users.

Reason for PSL Inclusion

This is a pull request in response to the Apple iOS 14.5 change that affected Facebook Pixel tracking functionality for the domain(s) in the change, and we seek to resolve the impacts to the best of our ability to do so. Both Apple and Facebook support Public Suffix List for Private Click Measurement and Aggregated Event Measurement respectively.
○ We have reviewed the wiki here outlining the PSL and understand what it is and is not.
○ We have reviewed this matter with the team at Facebook, we are now fully aware about the consequences to the change we are requesting as it relates to cookies or other services, and choose to proceed in submitting this PR. We understand that despite reviewing the matter with Facebook, Facebook cannot control which use cases get accepted to the PSL
○ We understand that there is not any urgency and should this PR be merged to include our requested change, that there is no control over the timing of this change being updated downstream in browsers, libraries, certificate authorities or other systems or processes that incorporate the PSL.
○ We understand that if we later want to back out this change, there is also no guarantee that this will occur in a rapid fashion due to the same lack of control over browser, library, certificate authority, or other system or process changes.

○ We also confirm the domain listed holds a registration term longer than 2 years and shall
maintain more than a 1 year term in order to remain listed

DNS Verification via dig

dig +short TXT _psl.scoreapp.me
"https://github.com/publicsuffix/list/pull/1408"

make test

[x]

[bedfordsean]

Confirming that Facebook have vetted this request to confirm:

• Ownership of the domain
• Number of subdomains (Note this check was originally done against scoreapp.com which we have been advised will be moved to scoreapp.me)
• Whether those subdomains appear to represent individual businesses

Based on those checks, we made a recommendation to proceed with a PR here

[sleevi]

@bedfordsean I'm not understand how your message has any bearing on the PSL, what it's used for, or how this helps maintainers of the PSL.

Based on the explanation provided, I'm marking this WontFix.

[bedfordsean]

@sleevi sorry this was an attempt at more transparency about the checks that FB have carried out (as per our other Issue thread). This request has gone through the FB review process and we made the recommendation to proceed here. As mentioned previously to @stevenoddy, the decision to add, or not, to the PSL ultimately sits with this group.

[stevenoddy]

@sleevi thank you for taking the time to review this PR. I think I perhaps did not add enough information to the reason for PSL inclusion. Having gone through the outlined process with facebook first I assumed the reason provided by them to include was enough. Having now reviewed other similar PR's which have been successfully merged I can see a further explanation should be included...

Our platform is a lead generation and marketing platform. Each user who subscribes to our service can essentially build a quiz/microsite using our platform. This includes landing pages, forms and result pages. Each user gets a scoreapp.me subdomain which is where their microsite is hosted. Each subdomain is personal to the user and separate for each account.

For example a user may use
user1.scoreapp.me and would have pages such as user1.scoreapp.me/questions, user1.scoreapp.me/results

Another user might use
user2.scoreapp.me and would have pages such as user2.scoreapp.me/questions, user2.scoreapp.me/results

user1.scoreapp.me and user2.scoreapp.me should not be able to share cookies / scripts etc in anyway.

[bedfordsean]

Hi @stevenoddy, thanks for the extra context. Just to clarify how/why FB got involved; how much traction/need do you see for advertising via Facebook between these different subdomains? Is that common enough to warrant a need to solve for that, or is cookie/script separation your primary concern?

[stevenoddy]

@bedfordsean allowing our customers to verify ownership of their separate subdomains with fb is a primary concern for sure. We currently have over 2000 subdomains in use (currently under .scoreapp.com), many of which were running ads on FB prior to the changes, or intended to run ads and are now currently stuck.

[bedfordsean]

@stevenoddy thanks for confirming. What is your plan if we are unable to proceed with a PSL addition even with the extra context and cookie/security separations as described above?

[stevenoddy]

@bedfordsean some of our customers are able to link their own custom domains to our service which for these customers solves these problems however the provision and use of the sub domains is a core part of our service and therefore I feel strongly that including this domain is important and in the best interest of protecting our customers.

[sleevi]

This seems as clear and unambiguous an attempt to get on the PSL to evade platform limits as there ever was. Comments like #1408 (comment) seem to acknowledge this, while comments like #1408 (comment) make it clear that this is, in fact, a common endpoint under a single entities control with limited risk of exposure. Having sat through the 10 minute demonstration, and also looked at the functionality afforded and documented in the knowledge base, this seems to be a simple CMS in which ScoreApp controls content and display. Even if these are separate entities, there is no reason to reflect these on the PSL: except, of course, for additional tracking purposes and bypassing Apple and Facebook limits.

Am I missing something here? This seems the clearest WontFix we’ve had in a long time.

[stevenoddy]

@sleevi perhaps I'm missing something as I can see accepted and merged PR's such as this #1351 and this #1368 that have the exact same use case?

Our platform does control content and display, but it does allow our customers to install scripts and custom html in their sites in the same way the platforms in the above PR's do.

[sleevi]

Those PRs seem like they should also have been rejected. Given the volume of requests and the time commitment required, we may not have the time to perform all the same due diligence checks all of the time, as we’re only human, but for yours, it was performed, and it doesn’t seem to meet the goal, purpose, or need for the PSL.

[stevenoddy]

@sleevi respectfully those 2 PR's don't seem to be a few that have slipped through the net. There are several more and they seem to follow the same guidance we have followed and have been accepted by @dnsguru

ScoreApp is a multi-tenant platform which issues sub domains for each user, exactly the same as myshopify.com and therefore requests between sites using *.scoreapp.me domains are considered to be samesite, leaving them open to CSRF.

Before submitting this PR I carefully read the thread related to the influx of requests due to the FB / iOS, and as such waited and followed the guidance by going through the facebook process first and then following the guidance issued by them hence the comment from @bedfordsean. It seems because we went through this outlined process with FB our request is now being rejected and the users of our subdomains are left open to CSRF?

[sleevi]

CSRF doesn’t apply here. I’m not sure why you’re mentioning it.