Issues with shields blocking first party tracking pixel

Description of the issue:
First party pixel is blocked (has the same apex domain as the website)
Both pixel code (js) and collector domain are under the apex domain.

Exact URL of the website in question:

Did the issue present with default Shields settings? (yes/no)

Does the site function as expected when Shields are turned off?

Is there a specific Shields configuration that causes the site to break? If so, tell us that configuration. (yes/no):
no, default settings.

Does the site work as expected when using Chrome?

Brave version (check About Brave):
Version 0.69.135 Chromium: 77.0.3865.120 (Official Build) (64-bit)

cc @fanboynz on this

If its a tracking pixel, i would expect it to be blocked. What is the exact issue? Has lots of tracking elements, my display resolution/region/etc.

I expected that cross-site tracking will be blocked, but this is not a third party pixel or a cross site tracker.
Does Brave or any browser has an exact definition of what is considered cross site tracking?

I don’t know the full details on what is parsed/not parsed, but its at least taking the generic blocks in Easyprivacy. While not “cross-site” in this case, its tracking the user and should remain blocked. I do agree we should adjust the wording on this to avoid confusion.

What is allowed to be sent?
Is there a list of actions that are allowed?
for example:

  • a page view
  • an event

I am talking only about the action itself, not the rest of the parameters that are being collected by the script.
Any documentation I can take a look at?
is the EasyPrivacy.txt list enough?

Visting and might help. tl;dr any tracking of users isn’t allowed.

I’ll most certainly check it out.

There is still a lot of grey, undefined area (At least for me).
It would be nice, and time-saving if there would be any developer docs for these kinds of issues.

Thank you.

This topic was automatically closed after 30 days. New replies are no longer allowed.