Comment by dogma1138 | Hacker News Reader

Comment by dogma1138 | Hacker News Reader

Parent Full thread

> This is incredibly silly. URLs are how you get to a page. It's how The Web works!

That's a very general and simplistic view of things, and we both know it's not true. While URL's were designed originally to only provide an address for a specific resource we all know they are also used for storage, user state management and many other things, again not ideal but in some cases unavoidable.

Not to mention that URL's are not implicitly intended to be shared outside of the scope of your application you wouldn't link the 3 mile long URL that you get every time you login into your bank account would you?

> That's what the History API is for. When you add an anchor-tag query, store the original state in the tab's history.

Technically (best kind of not true) not true for the Google History API and even if it would be applicable for this it doesn't work in cases where you for example weren't signed in or explicitly blocking google tracking API's and services.

Not to mention that making a API call every time you need to do something as basic as backtracking on your search is just pure insanity when it comes to resourcing.

And if you are talking about the Chrome Page History API then why in god's name would i want a site to access it, not to mention it's not applicable in this case either.

> Infoleaks are BAD. The least Google could do is use their URL rewriting powers to remove the original query when they add a query stored in the anchor-tag. Life is bad, if this was in a link which was automatically shared (although all those pin URL generators link 10 fold more data than Google) I would agree with you, otherwise not really this isn't a use case for the application.

> ...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.

>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/+/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.

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

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.

> 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

    > Your search history is already visible to anyone sniffing your traffic

http://google.com/ normally redirects to https. It's possible to access Google over HTTP, but it's not typical.

> 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.

> in some cases unavoidable

That something is sometimes true is not an argument why it automatically is true in a particular case.

That's what google gives me by default:

https://www.google.com/search?q=bill+hicks+about+marketing&i...

Yet removing the crap works perfectly fine, so how is having that crap unavoidable?

https://www.google.com/search?q=bill+hicks+about+marketing

https://www.google.com/search?q=bill+hicks+about+marketing&s...

In contrast, out of the gate:

https://duckduckgo.com/?q=show+me+some+sanity&ia=definition

It's a pity it redirects to add "&ia=definition", but it's nearly pretty. And if this didn't blow your mind yet, if you right-click a search result to copy the URL, you get the actual URL with DDG, not an abomination of an URL that redirects you via Google to the URL you thought you copied (and which, to add insult to injury, gets masked when hovering over the link in the status bar, like a malware page might do it).

Sure, that's "unavoidable" if you want to track more stuff, but wanting to track more stuff in itself is not unavoidable. It'a choice.

> Not to mention that making a API call every time you need to do something as basic as backtracking on your search is just pure insanity when it comes to resourcing.

That's exactly what Google does though. It would be perfectly possible to let stuff be cached in the browser at least for a few minutes, but there is always requests being made. They throw away those user and server resources to track hits. It's a bit like YouTube used to buffer and allow skipping back and forth without having to load one more byte, and now doesn't. There's ads to display and usage statistics to gather. Which you might argue they need that to "improve their product", but I think looking at, thinking about and using a product can get you a long way, too. If you need to see how real people use it, pay them to use it while you record them. Yeah, I know, it would ruin everything and we'd be left with Pong, right? Baby food manufacturers could also improve their products if they could experiment on thousands of babies without any restrictions, and I bet if that was the norm, any reform would be met with visions of doom about toxic baby food.

Right now, nothing companies like Facebook, Google, Apple and Microsoft could invent would be nearly as cool as a simple, efficient web with users educating other users how to use it responsibly. If the web was plumbing, we'd be looking at people making all sorts of weirdly shaped pipes out of fancy materials, and people would sell their plumbing skills by talking about their religion and family, instead of time and materials needed, and capacity and stability of the result. We're still at the level of people burying slaves at the foot of a new aqueduct, and I can't wait until this hysterical gold rush is a mere footnote in the history of an actual information age. Right now we live in the marketing age, and the mediocrity is a direct result IMO.

Reply on news.ycombinator.com