Proposal: Privacy-specific changes to the footer

[carlesandres]

The problem

As the privacy team we were recently required to show a variation of our footer to California users only, as demanded by the new privacy legislation that applies to them (CCPA).

The current solution

In order to avoid splitting the CDN caches further, the approach we took was to keep rendering the existing version of the footer from the server, and to make the necessary alterations for California users in the client.*

We implemented this change directly on next-front-page as a way to ensure we would meet the basic requirements by the hard deadline of 1st July, imposed by CCPA.

The proposed solution

We are now being asked to make a different change to the footer for California users.

Considering we are expecting new privacy laws to come out in the future, which will likely need their own links or wording in the footer, we are proposing:

1. Keep the code to dynamically modify the footer in a new package that lives under the privacy monorepo, so that all the privacy-specific business logic is contained where it makes sense.
2. Import this module within dotcom-ui-footer so that it’s brought to all of dotcom footers consistently and test-ably

We are seeking feedback from Platforms team and anyone else interested on this approach to make sure it's aligned with the overall dotcom architecture.

---

*

Detecting the privacy legislation that applies to a user is also done client-side by querying the new https://privacy.ft.com/api/v1/compliance-region.json endpoint.

We currently check the user compliance region and alter the footer after most other JS has run on the page, since the it takes usually a few seconds for a user to scroll to the footer.

All this functionality is currently behind the privShowCCPALinkOnFooter flag and only being applied to the homepage.

[carlesandres]

@pixelandpage @andygout @kavanagh I would love to hear your thoughts on this as soon as you find the time, since we have just received the new requirements and we are supposed to implement them before 1st July.

[kavanagh]

hi @carlesandres, this seems like a good idea. I have a few questions:

1. What should have the dependency on the new privacy package, the app (ie next-front-page) or dotcom-ui-footer. If dotcom-ui-footer imports it, that doesn't really guarantee that the privacy links displayed in the footer are the same across all apps? As an App owner, I don't think it would be obvious to me that I need to go and update the footer package version to get the latest privacy links, or indeed be notified that they're out of date. Perhaps the relationship between app and privacy package should be direct/explicit?

2. How would the client code (HTML / CSS / JS) change with this proposal? Is this change just about more efficiently deploying code changes and separation of concerns?

3. Will the markup actually be high-coupled with the markup of the footer? If we decided to change the footer design or markup, would we also need to change the privacy package? If so, should the package actually live in the page kit repo?

[carlesandres]

Hi @kavanagh. Thanks for the quick feedback. To answer your questions:

1. We are proposing that the new module (temptative name privacy-footer-localiser) is a dependency of dotcom-ui-footer for dotcom pages, so that, if someone needs to get all the latest changes that affect the footer they just update dotcom-ui-footer. My assumption is that any new non-patch release of the privacy-footer-localiser would require a release of dotcom-page-kit, but this would still be simpler than updating the dependency directly in all of the apps individually. Non-dotcom apps should import the new package directly (unless they have a wrapper around the footer too). But your point is valid and it might not be immediately obvious to app owners, which we might be able to mitigate by adding documentation to both dotcom-page-kit and the Next wiki.

2. The change involves removing the bit of code we added to next-front-page to manipulate the footer, move it to the new package and bring it back to next-front-page and the rest of dotcom by means of the new mechanism. We actually want the privacy links to look the same for each user across all of ft.com. The initial work we did only on the homepage was the fastest implementation we could come up with that would ensure we met the essential requirements.
   You are right, the change is all about separation of concerns and replicating the organisation's team structure in the code structure so that deploying is more efficient.

3. The markup is always going to be somewhat coupled with that of the footer because we are manipulating DOM elements on-the-fly. We have started running some tests-in-production that ensure things behave as expected in a some scenarios and the intention is to increase the coverage of those tests so that the ads-privacy team gets notified quickly if something unexpected happens to any of the apps affected.

[andygout]

Thanks @carlesandres.

Given this change needs to be applied to all FT.com apps then I think it can be justified as being added as a dependency of dotcom-ui-footer. For example, we have previously turned down proposals that want to add the ability to modify the footer for the sake of one app only.

I am uneasy about manipulating DOM elements client-side. Any iterations on the design and/or content of the footer would potentially need to include work (or at least consideration) to maintain the effect of privacy-footer-localiser. What would the trade-off be to get the information at preflight to allow the footer to be a component that simply spits out the information fed into it? You mention splitting the CDN cache further - can you expand on that in terms of the specific problems it poses (I guess it all increases the preflight tasks and therefore the time it takes for that stage to complete).

[kavanagh]

@carlesandres so if a change is made to privacy-footer-localiser, you must release dotcom-ui-footer also but without much change to the latter except a version change of a dependency? If the concerns are separated and both had good test then I'd hope this wouldn't be necessary unless there is a major change in that requires the footer to be bumped. This is the kind of relationship that was onerous with n-ui and we tried to design out of PageKit.

You are right, the change is all about separation of concerns and replicating the organisation's team structure in the code structure so that deploying is more efficient.

Ok, that's good to know. Although it's still feasible for the Ads & Privacy team to own a component within the dotcom-page-kit repo. If we took our team structure out of the equation, I'd have thought this functionality belongs in page-kit because it's used as part of the furniture of all dotcom pages. If there are code libraries and types that are used in different contexts beyond the render-links-in-the-footer use case then I could see the argument for them living in the privacy repo.

Another way to look at this would be to take another element like the navigation in the header, as an example. At the moment, that lives in the page-kit repo. If the Content Discovery or Accounts teams owned that functionality, I wouldn't see the ownership argument as a good reason to move this code to another repo. I could see a good reason if we wanted to use some of the types in dotcom-types-navigation in another context such as the App or Amp. But in that case, I'd probably leave the dotcom specific parts in dotcom-ui-header or dotcom-server-navigation in this repo.

[kavanagh]

@andygout, when @carlesandres says "manipulating DOM elements client-side", I think he means showing and hiding them. There is a design doc about this. Provided we have the right tests in page-kit, I think the client-side rendering is fine while we have the single locale (California) use case.

[carlesandres]

Thank you both @andygout @kavanagh for taking the time to discuss this.

Based on your comments and considering the new requirement (which is about changing the text of the "Privacy" Link on the footer to "Privacy CCPA Updates" for California users only), I am going to give this some more thought and I'll get back to you with a refined proposal.

[carlesandres]

Hi again @kavanagh and @andygout ! I've gone back to my team for further clarification on the CCPA requirements that affect the footer.

Requirement # 1: Add a "Do Not Sell My Info" link to the footer

1. The business wants us to show and additional "Do Not Sell My Info" link ONLY on the homepage's footer. Apparently CCPA legislation requires it only on the homepage and, as a business, we really don't want people to click on it so, after asking again, I've been told we do not want the new link on other pages.

2. The current implementation adds the "Do Not Sell My Info" node dynamically, rather than rendering it for everyone server-side and then removing it for non-CA users. This is an oversight on my part of the design document and I am happy to address if you think it makes a difference, although I'm completely new to next-navigation and next-api and it might take me a while to figure out how to do it in a safe manner.

Requirement # 2: Move the "Privacy" link text to "Privacy - CCPA Updates".

3. In this case, the requirement is to make the change on all pages but only for California users and only until Aug 1st.

At this point, the only option we have to meet this last-minute requirement is to make the change on the client side. My proposal is to expose a method from the new privacy-footer-localiser module that we can invoke from page-kit.

Future requirements

Beyond these two requirements, we are working on the assumption that new privacy laws will come out soon and that they will bring their own set of conflicting requirements and complex scenarios, with the potential to be sued by consumers and be given huge fines.

For all of that, we believe we should consider making client-side changes to the footer standard practice , so that we can accommodate its content to the specific legislation that applies to each user. I believe @oliverturner has a suggestion that could help making those client-side manipulations more robust.

[oliverturner]

On the topic of making client-side updates more robust and flexible, my proposal is to add a new DOM node dedicated to privacy in Page Kit's layout template.

Depending on how these emergent requirements shape up, it could be rendered into to add elements or contain pre-rendered elements that are selectively revealed.

In either case, with a guarantee that Privacy-related client-side updates would be restricted to this element, this would allow it to be targeted for modification without risk to other components.

[andygout]

Requirement # 1: Add a "Do Not Sell My Info" link to the footer

I cannot see too much difference (in terms of an end-user experience) between rendering the "Do Not Sell My Info" link for all then hiding for those to whom it does not apply versus adding it client-side for those to whom it does apply. So it seems whatever you feel the neatest technical solution is would be the one to go with.

Do we still support a core (non-JS) experience that would need to accommodate the various scenarios?

Also, if this is only applied to the front page, will that app have a direct dependency on privacy-footer-localiser to conduct this logic?

Requirement # 2: Move the "Privacy" link text to "Privacy - CCPA Updates".

I think your description of invoking a privacy-footer-localiser method from Page Kit was previously discussed in this thread. As per @kavanagh's earlier comment, if the privacy-footer-localiser package is to be used exclusively for the footer logic then it can live within Page Kit (and be owned by Ads & Privacy), but if its scope is larger then it should remain as a dependency of dotcom-ui-footer.

add a new DOM node dedicated to privacy in Page Kit's layout template
This sounds sensible and will keep things clean and compartmentalised.

---

@carlesandres Do any of these changes need to be completed before tomorrow (01 Jul 2020)? You mention a 'last-minute requirement' and a I wonder if it relates to this deadline. Let me know if you want any help getting this over the line.

[carlesandres]

Do we still support a core (non-JS) experience that would need to accommodate the various scenarios?

No. It don't think it has been discussed and it seems tricky without moving the logic to the server. The thing that might mitigate the legal implications of this is the (somewhat related) fact that while Javascript is disabled the user information is not shared with third-parties.

Also, if this is only applied to the front page, will that app have a direct dependency on privacy-footer-localiser to conduct this logic?

Yes.

If the privacy-footer-localiser package is to be used exclusively for the footer logic then it can live within Page Kit (and be owned by Ads & Privacy), but if its scope is larger then it should remain as a dependency of dotcom-ui-footer

This package will only modify the footer. I was trying to point to the fact that the package will be used to modify the footer of both every page and also just some of them, in case it made you guys reconsider. I'm happy to build it as part of PageKit since that seems to be the preferred architecture.

Do any of these changes need to be completed before tomorrow (01 Jul 2020)? You mention a 'last-minute requirement' and a I wonder if it relates to this deadline.

Since we only received the new requirement 3 or 4 days ago, we've been given until the July 7th for that particular requirement, but I am aiming at getting it out asap.

Let me know if you want any help getting this over the line.

Thanks for the offer, it's very likely that I will need some help. 😃

[kavanagh]

@andygout: I cannot see too much difference (in terms of an end-user experience) between rendering the "Do Not Sell My Info" link for all then hiding for those to whom it does not apply versus adding it client-side for those to whom it does apply. So it seems whatever you feel the neatest technical solution is would be the one to go with.

Do we still support a core (non-JS) experience that would need to accommodate the various scenarios?

@carlesandres : No. It don't think it has been discussed and it seems tricky without moving the logic to the server. The thing that might mitigate the legal implications of this is the (somewhat related) fact that while Javascript is disabled the user information is not shared with third-parties.

Yes, it was discussed, but doesn't seem to be noted in the original design doc.

The idea was for the page to always contain the link and hide it for users who are not in California. If javascript fails (or is disabled), the privacy API fails, or the method of identifying the geographical location isn't working correctly then we'll still be compliant.