It's like a grocery store with free food, where the shoppers are unknowingly participating in pharmaceutical testing
That's... actually a pretty great analogy. I'm stealing that.
Really every time I look at a cell phone these days I sigh. I like to improve free software and/or make custom things for my own use that maybe might someday be useful to other people... but only on open OSes. I pretty much only do free work on free things. Despite the linux roots, Android isn't open enough for me to even want to try... and the hardware underneath it isn't either. Shame. Back in my college days one would have thought "wow I wonder what that kid is going to do when he can get all that computing power onto a device that fits in his hands and has all sorts of sensors and gadgets built in." Answer turns out to be... spend a friggin whole afternoon time turning off all the crap that came pre-installed and then wonder why really basic things like file managers and notepads are not pre-installed, and chafe at access restrictions that seem to only really be effective at keeping me out of my own phone but I can't trust to actually protect me against the crazy ecosystem since they are so poorly documented I have no clue what any of the security settings actually do vs what they say they do... if they say anything coherent at all.
So I then just use it to take pictures and make phone calls and pretty much nothing else. Sad. Not the way I pictured the future two decades ago.
The closest I got to actually doing anything was wanting to use an old obsolete phone to sit between a game controller and the console to undo the feeble dead zones game developers ruin their console ports with... since it had both bluetooth and USB gadget. You couldn't even get at the friggin bluetooth or USB hardware at a useful level. It's was all extremely high level HAL (which probably gets yanked out from underneath developers and replaced with another capriciously designed API once every 4 years or so.) Fuck it, old phones are useless for hacking unless you're going to break out the EE gear and invest months into reverse engineering that shit.
Yeah we might as well give up and just let these guys wander around the globe and use bank accounts anywhere they please since we can't lock them up. Heck just forget the whole thing happened, I'm sure they learned their lesson.
Meanwhile, internal documents show, a trade group representing businesses that could face new regulations and lawsuits if the study were released had frequent access to top EPA officials and pressed them to either keep it under wraps or change its findings.
...and the cover-up is (usually) worse than the crime. They never learn. You think tobacco would be the whipping child of the courts these days if it had been a simple case of "oh, when we found out we put warnings on the boxes right away"? These interest groups are a liability to their industries but the industries can't get enough of them.
You can try it out on a few natural language sentence diagram applications e.g. http://www.link.cs.cmu.edu/cgi... (though that server seems to be unresponsive at the moment.)
Here's one that hits many of the words listed here.
give or take point get set and mark go for good line plays make the dead run a light roll
Yeah... the generic IPSec support for control plane stuff is even better, but I'll take RADSec when I can't get that.
(We were actually running it from FreeRADIUS with the eduroam TLRs for a while but they stopped supporting it. Hopefully to return some day.)
Was just reading up on EAP-PWD as a result of this thread... needs a password change mechanism and identity privacy but good to see something else practical gaining some small toehold (on Android).
Maybe wrap it in an opportunistic unauthenticated TLS session to gain fast resumption and identity privacy against passive (but not active) attackers, but that still leaves you without an inline password-change mechanism...
I've never seen a properly configured supplicant in my life.
If you have few enough users that you can safely share the PSK among them, you have few enough users to go secure their supplicants. Also, even misconfigured OSX users are relatively safe assuming they connect safely the first time, given the supplicant's pinning behavior.
I've also never seen a secure authenticator in my life.
...you ain't been around. Most systems these days authenticate from the controller, not the AP, so the RADIUS all happens in the DC, behind locked doors. AP/Controller comms is by IPSec or a vendor's minor perversion of IPSec, usually built on top of a hardware TPM loaded with a factory device cert. Also a lot of the controllers support either terminating IPSec generically, or RadSec for RADIUS.
(in the case of the OpenWRT setup I mentioned, RADIUS traffic never leaves the box, but of course you could do RADSec or IPSec if you needed to.)
The F**** it is. If you select a PSK with sufficient entropy and successfully guard it from "undesirables" it's way more secure than enterprise.
It's the guarding it from undesirables part that makes WPA2 less secure. Otherwise it is as secure, not more secure, than properly implemented WPA2-Enterprise. The trick to properly implementing WPA2-Enterprise is mostly in the client setup, as long as you follow some pretty well understoof best practices on the server side.
As to the GP: if your OpenWRT box has enough RAM and flash, you can get the entire WPA2-Enterprise stack up on a single device.
Yes, pretty sure. WPA3 development for hostapd has been proceeding abreast the standard development process. Perhaps some chipsets may not be able to pull off the 192-bit crypto suite in hardware... but nearly nobody will deploy that I would guess. No idea on timelines... you can watch for code commits on w1.fi/cgit but you need to know a whole buttload of acronyms to understand WTH is going on.
It's an improvement, and I'd much rather have it than not, but without any authentication you have no way of knowing in a public WiFi hotspot if the AP you connected to is the one operated by the hotspot, or the one running off the laptop of the guy next to you sipping a latte he payed for from the bank account of the last guy who sat where you are sitting. Same goes for anything using a symmetric key, so adding a WiFi password that you then tell to everyone does not help things.
It's TBD whether the extra safety it provides will balance out the extra risk assumed because everyone feels compelled to use unauthenticated WiFi systems for customer convenience... but since nearly none of them were doing WPA2-E with a known guest user/password and a CA-signed AAA cert to begin with, it's probably a net plus.
The FOSS projects (other than base OS) that I am most closely involved with in using where I work fall into this category... but it's been hard to sell buying those support agreements to management. Either we're using a project because it "costs nothing" and we're ignoring the availability of support to back up our local talent, or we use a non-FOSS project (with its support) because management seems to consider for-pay software more reputable... and they will even prefer some third party supporting someone else's FOSS software to buying support directly from that project for some reason. The more commercial sounding the vendor, the more likely we'll go with them. It's a bit perverse.
On the other hand I have the flexibility at this job to do a bit of customization and send PRs back upstream, so at least we sort of pay... in code.
Anyway this model sort of ignores the sunk cost of getting the software into a useful state to begin with... you only make money on the feature adds, and you have to figure out how to backfill all the time spent initially developing the base project without pricing yourself out of the market of everyone competing to support your project.
I'm a pretty strong FOSS advocate but given the state of things I really do not see a problem with the model of "payers get early access" model... which used to be called "ransomware" before that word took on a whole new meaning. Basically people can get their feature requests worked on and then embargoed so only they (or in some models, any paying customer) can use that code for a certain number of months. This allows competitive advantages to be bought which adds some value to the purchase.
The end result is the FOSS edition of the product trails the leading edge by some time lag, but as long as the organization has a strong charter, everything eventually ends up FOSS.
Where have you been in the 90s? The situation was FAR more of a mess, with lots of proprietary codecs and players like Real and On2.
Well, they may not be popular anymore, but once they are there, they are still there, so the situation can only get worse if you are writing a comprehensive library:-)
Should they just adopt new and inferior solutions and hope for the best?
I think the idea here is that the follow-up science/engineering to academic initiatives doesn't actually get funded/done because the unoptimized first cut of a new methodology isn't instantly better than the state of the art. It's basically arguing that the technology is undergoing path dependence, which is no big surprise as it happens all the time in lots of areas.
That said, the AV crowd has sure made a complete and utter mess of their formats. Piles of CODECs all with various levels of support for piles of video modes all bundled into piles of meta-formats with piles of methods for syncing up audio/ancillary/multistream... my eyes glaze over pretty quickly these days when faced with navigating that maze. Having options is awesome. Leaving them perpetually scattered around on the floor like a bunch of legos... not so much.
(Still waiting to see someone with serious genetic-algorithms chops tackle lossless CODECs... there's a ready-made problem with a cut and dry fitness function right there.)
They are starting to realize a lot of the freshwater microplastic is from large businesses putting compostables in plastics bags which get ground up and spread on fields.
We recycle all our plastic bags here... it isn't hard. However given that their are always going to be assholes throwing them out the car window, I suppose it is better to phase them out. Which means I need some sort of mnemonic for remembering to put the reusables back in the car. And better reusables than the crap ones the grocery store sells which can't hold three 2-liters without ripping the side because they sewed the handle support into a single ply of cloth... and usually straight through foil on the thermal bags, which goes first since it cannot stretch. Stupid.
Yeah, well they would get even better security still if the walled gardens would democratize the vetting process, and allow users to add multiple authorities which vouch for apps, and choose which authorities to trust (to the possible exclusion of "the store" whichever store that happens to be.)
(Really it astounds me that people stand for being forced to divulge a user identity in order to obtain all software, including free-as-in-beer and opensource, but that's an othogonal matter. It also astounds me that people stand for having basic things like a goddamn text notepad or file manager missing from the base install and relying on 3rd parties, but hey... it's the 10's)
Really I'm more inclined towards the systems that apply tactile stimulation to a patch on the user's skin, instead of crowding out their already overtaxed auditory spectrum. https://jneuroengrehab.biomedc...
The new tools are insanely better by every single measure possible.
I use both, and I know that iproute2 is definitely better in many respects.
But definitey not all: the output is less readable/useful (workflow matters more than logical structure, guys) and the manpages suck (yes you should have BNF somewhere in the manpage, but it should not *be* the manpage. A manpage should list most common usages first, and end with a list of examples... examples, not restatements of the BNF... for intermediate use cases.)
That's for a different class of problem. QC is a much bigger threat to all widely deployed asymmetric key exchange schemes and public key systems. Basically this means any conversation that is recorded now may be decrypted later, since almost nothing uses offline-pre-shared keys these days... that model just does not fit how the world wants to use cryptography.
Pilot implementations of the new post-quantum key exchanges (kex) are already starting to become available e.g. as strongswan plugins, but they might be a bit premature as implementations... I'd like to see more cryptographers who know their shit sign off on the lightweight forms of RLWE-kex before it gets deployed alone as a kex. Until then it would probably be better to also performs a non-qc-safe kex and xor the two, in case there is a flaw in it.
Really I'm not going to worry about the upcoming Krynoid invasion at least until they manage to get one of those new-fangled ground-up-re-engineered photosynthetic cycles edited into a viable plant.
Heheh. Hate to break it to you, but name LEDE isn't the part of LEDE that is surviving the re-merge with OpenWRT. (I did like that name better, but it's the code and project processes that matter so I'm glad to see everyone pulling together again.)
Slashdot Mirror
It's like a grocery store with free food, where the shoppers are unknowingly participating in pharmaceutical testing
That's... actually a pretty great analogy. I'm stealing that.
Really every time I look at a cell phone these days I sigh. I like to improve free software and/or make custom things for my own use that maybe might someday be useful to other people... but only on open OSes. I pretty much only do free work on free things. Despite the linux roots, Android isn't open enough for me to even want to try... and the hardware underneath it isn't either. Shame. Back in my college days one would have thought "wow I wonder what that kid is going to do when he can get all that computing power onto a device that fits in his hands and has all sorts of sensors and gadgets built in." Answer turns out to be... spend a friggin whole afternoon time turning off all the crap that came pre-installed and then wonder why really basic things like file managers and notepads are not pre-installed, and chafe at access restrictions that seem to only really be effective at keeping me out of my own phone but I can't trust to actually protect me against the crazy ecosystem since they are so poorly documented I have no clue what any of the security settings actually do vs what they say they do... if they say anything coherent at all.
So I then just use it to take pictures and make phone calls and pretty much nothing else. Sad. Not the way I pictured the future two decades ago.
The closest I got to actually doing anything was wanting to use an old obsolete phone to sit between a game controller and the console to undo the feeble dead zones game developers ruin their console ports with... since it had both bluetooth and USB gadget. You couldn't even get at the friggin bluetooth or USB hardware at a useful level. It's was all extremely high level HAL (which probably gets yanked out from underneath developers and replaced with another capriciously designed API once every 4 years or so.) Fuck it, old phones are useless for hacking unless you're going to break out the EE gear and invest months into reverse engineering that shit.
Yeah we might as well give up and just let these guys wander around the globe and use bank accounts anywhere they please since we can't lock them up. Heck just forget the whole thing happened, I'm sure they learned their lesson.
Meanwhile, internal documents show, a trade group representing businesses that could face new regulations and lawsuits if the study were released had frequent access to top EPA officials and pressed them to either keep it under wraps or change its findings.
...and the cover-up is (usually) worse than the crime. They never learn. You think tobacco would be the whipping child of the courts these days if it had been a simple case of "oh, when we found out we put warnings on the boxes right away"? These interest groups are a liability to their industries but the industries can't get enough of them.
The real killer is concrete production
Well, there's this at least.
You can try it out on a few natural language sentence diagram applications e.g. http://www.link.cs.cmu.edu/cgi... (though that server seems to be unresponsive at the moment.)
Here's one that hits many of the words listed here.
give or take point get set and mark go for good line plays make the dead run a light roll
Yeah... the generic IPSec support for control plane stuff is even better, but I'll take RADSec when I can't get that.
(We were actually running it from FreeRADIUS with the eduroam TLRs for a while but they stopped supporting it. Hopefully to return some day.)
Was just reading up on EAP-PWD as a result of this thread... needs a password change mechanism and identity privacy but good to see something
else practical gaining some small toehold (on Android).
Maybe wrap it in an opportunistic unauthenticated TLS session to gain fast resumption and identity privacy against passive (but not active) attackers, but that still leaves you without an inline password-change mechanism...
I guess HPE-Aruba counts as a lot of nothing?
https://www.arubanetworks.com/...
I've never seen a properly configured supplicant in my life.
If you have few enough users that you can safely share the PSK among them, you have few enough
users to go secure their supplicants. Also, even misconfigured OSX users are relatively safe assuming they
connect safely the first time, given the supplicant's pinning behavior.
I've also never seen a secure authenticator in my life.
...you ain't been around. Most systems these days authenticate from the controller, not the AP,
so the RADIUS all happens in the DC, behind locked doors. AP/Controller comms is by IPSec
or a vendor's minor perversion of IPSec, usually built on top of a hardware TPM loaded with a
factory device cert. Also a lot of the controllers support either terminating IPSec generically,
or RadSec for RADIUS.
(in the case of the OpenWRT setup I mentioned, RADIUS traffic never leaves the box, but
of course you could do RADSec or IPSec if you needed to.)
The F**** it is. If you select a PSK with sufficient entropy and successfully guard it from "undesirables" it's way more secure than enterprise.
It's the guarding it from undesirables part that makes WPA2 less secure. Otherwise it is as secure, not more secure, than properly implemented WPA2-Enterprise.
The trick to properly implementing WPA2-Enterprise is mostly in the client setup, as long as you follow some pretty well understoof best practices on the server side.
As to the GP: if your OpenWRT box has enough RAM and flash, you can get the entire WPA2-Enterprise stack up on a single device.
It's all the little TV-attached gadgets these days. No laptops or phones ship without WPA2-Enterprise.
Now, tons of them still arrive with an insecurable PEAP-MSCHAP/TTLS implementation (thanks tons Google) but that's a different issue.
Yes, pretty sure. WPA3 development for hostapd has been proceeding abreast the standard development process. Perhaps some chipsets may not be able to pull off the 192-bit crypto suite in hardware... but nearly nobody will deploy that I would guess. No idea on timelines... you can watch for code commits on w1.fi/cgit but you need to know a whole buttload of acronyms to understand WTH is going on.
It's an improvement, and I'd much rather have it than not, but without any authentication you have no way of knowing in a public WiFi hotspot if the AP you connected to is the one operated by the hotspot, or the one running off the laptop of the guy next to you sipping a latte he payed for from the bank account of the last guy who sat where you are sitting. Same goes for anything using a symmetric key, so adding a WiFi password that you then tell to everyone does not help things.
It's TBD whether the extra safety it provides will balance out the extra risk assumed because everyone feels compelled to use unauthenticated WiFi systems for customer convenience... but since nearly none of them were doing WPA2-E with a known guest user/password and a CA-signed AAA cert to begin with, it's probably a net plus.
The FOSS projects (other than base OS) that I am most closely involved with in using where I work fall into this category... but it's been hard to sell buying those support agreements to management. Either we're using a project because it "costs nothing" and we're ignoring the availability of support to back up our local talent, or we use a non-FOSS project (with its support) because management seems to consider for-pay software more reputable... and they will even prefer some third party supporting someone else's FOSS software to buying support directly from that project for some reason. The more commercial sounding the vendor, the more likely we'll go with them. It's a bit perverse.
On the other hand I have the flexibility at this job to do a bit of customization and send PRs back upstream, so at least we sort of pay... in code.
Anyway this model sort of ignores the sunk cost of getting the software into a useful state to begin with... you only make money on the feature adds, and you have to figure out how to backfill all the time spent initially developing the base project without pricing yourself out of the market of everyone competing to support your project.
I'm a pretty strong FOSS advocate but given the state of things I really do not see a problem with the model of "payers get early access" model... which used to be called "ransomware" before that word took on a whole new meaning. Basically people can get their feature requests worked on and then embargoed so only they (or in some models, any paying customer) can use that code for a certain number of months. This allows competitive advantages to be bought which adds some value to the purchase.
The end result is the FOSS edition of the product trails the leading edge by some time lag, but as long as the organization has a strong charter, everything eventually ends up FOSS.
Where have you been in the 90s? The situation was FAR more of a mess, with lots of proprietary codecs and players like Real and On2.
Well, they may not be popular anymore, but once they are there, they are still there, so the situation can only get worse if you are writing a comprehensive library :-)
Should they just adopt new and inferior solutions and hope for the best?
I think the idea here is that the follow-up science/engineering to academic initiatives doesn't actually get funded/done because the unoptimized first cut of a new methodology isn't instantly better than the state of the art. It's basically arguing that the technology is undergoing path dependence, which is no big surprise as it happens all the time in lots of areas.
That said, the AV crowd has sure made a complete and utter mess of their formats. Piles of CODECs all with various levels of support for piles of video modes all bundled into piles of meta-formats with piles of methods for syncing up audio/ancillary/multistream... my eyes glaze over pretty quickly these days when faced with navigating that maze. Having options is awesome. Leaving them perpetually scattered around on the floor like a bunch of legos... not so much.
(Still waiting to see someone with serious genetic-algorithms chops tackle lossless CODECs... there's a ready-made problem with a cut and dry fitness function right there.)
They are starting to realize a lot of the freshwater microplastic is from large businesses putting compostables in plastics bags which get ground up and spread on fields.
We recycle all our plastic bags here... it isn't hard. However given that their are always going to be assholes throwing them out the car window, I suppose it is better to phase them out. Which means I need some sort of mnemonic for remembering to put the reusables back in the car. And better reusables than the crap ones the grocery store sells which can't hold three 2-liters without ripping the side because they sewed the handle support into a single ply of cloth... and usually straight through foil on the thermal bags, which goes first since it cannot stretch. Stupid.
Yeah, well they would get even better security still if the walled gardens would democratize the vetting process, and allow users to add multiple authorities which vouch for apps, and choose which authorities to trust (to the possible exclusion of "the store" whichever store that happens to be.)
(Really it astounds me that people stand for being forced to divulge a user identity in order to obtain all software, including free-as-in-beer and opensource, but that's an othogonal matter. It also astounds me that people stand for having basic things like a goddamn text notepad or file manager missing from the base install and relying on 3rd parties, but hey... it's the 10's)
Indeed... https://en.wikipedia.org/wiki/...
Really I'm more inclined towards the systems that apply tactile stimulation to a patch on the user's skin, instead of crowding out their already overtaxed auditory spectrum. https://jneuroengrehab.biomedc...
The new tools are insanely better by every single measure possible.
I use both, and I know that iproute2 is definitely better in many respects.
But definitey not all: the output is less readable/useful (workflow matters more than logical structure, guys) and the manpages suck (yes you should have BNF somewhere in the manpage, but it should not *be* the manpage. A manpage should list most common usages first, and end with a list of examples... examples, not restatements of the BNF... for intermediate use cases.)
Don't be bummed. Planet 9 really may be from outer space .
We would only have to double the number of bits.
That's for a different class of problem. QC is a much bigger threat to all widely deployed asymmetric key exchange schemes and public key systems. Basically this means any conversation that is recorded now may be decrypted later, since almost nothing uses offline-pre-shared keys these days... that model just does not fit how the world wants to use cryptography.
Pilot implementations of the new post-quantum key exchanges (kex) are already starting to become available e.g. as strongswan plugins, but they might be a bit premature as implementations... I'd like to see more cryptographers who know their shit sign off on the lightweight forms of RLWE-kex before it gets deployed alone as a kex. Until then it would probably be better to also performs a non-qc-safe kex and xor the two, in case there is a flaw in it.
Really I'm not going to worry about the upcoming Krynoid invasion at least until they manage to get one of those new-fangled ground-up-re-engineered photosynthetic cycles edited into a viable plant.
And probably not even then.
good hacking jobs would go unnoticed.
...only 0.001% of hacking activity is of this quality, and it's usually not directed at your house.
Heheh. Hate to break it to you, but name LEDE isn't the part of LEDE that is surviving the re-merge with OpenWRT. (I did like that name better, but it's the code and project processes that matter so I'm glad to see everyone pulling together again.)