Protocol-relative URL and permissions policy #40

alois-bissuel · 2022-06-24T12:10:27Z

Hi,

I believe I have found a discrepancy in the way permissions policy are handled in an iFrame using a protocol-relative URL. I noticed that I could not allow the attribution reporting API in an iFrame whose source was a protocol-relative URL, if I did not specify the exact origin with the protocol.
According to what I found in the permissions policy explainer, allow="attribution-reporting" is in fact a short-hand for allow="attribution-reporting 'src'" , where 'src' is a special keyword which resolves to the origin of the source of the iFrame.
I believe that in the case of protocol-relative URL, the 'src' keyword will not resolve to the absolute origin, and hence the attribution-reporting policy is not allowed.

I am not sure this is exactly the right place for this question/report, so let me know if I should raise it somewhere more appropriate.

Thanks a lot!

Minimal working example

Create a local webserver which responds with
<html><body><h1><iframe src="//www.wikipedia.org/" allow="attribution-reporting" frameborder="1"></h1></body></html>

Attribution-reporting is not allowed in the wikipedia iFrame

Switching to a "protocol-absolute" URL (ie src="https://www.wikipedia.org/") or specifying the resolved secure origin in the allow (ie allow="attribution-reporting https://www.wikipedia.org") will enable attribution-reporting.

The text was updated successfully, but these errors were encountered:

samdutton · 2022-06-27T21:05:07Z

@kevinkiklee @rowan-m FYI

maudnals · 2022-06-28T13:09:14Z

Hi @alois-bissuel,

Thanks for filing this!

I put together a quick demo with two iframes, one with an explicit URL as src and the other with a protocol-relative URL as src:

      <iframe src="https://example.com/" allow="attribution-reporting" frameborder="1"></iframe>
      
      <iframe src="//www.example.com/" allow="attribution-reporting" frameborder="1"></iframe>

In this demo, it seems that attribution-reporting is allowed in both. Tested in Chrome Beta and Canary.

See the live demo and code.

Would you confirm that you're also seeing this?
(If so the issue may lay somewhere else, happy to troubleshoot with you).
Anything that demo is doing differently from your code?

I also checked if by any chance wikipedia.org had disallowed the feature, it doesn't seem to be the case, and it appears as allowed in the iframe even with a protocol-relative URL.

maudnals · 2022-06-28T13:19:41Z

+If it helps, I can also give you edit rights to that demo code, let me know!

maudnals · 2022-06-28T13:37:33Z

EDIT: To clarify, the behavior I observed is the same regardless of whether 'src' is present.

alois-bissuel · 2022-06-28T13:56:21Z

Thank you very much @maudnals for this hosted example.
I indeed see the same behaviour as you (that is to say that everything is working well).
Still my issue when firing a local server persists, on both Chrome canary and beta. Did you try my minimal example too?
I am using a Mac, if this changes things.
P.S. I also tried example.com on my MWE, but locally I did not have the same results, as src="//example.com" will resolve to the insecure version http://example.com, as my webpage is hosted on http://localhost

maudnals · 2022-06-28T14:53:10Z

I indeed see the same behaviour as you (that is to say that everything is working well).

Nice to know, noted.

Did you try my minimal example too?

I was able to reproduce locally, but interestingly, only for wikipedia.org - example.com behaves fine.
Can you try reproducing with src="//www.example.com/? If the issue doesn't repro for src="//www.example.com/, we're getting closer to what the problem may be.

Here's what I do
EDIT: formatting
EDIT 2: added one example without www

app.get('/', (req, res) => {
  const html =
    `<html>` +
    // IFRAME 0 - example.com with a protocol-relative URL (no www)
    `src="//example.com/"<iframe src="//example.com/" allow="attribution-reporting" frameborder="1"></iframe><br/>` +
    // IFRAME 1 - example.com with a protocol-relative URL (with www)
    `src="//www.example.com/"<iframe src="//www.example.com/" allow="attribution-reporting" frameborder="1"></iframe><br/>` +
    // IFRAME 2 - example.com with an HTTPS URL
    `src="https://example.com/"<iframe src="https://example.com/" allow="attribution-reporting" frameborder="1"></iframe><br/>` +
    // IFRAME 3 - example.com with an HTTP URL
    `src="http://example.com/"<iframe src="http://example.com/" allow="attribution-reporting" frameborder="1"></iframe><br/>` +
    // IFRAME 4 - wikipedia.org with a protocol-relative URL (no www)
    `src="//wikipedia.org/" <iframe src="//wikipedia.org/" allow="attribution-reporting" frameborder="1"></iframe><br/>` +
    // IFRAME 5 - wikipedia.org with a protocol-relative URL (with www)
    `src="//www.wikipedia.org/"<iframe src="//www.wikipedia.org/" allow="attribution-reporting" frameborder="1"></iframe><br/>` +
    // IFRAME 6 - wikipedia.org with an HTTPS URL
    `src="https://wikipedia.org/"<iframe src="https://wikipedia.org/" allow="attribution-reporting" frameborder="1"></iframe>` +
    `</html>`;

  res.send(html);
});

Chrome Canary
Local node server, access via http://localhost (not HTTPS - note that anyway, localhost is supposed to behave like a secure context, though there may be nuances).

Observation:

The first four iframes (example.com) have attribution-reporting allowed
The last three (wikipedia.org) have attribution-reporting blocked

alois-bissuel · 2022-06-28T15:03:40Z

Will try tomorrow with your exact same example.
I did try src="//www.example.com", and it behaved similarly (as "//example.com").
Could you please check which full URL is resolved in this local server example? For me, it resolved to the insecure "http://example.com".

maudnals · 2022-06-28T15:39:02Z

//example.com/ -> http://example.com/
//www.example.com/ -> http://www.example.com/
--
https://example.com/ -> https://example.com/ (same)
http://example.com/ -> http://example.com/ (same)
--
//wikipedia.org/ -> https://www.wikipedia.org/
//www.wikipedia.org/ -> https://www.wikipedia.org/
--
https://wikipedia.org/ -> https://www.wikipedia.org/ (same)

Observations:

Protocol-relative URLs for wikipedia seem to redirect to https:...
Protocol-relative URLs for example.com seem to redirect to http:...

This seems like a site-specific setting, something example.com and wikipedia do differently. Maybe HSTS or along these lines? Will investigate tomorrow.

maudnals · 2022-06-28T16:23:42Z

Indeed wikipedia.org has an HSTS header and example.com doesn't. That would/should explain the redirects we're observing.
I'm unsure yet how/whether that relates to attribution-reporting being blocked on wikipedia.org and not on example.com.

Two more observations:

I tweaked the deployed demo site and it DOES repro in some cases. See below.
I ran the localhost site with HTTPS, and the results were different than with an HTTP localhost. See below.

maudnals · 2022-06-28T16:58:37Z

To summarize what we've observed:

In both Canary and Beta, in a site that includes an iframe that has allow="attribution-reporting" on:

On an HTTP localhost site, attribution-reporting is blocked in any wikipedia.org iframe (regular URL and protocol-relative URL), but allowed in any example.com iframe. Repro demo
On an HTTPS localhost site, attribution-reporting is blocked with a regular URL (src="https://wikipedia.org/") and with one type of protocol-relative URL (src="//wikipedia.org/"). But with src="//www.wikipedia.org/" (iframe 5), and with any example.com iframe, attribution-reporting is allowed. Repro demo
On a deployed HTTPS site, the behavior is the same as for the HTTPS localhost site. Repro demo
wikipedia.org has an HSTS while example.com doesn't.

This happens regardless of whether 'src' is present in the policy.
chrome://flags/#privacy-sandbox-ads-apis and chrome://flags/#enable-experimental-web-platform-features are both on.

@alois-bissuel Please feel free to sanity-check what I've observed with the repro demos, and to share any observations from your side when you get a chance. Thank you! I'm not clear at this stage what causes this behavior and whether this works as intended, so if you're observing the same, I'll reach out to the feature team.

maudnals · 2022-06-30T16:00:11Z

@alois-bissuel The feature team is looking into this issue, will keep you posted.
Thanks!

maudnals · 2022-07-14T13:28:58Z

(Apologies for the delayed reply)

Our Chrome Eng team has looked into it and it seems the issue has been found ⏤ I haven't had a chance to test, but let me paste here the reply:

Ok, found the problem.

For wikipedia, http://wikipedia.org, http://www.wikipedia.org, https://wikipedia.org  are all redirected to https://www.wikipedia.org.

And allow="attribution-reporting" default to src that is same origin as the src of the iframe.

Basically it's just the src attribute of the iframe if it starts with http or https, otherwise it's adding http or https to the src attribute depending on whether the parent site is http or https.

Therefore for http localhost, http://wikipedia.org, http://www.wikipedia.org, https://wikipedia.org are allowed for iframes 4-6 respectively. As the final navigation url https://www.wikipedia.org is different from any of them, it's not allowed for iframes 4-6.

For https localhost, iframe 5 allow list is https://www.wikipedia.org and therefore it's allowed.

For both http and https localhost, if src is set to https://www.wikipedia.org, it's allowed as expected.

For [example.com](http://example.com/), there's no redirect, so it's working as expected.

maudnals · 2022-07-15T12:13:43Z

@alois-bissuel
With this in mind, the issue seems caused by wikipedia's redirects, and not by the protocol-relative URL.
Including www in the protocol relative-URL should solve the issue for wikipedia (see demos above).

Can you confirm?

Now I understand your issue is broader, as in, anytime you embed an iframe that's redirected, you may face this problem.
Is this correct?

One way to mitigate this is to explicitly list the final destination of the redirect in the policy's src, but I don't know how realistic this is in practice.

(Another example: let's take an HTTPS deployed site, that embeds an iframe that looks like this:

<iframe src="https://wikipedia.org/" allow="attribution-reporting" frameborder="1">

allow="attribution-reporting" defaults to the same origin as the src of the iframe.
So in this case, attribution-reporting is is allowed on https://wikipedia.org/
However, https://wikipedia.org/ is redirected to https://www.wikipedia.org
So this is why attribution-reporting is blocked on https://wikipedia.org

See a repro here (IFRAME 7) https://shimmer-well-juravenator.glitch.me/)

alois-bissuel · 2022-07-15T15:12:24Z

Thanks for the detailed conclusion, I will look at it again on Monday.
I believe as you stated that any redirect might indeed cause problems.

alois-bissuel · 2022-07-28T12:59:08Z

Hello,

Sorry for not following up on your previous conclusions @maudnals. I believe you nailed the issue and broadened its scope (ie that any redirect will break the permission policy system if we rely on the src shorthand).
Depending on the maturity of the OT, I don't think that explicitly listing the destination is realistic, given the overall complexity of the adtech ecosystem.

Thanks again for your thorough investigation !

maudnals · 2022-08-02T13:39:50Z

Thanks @alois-bissuel!
Would it be fair to close this issue now⏤not because the underlying problem is solved, but because it's been found and is already captured and discussed in #41.
I've updated this comment to ensure #40 is referenced in #41.

alois-bissuel · 2022-08-31T13:05:50Z

Closing for all the reasons highlighted by @maudnals.

alois-bissuel added the attribution-reporting Issues relating to the Attribution Reporting API label Jun 24, 2022

alois-bissuel assigned maudnals Jun 24, 2022

maudnals mentioned this issue Jun 28, 2022

Origin trial token inside iFrames #38

Closed

maudnals mentioned this issue Jul 15, 2022

Permissions-Policy limitations WICG/attribution-reporting-api#519

Closed

maudnals mentioned this issue Aug 2, 2022

Remove the permissions policy need in cross-origin iFrames during the OT #41

Closed

alois-bissuel closed this as completed Aug 31, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Protocol-relative URL and permissions policy #40

Protocol-relative URL and permissions policy #40

alois-bissuel commented Jun 24, 2022

samdutton commented Jun 27, 2022

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022

alois-bissuel commented Jun 28, 2022

maudnals commented Jun 28, 2022 •

edited

Loading

alois-bissuel commented Jun 28, 2022

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 30, 2022

maudnals commented Jul 14, 2022 •

edited

Loading

maudnals commented Jul 15, 2022 •

edited

Loading

alois-bissuel commented Jul 15, 2022

alois-bissuel commented Jul 28, 2022

maudnals commented Aug 2, 2022 •

edited

Loading

alois-bissuel commented Aug 31, 2022

Protocol-relative URL and permissions policy #40

Protocol-relative URL and permissions policy #40

Comments

alois-bissuel commented Jun 24, 2022

Minimal working example

samdutton commented Jun 27, 2022

maudnals commented Jun 28, 2022 • edited Loading

maudnals commented Jun 28, 2022 • edited Loading

maudnals commented Jun 28, 2022

alois-bissuel commented Jun 28, 2022

maudnals commented Jun 28, 2022 • edited Loading

alois-bissuel commented Jun 28, 2022

maudnals commented Jun 28, 2022 • edited Loading

maudnals commented Jun 28, 2022 • edited Loading

maudnals commented Jun 28, 2022 • edited Loading

To summarize what we've observed:

maudnals commented Jun 30, 2022

maudnals commented Jul 14, 2022 • edited Loading

maudnals commented Jul 15, 2022 • edited Loading

alois-bissuel commented Jul 15, 2022

alois-bissuel commented Jul 28, 2022

maudnals commented Aug 2, 2022 • edited Loading

alois-bissuel commented Aug 31, 2022

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jun 28, 2022 •

edited

Loading

maudnals commented Jul 14, 2022 •

edited

Loading

maudnals commented Jul 15, 2022 •

edited

Loading

maudnals commented Aug 2, 2022 •

edited

Loading