171202 2017-04-23 14:06:44 -0700 Content blocker `load-type=third-party` is applied to subdomain requests 2024-03-11 17:16:52 -0700 1 1 1 Unclassified WebKit WebKit Misc. Safari 10 Unspecified Unspecified NEW InRadar P2 Normal --- 1 am webkit-unassigned achristensen ahmad.saleem792 krzysztof.modras mjs timothy webkit-bug-importer oldest_to_newest 1300366 0 am 2017-04-23 14:06:44 -0700 Request to `subdomain.example.org` sent from `example.org` is considered third party. All the ad blockers out there use another definition of `third-party`, requests to subdomains are considered first-party. 1620587 1 mjs 2020-02-19 02:28:51 -0800 We should probably use a definition of third-party that is in terms of in terms of "site" rather than "origin", as in the definitions of "first party" and "third party" in the WebKit Tracking Prevention policy: https://webkit.org/tracking-prevention-policy/ While this does not match the same-origin policy sense, it does match cookies and the way our http cache partitioning works. 1620589 2 webkit-bug-importer 2020-02-19 02:30:37 -0800 <rdar://problem/59584586> 1620622 3 am 2020-02-19 03:39:50 -0800 Yeah, the first-party definition you use in ITP makes perfect sense. 1621089 4 mjs 2020-02-19 22:07:55 -0800 This might be a compatibility break, so I wonder if we need to add a new version of third-party with a different name. ('third-party-site' maybe? and legacy version aliased to third-party-origin?) 1621128 5 am 2020-02-20 00:21:24 -0800 In my opinion, this change won't cause any troubles. On the contrary, it might fix a few things. The thing is that most of the content blockers for Safari are actually "converted" from existing filter lists like EasyList, AdGuard filters, etc, and all these filter lists expect the requested behavior of "third-party".