Comment by danso | Hacker News Reader

Comment by danso | Hacker News Reader

I've noticed this before as everytime I copy-paste a search URL, I manually delete the parameters as even the non-readable ones probably contain some metadata about me.

Yeah, it'd be nice if Google search pages came with a handy "Link to this" button as Google Maps and Google Books do...but in reality, that would raise even more issues. If I understand Google's search mechanism...the results are tailored to each user...my search for "burger place" is going to be much different than someone doing it in New York. Yet if I see a "Link to this" button -- especially if it's a link shortener -- then I would expect it to direct all users to results that I've seen. OK, I don't expect that...but I bet 99% of other users do.

So it's not a clearcut decision about whether such a feature should exist, given the ephemeralness and personalization of SERP. So given that it's not an intended common use case to pass around URLs to results...what is it that Google should do to fix this? Re-engineer their system so that every URL is a non-human-readable URL that obfuscates all possible metadata? Remove the ability to tailor search results based on past results of that same session? I can see why they might choose: "If a user wants to send around a URL by manually copying and pasting it, we should trust them to read it before they send it out as the relevant parameters are human readable"

I suspect it's someone being clever.

I think doing subsequent searches as a "#q=x" change to the URL lets them avoid reloading the page and use clever javascript to replace the results.

A friend of mine says that the only part of the URL you can change on older browsers and not refresh the page is the anchor-tag part.

OTOH, if you only put search params in the anchor-tag part, the initial search is much slower on slow connections.

Still, infoleaks are BAD. Page load and update speed shouldn't come before safety of a user's private information.

Strange to cite a "friend" when stating a basic fact about how web browsing works.

Two things:

1) I'm not a web dev, I'm a backend and networking guy.

2) Given that -AIUI- any non-host, non-scheme, or non-path part of the URL can be programatically altered in a newer browser without triggering a page reload, I don't see how one can call the behavior a "basic fact about how web browsing works". I would call that sort of thing an "implementation detail". :)

Fact-checking is good, but it takes time and it's not always worth the trouble. I'd rather see someone use an honest qualifier than either claim certainty they don't have, or not post at all.

> [What should] Google ... do to fix this? Re-engineer their system so that every URL is a non-human-readable URL that obfuscates all possible metadata?

Remove the non-search-string metadata from the URL?

I mean, it's really a no-brainer.

No, it's not a "no-brainer." Copying and pasting the URL is, AFAIK, not a common use-case for the majority of browser users. I'm reminded that right now as I type this in Safari, which some time ago made the decision to hide virtually all of the current URL except for the domain name. If you think back a few years farther back, then you remember when URLs and search boxes had different inputs, rather than the omnibox that is now standard feature across the major browsers...which means that the conscious recognition of the URL is even less likely among most users.

Furthermore, the design trend is such that in most consumer-friendly websites, users have been trained/encouraged to share via buttons -- this is something that Google itself explicitly encourages in Google Maps -- again, deemphasizing the fact that URLs are (well, generally) available in the omni-box.

So I think it's a reasonable assumption that users who copy-paste from the omnibox are relatively rare. And those that do do it have something that button-pushers don't: the ability to examine what they've just copied-pasted.

Again, I don't think this is a case of "Oh, but everyone should know better than to blindly do such-and-such", a sentiment that many of us agree is wrongly applied to the hitting "OK" on agreeing to indecipherable TOS screens. But I can see why it's not an obvious design decision given the feature set that Google wants in its search functionality. The more I think about it, the more I think it should be more incumbent upon the user to notice what they of their own volition have decided to send out as text.

How is that different than the expectation required of users who send out screenshots? When I want to screenshot a webpage on my desktop -- even though I intend just to show the webpage, I know not to use the fullscreen-capture option because it will capture lots of metadata, even if the browser page itself is in full screen. Same deal on an iphone, in which screen-capture will leak metadata about you as a user (when the photo was taken and thus, possibly your time zone. And also your carrier) unless you intentionally crop it out before sending. And cropping out photos is very unintuitive on iphones (i.e. it is not easy to do without jumping into a third party application)

> No, it's not a "no-brainer."

This conversation is substantially similar to the conversation we're having over here: https://news.ycombinator.com/item?id=10467855 so, I'll keep the conversation in one thread.

I thought that firefox is a major browser?

Reply on news.ycombinator.com