Yes, tutorials should be expected to teach people about security if it is within their scope. But the problem with the tutorials from the article is that the authors seem to be genuinely unaware of the security issues. That may also be the reason why they are trying to do the impossible, that is teaching web authentication to beginners in a 10 minute blog post format. And then they often get positive feedback because people like simple but wrong answers to difficult problems.
Some time ago I found this video series on YouTube about how to build a PHP application from scratch. Ten hours worth of XSS, CSRF, SQL injection, badly coded authentication, you name it. When confronted, the instructor said that he did not want to confuse the beginners with all of that security stuff. I just thought "ok" and moved on.
Now I went back to this guy's YouTube channel and saw that half a year later he finally did upload a bonus episode on how to mitigate SQL injections. One person in the comment section actually thanked him for the much needed video because their site was getting hacked. It is pretty hilarious to see this unfold but I do feel bad for the ~10k people who watched his videos.
XSS and SQL injection should be impossible by design, by using proper libraries which treat HTML/SQL as structured formats, and use this structure to properly embed text as text, rather than allowing user input to be interpreted as surrounding HTML/SQL constructs. (I suppose parameterized queries are "good enough" even though they treat SQL as a string rather than an AST, because the SQL engine hopefully interpolates the text/numbers/etc. after parsing the query into an AST.)
This gets at the heart of why the problem is so widespread. Beginners are the last people you can expect to figure out how to install and use the “right” library. Watching someone learn programming (from actual nothing) is very insightful - they often don’t stop and think because they have no intuition. Rather they flail in the dark until they land on something that almost works and use that as the kernel of their solution. PHP used to have very poor flail-performance and you still see it in things that are trickier to index and refute like videos.
Maybe the solution here is to just have some kind of legal penalty to losing user data due to incompetence. The problem here is that self taught programmers are going out to the real world and writing code that gets used to process sensitive info without any senior developer guiding them or reviewing.
If there was a penalty to the business, they would stop getting the bottom of the barrel programmer to work on their own. Yes it would make it a little harder to enter the market but any large business could still hire juniors and review their code properly.
In most other industries, you are responsible for your work. Usually you even need a formal certification first.
Conceptually how is this different than someone building a staircase it their house with tools, lumber, and no interest in accessibility and building codes?
This analogy still works. The staircase is not public, its in your house. Which would map to running on your local computer or local network.
As soon as you turn your house in to a public venue (put your code in use for the public) you now have to worry about accessibility and safety. If that stair case collapses because of your dodgy building, you are liable. But you are free to fall off your own staircase in your own house.
So people are free to run whatever they want on their computer. But once you start taking user data, you now have legal responsibility. User data is hazardous waste that needs ultimate care.
Your comment made me laugh because I thought of those ads for the new GardenHoze 2000 when they switch to b/w and show some pretend moron who pretends to not know how garden hoses work and has all kinds of trouble with them. Morons obviously need the GardenHoze 2000 to solve their garden hose problems! You're the pretend moron who pretends to not know how taxes work.
Wow, the voice of reason in the first comment? Am I really on HN? Of course, you are 100% correct. There is nothing stopping one of the big players from offering a more "repairable" product to satisfy all of the supposed demand. Remember, R2R wants to force their ideas upon _everyone_. Doesn't that mean, that there should already be a huge group of people who are willing to buy repairable devices?
Instead of making new laws, R2R should be focused on repealing existing bad laws that hinder competition (patent, copyright, regulation, etc).
none of which will help, because the big companies will just buy up all the competition. and not all regulation hinders competition, anti-monopoly regulation protects competition. and so does right to repair btw, because now i can run a repair business that competes with the manufacturer in fixing their devices.
I find it hard to believe that there is such a thing as a long lasting natural monopoly. The only monopolies that seem to last are the ones that are rooted in state coercion.
Besides that, when I talk about "getting rid of regulation", I of course mean to get rid of barriers to entry. It may be feasible for large companies to set aside a couple of millions for a dedicated compliance department. Small startups do not have those resources.
But even in the current market, as imperfect as it is, there are a countless competing electronics manufacturers. How is it that not a single one of them has started to offer a product line that caters to the "repair" crowd? Maybe that is something that's worth looking into?
well, actually there is at least one: the fairphone. but its product is not competitive enough to be able to attract everyone who is in the repair crowd. that said, it's doing better than the openmoko did, so there is hope. the problem is now that manufacturers need to discover this market and want to compete in it.
As far as there exist unjust laws that prevent people from repairing their devices, by all means, get rid of them (IP laws especially). But by all means, do not add more regulation.
“All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what has regulation ever done for us?”
There are many factors that contribute to appreciation and depreciation. Decay is just one of them. There could be other appreciating factors that outweigh the depreciating ones. Also, if you measure the value of something in a generally depreciating currency, you automatically get rising prices (ceteris paribus).
The bug is that the closure is mutating the same data structure (a Vec in this case) in a different thread - i.e., a data race.
In this specific case, only the spawned thread is mutating the Vec, but the Rust compiler is usually conservative, so it marked this as a bug.
The actual bug is one or both of the following:
1. One of the threads could cause the underlying Vec to reallocate/resize while other threads are accessing it.
2. One of the threads could drop (free) the Vec while other threads are using it.
In Rust, only one thread can “own” a data structure. This is enforced through the Send trait (edit: this is probably wrong, will defer to a Rust expert here).
In addition, you cannot share a mutable reference (pointer) to the same data across threads without synchronization. This is enforced through the Sync trait.
There are two common solutions here:
1. Clone the Vec and pass that to the thread. In other words, each thread gets its own copy of the data.
2. Wrap the Vec in a Mutex and a Arc - your type becomes a Arc<Mutex<Vec<String>>>. You can then clone() the data and pass it to the new thread. Under the hood, this maps to an atomic increment instead of a deep clone of the underlying data like in (1).
The Mutex implements the Sync trait, which allows multiple threads to mutate the data. The Arc (atomic ref count) allows the compiler to guarantee that the Vec is dropped (freed) exactly once.
Since we give manufacturers an artificial monopoly over the ability to provide those parts, schematics, tools, and software, it seems reasonable that we might give them some responsibilities along with that privilege.
It's less about forcing manufacturers to do something, and more about saying to them, "if we give you permission to take away other people's rights and make it a felony for other people to build businesses around flashing firmware on your tractors without your permission, then in return you have to give people better avenues for repair."
Copyright and DRM laws create artificial monopolies that we grant companies because (for better or worse) we've decided that market intervention into creative industries and granting people limited legal monopolies over ideas is sometimes in the best interest of the market/society. But copyright is a privilege that we grant companies for pragmatic reasons, it's not a constitutional right or a natural property right. Copyright is a market intervention by the government, and it's fine for that intervention to come with caveats and conditions.
