Re: [tor-bugs] #34366 [Applications/Tor Browser]: The onion-location mechanism does not redirect to full URL

[Tor Bug Tracker & Wiki]

#34366: The onion-location mechanism does not redirect to full URL
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-9.5-issues|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by acat):

 Replying to [comment:3 mcs]:
 > For what it's worth, it would be more consistent with HTTP's `Location`
 header to preserve fragment identifiers. From
 https://tools.ietf.org/html/rfc7231#section-7.1.2:
 >  If the Location value provided in a 3xx (Redirection) response does
 >  not have a fragment component, a user agent MUST process the
 >  redirection as if the value inherits the fragment component of the
 >  URI reference used to generate the request target (i.e., the
 >  redirection inherits the original reference's fragment, if any).
 > The RFC also include some examples. I don't think reusing the fragment
 component would be harmful in too many cases and we could leave it to the
 website maintainer to watch out for such problems.

 Thanks, I did not know that. It seems we lost this by basing our
 implementation in `Refresh` instead of `Location` redirects (to avoid
 issues with the redirect `Response` codes). Yes, maybe we could just
 modify our patch to always inherit the fragment (if the `Onion-Location`
 doesn't have a fragment already).

 Replying to [comment:2 sysrqb]:
 >I understand why this is a useful feature, but I worry about successfully
 achieving this goal. I think the underlying question is "should reloading
 a page based on onion-location provide same-origin behavior?". If it
 should not provide that behavior, then we should simply reload the page
 using the provided URL without modification. If the behavior should be
 "same-origin"-like, then I like the idea of providing a "relative" mode.
 However, if that is the case, then we need to discuss how cookies and
 storage are shared. I expect some pages contain content depending on a
 cookie or localstorage, and reloading the page with a different domain may
 cause weird problems if the anchor isn't valid on the new page or in the
 SPA. Alt-svc entirely avoids this problem.
 Treating as the same-origin is an interesting idea, and I think we should
 consider it (probably has some risks, since this behaviour is not there
 for `Location` or any redirects in general). But given that inheriting the
 fragment already happens with `Location`, it **may** be just fine to also
 implement it for `Onion-Location`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34366 [Applications/Tor Browser]: The onion-location mechanism does not redirect to full URL

[Tor Bug Tracker & Wiki]

#34366: The onion-location mechanism does not redirect to full URL
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-9.5-issues|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 For what it's worth, it would be more consistent with HTTP's `Location`
 header to preserve fragment identifiers. From
 https://tools.ietf.org/html/rfc7231#section-7.1.2:
  If the Location value provided in a 3xx (Redirection) response does
  not have a fragment component, a user agent MUST process the
  redirection as if the value inherits the fragment component of the
  URI reference used to generate the request target (i.e., the
  redirection inherits the original reference's fragment, if any).
 The RFC also include some examples. I don't think reusing the fragment
 component would be harmful in too many cases and we could leave it to the
 website maintainer to watch out for such problems.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34366 [Applications/Tor Browser]: The onion-location mechanism does not redirect to full URL

[Tor Bug Tracker & Wiki]

#34366: The onion-location mechanism does not redirect to full URL
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-9.5-issues|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:1 acat]:
 > One way to avoid having to scroll again would be to keep the scroll
 position when there is the redirect. That might solve the issue when there
 is no hash in the url, so this solution might be implemented
 independently.
 >
 > However, the hash part of the URL (fragment identifier?) is not only
 used for anchors, but also for other stuff like navigation in single-page
 applications, etc., so it would be good to preserve it. One idea would be
 to allow a "relative mode" for Onion-Location, where the value is
 interpreted as the scheme + host, and the redirect is performed by
 appending the current path + query params + hash to it. This would also
 allow to have shorter and simpler Onion-Location headers for websites, and
 in most cases, to serve the same static Onion-Location header for the
 whole website.

 I understand why this is a useful feature, but I worry about successfully
 achieving this goal. I think the underlying question is "should reloading
 a page based on onion-location provide same-origin behavior?". If it
 should not provide that behavior, then we should simply reload the page
 using the provided URL without modification. If the behavior should be
 "same-origin"-like, then I like the idea of providing a "relative" mode.
 However, if that is the case, then we need to discuss how cookies and
 storage are shared. I expect some pages contain content depending on a
 cookie or localstorage, and reloading the page with a different domain may
 cause weird problems if the anchor isn't valid on the new page or in the
 SPA. Alt-svc entirely avoids this problem.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34366 [Applications/Tor Browser]: The onion-location mechanism does not redirect to full URL

[Tor Bug Tracker & Wiki]

#34366: The onion-location mechanism does not redirect to full URL
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-9.5-issues|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by acat):

 One way to avoid having to scroll again would be to keep the scroll
 position when there is the redirect. That might solve the issue when there
 is no hash in the url, so this solution might be implemented
 independently.

 However, the hash part of the URL (fragment identifier?) is not only used
 for anchors, but also for other stuff like navigation in single-page
 applications, etc., so it would be good to preserve it. One idea would be
 to allow a "relative mode" for Onion-Location, where the value is
 interpreted as the scheme + host, and the redirect is performed by
 appending the current path + query params + hash to it. This would also
 allow to have shorter and simpler Onion-Location headers for websites, and
 in most cases, to serve the same static Onion-Location header for the
 whole website.

 If we think this is a good idea, then the question would be how to do it
 in a backwards-compatible way. We could use a trick like: if it starts
 with `http:` or `https:`, treat like an absolute `Onion-Location`,
 otherwise, treat like a relative one (and assume it's `http:`). I guess
 for a .onion, not redirecting to `https` directly is not a big issue.
 Another possible solution would be to use sysrqb's idea of making `Onion-
 Location` a
 [https://trac.torproject.org/projects/tor/ticket/21952#comment:134
 structured header]. We could then express a "relative" `Onion-Location`
 header like `Onion-Location: "http://hostname.onion";; relative`, for
 example (a string item and a boolean parameter `relative`).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs