Also, easier to be cheaper when you don't give a crap about actually making money: "The company posted a net loss of $645 million", most companies aren't darling hip tech companies that are allowed to lose $645 million a quarter and still be loved by investors.
It remains to be seen how they will do when they run out of investor patience.
That kind of skips the whole 'own my own damn car' option, which hopefully presumably will be a viable option, and in fact a cheaper than ever option (insurance should go down, electric cars have less maintenance and fewer things to suddenly and catastrophically break).
I think there's justified concern that the culture inundates people with 'nah, you don't want to own anything, rent everything' which creates an unfortunate relationship between those who own and those who use. It's generally an exploitative relationship, people getting long term suckered to avoid short term sticker shock, further funneling 'wealth' to upper class folk. People are all the time converting people to 'easy monthly payments' for fun and mostly a lot of juicy profit.
At some point that won't be true. Of course hopefully the answer is not to intentionally not progress because we can't sort out a fair economy, but to sort out some fair economy that will work.
Post scarcity might be easier, the challenge will be the in-between, where some people are still pretty much needed more than 40 hours a week and some people we couldn't find work for them to do even if they wanted to.
I don't have the parking costs in my context, but all those other costs you mention, you are paying for them whether it is your car or a rental. Additionally you are paying for more expenses that you wouldn't incur (it uses fuel to move between fares and associated wear and tear and probably taxes not levied on a privately owned vehicle) and likely some sort of parking fee if it is ever at rest, as well as a profit margin to make it worthwhile for the owner of the item above and beyond expenses.
Rental makes sense for one-off or occasional use of an item. If you are using something *daily*, owning is going to be cheaper than renting over the long term. Otherwise, rentals wouldn't be a viable commercial endeavor. In the short term ownership is going to be extremely cheaper or more expensive (purchases and repairs comes in bursts), but as long as you don't get too obsessed with those incidents, you realize it's still cheaper.
Well not over 30 years ago, Ctrl-Alt-Del as a Secure Attention Key until 1994 in Windows NT. Other than that it was a reboot sequence.
But the concept has been out of fashion for years, but warrants a reminder of the value of something the OS can hook and unconditionally react to to discourage OS dialog phishing.
Also amused that in all of our cases, there's a lock and a very sturdy door. And nothing but sheetrock right next to the door separating a determined individual from getting in, without so much as tripping an alarm.
In that case, collision attacks should be ignored in this context, since they have no meaning in the face of a salt.
Hashes per second is the metric that matters. If you use MD5 in a PB-KDF of 1000 passes or a SH256 in a PB-KDF of 1000 passes, either way each guess is 1,000 hash calculations, and the key space is identical (the passwords).
Here's a benchmark showing hashcat performance, note that md5 is roughly 10 times more than sha-256. https://gist.github.com/epixoi...
Now maybe you are thinking of cheap single-pass md5 versus some sort of practice incorporating a pb-kdf or similar scheme., but in terms of hash performance, they aren't that far from each other.
Or maybe you are mistaking the hash length for how many guesses are needed. In AES-128 versus AES-256, it is indeed 2**128 more because the unknown key is known to be 256 bit versus 128 bit, but in a crypted password context, the password is the unknown to test against.
Collision attacks only mean something to unsalted password hashes (which are just terrible) and signature verification. It doesn't mean anything for HMAC or HMAC based things like PB-KDF which should be employed if any normal crypto hash is used.
Yep nothing like a credential I leave behind on any surface I touch.
It's funny, there's a room at work that (in part) is secured by a fingerprint reader. it's about 10 feet from a door that you can see the fingerprints clearly left behind as people push the doors open on the way to the fingerprint reader.
The challenge in the industry is that the most innocuous thing can become a critical security decision.
This is one of the big failings of the status quo, companies have a 'security' team that is somehow on the hook for *everyone else's* code, explictly responsible for a small chunk of formally recognized 'security' related code, while any one left naive about security could botch it for everyone without anyone even realizing the security team should pay attention to it.
I think code review is unlikely to discern mistakes at the scale of a large piece of software.
On the other hand, breaking up the chunks of the monolithic application into pieces to do unit testing can presumably make fuzzing easier. So the ability to re-build the project in a different way can be helpful.
If your password would fail in an offline attack, it doesn't matter what hash algorithm was used. It's only a 10-fold difference in cracking speed, which for a good password is the difference of 10 million versus a million years, and for a bad password the difference between a minute and 10 minutes.
No reason to use it of course, and it's easier for people to just do SHA2 rather than keep track of whether the meangingful weaknesses (collisions) of md5 matter for your app or not (unless it is unsalted, and unsalted hash of a password *would* be vulnerable to md5's weakness especially, but also opens up the door to rainbow tables regardless of the hash, so not worth much debate there).
In the realm of password cracking a well-salted MD5 hash, it's only 10x quicker to crunch through md5 than an equivalent sha256. If it were a truly random string needing brute force, we are still talking about a million years for a cluster of a thousand nodes with 8x gtx 1080s each to crack a *single* PB-KDF with 1,000 rounds. For a dictionary attack, both methods would fall in short order.
The real weakness in MD5 is in applications that rely on attacker not being able to know a collision, such as md5sums and such.
Of course, no reason to bother to do MD5, easier to just always do SHA2, but in the interest of being accurate about the risk...
In an HMAC, PBKDF, etc application, MD5 is still safe practically speaking, but it's easier to avoid raised eyebrows to move on to SHA2 than to explain that. In these scenarios, a has collision isn't going to help.
If you are using the hash as a validation of something else (md5sum of a file, md5 fingerprint of a certificate), that is meaningfully risky, since has collision is the means of breaking it and that is the weakness in the algorithm.
Perhaps offtopic maybe. The scenario here is indicative of general programmer behavior: easy and functional without looking at the consequences.
The annoyance of runtimes and vulnerabilities in those runtimes are a distinct phenomenon. In fact, I'd say that Java's experience is a good example of the problems of shipping language runtime with your app, which can extend to static linking and providing 'appliance' virtual machines or containers. The lazy mindset that infects java app deployment to cause the phenomenon you see,.. those people will crew up *any* target they may have the exact same way (and sadly this happens more and more, with many libraries no longer making the effort to be api compatible version to version, and pointing to dockerhub in general or virtualenv in python or similar strategies as why it doesn't matter to be compatible and have maintenance streams and other such work devs have no interest/patience for if they are allowed to skip it.)
I think there's room for "I've looked at rust, it might be a good idea, but not to the extent it is hyped".
I will concur that I see too many folks saying roughly "oh yeah, Java/Javascript/(etc.) are so much less secure than rust". Those people obviously don't understand *why* rust has the claims about security and/or really piss poor understanding of other languages. It also implies a huge misunderstanding about security in general, that a language design can fix the most usual offenders nowadays (it's generally poor design rather than some sort of buffer overflow or use after free) It is over hyped and way too many people champion it without understanding other than hip to be novel. Hype indeed can inspire a healthy wave of skepticism. Particularly after Go went through just about the exact same hype cycle about 5 minutes ago and has much of the same benefits.
Rust has some decent concepts as a "c-like" language, but with far less tedium around making sure you don't go off into undesired places when your code executes. While most security problems stem from design, there are certainly problems that are still caused by careless mistakes with pointers taken at face value.
Yeah, I will confess to not knowing your specific scenario, but I too was faced with a language/library set that had a terrible TLS implementation. I subclassed the plain http class to provide my own tls handling because I know precisely what happens using the default scheme.
This of course drew incredulous response from a security architect that worked on a similar product, saying that I was running a terrible risk by authenticating certificates ssh-style rather than with a CA. I then asked if that concerned him so much, why did his product have a client that allowed user to disable cert validation? He said because users demanded it as soon as they released, and it's the user's fault if that screws them over. I informed him that I didn't provide an option to disable validation, and not one of my users has asked for it. I never could convince him this was a good thing. Note the target market is 99.99% private services not even resolvable by the internet DNS servers. I helped a few of his clients and every last one had hard set it to disable cert validation, and besides I suspect he didn't really understand the underlying way the certificates work, since manually blessed certificates are no more blessed if you use a CA to mark that rather than storing the fingerprints directly.
Too much work in security is about offering a hypothetical possible credibly secure way that no one wants to do, and then offering a feasible approach to get work done so they can blame the users or downstream developers for mistakes. Not enough sentiment of "must make the secure approach also the easy choice".
Of course the secure 'solutions' should take note that something is deeply wrong with how they go about providing secure options when this happens so much.
People don't do this because they like being insecure, they do it because it's easier.
Disabling CSRF is popular because it's *generally* implemented in a pain-in-the-ass way. Not only in a pain in the ass way, but it seems every five seconds another framework comes up with a slightly different approach to CSRF that isn't any better or worse than the myriad of approaches already. One massive improvement on that front in general would be to disable all that crap if no referrer is set at all, which would solve 99% of the situations where people feel compelled to weaken CSRF protection (non-browser automation).
There are two accepted approaches for TLS if you are note doing things for internet sites: Maintain a convoluted CA setup or if you can't bring yourself to do that, well, disabling it is the only other easy way provided. In my software I tend to provide option of treating TLS software similar to ssh known hosts if CA verification is not an issue, and users are never bothered, until something does go awry.
Using obsolete communication protocols and hashes is generally the consequence of having to interact with data or equipment or older setups. Sure some of it is just people got taught that specific way once upon a time directly addressing low level crypto functions, but a lot is intentional. Of course this is a problem that propagates, new interface to old setup uses old protocol, new thing to talk to new thing, well might as well use old protocol there.
So the vast majority of consumption is going to be video and music, latency doesn't matter one bit. For phone conversations (sadly always done over *terrible* HFP), latency is dwarfed by the long-haul communication.
I still say the easy answer is usb-c and similar headphones, and not sure what the justification is for saying 'that's not the answer'.
Even as latency happens, our hearing/visual system is *so* used to wildly varying video/audio input that we aren't remotely sensitive to audio latency.
FLAC for listening doesn't make a difference compared to the high end of the common bluetooth codecs. Countless double blind tests have shown that the human ear cannot tell the difference.
An argument can be made as a source for post-processing needing FLAC to preserve data, but if the very next hop is a human ear and not manipulation, it doesn't make a difference.
Actually, you don't really get to spend a lot of time. You try it and it will either be fantastic or suck really badly and there's nothing you can do about it. Of course the vagueness of advertising 'bluetooth' means you generally are playing roulette with the quality when you buy stuff. At least android + ford system seems to work well, though I have no idea what codec it negotiated.
The sockets are less to blame, it's how they tend to get mounted. Demand better, demand through-mounted usb connectors and the suckers are back to parity with the typical headphone jack. The devices vendors had to be more strict with headphone jacks, because they are long and long means it becomes annoyingly a lever and needs overkill to keep it from peeling from the board. usb connectors are so shallow, they like cheaping out with surface mount because it works *most* of the time.
, the obvious replacement isn't another wire with a proprietary connector like Apple's Lightning or the many incompatible and strange flavors of USB-C audio. It's Bluetooth. And Bluetooth continues to suck,
Why isn't a connector the obvious replacement? What do you mean incompatible and strange flavors of usb-c, what the hell are you talking about?
Not likely to be feasible for the private solar capacity.
However, it is likely that some capacity would survive, so while not everyone would have their power, there might be enough spotty power to greatly improve conditions compared to total loss of grid.
Slashdot Mirror
Also, easier to be cheaper when you don't give a crap about actually making money:
"The company posted a net loss of $645 million", most companies aren't darling hip tech companies that are allowed to lose $645 million a quarter and still be loved by investors.
It remains to be seen how they will do when they run out of investor patience.
That kind of skips the whole 'own my own damn car' option, which hopefully presumably will be a viable option, and in fact a cheaper than ever option (insurance should go down, electric cars have less maintenance and fewer things to suddenly and catastrophically break).
I think there's justified concern that the culture inundates people with 'nah, you don't want to own anything, rent everything' which creates an unfortunate relationship between those who own and those who use. It's generally an exploitative relationship, people getting long term suckered to avoid short term sticker shock, further funneling 'wealth' to upper class folk. People are all the time converting people to 'easy monthly payments' for fun and mostly a lot of juicy profit.
At some point that won't be true. Of course hopefully the answer is not to intentionally not progress because we can't sort out a fair economy, but to sort out some fair economy that will work.
Post scarcity might be easier, the challenge will be the in-between, where some people are still pretty much needed more than 40 hours a week and some people we couldn't find work for them to do even if they wanted to.
I don't have the parking costs in my context, but all those other costs you mention, you are paying for them whether it is your car or a rental. Additionally you are paying for more expenses that you wouldn't incur (it uses fuel to move between fares and associated wear and tear and probably taxes not levied on a privately owned vehicle) and likely some sort of parking fee if it is ever at rest, as well as a profit margin to make it worthwhile for the owner of the item above and beyond expenses.
Rental makes sense for one-off or occasional use of an item. If you are using something *daily*, owning is going to be cheaper than renting over the long term. Otherwise, rentals wouldn't be a viable commercial endeavor. In the short term ownership is going to be extremely cheaper or more expensive (purchases and repairs comes in bursts), but as long as you don't get too obsessed with those incidents, you realize it's still cheaper.
Well not over 30 years ago, Ctrl-Alt-Del as a Secure Attention Key until 1994 in Windows NT. Other than that it was a reboot sequence.
But the concept has been out of fashion for years, but warrants a reminder of the value of something the OS can hook and unconditionally react to to discourage OS dialog phishing.
Well, it's one thing to remove a function between big updates you opt into.
It's another to remove stuff by surprise in a normal update.
Also amused that in all of our cases, there's a lock and a very sturdy door. And nothing but sheetrock right next to the door separating a determined individual from getting in, without so much as tripping an alarm.
In that case, collision attacks should be ignored in this context, since they have no meaning in the face of a salt.
Hashes per second is the metric that matters. If you use MD5 in a PB-KDF of 1000 passes or a SH256 in a PB-KDF of 1000 passes, either way each guess is 1,000 hash calculations, and the key space is identical (the passwords).
Here's a benchmark showing hashcat performance, note that md5 is roughly 10 times more than sha-256.
https://gist.github.com/epixoi...
Now maybe you are thinking of cheap single-pass md5 versus some sort of practice incorporating a pb-kdf or similar scheme., but in terms of hash performance, they aren't that far from each other.
Or maybe you are mistaking the hash length for how many guesses are needed. In AES-128 versus AES-256, it is indeed 2**128 more because the unknown key is known to be 256 bit versus 128 bit, but in a crypted password context, the password is the unknown to test against.
Collision attacks only mean something to unsalted password hashes (which are just terrible) and signature verification. It doesn't mean anything for HMAC or HMAC based things like PB-KDF which should be employed if any normal crypto hash is used.
Yep nothing like a credential I leave behind on any surface I touch.
It's funny, there's a room at work that (in part) is secured by a fingerprint reader. it's about 10 feet from a door that you can see the fingerprints clearly left behind as people push the doors open on the way to the fingerprint reader.
The challenge in the industry is that the most innocuous thing can become a critical security decision.
This is one of the big failings of the status quo, companies have a 'security' team that is somehow on the hook for *everyone else's* code, explictly responsible for a small chunk of formally recognized 'security' related code, while any one left naive about security could botch it for everyone without anyone even realizing the security team should pay attention to it.
I think code review is unlikely to discern mistakes at the scale of a large piece of software.
On the other hand, breaking up the chunks of the monolithic application into pieces to do unit testing can presumably make fuzzing easier. So the ability to re-build the project in a different way can be helpful.
If your password would fail in an offline attack, it doesn't matter what hash algorithm was used. It's only a 10-fold difference in cracking speed, which for a good password is the difference of 10 million versus a million years, and for a bad password the difference between a minute and 10 minutes.
No reason to use it of course, and it's easier for people to just do SHA2 rather than keep track of whether the meangingful weaknesses (collisions) of md5 matter for your app or not (unless it is unsalted, and unsalted hash of a password *would* be vulnerable to md5's weakness especially, but also opens up the door to rainbow tables regardless of the hash, so not worth much debate there).
In the realm of password cracking a well-salted MD5 hash, it's only 10x quicker to crunch through md5 than an equivalent sha256. If it were a truly random string needing brute force, we are still talking about a million years for a cluster of a thousand nodes with 8x gtx 1080s each to crack a *single* PB-KDF with 1,000 rounds. For a dictionary attack, both methods would fall in short order.
The real weakness in MD5 is in applications that rely on attacker not being able to know a collision, such as md5sums and such.
Of course, no reason to bother to do MD5, easier to just always do SHA2, but in the interest of being accurate about the risk...
It depends upon the application.
In an HMAC, PBKDF, etc application, MD5 is still safe practically speaking, but it's easier to avoid raised eyebrows to move on to SHA2 than to explain that. In these scenarios, a has collision isn't going to help.
If you are using the hash as a validation of something else (md5sum of a file, md5 fingerprint of a certificate), that is meaningfully risky, since has collision is the means of breaking it and that is the weakness in the algorithm.
Perhaps offtopic maybe. The scenario here is indicative of general programmer behavior: easy and functional without looking at the consequences.
The annoyance of runtimes and vulnerabilities in those runtimes are a distinct phenomenon. In fact, I'd say that Java's experience is a good example of the problems of shipping language runtime with your app, which can extend to static linking and providing 'appliance' virtual machines or containers. The lazy mindset that infects java app deployment to cause the phenomenon you see,.. those people will crew up *any* target they may have the exact same way (and sadly this happens more and more, with many libraries no longer making the effort to be api compatible version to version, and pointing to dockerhub in general or virtualenv in python or similar strategies as why it doesn't matter to be compatible and have maintenance streams and other such work devs have no interest/patience for if they are allowed to skip it.)
I think there's room for "I've looked at rust, it might be a good idea, but not to the extent it is hyped".
I will concur that I see too many folks saying roughly "oh yeah, Java/Javascript/(etc.) are so much less secure than rust". Those people obviously don't understand *why* rust has the claims about security and/or really piss poor understanding of other languages. It also implies a huge misunderstanding about security in general, that a language design can fix the most usual offenders nowadays (it's generally poor design rather than some sort of buffer overflow or use after free) It is over hyped and way too many people champion it without understanding other than hip to be novel. Hype indeed can inspire a healthy wave of skepticism. Particularly after Go went through just about the exact same hype cycle about 5 minutes ago and has much of the same benefits.
Rust has some decent concepts as a "c-like" language, but with far less tedium around making sure you don't go off into undesired places when your code executes. While most security problems stem from design, there are certainly problems that are still caused by careless mistakes with pointers taken at face value.
Yeah, I will confess to not knowing your specific scenario, but I too was faced with a language/library set that had a terrible TLS implementation. I subclassed the plain http class to provide my own tls handling because I know precisely what happens using the default scheme.
This of course drew incredulous response from a security architect that worked on a similar product, saying that I was running a terrible risk by authenticating certificates ssh-style rather than with a CA. I then asked if that concerned him so much, why did his product have a client that allowed user to disable cert validation? He said because users demanded it as soon as they released, and it's the user's fault if that screws them over. I informed him that I didn't provide an option to disable validation, and not one of my users has asked for it. I never could convince him this was a good thing. Note the target market is 99.99% private services not even resolvable by the internet DNS servers. I helped a few of his clients and every last one had hard set it to disable cert validation, and besides I suspect he didn't really understand the underlying way the certificates work, since manually blessed certificates are no more blessed if you use a CA to mark that rather than storing the fingerprints directly.
Too much work in security is about offering a hypothetical possible credibly secure way that no one wants to do, and then offering a feasible approach to get work done so they can blame the users or downstream developers for mistakes. Not enough sentiment of "must make the secure approach also the easy choice".
Not really the fault of the language....
Of course the secure 'solutions' should take note that something is deeply wrong with how they go about providing secure options when this happens so much.
People don't do this because they like being insecure, they do it because it's easier.
Disabling CSRF is popular because it's *generally* implemented in a pain-in-the-ass way. Not only in a pain in the ass way, but it seems every five seconds another framework comes up with a slightly different approach to CSRF that isn't any better or worse than the myriad of approaches already. One massive improvement on that front in general would be to disable all that crap if no referrer is set at all, which would solve 99% of the situations where people feel compelled to weaken CSRF protection (non-browser automation).
There are two accepted approaches for TLS if you are note doing things for internet sites: Maintain a convoluted CA setup or if you can't bring yourself to do that, well, disabling it is the only other easy way provided. In my software I tend to provide option of treating TLS software similar to ssh known hosts if CA verification is not an issue, and users are never bothered, until something does go awry.
Using obsolete communication protocols and hashes is generally the consequence of having to interact with data or equipment or older setups. Sure some of it is just people got taught that specific way once upon a time directly addressing low level crypto functions, but a lot is intentional. Of course this is a problem that propagates, new interface to old setup uses old protocol, new thing to talk to new thing, well might as well use old protocol there.
So the vast majority of consumption is going to be video and music, latency doesn't matter one bit. For phone conversations (sadly always done over *terrible* HFP), latency is dwarfed by the long-haul communication.
I still say the easy answer is usb-c and similar headphones, and not sure what the justification is for saying 'that's not the answer'.
Even as latency happens, our hearing/visual system is *so* used to wildly varying video/audio input that we aren't remotely sensitive to audio latency.
FLAC for listening doesn't make a difference compared to the high end of the common bluetooth codecs. Countless double blind tests have shown that the human ear cannot tell the difference.
An argument can be made as a source for post-processing needing FLAC to preserve data, but if the very next hop is a human ear and not manipulation, it doesn't make a difference.
Actually, you don't really get to spend a lot of time. You try it and it will either be fantastic or suck really badly and there's nothing you can do about it. Of course the vagueness of advertising 'bluetooth' means you generally are playing roulette with the quality when you buy stuff. At least android + ford system seems to work well, though I have no idea what codec it negotiated.
The sockets are less to blame, it's how they tend to get mounted. Demand better, demand through-mounted usb connectors and the suckers are back to parity with the typical headphone jack. The devices vendors had to be more strict with headphone jacks, because they are long and long means it becomes annoyingly a lever and needs overkill to keep it from peeling from the board. usb connectors are so shallow, they like cheaping out with surface mount because it works *most* of the time.
, the obvious replacement isn't another wire with a proprietary connector like Apple's Lightning or the many incompatible and strange flavors of USB-C audio. It's Bluetooth. And Bluetooth continues to suck,
Why isn't a connector the obvious replacement? What do you mean incompatible and strange flavors of usb-c, what the hell are you talking about?
Not likely to be feasible for the private solar capacity.
However, it is likely that some capacity would survive, so while not everyone would have their power, there might be enough spotty power to greatly improve conditions compared to total loss of grid.