Search Usability Regression in v10
I reported this usability problem on the tor-talk list but received no replies, so I thought I’d try here. For some context, I’m a researcher at Carnegie Mellon University, and I’m considering running a user-study involving Tor Browser in the coming months. I think this usability problem might negatively impact users (in my study, and at large), so I thought I should bring it to your attention.
I’m seeing a small but annoying usability problem in v10 of Tor Browser (tested with 10.0.2 on a Mac). Replication:
Open a new window Search using either the URL bar or the “Search with DDG” field. On the page with search results, note that the page’s URL doesn’t contain the search query in the URL parameters. Click on a link in the search results Click the back button Actual behavior: you are returned to a blank search page Expected behavior: you are returned to your search results
I don’t see this problem in the latest version of Firefox, 82.0.3, and I don’t remember seeing this problem before Tor Browser v10. Also, I do not see this problem for searches conducted with Google in Tor Browser.
I’m wondering whether this was an intentional change, or something that should be fixed. Hopefully it's an easy fix: if the search is conducted using URL parameters, then the back button should work as expected.
Sincerely, -Peter Story PhD Student
On Wed, Nov 18, 2020 at 03:59:15PM -0500, Peter Story wrote:
I reported this usability problem on the tor-talk list but received no replies, so I thought I’d try here. For some context, I’m a researcher at Carnegie Mellon University, and I’m considering running a user-study involving Tor Browser in the coming months. I think this usability problem might negatively impact users (in my study, and at large), so I thought I should bring it to your attention.
Hi Peter, Thanks for sending this mail and following up. I apologize for the lack of response, we're all overloaded. This is a known usability issue. It arises from the fact that Tor Browser sends the initial search query via a POST request. The breakage occurs because the "Back" action triggers a GET request for the previous site and it does not re-play the original POST request. I assume the reasoning for this is that POST requests are not assumed to be idempotent, whereas GET requests are. I'm not sure how best we can solve this except switching to using GET, however this places all queries into the URL bar and then they become vulnerabilbe to shoulder-surfing as such. That probably a necessary trade-off, though.
I’m seeing a small but annoying usability problem in v10 of Tor Browser (tested with 10.0.2 on a Mac). Replication:
Open a new window Search using either the URL bar or the “Search with DDG” field. On the page with search results, note that the page’s URL doesn’t contain the search query in the URL parameters. Click on a link in the search results Click the back button Actual behavior: you are returned to a blank search page Expected behavior: you are returned to your search results
I don’t see this problem in the latest version of Firefox, 82.0.3, and I don’t remember seeing this problem before Tor Browser v10. Also, I do not see this problem for searches conducted with Google in Tor Browser.
I’m wondering whether this was an intentional change, or something that should be fixed. Hopefully it's an easy fix: if the search is conducted using URL parameters, then the back button should work as expected.
Sincerely, -Peter Story PhD Student
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
Hello Matthew, Thanks for the quick reply! And no worries at all. Glad to hear that the team is aware of the problem! I think that switching back to GETs (I believe this was the behavior before v10) wouldn’t significantly increase the threat of should surfing. With the current configuration, the search is still visible on the search results page itself, and after clicking on a linked page the text of the search is still visible in the browser’s back button. I think this regression has the potential to seriously impact the browser’s usability, because when following links in search, a significant percent of linked websites block Tor users. When a user encounters a page which blocks them, they will probably try to return to the search results to try another website. Crucially, the back button not returning to the search results breaks this workflow. How does decision-making for issues like this typically work? If I’d like to help fix this issue, do you have any recommendations (e.g., should I open a PR with a fix)? Thank you! -Peter
On Nov 18, 2020, at 4:20 PM, Matthew Finkel <sysrqb@torproject.org> wrote:
On Wed, Nov 18, 2020 at 03:59:15PM -0500, Peter Story wrote:
I reported this usability problem on the tor-talk list but received no replies, so I thought I’d try here. For some context, I’m a researcher at Carnegie Mellon University, and I’m considering running a user-study involving Tor Browser in the coming months. I think this usability problem might negatively impact users (in my study, and at large), so I thought I should bring it to your attention.
Hi Peter,
Thanks for sending this mail and following up. I apologize for the lack of response, we're all overloaded.
This is a known usability issue. It arises from the fact that Tor Browser sends the initial search query via a POST request. The breakage occurs because the "Back" action triggers a GET request for the previous site and it does not re-play the original POST request. I assume the reasoning for this is that POST requests are not assumed to be idempotent, whereas GET requests are. I'm not sure how best we can solve this except switching to using GET, however this places all queries into the URL bar and then they become vulnerabilbe to shoulder-surfing as such. That probably a necessary trade-off, though.
I’m seeing a small but annoying usability problem in v10 of Tor Browser (tested with 10.0.2 on a Mac). Replication:
Open a new window Search using either the URL bar or the “Search with DDG” field. On the page with search results, note that the page’s URL doesn’t contain the search query in the URL parameters. Click on a link in the search results Click the back button Actual behavior: you are returned to a blank search page Expected behavior: you are returned to your search results
I don’t see this problem in the latest version of Firefox, 82.0.3, and I don’t remember seeing this problem before Tor Browser v10. Also, I do not see this problem for searches conducted with Google in Tor Browser.
I’m wondering whether this was an intentional change, or something that should be fixed. Hopefully it's an easy fix: if the search is conducted using URL parameters, then the back button should work as expected.
Sincerely, -Peter Story PhD Student
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev>
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev>
Hi Peter, I looked at this a little closer and this seems like a "regression" (change in behavior) on DDG and not in Tor Browser. I tested Tor Browser 8.0 (2018) and found the same behavior. I suspect this usability regression is caused by the results page not being considered cachable. Normally, Tor Browser (Firefox) would save the previous page in the bfcache (back-forward cache) and re-use it when the Back button is pressed, but this is not happening now and the page is requested again instead. There are three obvious paths forward. 1) Use a GET request instead of POST - This does not resolve the regression, but when the page is re-requested on "Back" the original search terms are included in the GET request and the user is presented with the results page again 2) Results from html.duckduckgo.com are (apparently) successfully cached (currently used when the Safest security level is set in Tor Browser) - Use this domain on all security levels, instead of the main DDG site with Javascript optimizations 3) Work with DDG and identify why this is broken and find a resolution I am leaning toward (1) because: a) This is the default method in Firefox b) I am skeptical about the (security) benefits of POST over GET c) We know this works We'll get some complaints about switching to using GET as the default search method in Tor Browser, so I'll reach out to DDG and work with them on this, too. I'd like to hear concerns about switching to using GET, too. On Wed, Nov 18, 2020 at 04:36:33PM -0500, Peter Story wrote:
Hello Matthew,
Thanks for the quick reply! And no worries at all.
Glad to hear that the team is aware of the problem! I think that switching back to GETs (I believe this was the behavior before v10) wouldn’t significantly increase the threat of should surfing. With the current configuration, the search is still visible on the search results page itself, and after clicking on a linked page the text of the search is still visible in the browser’s back button.
I think this regression has the potential to seriously impact the browser’s usability, because when following links in search, a significant percent of linked websites block Tor users. When a user encounters a page which blocks them, they will probably try to return to the search results to try another website. Crucially, the back button not returning to the search results breaks this workflow.
How does decision-making for issues like this typically work? If I’d like to help fix this issue, do you have any recommendations (e.g., should I open a PR with a fix)?
Thank you! -Peter
On Nov 18, 2020, at 4:20 PM, Matthew Finkel <sysrqb@torproject.org> wrote:
On Wed, Nov 18, 2020 at 03:59:15PM -0500, Peter Story wrote:
I reported this usability problem on the tor-talk list but received no replies, so I thought I’d try here. For some context, I’m a researcher at Carnegie Mellon University, and I’m considering running a user-study involving Tor Browser in the coming months. I think this usability problem might negatively impact users (in my study, and at large), so I thought I should bring it to your attention.
Hi Peter,
Thanks for sending this mail and following up. I apologize for the lack of response, we're all overloaded.
This is a known usability issue. It arises from the fact that Tor Browser sends the initial search query via a POST request. The breakage occurs because the "Back" action triggers a GET request for the previous site and it does not re-play the original POST request. I assume the reasoning for this is that POST requests are not assumed to be idempotent, whereas GET requests are. I'm not sure how best we can solve this except switching to using GET, however this places all queries into the URL bar and then they become vulnerabilbe to shoulder-surfing as such. That probably a necessary trade-off, though.
I’m seeing a small but annoying usability problem in v10 of Tor Browser (tested with 10.0.2 on a Mac). Replication:
Open a new window Search using either the URL bar or the “Search with DDG” field. On the page with search results, note that the page’s URL doesn’t contain the search query in the URL parameters. Click on a link in the search results Click the back button Actual behavior: you are returned to a blank search page Expected behavior: you are returned to your search results
I don’t see this problem in the latest version of Firefox, 82.0.3, and I don’t remember seeing this problem before Tor Browser v10. Also, I do not see this problem for searches conducted with Google in Tor Browser.
I’m wondering whether this was an intentional change, or something that should be fixed. Hopefully it's an easy fix: if the search is conducted using URL parameters, then the back button should work as expected.
Sincerely, -Peter Story PhD Student
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev>
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev>
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
Matthew, Thank you for taking a closer look! It’s interesting that DDG may have changed something on their end – I hadn’t thought of that possibility. I did some searching, and it looks like DDG is aware the POST can break back buttons, since they mention it here: https://duckduckgo.com/privacy
You can turn on POST requests on our settings page, but it has its own issues. POST requests usually break browser back buttons, and they make it impossible for you to easily share your search by copying and pasting it out of your Web browser's address bar. … Because of these drawbacks in HTTPS, POST and proxies we decided to take the redirect approach to combat search leakage. However, we leave the choice up to you. You can deviate from the default on our settings page by toggling the redirect or address bar settings. You can also use our encrypted version.
Since the DDG team has documented the limitations of using POST, my intuition is that they’d be unlikely to make changes to help overcome those limitations (e.g., by adjusting the caching settings for search results), but it couldn’t hurt to check with them! So my preference (at the moment) is also for option (1). Thanks! -Peter
On Nov 21, 2020, at 9:42 AM, Matthew Finkel <sysrqb@torproject.org> wrote:
Hi Peter,
I looked at this a little closer and this seems like a "regression" (change in behavior) on DDG and not in Tor Browser. I tested Tor Browser 8.0 (2018) and found the same behavior.
I suspect this usability regression is caused by the results page not being considered cachable. Normally, Tor Browser (Firefox) would save the previous page in the bfcache (back-forward cache) and re-use it when the Back button is pressed, but this is not happening now and the page is requested again instead.
There are three obvious paths forward.
1) Use a GET request instead of POST - This does not resolve the regression, but when the page is re-requested on "Back" the original search terms are included in the GET request and the user is presented with the results page again
2) Results from html.duckduckgo.com are (apparently) successfully cached (currently used when the Safest security level is set in Tor Browser) - Use this domain on all security levels, instead of the main DDG site with Javascript optimizations
3) Work with DDG and identify why this is broken and find a resolution
I am leaning toward (1) because: a) This is the default method in Firefox b) I am skeptical about the (security) benefits of POST over GET c) We know this works
We'll get some complaints about switching to using GET as the default search method in Tor Browser, so I'll reach out to DDG and work with them on this, too.
I'd like to hear concerns about switching to using GET, too.
On Wed, Nov 18, 2020 at 04:36:33PM -0500, Peter Story wrote:
Hello Matthew,
Thanks for the quick reply! And no worries at all.
Glad to hear that the team is aware of the problem! I think that switching back to GETs (I believe this was the behavior before v10) wouldn’t significantly increase the threat of should surfing. With the current configuration, the search is still visible on the search results page itself, and after clicking on a linked page the text of the search is still visible in the browser’s back button.
I think this regression has the potential to seriously impact the browser’s usability, because when following links in search, a significant percent of linked websites block Tor users. When a user encounters a page which blocks them, they will probably try to return to the search results to try another website. Crucially, the back button not returning to the search results breaks this workflow.
How does decision-making for issues like this typically work? If I’d like to help fix this issue, do you have any recommendations (e.g., should I open a PR with a fix)?
Thank you! -Peter
On Nov 18, 2020, at 4:20 PM, Matthew Finkel <sysrqb@torproject.org> wrote:
On Wed, Nov 18, 2020 at 03:59:15PM -0500, Peter Story wrote:
I reported this usability problem on the tor-talk list but received no replies, so I thought I’d try here. For some context, I’m a researcher at Carnegie Mellon University, and I’m considering running a user-study involving Tor Browser in the coming months. I think this usability problem might negatively impact users (in my study, and at large), so I thought I should bring it to your attention.
Hi Peter,
Thanks for sending this mail and following up. I apologize for the lack of response, we're all overloaded.
This is a known usability issue. It arises from the fact that Tor Browser sends the initial search query via a POST request. The breakage occurs because the "Back" action triggers a GET request for the previous site and it does not re-play the original POST request. I assume the reasoning for this is that POST requests are not assumed to be idempotent, whereas GET requests are. I'm not sure how best we can solve this except switching to using GET, however this places all queries into the URL bar and then they become vulnerabilbe to shoulder-surfing as such. That probably a necessary trade-off, though.
I’m seeing a small but annoying usability problem in v10 of Tor Browser (tested with 10.0.2 on a Mac). Replication:
Open a new window Search using either the URL bar or the “Search with DDG” field. On the page with search results, note that the page’s URL doesn’t contain the search query in the URL parameters. Click on a link in the search results Click the back button Actual behavior: you are returned to a blank search page Expected behavior: you are returned to your search results
I don’t see this problem in the latest version of Firefox, 82.0.3, and I don’t remember seeing this problem before Tor Browser v10. Also, I do not see this problem for searches conducted with Google in Tor Browser.
I’m wondering whether this was an intentional change, or something that should be fixed. Hopefully it's an easy fix: if the search is conducted using URL parameters, then the back button should work as expected.
Sincerely, -Peter Story PhD Student
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev>
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev>
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
Matthew, I was reading a recent Tor-usability paper ("Peeling the Onion’s User Experience Layer,” by Gallagher et al.) and I found a relevant quote:
“I did run into a quirk, and I do not know if this was due to Tor or DuckDuckGo. I use StackOverFlow to get help on coding problems and whenever I clicked back it took me to the main page of Tor and not to the list of search events. This was very frustrating because I had to retype my query and look for it again.” – (P6, F, 22, write-up) This paper was published in 2018, so this suggests that the usability issue we’ve been discussing has been present (at least in some form) for several years. To me, this suggests that DDG is unlikely to change things on their end, so this seems like another reason to prefer fix (1).
If we’d like to proceed with fix (1), would it be helpful if I implemented the change and opened a PR on the issue tracker? Thanks! -Peter
On Nov 23, 2020, at 9:42 AM, Peter Story <pstory@andrew.cmu.edu> wrote:
Matthew,
Thank you for taking a closer look! It’s interesting that DDG may have changed something on their end – I hadn’t thought of that possibility.
I did some searching, and it looks like DDG is aware the POST can break back buttons, since they mention it here: https://duckduckgo.com/privacy <https://duckduckgo.com/privacy>
You can turn on POST requests on our settings page, but it has its own issues. POST requests usually break browser back buttons, and they make it impossible for you to easily share your search by copying and pasting it out of your Web browser's address bar. … Because of these drawbacks in HTTPS, POST and proxies we decided to take the redirect approach to combat search leakage. However, we leave the choice up to you. You can deviate from the default on our settings page by toggling the redirect or address bar settings. You can also use our encrypted version.
Since the DDG team has documented the limitations of using POST, my intuition is that they’d be unlikely to make changes to help overcome those limitations (e.g., by adjusting the caching settings for search results), but it couldn’t hurt to check with them!
So my preference (at the moment) is also for option (1).
Thanks! -Peter
On Nov 21, 2020, at 9:42 AM, Matthew Finkel <sysrqb@torproject.org <mailto:sysrqb@torproject.org>> wrote:
Hi Peter,
I looked at this a little closer and this seems like a "regression" (change in behavior) on DDG and not in Tor Browser. I tested Tor Browser 8.0 (2018) and found the same behavior.
I suspect this usability regression is caused by the results page not being considered cachable. Normally, Tor Browser (Firefox) would save the previous page in the bfcache (back-forward cache) and re-use it when the Back button is pressed, but this is not happening now and the page is requested again instead.
There are three obvious paths forward.
1) Use a GET request instead of POST - This does not resolve the regression, but when the page is re-requested on "Back" the original search terms are included in the GET request and the user is presented with the results page again
2) Results from html.duckduckgo.com <http://html.duckduckgo.com/> are (apparently) successfully cached (currently used when the Safest security level is set in Tor Browser) - Use this domain on all security levels, instead of the main DDG site with Javascript optimizations
3) Work with DDG and identify why this is broken and find a resolution
I am leaning toward (1) because: a) This is the default method in Firefox b) I am skeptical about the (security) benefits of POST over GET c) We know this works
We'll get some complaints about switching to using GET as the default search method in Tor Browser, so I'll reach out to DDG and work with them on this, too.
I'd like to hear concerns about switching to using GET, too.
On Wed, Nov 18, 2020 at 04:36:33PM -0500, Peter Story wrote:
Hello Matthew,
Thanks for the quick reply! And no worries at all.
Glad to hear that the team is aware of the problem! I think that switching back to GETs (I believe this was the behavior before v10) wouldn’t significantly increase the threat of should surfing. With the current configuration, the search is still visible on the search results page itself, and after clicking on a linked page the text of the search is still visible in the browser’s back button.
I think this regression has the potential to seriously impact the browser’s usability, because when following links in search, a significant percent of linked websites block Tor users. When a user encounters a page which blocks them, they will probably try to return to the search results to try another website. Crucially, the back button not returning to the search results breaks this workflow.
How does decision-making for issues like this typically work? If I’d like to help fix this issue, do you have any recommendations (e.g., should I open a PR with a fix)?
Thank you! -Peter
On Nov 18, 2020, at 4:20 PM, Matthew Finkel <sysrqb@torproject.org <mailto:sysrqb@torproject.org>> wrote:
On Wed, Nov 18, 2020 at 03:59:15PM -0500, Peter Story wrote:
I reported this usability problem on the tor-talk list but received no replies, so I thought I’d try here. For some context, I’m a researcher at Carnegie Mellon University, and I’m considering running a user-study involving Tor Browser in the coming months. I think this usability problem might negatively impact users (in my study, and at large), so I thought I should bring it to your attention.
Hi Peter,
Thanks for sending this mail and following up. I apologize for the lack of response, we're all overloaded.
This is a known usability issue. It arises from the fact that Tor Browser sends the initial search query via a POST request. The breakage occurs because the "Back" action triggers a GET request for the previous site and it does not re-play the original POST request. I assume the reasoning for this is that POST requests are not assumed to be idempotent, whereas GET requests are. I'm not sure how best we can solve this except switching to using GET, however this places all queries into the URL bar and then they become vulnerabilbe to shoulder-surfing as such. That probably a necessary trade-off, though.
I’m seeing a small but annoying usability problem in v10 of Tor Browser (tested with 10.0.2 on a Mac). Replication:
Open a new window Search using either the URL bar or the “Search with DDG” field. On the page with search results, note that the page’s URL doesn’t contain the search query in the URL parameters. Click on a link in the search results Click the back button Actual behavior: you are returned to a blank search page Expected behavior: you are returned to your search results
I don’t see this problem in the latest version of Firefox, 82.0.3, and I don’t remember seeing this problem before Tor Browser v10. Also, I do not see this problem for searches conducted with Google in Tor Browser.
I’m wondering whether this was an intentional change, or something that should be fixed. Hopefully it's an easy fix: if the search is conducted using URL parameters, then the back button should work as expected.
Sincerely, -Peter Story PhD Student
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> <mailto:tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev> <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev>>
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> <mailto:tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev> <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev>>
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org <mailto:tbb-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
participants (2)
-
Matthew Finkel -
Peter Story