The $100 tab paid in dimes causes severe inconvenience to the person trying to count them and to the person who has to take them to the bank to cash them in and wait for them to be counted again.
Their very reasonable question was: if you can't distinguish the reverse engineered traffic from the traffic through your own app in order to block it, then what harm is the traffic doing? Presumably it's flying under your rate limits, and the traffic has a valid session token from a real customer. If you're unable to single it out and return a 4xx, why does it matter where it's coming from?
I can think of a few reasons it might, but I'm not particularly sympathetic to them. They generally boil down to "I won't be able to use my app to manipulate the user into taking actions they'd otherwise not take."
I'd be interested to hear if there are better reasons.
"if you can't distinguish the reverse engineered traffic from the traffic through your own app in order to block it, then what harm is the traffic doing?"
If you really believe this you'll use a custom user agent instead of spoofing Chrome. :-)
Some websites use HTTP referer to block traffic. Ask yourself if any reverse engineer would be stopped by what is obviously the website telling you not to access an endpoint.
I'll add that end users don't have complete information about the website. They can't know how many resources a website has to deal to reverse engineering (webmasters can't just play cat and mouse with you just because you're wasting their money) nor do they know the cost of an endpoint. I mean, most tech inclined use ad blockers when it's obvious 90% of the websites pay the cost of their endpoints by showing ads, so I doubt they would respect anything more subtle than that.
The only reason why "another client" can exist is due to limitations of the Internet itself.
If you could ensure that the web server can only be accessed by your client, you would do that, but there is no way to do this that can't be reverse-engineered.
Essentially your argument is that just because a door is open that means you're allowed to enter inside, and I don't believe that makes any sense.
The argument is that what you call "limitations of the Internet itself" is actually a feature, and an intended one at that. The state of things you're proposing is socially undesirable (and in many cases, anticompetitive). It's hard to extend analogies past this point, because the vision you're describing flies in the face of more fundamental social norms, and history of civilization in general.
It's not a limitation of the internet, it's a fundamental property of communication.
Imagine trying to validate that all letters sent to your company are written by special company-provided typewriters and you would run into the same fundamental limits.
Whenever you design any client/server architecture, the first rule should always be "never trust the client," for that very reason.
Rather than trying to work around that rule, put your effort into ensuring that the system is correct and resilient even in the face of malicious clients.
> If you really believe this you'll use a custom user agent instead of spoofing Chrome. :-)
Read up on the history of User Agent string, and why everyone claims they're Mozilla and "like Gecko". Yes, it's because of all the silly people who, since earliest days of the WWW, tried to change what they serve based on the contents of User-Agent header.
Not the greatest example. If someone has incurred a $100 debt to you, then, from a legal perspective, you must consider delivery of a thousand dimes as having paid the debt. You don't get a choice on that without prior contractual agreement.
I think it's the greatest example because it's something you're technically allowed to do but that you obviously shouldn't do because you're wasting other people's resources.
This is not an accurate reading of the code. Snopes quotes an FAQ on the US Treasury site (now missing, but presumably still correct) [0]:
> Q: I thought that United States currency was legal tender for all debts. Some businesses or governmental agencies say that they will only accept checks, money orders or credit cards as payment, and others will only accept currency notes in denominations of $20 or smaller. Isn't this illegal?
> A: The pertinent portion of law that applies to your question is the Coinage Act of 1965, specifically Section 31 U.S.C. 5103, entitled "Legal tender," which states: "United States coins and currency (including Federal reserve notes and circulating notes of Federal reserve banks and national banks) are legal tender for all debts, public charges, taxes, and dues."
> This statute means that all United States money as identified above are a valid and legal offer of payment for debts when tendered to a creditor. There is, however, no Federal statute mandating that a private business, a person or an organization must accept currency or coins as for payment for goods and/or services. Private businesses are free to develop their own policies on whether or not to accept cash unless there is a State law which says otherwise. For example, a bus line may prohibit payment of fares in pennies or dollar bills. In addition, movie theaters, convenience stores and gas stations may refuse to accept large denomination currency (usually notes above $20) as a matter of policy.
I specifically said "incurred a ... debt" and "without prior... agreement". As your source says
> In short, when a debt has been incurred by one party to another, and the parties have agreed that cash is to be the medium of exchange, then legal tender must be accepted if it is proffered in satisfaction of that debt.
You are correct that if cash is not accepted at all, or if payment is to happen ahead of the exchange of goods or services, you are not obligated to accept arbitrary cash.
No, your claim is backwards—if the parties have agreed that dimes are valid payment of debt then that agreement must be upheld. Absent a prior agreement to accept dimes, the party receiving the money may refuse any combination of currency that they see fit.
In other words, an agreement isn't required in order to refuse legal tender, an agreement would be required to make it mandatory.
A court might decide that an agreement to accept cash without specifying in what form was meant to include dimes, but I see no evidence anywhere that a court has to rule that way if the contextual evidence suggests something else was probably meant.
"legal tender" is a term of art that specifically means a creditor must accept it, and your big quote clearly supported this, discussing only the common misconception that legal tender means it can't be refused in an offer to purchase. You are arguing backwards yourself.
The law says that coinage is valid legal tender for an offer to settle a debt but the counterparty is not required to accept it... unless they contractually agreed to do so.
Only the U.S. government is required to accept payment in coins. Many states also require their agencies to accept payment in coinage but some have laws limiting the size of debts that can be paid this way.
That link is, again, about the difference between offers to purchase and offers to settle debts.
Think logically about this. What do you think legal tender even means otherwise? Why would you need a special term to denote a form of payment that a creditor can accept if they want to? I could accept settlement in jelly beans if I wanted to. The entire point is that you must accept legal tender, that is what makes it different from everything else.
Not the greatest example. If someone has incurred a $100 debt to you, then, from a legal perspective, you must consider delivery of a thousand dimes as having paid the debt. You don't get a choice on that without prior contractual agreement.
I love Python but it always amazes me how hard it is for it to just... work.
So there is virtualenv, built in, but... if there is a venv directory, Python doesn't just use it.
Like you have app.py, and you python app.py, that doesn't run it with the venv python. This leads to all sorts of problems with scripts that assume they're running under venv. Which means you probably want to write a script that sources venv just so you don't forget, but if you place it in the same directory you may forget you need to call the script, so you probably want to add an extra directory to hide all the python code so you only see the shell script that you need to run to properly setup the environment to run the python code. Or just use an IDE.
Just "pip install." But pip isn't installed and ensure pip doesn't work? What do I even do then?
I recall downloading a project that required a library that wasn't available for the newest version of python, so when you tried to install the requirements pip wouldn't find it. I discovered this, naturally, because I updated my operating system so the python version changed which means the project that used to work stopped working! What is the solution for installing multiple python versions side by side? Hint: it's not an official project by the Python organization but something you can find on github.
My recent workflow is to use a great program called mise. You have a config file in your directory and hey presto, python venvs work, they install themselves if they don't already exist, and it will install the exact version of python you specify in your config. On top of that is will set environment variables for you and unload them when you change directory. If you combine this with uv (just tell mise you want uv installed in the config) you can run uv pip sync and instantly reflect any changes in your requirements file directly into your venv very quickly.
> Absolutely no headaches working on dozens of local python projects.
The other day, I moved over to a new container base image that's supposed to run Ansible inside of it. Almost immediately, when trying to manage a RHEL8 compatible host, I got this error: https://github.com/ansible/ansible/issues/82068
I've had issues not only with Python projects that I write, but also with software that's relying on it. Then again, while there are both problems and ways around those, my experience has been similar with pretty much every tech stack out there: from Java apps that refuse to run on anything newer than JDK 8 (good luck updating dozens of Spring dependencies across approx. half a million lines of code in a codebase that's like a decade old), to hopelessly outdated PHP versions or software that works on ancient Yarn versions but not on newer ones and doesn't even build correctly when you move over to Node with npm or software that's stuck on old Gulp versions. Same for Ruby and Rails versions that will run, or .NET and ASP.NET codebases, where the framework code ends up being tightly coupled to the business logic, don't even get me started on front ends that rely on Angular (or AngularJS), Vue (2 to 3 migrations) or React. I've had Debian updates break GRUB, AMD video drivers for the iGPU on the 200GE preventing it from booting, differences between Oracle JDK and OpenJDK having a 10x impact on performance, Nextcloud updates corrupting the install, the same happening with GitLab installs, just a day ago I had a PostgreSQL instance refuse to start up with: PANIC: could not locate a valid checkpoint record. PostgreSQL, of all software.
Sometimes churn feels unavoidable if you don't want code to rot and basically everything is brittle. All software kind of sucks, sometimes certain qualities just suck a bit more than the average. Containers and various version management tools make it suck a bit less, though!
I think the basic text widget of all the toolkit support text attributes (color, styles,…) and as the solutions for syntax highlighting and other stuff existed already, it was not a big stretch to add them instead of having two editors (the first user was the programmer)
I had access to the Internet. The whole thing was in English! Can you believe it? I had no choice but to learn English.
In hindsight, I'd say the most important for learning English was that I was an ignorant teenager. I just... typed completely broken sentences into forums that today I wouldn't even be able to fathom how could I get the grammar so wrong. I got banned several times from Freenode channels, for pestering people with unintelligible questions and then not being able to understand the answers.
I was unaware and shameless and that shamelessness allowed me to make progress. Were I to learn English today, I'd probably be too self-aware to embarrass myself trying to use a language I can't use, and that would make it far more difficult to learn anything.
I suppose that's a good life lesson in general. You can't get good at something without being embarrassingly bad at it at first. If there was a pill to make you unaware of your own embarrassing self, that would be a learning pill. In fact, I guess we should really be learning new things while drunk!
As far as I'm aware, federation tends to be opposite to privacy because there can't be centralized control of access. e.g. none of the federated social media support private profiles but Instagram does, so Instagram is actually more private than most of these.
"Privacy" here means "no big tech will be tracking me and trying to shove ads down users' throats", not that the published content is protected from public view.
I genuinely don't understand this perspective of privacy. I think it's a dishonest use of the word.
For example, in Bluesky, which users you blocked is public information.
To me, this sounds like a bigger "privacy" issue than "the ad company figured out you're a man who lives near the beach so you get ads about surfboards."
Privacy is about control of your data. Control requires centralization. How come people think decentralization is good for privacy? This is a very narrow definition of privacy that doesn't matter for most people.
You don't have control over your data, but Facebook does at least, so long as you trust Facebook, it's fine.
Keyword: TRUST.
Decentralization is often paired with trustlessness, and that's where things fall apart. The average person isn't a paranoid cybersecurity expert. They will trust on services evem if those services' whole mantra is "trust nobody, even us."
In essence, with Facebook, you are knowingly transferring control of your data to Facebook. With decentralized social media, you completely let go of any control and there is nobody to take over it.
Most people won't understand that nobody will have control of the data. They'll think they can just ask Mastodon staff to delete a post from an instance across the globe after they pressed the delete button and for some reason it didn't completely disappear from every instance.
I'm afraid all the privacy problems of decentralization didn't manifest yet because almost nobody is using it to begin with. If more people start to use it, it's going to be obvious we're only trading one privacy violation by another.
> You don't have control over your data. (...) as long as you trust Facebook
You just lost any right to complain over people misusing words.
> With decentralized social media, you completely let go of any control and there is nobody to take over it.
Quite the opposite. Decentralized social media allows you to be in control if you so desire.
> I'm afraid all the privacy problems of decentralization .
You were arguing that centralized systems are inherently more private. This is absolute and utter bullshit.
Is the "real privacy" story weak on federated social media? Yes, currently it is. But to have a "real private" communication platform, control MUST be given to the end user, which in effect means that the system MUST be decentralized.
No e-mail/phone number requirement. New uploaders must be vetted by moderators/quarantined. No video support. Use AI to detect if something is a meme then shadowban the post. Design must look like https://www.fotki.com/
Well, I was asked what I would do, and what I would do is...
Instead of supporting videos and memes and trying to compete with Facebook, Instagram, TikTok, Twitter, Tumblr, Bluesky, Mastodon, Reddit and EVEN IMGUR
I'd focus on images and then my only competitor would be Pinterest, and I wouldn't have to deal with all the complexity that comes with supporting video.
Just because you're right doesn't mean you aren't wrong.