Hacker News Reader

Comment by lolc | Hacker News Reader

So they're modifying URL? Facebook is breaking things. But sure, they've run the numbers and decided they don't care.

Browsers will now have to resort to removing query parameters to prevent tracking. And websites should really use click-to-enable sharing buttons to prevent Facebook from snooping on everything.

View on HN

My guesstimate is that the number of URLs that are shared on Facebook AND that already have a completely orthogonal "fbclid" parameter is infinitesimal.

Maybe among the URLs shared on Facebook there are a few whose servers only respond to a fixed amount of parameters, changing their behaviour when additional unused parameters are appended to the query string, but I imagine that the number of such cases is so low it's not even worth considering.

What exactly is Facebook breaking, in your opinion?

Would Facebook also break things if they were instead making an async request to the destination and appending a custom header to it, something like "X-Coming-From-Facebook"?

> What exactly is Facebook breaking, in your opinion? > > Would Facebook also break things if they were instead making an async request to the destination and appending a custom header to it, something like "X-Coming-From-Facebook"?

Extra headers are typically ignored, not only since different clients send different headers since the beginning.

I know multiple systems which however decode the query string and complain about unknown options or don't accept a query string at all for some resources. On the later case it is ignorance on the other case it is intensive input validation.

This is the reason why Google Analytics can be configured to read marketing parameters out of the hash fragment instead of the query string. A surprising number of sites will choke when unexpected data shows up in either the query string or the hash fragment, but very few will choke on both (most sites that mishandle query parameters are from an era before rich use of fragments became common).

Notably, most links with GA marketing parameters are under the control of the website owner. Facebook links are not. This makes such a work-around less feasible.

It breaks some server-side caches. And the article itself notes that pages were indexed by Google with the "fbclid" parameter attached.

I don't get the part about async requests. What's the scenario?

I've seen a broken link from this url parameter already.

I understand being upset about the tracking aspect, but attaching query params to a link isn't breaking anything. Of all the ways Facebook could have implemented something like this, I actually prefer it this way. Query params are easy for me and other adblockers to strip off. Imagine if they were messing with request headers or something that was harder to notice or change.

An incredibly small number of sites might already be using `fbclid` internally, and an even smaller number won't be able to update their sites.

I am totally on board the don't-break-the-web train, but this just doesn't seem like a problem to me. Maybe once stats come out we'll see that it's a bigger issue, but... I kinda doubt it.

I got caught this weekend where I linked an image on Facebook, and it generated the preview properly but the link is broken because the host 404's with the added fbclid parameter.

I entered: https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg

Facebook made: https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg?fbclid=IwAR2...

So sure, there may be an argument that the server should ignore that param. But it's absolutely false to say it "isn't breaking anything".

I guess this makes sense. The request contained something the server didn't understand, and wasn't expecting, so returning a 404 seems sane.

After all, as a developer, it's my site - I choose the URLs (including the query strings) which are valid and acceptable to me.

I wonder how many sites other than Twitter are rejecting requests with unknown query parameters?

Huh. That is very surprising to me, but I stand very corrected.

I would consider it to be pretty bad practice to treat query params this way, extra query params should be ignored. However, web standards are descriptive, not prescriptive. If enough sites have strict requirements about the number of query params, then it doesn't really matter what good practice is, and Facebook should accommodate this by moving back to cookies or at least make it opt-in or something.

Facebook can't set arbitrary request headers easily. That would require messing with how the user-agent retrieves things. Cookies are the chosen way servers can set client request headers. So the tracking-information is passed by a cookie. Now since browsers are starting to be selective about cookies, Facebook becomes inventive.

Adding a request parameter absolutely will break things. And they knew this. The only question was what's worse: Not being able to track some people or breaking some of their links. Facebook decided the former is more important to them and their customers.

And even if nothing else brakes, uglifying the URL people are posting is in itself an anti-feature.

I'm less worried about uglifying URLs, and more about the 404 stuff that a few other people have posted about now. It never occurred to me that there'd be more than an extremely minimal number of sites that would error out when receiving extra query params.

That's a new one for me, I need to make sure I remember it in the future. From what I'm seeing online, it's not even necessarily considered bad practice, so... I dunno anymore.

But agreed, Facebook should back this out.

Try going to a Pizzeria and say "Pizza Margherita, with extra Zejeako please". Should they just give you a Pizza Margherita because they don't know what Zejeako is? Or should they tell you they can't do it?

> Facebook should back this out.

They won't. They knew what would happen and did it anyway.

Reply on news.ycombinator.com