Alas, people used it for other things as well because they understood perl, but not the languages they should have been using (Mostly C or C++, in Perl's heyday.)
Beg to differ. I learned C and C++ way before Perl 5, and subsequently used a lot of Perl 5 (yes, also for things other than string handling.) One thing I liked the most about it was the error messages were way better than C was at the time... something I'm glad the Perl culture is taking great pains to carry forward into Perl 6.
What people didn't understand and didn't want to use was autoconf and all the other glue necessary to make C/libc portable. Because no sane person wants to.
At least one of them is the same f-up as IKEv2 still has... they don't double-check that the initial negotiation was MITM-free later on into the process. Really you have to take a portion of the keying material and use it to verify the very first packets without exposing the rest of the keying material, then if and only if you have not detected too many "doorknob twists" on that process, continue using the rest of the keying material for the actual session key negotiation.
For example, say a client supports the elliptic curves P-521 and P-256, and prefers to use them in that order. In that case, even thoug the AP also supports the P-521 curve, an adversary can force the client and AP into using the weaker P-256 curve. This can be accomplished by jamming the messages of the Dragonfly handshake, and forging a message that indicates certain curves are not supported.
...which of course can be mitigated by NOT DOING THAT (in both cases). But then of course you have to either tell supplicants which don't support the stronger alg to go stuff it. or somehow segregate them into a lower security class if there's a point to letting them on at all.
IIRC most of the SAE algorithms also demand some throttling be done and excesses on that throttling reported to the other side in order for both sides to require a password reset if someone has been aggressively on-line guessing. Not sure if that's required by the standard even though it is a countermeasure mentioned by authors of these crypto suites in the original papers that publish them. That in turn requires keeping state on peers long-term. How much you wanna bet client supplicants find way to fail to implement that?
A year or two ago I would have pointed out that depending on your driving patterns, hybrids will get much more than +10% on fuel in some situations, even though ICEs have improved. And I waould have said that a plug-in hybrid would be a good option.
Not anymore. My Prius's head gasket was going (350k on it) so I looked around and hands down it was far too affordable to get a pure EV and never again have to take it in for an oil change, spark plug replacement, tune-up, or major ICE-related surgery... which accounted for the majority of mechanical issues.
Getting rid of that burden is worth enough to me that I would have bought it without the tax subsidy. Plus I was willing to pay thousands to get a circuit dug out to the garage in a house I don't even own.
Now I never have to freeze my ass off at a gas pump again.
(Don't get me wrong, I think the level of technology that has allowed us to make ICEs as reliable as they are is nothing short of amazing... it's just time to admit the technology approaches obsolescence.)
I fully back this IF the politicians, like Elizabeth Warren, can also go to jail for their failures. I'm sure she will agree to this......
You should be. For example she's introduced a bill that could put her in jail if she owned any individual stocks (along with all the other Senators, Congressmen, and much of the White House.)
Maybe RTFB? It probably says what it considers "negligence".
Proving the code that USES their library is yet another thing.
That's the rub. There will be some wrapper written to make parameter exchange automatic, or facilitate finding a VPN gateway, or whatnot, and it'll undo all the hard work in a few lines of hastily coded VB.
There's a hard and fast requisit for establishing a MITM-proof crypto channel: you have to exchange some keying material safely... whether that's through a CA system or a preshared key or whatever, it simply must be done... and the users will choose the software which skips that step because someone assured them it is taken care of automagically, and well heck, that's much easier.
They market themselves as easy to use and then ship with innumerable security holes and deficiencies. Half of them think they are in a living room with everyone in the same broadcast domain and spew exploitable multicast everywhere or want you to punch holes in your network to accommodate them. Cloud services tell users just put you data up here, no mention that they keep getting p0wned by leaving it up in unprotected mongodbs/repos accidentally. CDN-based apps with their thousands of IP addresses all shared by other services make L4 security filers impossible to define. Wifi supplicants and VPN clients which don't have any sane way to install, much less find, a corporate configuration profile that actually locks down the protocol sanely. Unmerited complete trust in DNS results. Self-help support operations that take opaque data dumps including PII, IP, and crypto keys over email to some outsourced support center who knows where.
So its nearly 2020 and the bright side is you almost never see telnet servers in products anymore. That took decades. In the meantime we are inundated with new attack surface daily.
90+% of all my problems, many of them security related, are because people want to use product X and product X is a dumpster fire. I don't blame the people for wanting to use it. It's what they were shown in an advertisement, and everyone they know is using it. I blame the manufacturers of product X for shipping crap.
Nope never. I carry my cards in an intelligently designed leather wallet in a jacket pocket, not directly in my pants pocket or in a cloth wallet designed to dump them on the floor if it falls out. And I don't shimmy locks or cut cocaine, so I have never had that problem.
What I want to know is what happens to the pennies, tinfoil, and the ferromagnetic hair barrette someone dropped on the charge plate.
But hey if it works and is efficient, more power to them. Pun intended.
Personally, once I get my Level 2 charger installed at home I'll probably only rarely give a crap what's going on at the public stations, and (un)plugging in before/after parking is not something I view as onerous. Literally takes just ten seconds.
Sigh, I'm so sick of whataboutism and fake controversies from the trumpkins. At least they've stopped saying nuclear material was physically transported from Canada/US to Russia. That's progress I guess. Like, a 'getting your kid to stop eating the boogers but not the public nose picking itself" level of progress.
...or the market will realize that now there is a rather short time limit on the "wait for the Muller" excuse not to impeach Trump for his nearly innumerable other offenses.
Place your bets. It's the world's greatest casino.
1) Human does work 2) Developer fresh out of college with limited google-foo and general DIY mentaility re-invents the wheel to make process 1000 times better than human 3) Re-invented wheel is tweeted about and another developer also unaware of 10s of other previously existing wheels wraps implementation into an API for whatever the popular language of the week is, making it 3 times less efficient. 4) Developer at startup integrates said library and publishes it as part of an SDK for a larger product suite, gaining no efficiency. 5) Customers note lack of many features other implementations of said wheel have had for decades. Many TAC cases and meetings are held. 6) Company hastily responds by glomming imitations of missing features onto oversimplistic implementation, doesn't bother to push upstream, and makes things 5 times less efficient. 7) https://xkcd.com/927/ happens, making things 3 times less efficient 8) Product has to run on new hardware and the fastest way to do that is run it on an emulator, making things 20 times less efficient. 9) Desk jockey gets distracted reading slashdot while waiting for laggy UI, takes 5 times longer to do job than necessary.
There is still a lot we don't know. Like what's coming off the wicks when they inevitably overheat due to most of the devices being built very cheaply/disposable.
That said, there is zero reason to ban these things. The odds off them being worse than combustion are very low.
Research could lead to less harmful products.
We definitely need the research done. It's fine to warn against using vapes and educate the public, but we don't need bans in the meantime.
It's sad to see the abstinence-only-anti-tobacco lobby making things worse. But it's been like that for decades now... they dissemble so much in their ads they spoil any trust they might have initially had with their target audience.
(BTW as a smoker I had no problem with the ad with the tiny "bully" guy in tan pants and a white wifebeater... I laughed and liked that ad. One of the only ads that didn't make me get out of my chair to go have a puff. But everything by "the Truth" campaign endangers the longevity of my TV if there are throwable abjects nearby because all their ads are deceptive.)
I have some. They aren't like single-lense-across-the-face, rather more golf-glasses style, and I'm not sure the knock-off brand I got did the math as well as Oakley might (for even more $$$), but for a certain range of mild prescriptions it is possible.
Thanks and I was really wondering WTH was going on with low-end chicken lately. The way it crunches (when it shouldn't) is kinda hard to describe. Sorta styrofoamish I guess,
So you are recommending sites source their js from a site other than their own?
I didn't do any dabbling into ECMAscript until recently. Glad I waited. Seems modern ECMAScript plus HTML5 makes most of the frameworks useless if you are developing something that doesn't have to run on some grandmother's iMac G5.
Slashdot Mirror
This shoulda been FP. Stop slacking, slashdotters.
Alas, people used it for other things as well because they understood perl, but not the languages they should have been using (Mostly C or C++, in Perl's heyday.)
Beg to differ. I learned C and C++ way before Perl 5, and subsequently used a lot of Perl 5 (yes, also for things other than string handling.) One thing I liked the most about it was the error messages were way better than C was at the time... something I'm glad the Perl culture is taking great pains to carry forward into Perl 6.
What people didn't understand and didn't want to use was autoconf and all the other glue necessary to make C/libc portable. Because no sane person wants to.
At least one of them is the same f-up as IKEv2 still has... they don't double-check that the initial negotiation was MITM-free later on into the process. Really you have to take a portion of the keying material and use it to verify the very first packets without exposing the rest of the keying material, then if and only if you have not detected too many "doorknob twists" on that process, continue using the rest of the keying material for the actual session key negotiation.
For example, say a client supports the elliptic curves P-521 and P-256, and prefers to use them in that order. In that case, even thoug the AP also supports the P-521 curve, an adversary can force the client and AP into using the weaker P-256 curve. This can be accomplished by jamming the messages of the Dragonfly handshake, and forging a message that indicates certain curves are not supported.
...which of course can be mitigated by NOT DOING THAT (in both cases). But then of course you have to either tell supplicants which don't support the stronger alg to go stuff it. or somehow segregate them into a lower security class if there's a point to letting them on at all.
IIRC most of the SAE algorithms also demand some throttling be done and excesses on that throttling reported to the other side in order for both sides to require a password reset if someone has been aggressively on-line guessing. Not sure if that's required by the standard even though it is a countermeasure mentioned by authors of these crypto suites in the original papers that publish them. That in turn requires keeping state on peers long-term. How much you wanna bet client supplicants find way to fail to implement that?
A year or two ago I would have pointed out that depending on your driving patterns, hybrids will get much
more than +10% on fuel in some situations, even though ICEs have improved. And I waould have
said that a plug-in hybrid would be a good option.
Not anymore. My Prius's head gasket was going (350k on it) so I looked around and hands down it was far
too affordable to get a pure EV and never again have to take it in for an oil change, spark plug replacement,
tune-up, or major ICE-related surgery... which accounted for the majority of mechanical issues.
Getting rid of that burden is worth enough to me that I would have bought it without the tax subsidy. Plus I
was willing to pay thousands to get a circuit dug out to the garage in a house I don't even own.
Now I never have to freeze my ass off at a gas pump again.
(Don't get me wrong, I think the level of technology that has allowed us to make ICEs as reliable as they
are is nothing short of amazing... it's just time to admit the technology approaches obsolescence.)
I fully back this IF the politicians, like Elizabeth Warren, can also go to jail for their failures. I'm sure she will agree to this......
You should be. For example she's introduced a bill that could put her in jail if she owned any individual stocks (along with all the other Senators, Congressmen, and much of the White House.)
Maybe RTFB? It probably says what it considers "negligence".
Proving the code that USES their library is yet another thing.
That's the rub. There will be some wrapper written to make parameter exchange automatic, or facilitate finding a VPN gateway, or whatnot, and it'll undo all the hard work in a few lines of hastily coded VB.
There's a hard and fast requisit for establishing a MITM-proof crypto channel: you have to exchange some keying material safely... whether that's through a CA system or a preshared key or whatever, it simply must be done... and the users will choose the software which skips that step because someone assured them it is taken care of automagically, and well heck, that's much easier.
It ain't the users. It's the products.
They market themselves as easy to use and then ship with innumerable security holes and deficiencies. Half of them think they are in a living room with everyone in the same broadcast domain and spew exploitable multicast everywhere or want you to punch holes in your network to accommodate them. Cloud services tell users just put you data up here, no mention that they keep getting p0wned by leaving it up in unprotected mongodbs/repos accidentally. CDN-based apps with their thousands of IP addresses all shared by other services make L4 security filers impossible to define. Wifi supplicants and VPN clients which don't have any sane way to install, much less find, a corporate configuration profile that actually locks down the protocol sanely. Unmerited complete trust in DNS results. Self-help support operations that take opaque data dumps including PII, IP, and crypto keys over email to some outsourced support center who knows where.
So its nearly 2020 and the bright side is you almost never see telnet servers in products anymore. That took decades. In the meantime we are inundated with new attack surface daily.
90+% of all my problems, many of them security related, are because people want to use product X and product X is a dumpster fire. I don't blame the people for wanting to use it. It's what they were shown in an advertisement, and everyone they know is using it. I blame the manufacturers of product X for shipping crap.
Nope never. I carry my cards in an intelligently designed leather wallet in a jacket pocket, not directly in my pants pocket or in a cloth wallet designed to dump them on the floor if it falls out. And I don't shimmy locks or cut cocaine, so I have never had that problem.
there will also be a physical card made from titanium
,,,uh .... why?
produce a ton of CO2 during manufacture
We actually measure CO2 emissions in tons, so using it as a superlative here is dicey.
I would not sweat the battery production footprint. It will shrink over time and use more renewable process energy as well. Approximately half of a battery’s emissions come from electricity used in the manufacturing process." By the time a battery gets to 8 years old, much has improved. Currently the battery production footprint is nulled out about 2-3 years in, for average driving needs.
Meanwhile, upstream liquid fuel delivery systems are a pretty mature subject matter without much room for improvement.
What I want to know is what happens to the pennies, tinfoil, and the ferromagnetic hair barrette someone dropped on the charge plate.
But hey if it works and is efficient, more power to them. Pun intended.
Personally, once I get my Level 2 charger installed at home I'll probably only rarely give a crap what's going on at the public stations, and (un)plugging in before/after parking is not something I view as onerous. Literally takes just ten seconds.
Sigh, I'm so sick of whataboutism and fake controversies from the trumpkins. At least they've stopped saying nuclear material was physically transported from Canada/US to Russia. That's progress I guess. Like, a 'getting your kid to stop eating the boogers but not the public nose picking itself" level of progress.
Place your bets. It's the world's greatest casino.
We'll have to agree on the replaceable battery issue and disagree on on the green new deal.
These must be super-cheap li-ion cells and/or charging electronics. Normal cycle and shelf life for well maintained Li-ion is higher than this.
Not Fallout enough. It has to still work 300 years from now when the vault dwellers emerge.
That could conceivably happen.
Here's a more plausible scenario:
1) Human does work
2) Developer fresh out of college with limited google-foo and general DIY mentaility re-invents the wheel to make process 1000 times better than human
3) Re-invented wheel is tweeted about and another developer also unaware of 10s of other previously existing wheels wraps implementation into an API for whatever the popular language of the week is, making it 3 times less efficient.
4) Developer at startup integrates said library and publishes it as part of an SDK for a larger product suite, gaining no efficiency.
5) Customers note lack of many features other implementations of said wheel have had for decades. Many TAC cases and meetings are held.
6) Company hastily responds by glomming imitations of missing features onto oversimplistic implementation, doesn't bother to push upstream, and makes things 5 times less efficient.
7) https://xkcd.com/927/ happens, making things 3 times less efficient
8) Product has to run on new hardware and the fastest way to do that is run it on an emulator, making things 20 times less efficient.
9) Desk jockey gets distracted reading slashdot while waiting for laggy UI, takes 5 times longer to do job than necessary.
Game traffic is generally low bandwidth (but highly latency sensitive).
It's RTT that kills current network games and the more you offload to the cloud the more opportunity for lag.
The only hope of this industry is to introduce sedatives in the food supply so people are too wonked to play anything with twitch aspects.
There is still a lot we don't know. Like what's coming off the wicks when they inevitably overheat due to most of the devices being built very cheaply/disposable.
That said, there is zero reason to ban these things. The odds off them being worse than combustion are very low.
Research could lead to less harmful products.
We definitely need the research done. It's fine to warn against using vapes and educate the public, but we don't need bans in the meantime.
It's sad to see the abstinence-only-anti-tobacco lobby making things worse. But it's been like that for decades now... they dissemble so much in their ads they spoil any trust they might have initially had with their target audience.
(BTW as a smoker I had no problem with the ad with the tiny "bully" guy in tan pants and a white wifebeater... I laughed and liked that ad. One of the only ads that didn't make me get out of my chair to go have a puff. But everything by "the Truth" campaign endangers the longevity of my TV if there are throwable abjects nearby because all their ads are deceptive.)
Not only feel-good nonsense, but it makes a ridiculous generalization about "coders"
Yup. After all, the inefficient code that "coders" love to optimize had to come from somewhere. Where, if not from "coders"?
Someone hire this guy to write their headlines, please.
An appositive that modifies (restrictive appositive) shouldn't use commas. FWIW.
Whether you love or hate the harvard comma, it is generally agreed you don't use it on two-item lists.
I have some. They aren't like single-lense-across-the-face, rather more golf-glasses style, and I'm not sure the knock-off brand I got did the math as well as Oakley might (for even more $$$), but for a certain range of mild prescriptions it is possible.
Thanks and I was really wondering WTH was going on with low-end chicken lately. The way it crunches (when it shouldn't) is kinda hard to describe. Sorta styrofoamish I guess,
So you are recommending sites source their js from a site other than their own?
I didn't do any dabbling into ECMAscript until recently. Glad I waited. Seems modern ECMAScript plus HTML5 makes most of the frameworks useless if you are developing something that doesn't have to run on some grandmother's iMac G5.