(In reply to :ehsan akhgari from comment #11) > (In reply to Julien Cristau [:jcristau] from comment #9) > > Especially since this seems to happen on sites that zendesk themselves host? (support.fastly.com CNAME fastly.zendesk.com) > > Hmm, baku, Steven, do you think it would make sense to have a special heuristic in ETP to relax storage restrictions when the top-level origin's domain is a CNAME record pointing to the third-party tracker's domain, assuming that the top-level domain has, in that case, relinquished the control of running their website to the third-party tracker? Sorry it's taken me so long to respond that you already have a prototype patch. It's an interesting direction that we should discuss further. I'm concerned that, as implemented, this heuristic enables some attacks on ETP. Consider that a site may maliciously set up CNAME records for the purpose of relaxing restrictions with various third parties. In theory, they can CNAME one subdomain for each partner. So `tracker1.news.example` CNAME'ed to `news.tracker1.example`, `tracker2.news.example` CNAMED'ed to `news.tracker2.example`, and so on. Then, when a user first visits (or on navigations) they do a quick top-level redirect: `news.example` --> `tracker1.news.example --> `tracker2.news.example` --> `tracker3.news.example` --> ... --> `trackerN.news.example` --> `news.example`. On each step in the redirect they sync their first-party cookie with the third party and then later just share data associated with the "first-party" cookie (for which every partner how has a mapping). Note that this attack is currently possible without the heuristic, but just requires top-level redirects to third-party redirects. E.g., * `news.example` * --> `tracker1.example/cookie_sync.html?targets=tracker2.example,trackerN.example,news.example&uid=12345` * --> `tracker2.example/cookie_sync.html?targets=trackerN.example,news.example&uid=12345` * --> ... * --> `trackerN.example/cookie_sync.html?targets=news.example&uid=12345` * --> `news.example` Where `uid` is `news.example`'s ID for the user. This requires the third parties to cooperate and not mess with each other's data, but you can also imagine a scenario where the redirects go back to `news.example` with each step. This type of workaround can be handled in the same way that WebKit handles it: https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/. If we add such a heuristic, do we expect a webkit-style mitigation to work? If we see a top-level redirect through a first-party origin that is CNAME'ed to a known tracker, do we purge the state for the first party? Will that lead to more breakage?
Bug 1540810 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to :ehsan akhgari from comment #11) > (In reply to Julien Cristau [:jcristau] from comment #9) > > Especially since this seems to happen on sites that zendesk themselves host? (support.fastly.com CNAME fastly.zendesk.com) > > Hmm, baku, Steven, do you think it would make sense to have a special heuristic in ETP to relax storage restrictions when the top-level origin's domain is a CNAME record pointing to the third-party tracker's domain, assuming that the top-level domain has, in that case, relinquished the control of running their website to the third-party tracker? Sorry it's taken me so long to respond that you already have a prototype patch. It's an interesting direction that we should discuss further. I'm concerned that, as implemented, this heuristic enables some attacks on ETP. Consider that a site may maliciously set up CNAME records for the purpose of relaxing restrictions with various third parties. In theory, they can CNAME one subdomain for each partner. So `tracker1.news.example` CNAME'ed to `news.tracker1.example`, `tracker2.news.example` CNAMED'ed to `news.tracker2.example`, and so on. Then, when a user first visits (or on navigations) they do a quick top-level redirect: * `news.example` * --> `tracker1.news.example` * --> `tracker2.news.example` * --> `tracker3.news.example` * --> ... * --> `trackerN.news.example` * --> `news.example`. On each step in the redirect they sync `news.example`'s first-party cookie with the tracker's third-party cookie (allowed by the heuristic) and then later just share data associated with `news.example`'s "first-party" cookie (for which every partner how has a mapping). Note that this attack is currently possible without the heuristic, but just requires top-level redirects to third-party redirects. E.g., * `news.example` * --> `tracker1.example/cookie_sync.html?targets=tracker2.example,trackerN.example,news.example&uid=12345` * --> `tracker2.example/cookie_sync.html?targets=trackerN.example,news.example&uid=12345` * --> ... * --> `trackerN.example/cookie_sync.html?targets=news.example&uid=12345` * --> `news.example` Where `uid` is `news.example`'s ID for the user. This requires the third parties to cooperate and not mess with each other's data, but you can also imagine a scenario where the redirects go back to `news.example` with each step. This type of workaround can be handled in the same way that WebKit handles it: https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/. If we add such a heuristic, do we expect a webkit-style mitigation to work? If we see a top-level redirect through a first-party origin that is CNAME'ed to a known tracker, do we purge the state for the first party? Will that lead to more breakage?
(In reply to :ehsan akhgari from comment #11) > (In reply to Julien Cristau [:jcristau] from comment #9) > > Especially since this seems to happen on sites that zendesk themselves host? (support.fastly.com CNAME fastly.zendesk.com) > > Hmm, baku, Steven, do you think it would make sense to have a special heuristic in ETP to relax storage restrictions when the top-level origin's domain is a CNAME record pointing to the third-party tracker's domain, assuming that the top-level domain has, in that case, relinquished the control of running their website to the third-party tracker? Sorry it's taken me so long to respond that you already have a prototype patch. It's an interesting direction that we should discuss further. I'm concerned that, as implemented, this heuristic enables some attacks on ETP. Consider that a site may maliciously set up CNAME records for the purpose of relaxing restrictions with various third parties. In theory, they can CNAME one subdomain for each partner. So `tracker1.news.example` CNAME'ed to `news.tracker1.example`, `tracker2.news.example` CNAMED'ed to `news.tracker2.example`, and so on. Then, when a user first visits (or on navigations) they do a quick top-level redirect: * `news.example` * --> `tracker1.news.example` * --> `tracker2.news.example` * --> `tracker3.news.example` * --> ... * --> `trackerN.news.example` * --> `news.example` On each step in the redirect they sync `news.example`'s first-party cookie with the tracker's third-party cookie (allowed by the heuristic) and then later just share data associated with `news.example`'s "first-party" cookie (for which every partner how has a mapping). Note that this attack is currently possible without the heuristic, but just requires top-level redirects to third-party redirects. E.g., * `news.example` * --> `tracker1.example/cookie_sync.html?targets=tracker2.example,trackerN.example,news.example&uid=12345` * --> `tracker2.example/cookie_sync.html?targets=trackerN.example,news.example&uid=12345` * --> ... * --> `trackerN.example/cookie_sync.html?targets=news.example&uid=12345` * --> `news.example` Where `uid` is `news.example`'s ID for the user. This requires the third parties to cooperate and not mess with each other's data, but you can also imagine a scenario where the redirects go back to `news.example` with each step. This type of workaround can be handled in the same way that WebKit handles it: https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/. If we add such a heuristic, do we expect a webkit-style mitigation to work? If we see a top-level redirect through a first-party origin that is CNAME'ed to a known tracker, do we purge the state for the first party? Will that lead to more breakage?