Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hide some navigation timing info when cross-origin redirects are present #7105

Closed
wants to merge 4 commits into from

Conversation

noamr
Copy link
Contributor

@noamr noamr commented Sep 23, 2021

When a navigation includes cross-origin redirects, the navigation timing
entry should not include information about redirect timing and internal
network timing, as that may expose cross-origin timing information.

Closes #7104

Depends on whatwg/fetch#1309

[x] At least two implementers are interested (and none opposed):

Part of is already implemented and tested, but has been omitted when refactoring the navigation timing spec into HTML.

[x] Tests already cover this: navigation-timing/test_timing_xserver_redirect.html

[] Implementation bugs are filed:
Chrome: 1063370
Firefox: 1733044
Safari: TBD

Will have to close these bugs for now if we agree to keep the status quo, which is what's reflected in this PR.

(See WHATWG Working Mode: Changes for more details.)


/browsing-the-web.html ( diff )
/infrastructure.html ( diff )


/browsing-the-web.html ( diff )
/infrastructure.html ( diff )

@domenic
Copy link
Member

domenic commented Sep 25, 2021

Can you restore the PR template for this change, by editing the original post?

@noamr
Copy link
Contributor Author

noamr commented Sep 26, 2021

Can you restore the PR template for this change, by editing the original post?

Done

noamr added a commit to web-platform-tests/wpt that referenced this pull request Sep 27, 2021
Exposing connection timing info such as domainLookupStart may expose the
fact that a cross-origin redirect has occured, information which should
be hidden.

This is fixed in whatwg/html#7105, and this
modifies the test to account for the new behavior.
noamr added a commit to web-platform-tests/wpt that referenced this pull request Sep 27, 2021
Exposing connection timing info such as domainLookupStart may expose the
fact that a cross-origin redirect has occured, information which should
be hidden.

This is fixed in whatwg/html#7105, and this
modifies the test to account for the new behavior.
@annevk
Copy link
Member

annevk commented Sep 28, 2021

To be clear, the template @domenic is referring to is https://github.com/whatwg/html/blob/main/PULL_REQUEST_TEMPLATE.md. I don't see it in OP.

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yoavweiss should review this as well or perhaps this should wait for @domenic who I believe reviewed the last round of navigation timing additions.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@annevk
Copy link
Member

annevk commented Sep 28, 2021

Also, thanks for working on this!

@yoavweiss
Copy link
Contributor

PR preview seems to be failing with a build error. Are you able to build this locally?

@noamr
Copy link
Contributor Author

noamr commented Sep 29, 2021

PR preview seems to be failing with a build error. Are you able to build this locally?

It builds locally, I rebased on forced push with hope.

Copy link
Contributor

@yoavweiss yoavweiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but I can't find the "opaque timing info" algorithm, which seems critical

source Outdated Show resolved Hide resolved
@noamr
Copy link
Contributor Author

noamr commented Sep 29, 2021

Looks good, but I can't find the "opaque timing info" algorithm, which seems critical

Yea, this depends on whatwg/fetch#1309.

Copy link
Contributor

@yoavweiss yoavweiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@noamr
Copy link
Contributor Author

noamr commented Sep 30, 2021

Trying to figure out whether exposing secureConnectionStart et al after cross-origin redirects is actually OK (as per current behavior), since the document who can read these attributes is from the same URL that the connection is relevant to. So in essence it doesn't expose any new cross-origin information at all.

Also, in that case, redirectStart and redirectEnd are values that can be extrapolated, since that final server knows the difference between navigationStart and the timing of its own request.

So I think we should either go with this (hiding all TAO-protected info when cross-origin redirects are present), or also expose redirectStart and redirectEnd when cross-origin redirects are part of the navigation.

If we choose to keep the current behavior, I will amend this PR to match it (it needs to special-case redirectStart and redirectEnd) and drop the WPT and browser issues.

@yoavweiss @sefeng211 @npm1 @annevk thoughts?

@annevk
Copy link
Member

annevk commented Sep 30, 2021

I think at least in theory a connection can encompass multiple origins (if the certificate is valid for all of them, though not all user agents support this), how does secureConnectionStart deal with that?

@noamr
Copy link
Contributor Author

noamr commented Sep 30, 2021

I think at least in theory a connection can encompass multiple origins (if the certificate is valid for all of them, though not all user agents support this), how does secureConnectionStart deal with that?

It would clamp secureConnectionStart to fetchStart - it would look like the secure connection was immediate.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Oct 1, 2021
… a cross-origin redirect for PerformanceNavigationTiming r=smaug

The actual text for hiding these information is actually missing at the
moment. This is the pending PR whatwg/html#7105
which should fix it.

In addition to this PR, the obsolete (obsolete, but still accurate) definition
for `redirectStart` and `redirectEnd` has specified that when there's a
cross-origin redirect, these timings should not be exposed.

Obsolete definition: https://w3c.github.io/navigation-timing/#dom-performancetiming-redirectstart

Differential Revision: https://phabricator.services.mozilla.com/D127200
jamienicol pushed a commit to jamienicol/gecko that referenced this pull request Oct 4, 2021
… a cross-origin redirect for PerformanceNavigationTiming r=smaug

The actual text for hiding these information is actually missing at the
moment. This is the pending PR whatwg/html#7105
which should fix it.

In addition to this PR, the obsolete (obsolete, but still accurate) definition
for `redirectStart` and `redirectEnd` has specified that when there's a
cross-origin redirect, these timings should not be exposed.

Obsolete definition: https://w3c.github.io/navigation-timing/#dom-performancetiming-redirectstart

Differential Revision: https://phabricator.services.mozilla.com/D127200
@noamr
Copy link
Contributor Author

noamr commented Oct 5, 2021

This is on hold until we figure out w3c/navigation-timing#160

@noamr
Copy link
Contributor Author

noamr commented Jan 17, 2022

This is on hold until we figure out w3c/navigation-timing#160

Since w3c/navigation-timing#160 is not close to resolution, for now continuing with this to at least reflect the current implementations.

When a navigation includes cross-origin redirects, the navigation timing
entry should not include information about redirect timing and internal
network timing, as that may expose cross-origin timing information.

This is already implemented and tested, but has been omitted when
refactoring the navigation timing spec into HTML.

Closes whatwg#7104
@noamr
Copy link
Contributor Author

noamr commented Feb 8, 2022

Looking at this again, I don't think it makes sense to TAO-protect anything in navigation timing as long as navigation start is the time origin. The connection info is anyway only relevant to the current origin, and redirectStart / redirectEnd can be derived from fetchStart not being zero.

Trying to figure out whether exposing secureConnectionStart et al after cross-origin redirects is actually OK (as per current behavior), since the document who can read these attributes is from the same URL that the connection is relevant to. So in essence it doesn't expose any new cross-origin information at all.

Also, in that case, redirectStart and redirectEnd are values that can be extrapolated, since that final server knows the difference between navigationStart and the timing of its own request.

So I think we should either go with this (hiding all TAO-protected info when cross-origin redirects are present), or also expose redirectStart and redirectEnd when cross-origin redirects are part of the navigation.

If we choose to keep the current behavior, I will amend this PR to match it (it needs to special-case redirectStart and redirectEnd) and drop the WPT and browser issues.

@yoavweiss @sefeng211 @npm1 @annevk thoughts?

Looking at this again, I don't think it makes sense to TAO-protect anything in navigation timing as long as navigation start is the time origin. The connection info is anyway only relevant to the current origin, and redirectStart / redirectEnd can be derived from fetchStart not being zero. Since the main reason to keep the time origin the way it is is backwards compatibility, maybe we should keep the status quo (hiding only redirectStart and redirectEnd) and add it to the spec even though it doesn't provide any real cross-origin protection.

@noamr
Copy link
Contributor Author

noamr commented Feb 8, 2022

Updated PR to send the "has cross origin redirects" info to nav-timing, where the decision to hide redirectStart and redirectEnd is made (as it's an API decision rather than a real cross-origin issue)

In conjunction with w3c/navigation-timing#170

@noamr
Copy link
Contributor Author

noamr commented Feb 24, 2022

Closed by w3c/navigation-timing#170

@noamr noamr closed this Feb 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Hide TAO-protected timing info from navigation timing when cross-origin redirects are present
4 participants