ID `tracker` can lead to browsers blocking the request

[johanstokking]

Summary

Console crash when opening device

Steps to Reproduce

ttn-org members, go here: https://eu1.cloud.thethings.network/console/applications/johan-test/devices/tracker

The device was fresh provisioned on an external Join Server.

What do you see now?

What do you want to see instead?

No crash

Environment

Brave Brave is up to date Version 1.22.67 Chromium: 89.0.4389.90 (Official Build) (x86_64)

(note that in Safari this works fine)

How do you propose to implement this?

No idea

How do you propose to test this?

No idea

Can you do this yourself and submit a Pull Request?

No

[johanstokking]

OK the problem is that the device ID is tracker and now my browser thinks it's a (browser) tracker.

Should we blacklist this ID? @bafonins @htdvisser

[bafonins]

Yeah, I think so. We dont really want someone else to experience the same issue. Also this solution is quite simple as it seems that other variations of ids with tracker arent blocked. e.g. bosch-tracker causes no issues.

[kschiffer]

Agreed. It would be good to somehow find out which other names could cause trouble.

[htdvisser]

On Firefox with uBlock Origin this also errors. In my case the EasyPrivacy was blocking it. Looking at that list, I've identified a number of other possibly problematic URLs that may be valid IDs in The Things Stack:

-ad-targeting?
-analytics-state?
-audience-science-pixel/
-ga-tracking/
-heatmaps-analytics/
-imppix/
-krux-tag/
-universal-analytics/
/accesslog?
/adb-analytics
/adimp?
/adinfo?
/adsct?
/ajaxlog?
/amp-omniture-iframe?
/analytics-collector
/analytics-savebt?
/analyticstracking?
/apilog?
/apixel?
/app-measurement?
/arstat?
/bcn?
/beacon?
/bkclick?
/blockstat?
/bypasspiphp?
/cablog?
/cct?
/click-tracker
/clickability?
/clicktrack?
/clientstat?
/cm-xtgreat?
/cn-track?
/cnavperf?
/comscore?
/containertag?
/cookiebean?
/cookietag?
/cross-domain-cookie?
/csc-event?
/ctrack?
/datacollectcode?
/dfpsvc?
/eluminate?
/etag?
/event-log?
/favcyanalytics?
/flip-stats-queue?
/fpcookie?
/ga-collect?
/gen204?
/geo-ip-detect?
/geoip?
/get-tracking-data
/gifbanner?
/googleanalyticsevents?
/hitcount?
/horizon-pageview?
/iclogs?
/impressions?
/kalturaevent?
/landings-pixel?
/logstat?
/logviewedpage?
/martypixel?
/mat0m0?
/netcounter?
/omniture?
/page-addviews?
/pagestat?
/pc-log?
/pingd?
/postlog?
/prodtracker?
/pvcounter?
/rec-impression?
/recommendtrack?
/record-impressions?
/record-stats?
/referadd?
/registeradevent?
/rtt-log-data?
/rum-track?
/savetracking?
/setcookie?
/simple-tracking?
/statspider?
/statstracker?
/stdlog?
/tealeaftarget?
/tops-counter?
/track-imp?
/track-visit-event?
/track-visit?
/trackconversion?
/trackimps?
/trackingab?
/trackmvisit?
/trackpagecover?
/trackpixel?
/trackpxl?
/trackstats?
/trackvisit?
/trigger-visit-event
/uedata?
/uf-stat?
/ulpixel?
/uo-stat?
/utrack?
/view-log?
/visit-tag?
/visitor-event?
/visitortrack?
/vjslog?
/yt-track-streamer
-track-email-open?
/email-pixel?
-monero-miner/

[htdvisser]

I'm afraid that it will become a never ending struggle if we start blocking IDs (or parts of IDs) that may be problematic in a specific group of users that uses some content blocking browser extensions. There will always be users that use different blocklists and we'll never keep up.

At the same time, we make the experience worse for users that don't use such extensions. Should we really prevent users from registering "tracker" devices?

Instead I think we should try to detect requests that get blocked by the user agent. I'm sure we can somehow tell the difference between an error returned by the server and an error returned by the request itself. Then we can show the user an error saying that "we couldn't perform a request to our server" and that it "may be related to your application ID {application_id} or device ID {device_id}".

[johanstokking]

I agree that this is a sliding edge, that the list will never be exhaustive, and that it can limit users in registering things with sane identifiers.

If we can detect ERR_BLOCKED_BY_CLIENT in our code, indeed we can tell the user to disable their ad blocker.

In my case, when disabling Brave Shields for the domain, everything worked fine.

[kschiffer]

Indeed, let's try that. The console should detect such errors and issue a warning toast notification saying sth like We have detected a possible ad blocker blocking one of our API connections. Please consider disabling ad blockers for this domain.. Additionally it should have a link to a docs page where we explain the situation in more detail and especially the fact that this is a misjudgement and we do not use any tracking and advertising.

@bafonins can you take over this one?