Forms provided by Constant Contact's SharpSpring product do not display on sites

[PsychoFox11]

Prerequisites

• This site DOES NOT contains sexually explicit material, otherwise use NSFW-specific form;
• Filters were updated before reproducing an issue;
• AdGuard product version is up-to-date;
• Browser version is up-to-date;
• If the site or app is broken, disabling AdGuard protection resolves an issue.

What product do you use?

AdGuard for Windows

AdGuard version

AdGuard for Windows v7.10.2 (build 3961, CL 1.9.86)

What type of problem have you encountered?

Website or app doesn't work properly

Which browser(s) do you use?

Chrome, Microsoft Edge

Which device do you use?

Desktop

Where is the problem encountered?

Many Domains

What filters do you have enabled?

AdGuard Base filter, AdGuard Tracking Protection filter

What Stealth Mode options do you have enabled?

No response

Add your comment and screenshots

1. Please read carefully as this was reported but only resulted in the example domain used to illustrate getting whitelisted, and this is affecting thousands of domains, causing the sites to appear broken, with more added every day - we are a service provider with a form builder used on customer sites, all users of these forms are affected. Forms provided by Constant Contact's SharpSpring do not display on sites using them when AdGuard's tracking protection is enabled. The script to display forms is separate from the service's tracking script, and should be allowed to generate the form.

2. The tracking script in ss.js creates a cookie and allows for tracking. The script in form.js generates the form, but will not track if ss.js was blocked from running and creating the cookie, as it relies on that for tracking. The form will still submit info without the tracking cookie and behave normally otherwise.

3. Note that the subdomain for the script is slightly different for each customer. In the sshtml.org example below, the tracking script is loaded via https://koi-3QNDUN6A20.marketingautomation.services/client/ss.js?ver=2.4.0
   And the form script is loaded via https://koi-3qnegvsspc.marketingautomation.services/client/form.js?ver=2.0.1
   The subdomain beginning with 'koi' will be different for each domain and customer. The version numbers at the end, after the ? in the URL, may be different as well, depending on when the form was implemented.
   Ultimately, if * is considered a wildcard, blocking *marketingautomation.services*ss.js* would be appropriate, as an example, while allowing form.js which is currently being blocked.

4. The rules that EasyList use properly block tracking, but not the forms when used with AdBlock Plus for example.
   See the EasyList tracking blocking rules here, and look for the domain 'marketingautomation.services' (it can take up to 5 minutes or more to fully load the page):
   https://easylist.to/easylist/easyprivacy.txt

5. If you want to block tracking, blocking ss.js will do that. The form.js will work as a form, but not track, if ss.js has not generated the cookie.

6. Screenshots
   Here are 3 example pages out of thousands of domains affected by this, along with before (AdGuard enabled) and after (AdGuard disabled) screenshots.

https://www.sshtml.org/dynamic-example/

https://www.synatic.com/contact

https://www.compagnon.com/items/nl-nl/downloads/whitepapers-overig/whitepaper-recruitment-is-marketing

Please reach out with any questions, as this is affecting quite a large number of sites, and as noted, the previous request only whitelisted the single domain used as an example.

Privacy

• I agree to follow this condition

[Alex-302]

Thanks, changed the rule.