Bug 1652244 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Hi baku,
I talked offline with gary, and also from comment 4.
I think the idea is that nested same-origin iframe should still be considered as first-party.

I'll write a summanty for all our third-party APIs...
1. `ThirdPartyUtil::IsThirdPartyWindow`
- not consider top-level 
2. `ThirdPartyUtil::IsThirdPartyChannel`
- not consider top-level 
3. `nsContentUtils::IsThirdPartyWindowOrChannel(nsPIDOMWindowInner* aWindow, nsIChannel* aChannel, nsIURI* aURI)  ` when passing `Window`
- not consider top-level 
4. `nsContentUtils::IsThirdPartyWindowOrChannel(nsPIDOMWindowInner* aWindow, nsIChannel* aChannel, nsIURI* aURI) ` when passing `Channel`
- consider top-level 
5. AntiTrackingUtils::IsThirdPartyWindow
- not consider top-level, this API is actually the same as calling `nsContentUtils::IsThirdPartyWindowOrChannel` with window
6. AntiTrackingUtils::IsThirdPartyChannel
- consider top-level, this API was added to support Fission because `nsContentUtils::IsThirdPartyWindowOrChannel` is not fission-compatible

As we talked yesterday, right now, the behavior of IsThirdPartyWindow and IsThirdPartyChannel is not sync (channel considers top-level while window doesn't).
So I'll suggest we do the following:
1. Do not use `nsContentUtils::IsThirdPartyWindowOrChannel` anymore because it is not fission-compatible (and also the function itself is confusing). We should replace places where we use this API with the other 3rd-party APIs
2. Update AntiTrackingUtils::IsThirdPartyWindow to consider top-level.
so for cases we need to consider top-level, use `AntiTrackingUtils::IsThirdPartyXXX`, for cases we don't want to consider top-level, use `ThirdPartyUtil::IsThirdPartyXXX`.

Does that make sense?
Hi baku,
I talked offline with gary, and also from comment 4, I think the idea is that nested same-origin iframe should still be considered as first-party.

I'll write a summanty for all our third-party APIs...
1. `ThirdPartyUtil::IsThirdPartyWindow`
- not consider top-level 
2. `ThirdPartyUtil::IsThirdPartyChannel`
- not consider top-level 
3. `nsContentUtils::IsThirdPartyWindowOrChannel(nsPIDOMWindowInner* aWindow, nsIChannel* aChannel, nsIURI* aURI)  ` when passing `Window`
- not consider top-level 
4. `nsContentUtils::IsThirdPartyWindowOrChannel(nsPIDOMWindowInner* aWindow, nsIChannel* aChannel, nsIURI* aURI) ` when passing `Channel`
- consider top-level 
5. AntiTrackingUtils::IsThirdPartyWindow
- not consider top-level, this API is actually the same as calling `nsContentUtils::IsThirdPartyWindowOrChannel` with window
6. AntiTrackingUtils::IsThirdPartyChannel
- consider top-level, this API was added to support Fission because `nsContentUtils::IsThirdPartyWindowOrChannel` is not fission-compatible

As we talked yesterday, right now, the behavior of IsThirdPartyWindow and IsThirdPartyChannel is not sync (channel considers top-level while window doesn't).
So I'll suggest we do the following:
1. Do not use `nsContentUtils::IsThirdPartyWindowOrChannel` anymore because it is not fission-compatible (and also the function itself is confusing). We should replace places where we use this API with the other 3rd-party APIs
2. Update AntiTrackingUtils::IsThirdPartyWindow to consider top-level.
so for cases we need to consider top-level, use `AntiTrackingUtils::IsThirdPartyXXX`, for cases we don't want to consider top-level, use `ThirdPartyUtil::IsThirdPartyXXX`.

Does that make sense?
Hi baku,
I talked offline with gary, and also from comment 4, I think the idea is that nested same-origin iframe should still be considered as first-party.

I'll write a summaty for all our third-party APIs...
1. `ThirdPartyUtil::IsThirdPartyWindow`
- not consider top-level 
2. `ThirdPartyUtil::IsThirdPartyChannel`
- not consider top-level 
3. `nsContentUtils::IsThirdPartyWindowOrChannel(nsPIDOMWindowInner* aWindow, nsIChannel* aChannel, nsIURI* aURI)  ` when passing `Window`
- not consider top-level 
4. `nsContentUtils::IsThirdPartyWindowOrChannel(nsPIDOMWindowInner* aWindow, nsIChannel* aChannel, nsIURI* aURI) ` when passing `Channel`
- consider top-level 
5. AntiTrackingUtils::IsThirdPartyWindow
- not consider top-level, this API is actually the same as calling `nsContentUtils::IsThirdPartyWindowOrChannel` with window
6. AntiTrackingUtils::IsThirdPartyChannel
- consider top-level, this API was added to support Fission because `nsContentUtils::IsThirdPartyWindowOrChannel` is not fission-compatible

As we talked yesterday, right now, the behavior of IsThirdPartyWindow and IsThirdPartyChannel is not sync (channel considers top-level while window doesn't).
So I'll suggest we do the following:
1. Do not use `nsContentUtils::IsThirdPartyWindowOrChannel` anymore because it is not fission-compatible (and also the function itself is confusing). We should replace places where we use this API with the other 3rd-party APIs
2. Update AntiTrackingUtils::IsThirdPartyWindow to consider top-level.
so for cases we need to consider top-level, use `AntiTrackingUtils::IsThirdPartyXXX`, for cases we don't want to consider top-level, use `ThirdPartyUtil::IsThirdPartyXXX`.

Does that make sense?
Hi baku,
I talked offline with gary, and also from comment 4, I think the idea is that nested same-origin iframe should still be considered as first-party.

I'll write a summaty for all our third-party APIs...
1. `ThirdPartyUtil::IsThirdPartyWindow`
- not consider top-level 
2. `ThirdPartyUtil::IsThirdPartyChannel`
- not consider top-level 
3. `nsContentUtils::IsThirdPartyWindowOrChannel(nsPIDOMWindowInner* aWindow, nsIChannel* aChannel, nsIURI* aURI)  ` when passing `Window`
- not consider top-level 
4. `nsContentUtils::IsThirdPartyWindowOrChannel(nsPIDOMWindowInner* aWindow, nsIChannel* aChannel, nsIURI* aURI) ` when passing `Channel`
- consider top-level 
5. AntiTrackingUtils::IsThirdPartyWindow
- not consider top-level, this API is actually the same as calling `nsContentUtils::IsThirdPartyWindowOrChannel` with window
6. AntiTrackingUtils::IsThirdPartyChannel
- consider top-level, this API was added to support Fission because `nsContentUtils::IsThirdPartyWindowOrChannel` is not fission-compatible

As we talked yesterday, right now, the behavior of IsThirdPartyWindow and IsThirdPartyChannel is not sync (channel considers top-level while window doesn't). However, I guess there will be some cases requring 3rd-party API considering top-level (like this one?).
So I'll suggest we do the following:
1. Do not use `nsContentUtils::IsThirdPartyWindowOrChannel` anymore because it is not fission-compatible (and also the function itself is confusing). We should replace places where we use this API with the other 3rd-party APIs
2. Update AntiTrackingUtils::IsThirdPartyWindow to consider top-level.
so for cases we need to consider top-level, use `AntiTrackingUtils::IsThirdPartyXXX`, for cases we don't want to consider top-level, use `ThirdPartyUtil::IsThirdPartyXXX`.

Does that make sense?

Back to Bug 1652244 Comment 8