How the hell do ya'll haul stuff home from the store on your bicycles???

I don't. I use to work at a place that had bikes to get between buildings on a large campus, and I didn't like taking a laptop in the bike. In the basket it just seemed like it would hop out and get wrecked, and in a backpack it made my balance all lousy...

However they do sell cargo bikes, basically bikes with a huge almost person sized basket, or more or less trailer that hitches behind the bike. I had a eScooter with a "cargo pod" for a while. It was pretty usable.

Now I live somewhere with winter snow, and all that stuff is pretty useless with a few inches of snow on the roads.

But in reality, the number of trips by car remained the same, except now the car wasn't starting where the person making that trip was (e.g. in a parking spot), so a car needs to be brought to the desired starting point. You have actually increased the number of trips by car, even if you have potentially reduced the total number of vehicles... any real reduction in number of owned vehicles just means more parking, not less traffic.

I don't think that is what they found. I mean I doubt that helps, but what they cited in the article was not the the car had to go extra miles and pick them up so it was all bad. What they cited was due to the lower cost and increased convince now more people traveled more miles. So people that had previously stayed home because the bus was too much of a pain, or owning a car was too expensive, used the UberPool to go places. So the car was traveling more miles because it was taking more people more miles. Like someone that would have thought "I want some fried chicken" and stayed at home and ate left over pasta because they don't own a car and taking a bus into town for fried chicken is too inconvenient, would pull out UberPool and say "hey, $2 they will pick me up in five minutes and I only need ot walk like 200 yards here, and 100 yards at other end Fried Chicken Here I come!!!!"; or alternately people who are too young to drive but old enough to have a phone and a Uber account with a few bucks in it can be mobile like someone who owns and can drive.

UberPool is what the original paper referred to, so in theory if you and I live next to each other and I am going to 100 main st and you are going to 100 coventry street we would normally each get in our cars and go, so 2 cars total. With UberPool we are in adjacent houses, so a single UberPool car comes pick us up, it drives 4 miles and drops one of us off at coventry street, and the other off a quarter mile later at main street. Only one car. An advantage, especially if you ignore that the car drove from somewhere to come get us rather then being in our garages before we had the need to go anywhere.

However what they found was UberPool is so easy to use and so cheep that rather then just the two of us leaving from adjacent locations and going to two close destinations that a bunch of other people that would normally not go anywhere (maybe kids too young to drive themselves, but old enough to have a few bucks to pay for an UberPool) also go somewhere. Specifically for every mile saved by having fewer cars on the road they "spent" another 3.7 miles on trips that would otherwise not have happened. So the two of us make that trip PLUS 3 kids from down the block go to the whole next town up to hand out at...um...AgWay? (this is a rural area, so AgWay, WalMart, TSC, or maybe the Pizza place...not that much choice!)

Ok, I agree one should strive to write readable code, but there is a difference between code that uses good argument, method, and variable names and one that ALSO describes any relationships, nuances, and history: let realInch: CGFloat = 96 is ok, but:
// A point is 72 DPI, and CSS 'pixels' are 96 DPI; realInch should match this. "inch" is what most
// of the app should use for mesurment so we can make 'scale models'. However things like fire
// suppression gaps, and notches that match the physical thickness of the material need to use realInch
// for safety & "actually fitting" reasons.
let realInch: CGFloat = 96

gives you far more context, and I would hope make it far more clear what is going on, and make it less likely that you would change:let fireSupressionSpace = CGVector(dx: realInch / 32, dy: realInch / 32)
from "realInch" to "inch". It might be better if something had an assert to make sure fireSupressionSpace isn't set low enough to create actual fire.

Examples from some actual code I use to drive a laser cutter. The fireSupressionSpace also has a comment about what design to test if you want to tweak it down and see if it sets the material on fire as opposed to just making cuts (if you cut a very small section of wood it appears that it can fall or be pushed by the fan into the cut zone and catch a small strip on fire, and fire inside the cutter can be bad because you might smoke damage the machine, or maybe burn down the house, in theory you ought to be watching what it is doing at all times when operating, and in practice that isn't too hard because I enjoy watching my designs become real physical objects, but occasional real world interruptions happen, and if you look away to see what dogs are barking at, or what a cat shoved off a table, or go upstairs to accept a signature delivery that could give Bad Things an opportunity to happen unobserved, and I like to avoid letting that happen).

Fair enough. I tend to find it helpful sometimes when it says things like "the frobniz and bar combine to...", but far less so when it says things like "destinationFolder is the folder to put items into..." or repeats anything the type system already tells me. Sometimes it is clear a comment/documentaiton was once true but has drifted into a lie (for example documenting on a color/tintColor parameter when the method no longer takes one!), and it is a setback if it is not-obvious that it was once true but true no more (same parameter & documentation but the code that implements it doesn't work, or is disconnected). However that is also true of "real" documentation.

Think about who is going to read it and why. Don't just barf a bunch of facts and knowledge onto the page

Great point, but on the other hand if due to time constraints or writing abilities all you can do is just barf out an unorganized tangle of facts that is for sure better then just having zero documentation. More people can take that tangle of facts and either get something from it, or absorb it, ask you a few questions, and write reshape it into an "overview", then a bulleted list of steps, and kick in a few examples then can do that starting from zero.

They are displayed in my client...but I don't have my client with me at all times. Like I originally signed up on my laptop and am on some painting related servers, and then I was doing some board gaming stuff and signed up on my phone, same account name but a different four digits, so that one is signed up to some boardgame stuff. If the "four numbers" had been "hey you pick a unique user name" I would very likely have remembered it. I manage to do that for a whole bunch of services already and have a pattern I follow, plus a system that sync's account names and credentials, but for Discord not the extra four digits.

C++ really doesn't prevent memory errors. Array bounds access is still unchecked. Vector bounds access is unchecked. Raw pointers are still legal, and can point to dead memory, or memory that has been reallocated for new uses. Most of the "modern" C++ containers still have complex iterator invalidation rules. In fact even if you stick to the simpler containers they have invalidation rules. If you have an iterator referencing an object in a vector o' stuff that iterator is invalid if you push a new element. I mean it will likely work unless you happened to push an new element and your vector length was les hone the capacity's and many implementations will when growing the vector attempt to "reallocate in place" if ht eOS happens to support it, and the OS happens to be able to do it in this particular case.

You can get a good part of the way if you use a subset of C++, if you mandate that no raw pointers are used and everything gets a shared_ptr smart pointer if you need ot dynamically allocate/access it. That C strings are not legal, only the C++ string class. That you can't use vector, and invent a whole new set of container classes that all bounds check, and do something "smart" about invalidating iterators (either actually making them invalid, or finding a way for them to stay valid, but never ever as current C++ implementations mostly do just treating them "as if they must be valid already and accessing whatever is in that memory now". It is also at that point non-trivial to look at a line of this C++ subset and know if that "*" is safe because it deals with the right special for my C++ subset smart pointer, or if someone managed to get a raw pointer maybe by accident or on purpose assigning it into some sort of type inference auto value so the actual name of a raw pointer never comes up...which makes code reviews something humans will need to do not something an automated tool can assure us about.

The problem with getting safety as a feature of a language is the safety tends to arise from what the language does not do and C++ hasn't seen a concept it can say "no" to. So C++ has a lot of features of various levels of safety, and they all intermix in a great big unsafe stew. The other problem with getting salty from language is people forget all the things that the language doesn't really help you with. So I think a ground up rewrite of something in Rust gets a lot of safety for free, but it leaves vast surface that the language doesn't help with. So "cool, no dangling invalid pointers, and no references past the end of an array, or via a r-b tree pointer where that node has been deallocated and reused to hold a permissions structure you can scribble on!", cool. However all the pain around remembering to dup the right file handles in the right order, or pay attention to every sys call return value and know which failures are "ok" and which are "oh god, bail! bail! bail!" remain.

Most of that is true of any bank account with any bank. The bit about not being able to access it except via the wallet app is not normal though, and while that is the contractual minimum they guarantee (as in "if you get rid of your iPhone and decline to buy or borrow another and reestablish a wallet connection with your account we might not work with you to get your money back and may tell you to go pound sand") Apple tends to go above and beyond, if in part only because they dislike bad press and they get enough bad press even when they are being perfectly reasonable. It is highly likely they would work with you (or instruct Goldman Sachs) to get your money back.

Want to use "your" money? That will require a written letter

It is a savings account. Many banks limit you to only one or two remote withdraws and make you go in person and talk to a banker for more. They also limit the amount per withdraw. So telling people they "might" need to authorize some transactions in person is actually less than many banks already do.

The agreement says that they can just decide to hold on to your money. Indefinitely. And all you can do about it is take them to arbitration. You'd have to be a complete idiot to use this account. Or, to put it another way, an Apple user.

Eh, I mean I'm not thrilled with arbitration clauses, but unless you are money laundering or Apple is under a government order to freeze your money even an arbitration panel is going to order them to release the money. I'm pretty sure this is very similar to the language in many other savings accounts.

Plus if you happen to have the Apple Credit Card you need in order to qualify for the Savings Account it already generates cash back even day you make a purchase which it deposits into the Apple Cash account which already has a similar set of restrictions, it just probably feels less "heavy" because Apple is throwing money into it for you and a savings account "feel like" something you take your own money and put it in.

The interest rate (4.1% I think) is pretty good, although if you shop around you can get a little higher.

I have one, you can call me an idiot if you want. "All" it has in it is $200 or so, Apple's cash back form stuff I was going to buy anyway, plus a whole $0.40ish worth of interest (for activating it about ten days ago on the cash they already gave me and I haven't spent yet). Which I'll admit I'll actually feel like an idiot if they freeze that account because I'll have made only $0.40(ish) at the cost of whatever hoops I'll need to jump through to get the $200(ish) back that sure they "gave" me, but I could have spent it at Wendy's already and had a literal mountain of cheap chili! Or maybe a stack of Baconator burgers too large for me to actually eat... Oh, or part of a keyboard cover for an iPad I guess.

When was the last time someone you know had a password actually brute forced? That's not the loss vector for passwords these days, it's data breaches. You can have the most secure password ever for your, e.g. banking app, but when the bank gets hacked and your passwords ends up on some leaked user database, your password strength is irrelevant. Those breaches may be a consequence of someone within the company having a weak password, but not the end users.

The data breaches frequently only leak encrypted passwords which are then brute force attacked (or the modern equivalent of rainbow tables are used). So strong passwords are still important in that they reduce the risk when a data breach leaks your encrypted password. Strong passwords are also recommended hand in hand with "use a different password everywhere" and along with those two recommendations is "use a password manager because humans can't remember all that crap, but with a password manager it is trivial". Once you use a password manager it doesn't really matter which of "strong passwords" or "different passwords on different sites!" is more important because it is simpler to do both of them.

However you asked a specific question, so the last time I know someone that had a password either brute forced or shoulder surfed was February. Last time I know for sure it was brute forced was, um, over a decade ago because I brute forced it (with their permission) as part of a demo. It was a 4 digit PIN, over half of which take under 10 guesses (as in the 10 most common PINs cover over half f PIN usage), they didn't have one of them so they got to see the big display "Congratulations you didn't use one of the 10 most guessable PINs, please wait five or ten minutes..." and a countdown. Theirs was a bit over three minutes, so just outside of the first quarter of the search space (I think the full search took 10 minutes -- the 4 digit PIN was combined with some on device entropy, and repeated through a HMAC a bunch of times so you had to run the cracker on the target device, and it took a while, and yes this was a 'attack via USB-A' to do that!)

Of course you could build a device that takes USB-C on one side, negotiates a high voltage on that side, before converting it to the voltage you want on the other side... but you might as well carry your own power supply.

It use to be common to be able to get power banks that could be charged and also provide a charge at the same time. That has become way less common, but they use to be my favorite for general charging as well as taking with me to charge things while on a trip. My current method is to use a USB-C power bank that can plug into the wall and then provides multiple power outs for charging my devices. I don't know for a fact that you can't attack the power bank and then take it over and attack whatever is connected to the bank's USB-C ports, but I think the power bank is too dumb to be used to mount an attack from, plus I try to only wirelessly charge form the power bank, and I'm sure Qi and MagSafe don't carry any useful data that could be used for an attack. Well, actually maybe I need ot do some more research, I know MagSafe transmits some information so the "right" colors can be used in some animations...

On Android type C usb cables get a cable that is only capable of charging = not wired to be able to transfer data, not sure if iphone cables are like that,

You can buy iPhone "power only no data" cables (or use a USB "adaptor" that only passes power and a regular iPhone cable). Apple doesn't sell them because they have historically been considered inferior products as opposed to "on purpose for security we don't support sync, only power!". iPhone's also have the "Hey do you trust this device? YES/NO" alert when you plug in something the iPhone hasn't seen and it gets any data from it. However that has two drawbacks over the hardware data-only-cable solution. (1) too easy for someone to not read the alert and just press "do it!", and (2) people might not realize that is they press the "no don't trust!" they still get power.

Also I think in both the Android and iPhone worlds USB-C-PD requires a data connection to negotiate anything with more than the default 5W or 10W at 5V. So a "power only" on a high power USB-C charger will take hours to go from ~0% to 50% while a "data+power" cable could do it in half an hour.

The other one is the mobile baseband processor, which typically has direct access to the application processor's memory. It runs a very small number of software stacks which are all closed source and therefore not really researched. Mobile phones are not trust worthy devices.

My detailed knowledge is admittedly only iPhones and some of it is up to a decade old, but the "baseband processor" on an iPhone (back when I knew how it worked in great detail) has a subset of the privileges that the application processor has. Admittedly because Apple begrudgingly had to run some other companies code on the baseband processor so they walled it off from the application processor. I would be a bit surprised if Apple's transition to Intel's "cellular modem" technology wasn't at least in part fueled by Apple being able to run it's own code on the baseband rather then someone else's, and I think when Intel exited that busness Apple bought the IP and brought it all in house so they almost for sure now control that stack. Which from their point of view makes it more trustworthy, but not from the viewpoint of th majority of the world that doesn't actually work for Apple. However they already have hardware designs where all the CPUs on the SOC don't need to trust each other, so I expect they will continue to be walled off although they might start treating it more like a TrustZone entity and less like a special on-off design wrinkle.

Moble phones may not be trust worthy, but I would trust an iPhone far more than a closed source desktop OS. Also I would trust them more then MacOS even though they are built largely from the same code base (but with #if's), even though I once worked on one of Apple's security teams and I did more work on macOS then iOS. iOS got to kick out more legacy security issues then macOS. That makes a world of difference. I mean just for one example to support iCloud keychain some fool(*) imported the entire iOS securityd process and all it's dependencies (some of which had to be faked with less secure subsystems) rather then directly implement iCloud keychain on the Mac. So if securityd on iOS has a bug and macOS avoided it with its giant C++ hideous securityd, it exists on macOS anyway in "secd", and may be exploitable.

(*) "some fool" being me. It was probably the right choice, although it did have a downside. We were also hoping to transition macOS to using secd more directly for the things secd actually does and make the older securityd responsible for less and less, but I have my doubts that that actually panned out...

Have you actually tried this in the last decade? TLS by default makes it _really_ hard to do that.

TLS by default does make it a lot harder, but by no means impossible. Sure if your attack starts by insisting someone install a new root cert you definitely lose some people because OSs on purpose make that flow hard, and fill it with dire warnings that some people will read...but if you had enough potential people to attack a small percent of them is still real "value".

Why on earth go to the extremes and effort of setting up fake WiFi networks or hacking into them, unless you _know_ there's a specific target you are going for?

Because general targets can also be valuable. So as an attacker I may not care about "bb_matt", but I do care about "anyone that interacts with a banking site I know how to man in the middle". As an attacker I especially care if I have some sort of scam or attack that works for a small number of limited value transactions but against a large number of people. If I had an attack that worked against unlimited value I would be less interested in "anyone blah blah blah bank" and more interested in "someone specifically with a large bank balance".

Almost all apps that carry important data have end-to-end encryption, so the bad actor would more than likely setup a fake WiFi access point with a login page that asks, as an example, users to login to their email account or something similar - but the numbers will be tiny.

Or set up something that looks like a public WiFi portal (or is one) that demands you install their root cert before you get the free WiFi. Anyone that knows what a root cert does will avoid installing one from anything except their work, and anyone that reads all the OS/browser warnings should avoid doing so, but people skip reading and do "dumb stuff" all the time. Just click whatever buttons in the alert that mean "get all this stuff off my screen and let me see cat videos!"

A scam doesn't need to catch everyone in order to be valuable, and there is some reason to believe that scams that are obvious to many people are actually more effective over the long run because the sort of people that would normally be able to track down the scammers and hold them accountable are the same people that run into obvious scams and go "who would fall for that?" and move on!

-------- (slashdot use to allow the HR HTML element, now it doesn't, i miss that!) -------

So I think the article is mixing some creditable advice "how likely is the attack? maybe don't worry about low probability attacks!" but failing to account for "how much does the risk mitigation cost?" & "how much does getting attacked hurt". The article seems to be saying "these aren't very likely so forget about them, move on!" as opposed to the more useful advice "how likely, scaled by how much it costs if they nail you, and does that cost more then the mitigation?". They get different results.

With one you get "public charger? plug in!", with the other you get "do you have a no-data power only cable? plug in!" and also "you need to trust their cable? Do you really need the power? If not just ignore the whole thing, if you desperately need the power though, go ahead, your phone is probably safe!". Yes, that is more thought then some people like to put into things, and a lot of people that don't like to think too hard about things like reassuring magazine articles that say "guy who likes to think about stuff says you don't have to think too hard. You were right all along!"