Live data from Hacker News

I’ve banned query strings

chrismorgan.info

281–290 of 317 posts

Re: I’ve banned query strings

#281
post #272

Earlier quoted context omitted.

> this should be sufficient to represent the file. Except it's not, because the oid can be a short hash ( https://github.com/gritzko/beagle/blob/a7e172/VERBS.md ) and that means you're at risk of colliding with every other top-level entry in the repository, so you're restricting the naming of those toplevel entries, for no reason. So namespacing git object lookups is perfectly sensible, and doing so with the type you…

how does adding the word blob in the url help with that? i don't think it makes a difference here. in fact compare these urls: https://github.com/gritzko/beagle/blob/a7e172/VERBS.md https://github.com/gritzko/beagle/raw/a7e172/VERBS.md https://github.com/gritzko/beagle/commit/a7e172/VERBS.md turns out that "blob", "raw" and "commit" have nothing to do with the hash itself, but are functions to describe how the object…

> how does adding the word blob in the url help with that? i don't think it makes a difference here.

How does adding a disambiguating segment help disambiguate?

"in fact, consider these urls":

https://github.com/gritzko/beagle/issues

https://github.com/gritzko/beagle/pulse

> are functions to describe how the object in question is to be presented

So they are functions, which take parameters, which makes prefix notation reasonably natural?

> the problem is rather that it is in a weird place. it should be at the end

That's, like, your opinion man.

> except i think putting it at the end makes handling relative paths more difficult as it would have to be appended to every link to other files.

It also doesn't make sense when file paths may not be relevant at all e.g. compare

https://github.com/gritzko/beagle/commit/a7e172

and

https://github.com/gritzko/beagle/commit/a7e172/VERBS.md

As well as where https://github.com/gritzko/beagle/blob/a7e172/ ends up

> the roxen webserver has an interesting solution for that. they call it prestates and it's placed at the beginning of a url: https://github.com/(commit)/gritzko/beagle/a7e172/VERBS.md .

> When developing and debugging is a great help to be able to turn on and off specific parts of the code that generates the current page.

That doesn't have anything to do with what github does.

Re: I’ve banned query strings

#283
I dislike the trend among computer users that query strings == tracking data. They're just one of the many ways a browser request can contain data. They are used for all sorts of things in perfectly valid websites, and it's difficult for me as a developer to just just arbitrarily accept that a certain feature HAS to be used for a certain malicious technique, despite it being common.

With more limited copy-paste functionality, tracking parameters could just as easily be put in the request body. Or a cookie/session data. Or, if you're nasty, you could get everything you want to know out of a user via fingerprinting with very little up-front data at all.

We as users have basically already been collectively pwned, the solution being to use VPNs, anti-tracking scripts/extensions, encryption, and just plain ol 'stop using services that track you'. The preceding are all leagues better for one's privacy than superstitiously chopping up a URL.

Honestly, disallowing other websites from from adding their query strings to your URLs I think is awesome, and I think it makes sense that websites should validate their URLs against their internal APIs only. But, given this was only done for query strings, and not other parts of the request, I still feel like this whole thing establishes more of a taboo than an actual security or privacy guideline.

Re: I’ve banned query strings

#285

Earlier quoted context omitted.

But you see that anyway from access.log or whatever your server supports and dashboard/analytics shows it anyway? What's the benefit of adding origin to query string?

Not always. Some web pages don't send referrers by making all links rel="noreferrer". Mastodon used to do this by default, though now they've changed their stance. Links opened from non-browser apps don't have any referrer information either. E.g. if somebody shares your link on iMessage, WhatsApp, or Telegram. Email clients may also strip out referrers, but I'm not entirely sure about this one. If people read your w…

I see where (both of you) are coming from, and I'm very privacy conscious (=paranoid) myself, but in this case, as a user, I wouldn't actually mind. It seems to me you would be tracking flows instead of users, which is fine in my book. Now, including Google fonts on every page, using their tag manager, analytics, captcha... That gives me the creeps. Waaay too much information about each and every user. But generic origin query params? Yeah, ok. :shrug:

Re: I’ve banned query strings

#287

Earlier quoted context omitted.

Indeed, that's not a query string! The #, and following text, is a fragment , is client-side only, and isn't the subject of the blogpost. Neither is percent encoding, which is just another way to send the exact same path from your browser to the server. Note that it has nothing to do with the length of the URL. That's just the error message he's chosen to use, because "4xx stop pissing about with my URLs" doesn't exi…

> percent encoding, which is just another way to send the exact same path This is not true for all characters. Some can only be expressed by percent-encoding, and decoding them will either break things completely (e.g. %20) or change the meaning of the URL (e.g. %2F, %3F in paths). Yes, you can encode x as %78 and it should work identically, and you can decode %78 to x and it should work identically—though in both ca…

Indeed, it's essential in some cases. I was talking about in the context of sutterd's suggestion, where just lower-case letters have been encoded.

> strong case for blocking the request as suspicious

Yep, as there shouldn't be any "normal" reason to do such a thing.

Re: I’ve banned query strings

#289

Earlier quoted context omitted.

Yeah, URLs really don’t have much in the way of semantics. Path is clearly intended for hierarchical data and query for non-hierarchical data, and there are strong customs, some commonly supported or even enforced by libraries, but no actual rules. Ultimately, it’s just a string that the server can decide what to do with. The really funny thing about this is that, when I was worrying about possible side effects if I…

Wikipedia web server treats anything after /wiki/ literally as the name of the article. So en.wikipedia.org/wiki/// is the article about C++ style comments

it looks like it goes to a disambiguation page for what "//" could refer to now (C++ style comments being the top entry), but that's delightful!

Re: I’ve banned query strings

#290

Earlier quoted context omitted.

I understand being for privacy, but on the flip side, information about you can result in a better experience. E.g. in the case of tracking where a person comes from, that can help those two websites improve by coordinating with each other in some way. Or your ads might actually show you something you didn't know you existed that you end up buying. That's probably better than seeing ads you likely have zero interest…

Textbook marketing speak: “Don't you want more relevant ads?”. It assumes that “ads” = useful information, but that's rare at best. Most ads focus on stealing your attention and creating a fear of missing out. NordVPN isn't educating you. They just manufacture a need and then hope that you won't invest time in researching a better option. Why would I give them more leverage to do that?

Is it that rare? Sure, there's no advertising profile for "hates VPN ads" but eg an adult male doesn't want ads for women's period pain medication and similarly an adult woman doesn't want ads for male testosterone or other male-coded enhancements ads. Then you get into niche interests like fishing or sewing or 3d printing.
Post reply on HN