Privacy

Privacy Requests

Adobe Campaign offers a set of tools to help you with your Privacy Compliance for GDPR and CCPA.

Refer to this page for general information on what Privacy Management is and the implementation steps in Adobe Campaign. You will also find best practices and an overview of the user process and personas.

URL Personalization

When adding personalized links to your content, always avoid having any personalization in the hostname part of the URL to avoid potential security gaps. The following examples should never be used in all URL attributes <a href=""> or <img src="">:

  • <%= url >
  • https://<%= url >
  • https://<%= domain >/path
  • https://<%= sub-domain >.domain.tld/path
  • https://sub.domain<%= main domain %>/path

Recommendation

To validate and ensure that you are not using above, run a query on tracking URL table via Campaign Generic Query Editor or create a workflow with filter criteria in the query activity.

Example:

  1. Create a workflow and add a Query activity. Learn more.

  2. Open the Query activity and create a filter on the nmsTrackingUrl table as follows: source URL starts with http://<% or source URL starts with https://<%.

  3. Run the workflow and check if there are result.

  4. If so, open the output transition to view the list of URLs.

URL signature

To improve security, a signature mechanism for tracking links in emails has been introduced. It is available in Build 19.1.4 (9032@3a9dc9c) and Campaign 20.2. This feature is enabled by default.

NOTE

When a malformed signed URL is clicked, this error is returned: “Requested URL ‘…’ was not found.”

In addition, since Campaign 20.2 and the Gold Standard release, you can use an enhancement to disable URLs generated in previous builds. This feature is disabled by default. You can reach out to Customer Care to enable this feature.

If you are running Gold Standard 19.1.4, you may experience issues with push notification deliveries using tracking links, or deliveries using anchor tags. If so, we recommend that you disable URL signature.

Whether you are running Campaign on premises or in a hybrid architecture, you must reach out to Customer Care to have URL signature disabled.

If you are running Campaign in a hybrid architecture, before you enable URL signature, ensure that the hosted mid-sourcing instance has been upgraded as follows:

  • Prior to the on-premises marketing instance
  • To the same version as the on-premises marketing instance or to a slightly higher version

Otherwise, some of these issues may arise:

  • Before the mid-sourcing instance is upgraded, URLs are sent without signature through this instance.
  • After the mid-sourcing instance has been upgraded and URL signature has been enabled on both instances, the URLs that had previously been sent without signature are rejected. The reason is that a signature is requested by the tracking files that have been provided by the marketing instance.

To disable URLs that have been generated in previous builds, follow these steps on all Campaign servers at the same time:

  1. In the server configuration file (serverConf.xml), change blockRedirectForUnsignedTrackingLink to true.
  2. Restart the nlserver service.
  3. On the tracking server, restart the web server (apache2 on Debian, httpd on CentOS/RedHat, IIS on Windows).

To enable URL signature, follow these steps on all Campaign servers at the same time:

  1. In the server configuration file (serverConf.xml), change signEmailLinks to false.
  2. Restart the nlserver service.
  3. On the tracking server, restart the web server (apache2 on Debian, httpd on CentOS/RedHat, IIS on Windows).

Data restriction

You have to make sure that the encrypted passwords will not be accessible by a low privilege authenticated user. To do that, there are two main way: restrict access to password fields only or to the entire entity (need a build >= 8770).

This restriction allows you to remove passwords fields but let the external account accessible from the interface for all users. Refer to this page.

  1. Go in Administration > Configuration > Data schemas.

  2. Create a new Extension of a schema.

  3. Choose External Account (extAccount).

  4. In the last wizard screen, you can edit your new srcSchema to restrict access to all password fields:

    You can replace the main element (<element name="extAccount" ... >) by:

    <element name="extAccount">
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
    
        <element name="s3Account">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
        </element>
        <element name="wapPush">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
        <element name="mms">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
    </element>
    

    So your extended srcSchema can look like:

    <srcSchema _cs="External Accounts (cus)" created="2017-05-12 07:53:49.691Z" createdBy-id="0"
                desc="Definition of external accounts (Email, SMS...) used by the modules"
                entitySchema="xtk:srcSchema" extendedSchema="nms:extAccount" img="" label="External Accounts"
                labelSingular="External account" lastModified="2017-05-12 08:33:49.365Z"
                mappingType="sql" md5="E9BB0CD6A4375F500027C86EA854E101" modifiedBy-id="0"
                name="extAccount" namespace="cus" xtkschema="xtk:srcSchema">
        <createdBy _cs="Administrator (admin)"/>
        <modifiedBy _cs="Administrator (admin)"/>
        <element name="extAccount">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
    
            <element name="s3Account">
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
            </element>
            <element name="wapPush">
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
            </element>
            <element name="mms">
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
            </element>
        </element>
    </srcSchema>    
    
    NOTE

    You can replace $(loginId) = 0 or $(login) = 'admin' with hasNamedRight('admin') to allow all users with admin rights to see these passwords.

Protecting pages containing PII

We strongly advise on-premise customers to protect the pages that might contain personal information such as mirror pages, web applications, etc.

The goal of this procedure is to prevent these pages from being indexed, thus avoiding a potential security risk. Here are a few useful articles:

To protect your pages, follow these steps:

  1. Add a robots.txt file at the root of your web server (Apache or IIS). Here is the content of the file:

    # Make changes for all web spiders
    User-agent:
    *Disallow: /
    

    For IIS, refer to this page.

    For Apache, you can place the file in /var/www/robots.txt (Debian).

  2. Sometimes adding a robots.txt file is not sufficient in terms of security. For example, if another website contains a link to your page, it might appear in a search result.

In addition to the robots.txt file, it is advised to add a X-Robots-Tag header. You can do it in Apache or IIS and in the serverConf.xml configuration file.

For more information, refer to this article.

On this page