Email based workflow systems

[wanderview]

One use case discussed at TPAC that might break with bounce tracking mitigations is email based workflow systems. Consider:

1. A user receives an email from SaaS provider with link.
2. Use clicks the link and is taken to saas.example/bouncer.
3. saas.example/bouncer sees that it does not have a cookie, sets a cookie, then redirects user to customer.example/step1.
4. Later another email is sent to the user with another link to saas.example/bouncer.
5. This time when the user follows the link saas.example/bouncer see the cookie, updates its value, and then redirects the user to customer.example/step2.
6. and so on...

Here the bouncer is being used to implement a business workflow solution for a customer.

Since the user never actually interacts with saas.example/bouncer, however, our mitigations will end up deleting the cookie. This will break the workflow.

Current work arounds are:

a. Add an interstitial explaining to the user that saas.example is managing the workflow for the customer and solicit an interaction. (Adds user friction.) b. Host a version of bouncer under the customer.example domain either via a CNAME or on-premise installation. (Adds integration costs for SaaS provider and customer.)

We should consider other ways we can support this use case.

[wanderview]

For folks familiar with this use case, do these workflow systems direct people to different URLs on a single site or potentially direct them to different sites altogether? For example, the workflow is completely contained in URLs on customer1.example vs contained in URLs spread across tool1.example, tool2.example, tool3.example, etc.

[wanderview]

Note, the partitioning idea in #42 could perhaps support this use case, but only if the email workflow is always redirecting to the same destination site. If its redirecting to different destination sites then the partitioning would not help.