Add trackers for Apple and Huawei; Added corresponding @ads attr

[ous50]

No description provided.

[MkQtS]

1. Why did you remove @!cn from dbankcloud.ru?
2. You should not add space after the type:
3. Type keyword is not encouraged (actually not used in this repo yet), not precise and may result in incorrect matches with other domains
4. Source/evidence of these ad domains?

[ous50]

1. Why did you remove @!cn from dbankcloud.ru?

Because @!cn has been removed(listed in README.md)

2. You should not add space after the type:

will fix it in next commit.

3. Type keyword is not encouraged (actually not used in this repo yet), not precise and may result in incorrect matches with other domains
4. Source/evidence of these ad domains?

These domains are all collected from my Adguard Home DNS logs.

[MkQtS]

Because @!cn has been removed(listed in README.md)

You've misunderstood. The attr @!cn is not removed from the repo, but the rules with @!cn are removed from category-xxx-cn/geolocation-cn lists. Not delete the attr itself, but avoid including these domain rules into the cn lists.

In the past, there're some @!cn domains in the cn lists. Like tiktok domains were included in bytedance and then geolocation-cn, so the geosite:geolocation-cn contained tiktok domains, which caused problems in practice. (It's reasonable that geosite:bytedance contains tiktok domains, but not for geosite:geolocation-cn/geosite:cn.) So I introduced functional selective inclusion, in which include:bytedance @-!cn means include all bytedance domains except those with @!cn attr, to fix the problem. @!cn is still and should be used.

4. Source/evidence of these ad domains?

These domains are all collected from my Adguard Home DNS logs.

We should be cautious to avoid blocking necessary domains, so I tend to not add @ads attr to those uncertain domains. (Users may not report the issue, even if it exists...)

[ous50]

Because @!cn has been removed(listed in README.md)

You've misunderstood. The attr @!cn is not removed from the repo, but the rules with @!cn are removed from category-xxx-cn/geolocation-cn lists. Not delete the attr itself, but avoid including these domain rules into the cn lists.

In the past, there're some @!cn domains in the cn lists. Like tiktok domains were included in bytedance and then geolocation-cn, so the geosite:geolocation-cn contained tiktok domains, which caused problems in practice. (It's reasonable that geosite:bytedance contains tiktok domains, but not for geosite:geolocation-cn/geosite:cn.) So I introduced functional selective inclusion, in which include:bytedance @-!cn means include all bytedance domains except those with @!cn attr, to fix the problem. @!cn is still and should be used.

I see. I would revert the @!cn attr

4. Source/evidence of these ad domains?

These domains are all collected from my Adguard Home DNS logs.

We should be cautious to avoid blocking necessary domains, so I tend to not add @ads attr to those uncertain domains. (Users may not report the issue, even if it exists...)

Is that means an SDK/clear documentation pointing that these are ADS service domains is required to add these @ads attrs?

[MkQtS]

We should be cautious to avoid blocking necessary domains, so I tend to not add @ads attr to those uncertain domains. (Users may not report the issue, even if it exists...)

Is that means an SDK/clear documentation pointing that these are ADS service domains is required to add these @ads attrs?

No, but that would be better. There's no clear standard. Specific keywords in the domain (like ads, tracking, logs...), sufficient evidence or ad domains recognized by other well-known projects (like easylist) would be enough.