In the 1940s it was common for studios to own movie theaters, but the Supreme Court ruled that this violated antitrust laws and forced them to sell off their theaters.
To me it's the same situation again, but now the theaters (streaming platforms) owning the studios.
Sadly the era of government that split up studios and theaters is long gone. Hollywood is built on a different time between things like this and its flavor of unions that cover the biggest players in the industry.
Closest thing we have to a Hollywood today is games, but game makers can also make consoles and industry wide unions would never happen. Is there some unionization in games? Yeah, but I haven't heard of any single one that cover a significant number of different studios
The tone of this and Chris's post gives me the impression that it's harmful to include these query parameters, but I don't understand how. Could someone elucidate me? I understand it can mangle some URLs and that's good enough reason not do it, but even then it seems like a minor incovenience.
The technical purist: you’re modifying a URL in a way that, while in line with accepted custom, is technically incorrect. URLs should (the least effective type of should) basically be treated as opaque.
Social: it’s tracking stuff, sibling comment trees are good, I won’t reiterate.
Clutter: it’s getting in the way of the bit you should care about, and contributing to normal people no longer caring about URLs because they’re too hard, too complex.
There are a lot of reasons I might not want a site to know where I came from to get to their site. It is basically sharing your browsing history with the site you are visiting.
Because of this, there have been a lot of updates to the http referer header, with restrictions on when it is sent, and an ability to opt out of the feature entirely.
Adding a url parameter with the same information bypasses any of these existing rules and ability to opt out. They should just use the standard.
If I release a video and send an email newsletter at the same time, which one caused the traffic increase? Should I invest in making more videos of sending more emails?
If you insist on knowing, include a different url in both that goes to the same place and use your damn server logs. You don’t need google analytics and whatever.
presumably you control the urls you are sending in the email. As a result if you want to use query strings that's fine. The issue only arises when you use query strings to implement tracking on someone else's site instead.
Oh, I have a couple - the users did not agree on being tracked (these query params are tracking information), and the site administrator does not want incoming traffic to be tracked. I know the latter can be hard to understand, but I for example sure as hell do not want to have any info in my logs that can be used to harm my users.
On a more personal note, I hate it when I go to copy a link to send via a message, and the tracking code glued onto it is twice as long as original URL... I either have to fiddle around with it to clean it up or leave the person I sent it to to wonder wtf am I on about with a screenful of random characters...
So it's violating users' privacy, it's shit UX, and on top of that, nobody asked for it...
Query strings are useful for way more than just tracking. Saving and servicing search queries is a way more common use case. So assuming it's only useful for tracking is very misleading.
Query strings are probably the least invasive tracking. They are transparent, obvious, and anonymous. Users are free to strip out and edit query strings if they don't want them.
More to the point, I can essentially do the same thing with HTTP routing - create an infinite number of unique URLs for tracking purposes. In that regard calling out query strings specifically for essentially the same thing but more transparently seems like splitting hairs.
Yeah I do not see an alternative way to easily copy paste links with things like filter settings saved.
Filters especially make sense as query params as they are non sequential but still visually readable as to what they do.
URL slugs make sense for sequential pages that are hierarchical but make no sense for non hierarchical data/routes.
Services can force tracking into links by encoding the whole url into a shortlink that makes it impossible to just remove the tracking alone as everything is encoded into a shorter non editable string.
> Query strings are probably the least invasive tracking. They are transparent, obvious, and anonymous.
They're not necessarily anonymous. utm=Google.com is, but s=abcdefg, where abcdefg is a hash of the specific user that generated that link, identifies to the site the specific user the link was shared from.
Thank you for explaining to me that query parameters can be used for other purposes apart from tracking. The articles in question though, are railing against query parameters being abused for tracking purposes - passing referers (sic) and UTM by adding them to URLs of sites that neither process them, nor want them.
Referral query strings are not for tracking though. The person putting them on the links gets nothing out of them. There is no PII being shared. They are purely added out of courtesy.
If I am handing out maps to your address, letting people know who is publishing the map is generally a good thing.
This is like saying having a return to sender address on mail is an invasion of privacy.
What's interesting is that none of these sites have a "search" feature. Which is an important accessibility feature and a clear and legitimate use case for a query string.
> The difference between 75 (usually a beautiful day) and 85 (hot) is 23.8C to 29.4C.
If you convert a nice, round number from one system to the other, you'll end up with a more precise, less nice number, which will give the impression that Celsius is harder to use.
In reality, people from metric countries just think in 5-degree increments: 25 is a beautiful day, 30 is hot. It doesn't feel any harder to read than Fahrenheit.
I wonder if there are people that moved to the U.S., switched to Fahrenheit and now find it more intuitive than Celsius. If one is easier than the other, I assume it still doesn't make up for the hurdle of learning a new system.
> I wonder if there are people that moved to the U.S., switched to Fahrenheit and now find it more intuitive than Celsius.
I've done the move twice in each direction. Neither is more intuitive.
When I moved back to C after 22 years in F, I had to adjust again. It took a few months. The other times were after fewer years, but still took (re)adjusting.
For purposes of backup I don't see that large of a difference between a single installer executable and a zipped folder that you'd get after installing a non DRMed game from Steam.
GOG has allowed third party backup software like https://github.com/Sude-/lgogdownloader to exist. I have a full offline mirror of my GOG library that I update monthly that will never happen with my Steam library.
The non-DRMed steam game will stop working after a while if you haven't logged into steam after a very long time. If steam ever went under, your locally installed single player games that work offline will stop working. Ask me how I know.
I've taken to getting a cracked copy of every steam game in my library so that steam can't screw me over again in the future.
Off the top of my head: going in-person to the bank, email, phone call or sms to a number that you previously informed to the bank (say when opening the account), otp a la authy or aegis. None of these require you to be on google or apple's walled garden.
> Since 2020, the rate of bank branch closures in the U.S. has doubled. The majority of those closures come from large and very large banks, contributing to an overall 5.6% decline in total bank branches nationwide since the start of the pandemic.
Nor did GGP's approach require them to be in google or apple's walled garden.
That's exactly the point: there's an easy and common method that many people choose to use, but there is still a perfectly working method for people who choose to not use apple or google.
the part you are missing is that this is the situation for now. Emphasis on for now. Google are already moving to restrict what software your phone can run i.e. they control your device.
Please, don't be so obtuse just for the sake of argument. Any rational, well-informed person can wee where this is going.
I think the upthread argument is the weak one in that regard. "See how terrible it is that banks offer a new method to get more convenient service for people who have an Apple or Google device? Because I choose not to, I had to use a perfectly viable method that people relied upon for decades and that still worked just fine."
That's an example of how the banks are continuing to accommodate customer preference, not the other way around. As to "where this is going", ATMs and debit cards are nearly pervasive and, yet almost 60 years after their introduction, I can still choose to bank with a teller if I insist on not having a debit card.
Do you mind elaborating why a db partitioned like that is not enough for your registration example? If the partitioning is based on the email address, then you know where the new user's email has to be if exists, you don't need to query all partitions.
For example, following your partitioning logic, if the user registers as john.smith@example.com, we'd need to query only partition j.
You're right, the email address example isn't clearcut -- its not an issue at all at registration. From there, you could never allow an email change. Or you could just add a layer for coordination, ex. we can imagine some global index that's only used for email changes and then somehow coordinates the partition change
My broad understanding is that you can always "patch" or "work around" any single objection to partitioning or sharding—like using extra coordination services, adding more layers, or creating special-case code.
But each of these patches adds complexity, reduces flexibility, and constrains your ability to cleanly refactor or adapt later. Sure, partitioning email addresses might neatly solve registration checks initially, but then email changes require extra complexity (such as maintaining global indices and coordinating between partitions).
In other words, the real issue isn't that partitioning fails in a single obvious way—it usually doesn’t—but rather that global state always emerges somewhere, inevitably. You can try to bury this inevitability with clever workarounds and layers, but eventually you find yourself buried under a mountain of complexity.
At some point, the question becomes: are we building complexity to solve genuine problems, or just to preserve the appearance that we're fully partitioned?
(My visceral objection to it is, coming from client-side dev virtually my entire career: if you don't need global state, why do you have the server at all? Just give use a .sqlite for my account, and store it for me on S3 for retrieval at will. And if you do need global state...odds are you or a nearby experienced engineer has Seen Some Shit, i.e. the horror that arises in a codebase worked on over years, doubling down on an seemingly small, innocuous, initial decision. and knows it'll never just be one neat design decision or patch)
Check the other partition for the user name. Create the new user with the same pointer (uuid, etc) to the user’s sqlite file, delete the old user in the other partition. Simple user name changed. Not really that complex to be honest. (After thinking this through I’m probably going to suggest us changing to sqlite at work…)
> if you don't need global state, why do you have the server at all?
2 reasons I can think of right off of the top of my head are:
- validation (preventing bad actors, or just bad input)
> Sampling uniformly such that each distance is equally likely across the line gives at least a 90% chance of choosing a rational.
Let's say the numbers are targets on the line. Your distribution implies the range 1-9 is less dense with targets than the range 9-10. Doesn't that mean you're less than 90% likely to hit something between 1-9?
> You are NOT more likely to throw a dart that lands in 9+ just because you have magically introduced an infinitely tense series of irrationals in that range.
If we turn this around, by forbidding a bunch of values in the 1-9 range from being hit, then won't the probabilities get skewed towards the 9-10 range?
No, because a dart throw is not a uniform draw from set elements. Is a uniform draw of length which the inclusion of irrational numbers does not affect. You are 90% likely to throw something in the first 90% of the line. It doesn’t matter if we say we will round anything in [1,2) to 1. There’s a ten percent chance of falling in that range.
Not a 0% chance because there happens to be an uncountable infinity number of options in [9,10)
To me it's the same situation again, but now the theaters (streaming platforms) owning the studios.
https://en.wikipedia.org/wiki/United_States_v._Paramount_Pic....