5 ms·

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 remov

by lolc 8y ago

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.

vntok 8y ago
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"?
- lolc 8y ago
  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?
- johannes1234321 8y ago
  > 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.
  - lmkg 8y ago
    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.
- probdist 8y ago
  I've seen a broken link from this url parameter already.
danShumway 8y ago
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.
- patrickyeon 8y ago
  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 https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg Facebook made: https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg?fbclid=IwAR2MX56GldkA2L5lM94VMK_A420E4FBWsoL7lBlHdtgHs03SpXZQ2rDRUQk 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".
  - kiallmacinnes 8y ago
    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?
  - danShumway 8y ago
    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.

by lolc 8y ago

vntok 8y ago

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"?

lolc 8y ago
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?
johannes1234321 8y ago
> 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.
- lmkg 8y ago
  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.
probdist 8y ago
I've seen a broken link from this url parameter already.

danShumway 8y ago

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.

patrickyeon 8y ago
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 https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg Facebook made: https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg?fbclid=IwAR2MX56GldkA2L5lM94VMK_A420E4FBWsoL7lBlHdtgHs03SpXZQ2rDRUQk 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".
- kiallmacinnes 8y ago
  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?
- danShumway 8y ago
  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.