Bugzilla

Ehsan, thanks for your suggestion!
Can you help take a quick look for both of the WIP patches and let me know how do you think? thanks!

(In reply to :Ehsan Akhgari (Out of office 5/10-5/21) from comment #7)

> 
> What do you mean by that?  I'm not sure if I understand...
> 
> I think the problem that we have here is that `GetTopWindowURI()` is having magic unwanted behaviour we don't want.  :-)  This null principal filtering business is really unhelpful to us.  But then again we probably shouldn't change the behaviour of the function globally either since other consumers probably depend on this.  So what to do?  Let's add an `aAllowNullPrincipal` argument (default to false) to the function to allow callers to customize its behaviour, and pass true here.

I didn't mean to change anything in GetTopWindowURI(), attach the WIP patch.
I also tried to use the "AllowNullPrincipal" approach. I have to add two idl methods and I feel that it is not as straightforward as I expected. 

> 
> Isn't that the data: URI?  Consider the case where the tracker uses some kind of data mining to learn various information from English words found in a URI, if the first-party page is an English page coming from a data: URI, a lot of info could leak that way (unless base64 encoded).
> 

Just out of curiosity(hope this is not a too dumb question), how does third-party tracker retrieve the data: URI in this scenario? I test both Firefox and Chrome, both don't include referer in the request, is there any other way to get that?

> > Maybe cryptomining is one of the cases that a third-party can still harm the user?
> 
> For sure.  Another case is fingerprinting, where they would use a data: URI page to capture a fingerprint of your device and phone it back home.  And so on.  :-)
> 
> So I would say yes we do want to fix this.

Agree! Thanks for the information :)

> 
> > 2. We can not generate the pairwise whitelist url because we don't have top-level window's uri, do we just skip whitelist?
> 
> Good question.  The above suggestion should address this by making sure we would have access to the top-level window's uri.

I tested the "AllowNullPrincipal" approach. URI from NullPrincial is "moz-nullprincipal {UUID}" which cause an error while generating whitelist URI because it is not a valid URI. So we still have to do additional handling with this approach :(

Ehsan, thanks for your suggestion!
Can you help take a quick look for both of the WIP patches and let me know how do you think? thanks!

(In reply to :Ehsan Akhgari (Out of office 5/10-5/21) from comment #7)

> 
> What do you mean by that?  I'm not sure if I understand...
> 
> I think the problem that we have here is that `GetTopWindowURI()` is having magic unwanted behaviour we don't want.  :-)  This null principal filtering business is really unhelpful to us.  But then again we probably shouldn't change the behaviour of the function globally either since other consumers probably depend on this.  So what to do?  Let's add an `aAllowNullPrincipal` argument (default to false) to the function to allow callers to customize its behaviour, and pass true here.

I didn't mean to change anything in GetTopWindowURI(), attach the WIP patch.
I also tried to use the "AllowNullPrincipal" approach. I have to add two idl methods and I feel that it is not as straightforward as I expected. 

> 
> Isn't that the data: URI?  Consider the case where the tracker uses some kind of data mining to learn various information from English words found in a URI, if the first-party page is an English page coming from a data: URI, a lot of info could leak that way (unless base64 encoded).
> 

Just out of curiosity(hope this is not a too dumb question), how does third-party tracker retrieve the URI of the data scheme in this scenario? I test both Firefox and Chrome, both don't include referer in the request, is there any other way to get that?

> > Maybe cryptomining is one of the cases that a third-party can still harm the user?
> 
> For sure.  Another case is fingerprinting, where they would use a data: URI page to capture a fingerprint of your device and phone it back home.  And so on.  :-)
> 
> So I would say yes we do want to fix this.

Agree! Thanks for the information :)

> 
> > 2. We can not generate the pairwise whitelist url because we don't have top-level window's uri, do we just skip whitelist?
> 
> Good question.  The above suggestion should address this by making sure we would have access to the top-level window's uri.

I tested the "AllowNullPrincipal" approach. URI from NullPrincial is "moz-nullprincipal {UUID}" which cause an error while generating whitelist URI because it is not a valid URI. So we still have to do additional handling with this approach :(