4 ms·

> ...we both know it's not true. I know no such thing. When I want to share a search result or anything else -that doesn't require authentication- with a frien

> ...we both know it's not true. I know no such thing. When I want to share a search result or anything else -that doesn't require authentication- with a friend, I copy the URL in the address bar and paste it to them. This is how The Web works. > ...if this was in a link which was automatically shared... I would agree with you [that this is a bad thing.] So, it would be acceptable to you if Google put your Google Account login and password in URI-encoded plain text in the URL of your search results? Why or why not? > Not to mention that making a API call every time you need to do something as basic as backtracking on your search... 1) Google already does exactly what I described when you make a search on *.google.com with a Javascript-enabled browser. It's what lets your back button work with their JS-based page updates. ;-) 2) A person driving his User Agent doesn't use the History API to go to a previous search result. He uses his back button or equivalent key combo.

dogma1138 11y ago
>This is how The Web works. This is one of many ways the web works, URLs were designed way before there was an easy way to share them outside of the scope of the website it self. Looking at my history 50-60% of the URL's in it aren't humanly readable and are 10 miles long, many of them do not require authentication it would be nice if people would adhere to URL's are meant to be humanly readable and easy to share but you know... ...life. >Google already does exactly what I described when you make a search on *.google.com with a Javascript-enabled browser. It's what lets your back button work with their JS-based page updates. ;-) No it doesn't my back button works just fine and there isn't a single request made when i click it, just tried it know both with the network parses in chrome dev tools and fiddler. And again the history API isn't used for this not to mention it has been deprecated and turned into the App Activities API which has quite a different set of functions now, moments are still supported but it's pretty weird now. https://developers.google.com/+/history/ https://developers.google.com/+/history/ https://developers.google.com/+/features/app-activities https://developers.google.com/+/features/app-activities Yes info leaks are bad, but this isn't even an info leak if you start a completely new query it resets the original query variable e.g.: You search for query you'll get ?q set to query and ?oq set to query you search for query history it will set ?q to query history and keep ?oq set to query you search i got a rash on my butt it will reset both the ?q and ?oq URL parameters to the new query because it's unrelated. So you won't leak the fact that you searched for manliness enhancing spa treatments to your friends if you link them a query of a pole dancing cat. Your honor is safe my friend.
- simoncion 11y ago
  I notice you didn't address my question: "So, it would be acceptable to you if Google put your Google Account login and password in URI-encoded plain text in the URL of your search results? Why or why not?" This is actually a pretty important question. > Looking at my history 50-60% of the URL's in it aren't humanly readable and are 10 miles long... It doesn't matter how long the URL is. It doesn't matter if you can easily read it. The Web works through URLs. URLs (and URIs) are how you access resources. * Data in the href attribute of the a tag? A URI. * Data in the src attribute of the img tag? A URI. * Data in the src attribute of the script tag? A URI. * Data in the 200 response to an HTTP GET request? A URI. * Data in the 30[1|2] HTTP response? A URI. * Data in the address bar of your User Agent? A URI. > [T]he history API... has been deprecated and turned into the App Activities API... No. It has not. > ...my back button works just fine and there isn't a single request made when i click it... Right. That's what the History API does. It's a strictly client-side thing. I guess you're dreadfully confused. Here's [0] the first result for "History API". It also happens to describe exactly what I'm talking about. > this isn't even an info leak if you start a completely new query it resets the original query variable ... you'll get ?q set to query and ?oq set to query ... > you search for query history it will set ?q to query history and keep ?oq set to query Cannot repro. Here's what I see: * Use omnibox to search for "thing": o=thing&oq=thing * Use google search page that loads with results for "thing" to search for "things": o=thing&oq=thing#q=things * Use that same page to search for "dingus dongus": o=thing&oq=thing#q=dingus+dongus Chrome 46, using the default Omnibox settings. [0] https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API
wtracy 11y ago
Putting your password in plaintext is unacceptable because exposes it to anyone who may be sniffing your traffic. Your search history is already visible to anyone sniffing your traffic, so it's presence in the URI is moot. I guess my point is that there's a continuum here. There's already other ways for this data to leak (it's already plaintext on the wire, and it's already there in your browser history) and this particular attack vector is easy to mitigate if you put just a little effort into it.
- simoncion 11y ago
  > Putting your password in plaintext is unacceptable because... I know that. :) dogma1138 said: > ...given all the other dark magic that is in the URL which can include your client type, version, location and other things (e.g. inter-service referrals if you go there from another google service like Google Maps) i think the original query is the least of your worries. There are people for whom and situations in which having a search query exposed is utterly disastrous. I asked the question I asked in order to determine if dogma1138 held the opinion that * "URL's are not implicitly intended to be shared outside of the scope of your application" [0], and therefore any sensitive information in them is 100% okay, because -in his world- noone ever shares hard-to-read URLs anyway or * URLs can have potentially disastrously sensitive information in them, as long as it's not username and password or some other opinion. In short, this was an information-gathering question designed to test the bounds of a hypothesis that I was forming, but did not yet have enough information to put any faith into. :) [0] https://news.ycombinator.com/item?id=10467919 https://news.ycombinator.com/item?id=10467919
- kps 11y ago
  > Your search history is already visible to anyone sniffing your traffic http://google.com/ http://google.com/ normally redirects to https. It's possible to access Google over HTTP, but it's not typical.
- leni536 11y ago
  > Putting your password in plaintext is unacceptable because exposes it to anyone who may be sniffing your traffic. I thought query strings are encrypted in a https request.

dogma1138 11y ago

>This is how The Web works. This is one of many ways the web works, URLs were designed way before there was an easy way to share them outside of the scope of the website it self. Looking at my history 50-60% of the URL's in it aren't humanly readable and are 10 miles long, many of them do not require authentication it would be nice if people would adhere to URL's are meant to be humanly readable and easy to share but you know... ...life. >Google already does exactly what I described when you make a search on *.google.com with a Javascript-enabled browser. It's what lets your back button work with their JS-based page updates. ;-) No it doesn't my back button works just fine and there isn't a single request made when i click it, just tried it know both with the network parses in chrome dev tools and fiddler. And again the history API isn't used for this not to mention it has been deprecated and turned into the App Activities API which has quite a different set of functions now, moments are still supported but it's pretty weird now. https://developers.google.com/+/history/ https://developers.google.com/+/history/ https://developers.google.com/+/features/app-activities https://developers.google.com/+/features/app-activities Yes info leaks are bad, but this isn't even an info leak if you start a completely new query it resets the original query variable e.g.: You search for query you'll get ?q set to query and ?oq set to query you search for query history it will set ?q to query history and keep ?oq set to query you search i got a rash on my butt it will reset both the ?q and ?oq URL parameters to the new query because it's unrelated. So you won't leak the fact that you searched for manliness enhancing spa treatments to your friends if you link them a query of a pole dancing cat. Your honor is safe my friend.

simoncion 11y ago
I notice you didn't address my question: "So, it would be acceptable to you if Google put your Google Account login and password in URI-encoded plain text in the URL of your search results? Why or why not?" This is actually a pretty important question. > Looking at my history 50-60% of the URL's in it aren't humanly readable and are 10 miles long... It doesn't matter how long the URL is. It doesn't matter if you can easily read it. The Web works through URLs. URLs (and URIs) are how you access resources. * Data in the href attribute of the a tag? A URI. * Data in the src attribute of the img tag? A URI. * Data in the src attribute of the script tag? A URI. * Data in the 200 response to an HTTP GET request? A URI. * Data in the 30[1|2] HTTP response? A URI. * Data in the address bar of your User Agent? A URI. > [T]he history API... has been deprecated and turned into the App Activities API... No. It has not. > ...my back button works just fine and there isn't a single request made when i click it... Right. That's what the History API does. It's a strictly client-side thing. I guess you're dreadfully confused. Here's [0] the first result for "History API". It also happens to describe exactly what I'm talking about. > this isn't even an info leak if you start a completely new query it resets the original query variable ... you'll get ?q set to query and ?oq set to query ... > you search for query history it will set ?q to query history and keep ?oq set to query Cannot repro. Here's what I see: * Use omnibox to search for "thing": o=thing&oq=thing * Use google search page that loads with results for "thing" to search for "things": o=thing&oq=thing#q=things * Use that same page to search for "dingus dongus": o=thing&oq=thing#q=dingus+dongus Chrome 46, using the default Omnibox settings. [0] https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API

wtracy 11y ago

Putting your password in plaintext is unacceptable because exposes it to anyone who may be sniffing your traffic. Your search history is already visible to anyone sniffing your traffic, so it's presence in the URI is moot. I guess my point is that there's a continuum here. There's already other ways for this data to leak (it's already plaintext on the wire, and it's already there in your browser history) and this particular attack vector is easy to mitigate if you put just a little effort into it.

simoncion 11y ago
> Putting your password in plaintext is unacceptable because... I know that. :) dogma1138 said: > ...given all the other dark magic that is in the URL which can include your client type, version, location and other things (e.g. inter-service referrals if you go there from another google service like Google Maps) i think the original query is the least of your worries. There are people for whom and situations in which having a search query exposed is utterly disastrous. I asked the question I asked in order to determine if dogma1138 held the opinion that * "URL's are not implicitly intended to be shared outside of the scope of your application" [0], and therefore any sensitive information in them is 100% okay, because -in his world- noone ever shares hard-to-read URLs anyway or * URLs can have potentially disastrously sensitive information in them, as long as it's not username and password or some other opinion. In short, this was an information-gathering question designed to test the bounds of a hypothesis that I was forming, but did not yet have enough information to put any faith into. :) [0] https://news.ycombinator.com/item?id=10467919 https://news.ycombinator.com/item?id=10467919
kps 11y ago
> Your search history is already visible to anyone sniffing your traffic http://google.com/ http://google.com/ normally redirects to https. It's possible to access Google over HTTP, but it's not typical.
leni536 11y ago
> Putting your password in plaintext is unacceptable because exposes it to anyone who may be sniffing your traffic. I thought query strings are encrypted in a https request.