This is a good point... realistically, why do the wireless keyboard/mouse makers use their own protocol, which is most likely far less secure than something designed by people who know what they are doing? BT is a relatively open protocol that has stood the test of time. Yes, it has had its security issues, but after 10+ years, it is pretty robust, and is definitely good enough, assuming proper pairing with 4-6 digit PINs (and re-pairing happens very infrequently.) If one needs more security, it can be handled at the application layer.
When I see some mouse or keyboard requiring its own dongle, I move on. If they are too cheap to use an industry standard for their stuff, then I'm suspecting they skimped on security somewhere else.
I personally am avoiding Samsung, and hoping for the HTC One M10 is as unlockable as the phones before it. My main issues are with Knox (permanently zapping a phone and rendering it forever unable to use services) only hurts legit owners of the device. I also despise the fact that it took a large bounty for someone to make a usable root for the S5, and the difficulty of a bootloader break on the latest models.
If Samsung allowed for an unlockable bootloader like the Nexus line, didn't fry parts of the phone with Knox (so it could be relocked/resold), their phones are very good in quality. But it is going to be a HTC, LG, or a Nexus phone for me, because of this.
Apple's model is at least honest. You pay for the hardware, and you also know that when OS support is pulled, you will wind up paying for hardware in a few years... but that is a lot better than finding any and every way to sell your data to third parties.
I have never understood the purpose of a "smart fridge". Does it help keep things cold better than a plain fridge? No. Does it provide a high temperature alarm? No. For the price of one of those overpriced units with fail-prone gewgaws, I can buy myself a fridge that runs on electric, but switches to natural gas or propane, and has an overtemp alarm. To boot, the only electricity the fridge needs if running on gas is the current to power the light bulb when the door is open.
I can see what -can- come with a smart fridge. Not just monitoring, with the data constantly sold, but having fridge doors lock until interactive ads are completed by the user, the fridge not allowing the door to open unless "authorized" food is stored (stuff packaged with encrypted RFID tags), and so on. Of course, there are the hacking implications. Turn a freezer off, let stuff get nice and full of botulism, turn freezer back on, the owners of the fridge would never be the wiser until they ate the food inside.
Of course, the smart fridge likely will have worse cooling performance than a regular one, just like a smartphone drops calls more often than an old flip phone.
No thanks... I'll take an absorption fridge that actually is worth the price premium any day over a smart fridge.
Even if wasn't a chip, one could always use a MicroSD card to stash firmware. An internal MicroSD reader is small and inexpensive, and can easily be made to be read-only. This might be a decent compromise between resistance from network/external attacks and the need to update. Of course, physical access can be an issue, but there is always requiring signed firmware and executables to deter that. If physical access isn't an issue, this might be an ideal way to upgrade firmware on devices that are somewhat accessible.
We have seen how voting can be changed with "trusted" computers and e-voting. Once a bit gets flipped, nobody will know about it. Online voting means that we can now add untrusted computers to the mix, and the next round of malware will go for this.
How about something actually secure? David Chaum has a verifiable means of voting. What is so wrong with paper ballots? No, they are not 100% secure, but it is a lot harder to get physical access to ballots to change entries than it is to add a few lines of code into a device's firmware, or have added functionality on a CPU mask that wasn't specified by the designers, but placed by the fab, just to change an election result.
Elections are too important to have them be "vote early, vote often" concepts. This isn't electing the next American Idol... this is a function critical to how a government works, and should be treated as such.
I'm just hoping this becomes officially supported in RedHat and downstreams (CentOS, Oracle UBL, SuSE, etc.) Backups will be easy, as I can just do a ZFS send, pipe it to a zbackup repository on a NAS, call it done.
RAID? For one pool, get a bunch of large, slow drives, add a pair of SSDs (as they will be hit heavily) for ZIL/L2ARC, and use RAID-Z2 for everything else. This way, if bit rot is encountered, ZFS can not just find it, but fix it. This way, random I/O is handled effectively, but most data can just migrate to the relatively slow spinning platters for safekeeping.
Probably the closest one can get, next to having the "secret sauce" software, would be to have a zpool with 20 drives, and have it configured as RAID-Z3, so it would take four drive failures to lose your data.
These are ideal for vast sums of low tier data... but Backblaze is based on storing stuff as cheaply as possible. For other needs like faster access, either add a "landing zone" for data in the pool with SSDs for ZIL/L2ARC, or as a compromise, go with smaller, faster HDDs for data being worked on fairly often.
Since iOS 4.x, if I use an all digit password, type it in on the full keyboard, I'll get the numpad and the OK button. I have used a longer PIN just for peace of mind, and with the fingerprint scanner, no excuse not to use a decent passphrase.
BitCoin will wind up between being the next best thing since sliced bread and refrigeration versus a tulip fad. It is a new sector for financial trade, and has already had its first tier of scammers and pump and dumpers.
What will happen is that it will evolve. Either BitCoin adds features, or a BTC 2.0 will come along to give more features to allow it to be used in more circumstances. Things like escrow where Charlie can independently inspect goods, then allow or decline an Alice -> Bob transaction. Or, allowing a transaction to have info in it, such as "sales tax/VAT is part of this payment" or a "For:" field, which shows that the seller did pay taxes, so a blockchain accounting can show the books are balanced.
I have read discussions on how to mitigate this. Perhaps some slight proof of work? Or, on the underlying protocol, use something like bcrypt and require a certain number of rounds to be run before the wallet is unlocked.
Brain wallets are useful. By having some key strengthening algorithm in place wouldn't stop brute-forcing, but it would at least slow them down.
I also develop, and I wonder how loud the fans are when I have a few VMs running, the GPUs being hammered, and a zbackup process going on in the background to save my home directory files to my NAS. The laptop can support up to 32 gigs of RAM, which is decent. It also can handle a PCIe based SSD, which also is a nice thing to have.
True. I'm assuming relatively low speed, due to congestion. Usually metro wrecks consist of rear-enders, light-runners, someone yielding into a car, not a lane, or other fender-benders. However, on country roads, there would be far fewer wrecks... but far more grievous. However, a vehicle's AI usually has fewer factors to figure out in those cases, and can react (brake, swerve, accelerate) far faster than a human can.
Regardless, the odds go up. Yes, one can wind up with the epic fail condition that a human could have avoided where an AI couldn't, but I'd suspect the other way round is far more likely.
If I have a 1 in ten thousand chance of getting in an accident with an automated vehicle, those are pretty good odds. On average, in the city I live in, I get nearly hit once every 100 times.
So, taking a 1 in 10,000 risk of an AI flub-up, even if it goes on my insurance, that's fine with me. It doesn't go on my driving record as a conviction, so I don't have to worry about points. With one free driver fsck-up every 3-5 years, where rates don't get hiked even if I am found culpable, I'll take those odds.
Toss in some dash cams, and it reduces those odds even more.
A while back, it was an excellent source for software... the closest thing Windows ever got to a repository. However when they started bundling foistware [1] with other people's downloads, they changed to yet another site that is not worth visiting.
[1]: Software that adds browser add-ons and toolbars, then adds a loopback VPN and a trusted root CA into Firefox's keystore is not exactly trustworthy.
AV software is just for checking that box for the legal eagles. The real security comes from keeping the web browser from being hit by exploits. Toss in NoScript and AdBlock, and this will go a lot further, security-wise, than any AV product. Mainly because AV products are always trying to play catch-up, while if the malvertising doesn't make it to the browser, or get executed, even a zero-day is defeated.
RedHat, and SuSE have been given FIPS/Common Criteria/EAL certification in the past. Right now, it is pending for RHEL 7.x, but it will come eventually, and this shows the OS has seen independent validation by a very expensive lab that isn't just limited to one country.
CentOS, Oracle Linux, and other downstreams inherit this as well... maybe not the certification, but the structure.
Debian/Ubuntu isn't a slouch either, nor are the other mainstream variants, just because there are people who actually care about security scrutinizing the distributions. They won't catch everything, but it gives some assurance that the OS will pass muster.
Precisely. A browser needs to have security patches be ready for users almost immediately, so if a downstream fork doesn't get patches propagated, it becomes a security issue in waiting.
Because browsers are either the primary attack vector for malware, or at least comparable to Trojans, security is paramount, and firms forking a browser cannot take doing this lightly, because there will need to be maintainers who have to see what security issues are going on with the upstream and either copy code, or write code to fix them in their product.
The "furthest" I wind up straying is using Chromium on Ubuntu. Since Chrome and Chromium have a lot of cross-pollination, a bug in one will get patched in both.
Slashdot is one of a number of websites (Zam and bikeforums are others) which are worth supporting directly. I'd be more than willing to pay either by the page, or for periods of time.
1: Start with a decent phone that has an unlockable bootloader. HTC devices come to mind, as well as Google Nexus offerings. 2: Install CyanogenMod, or a good base ROM with support. It doesn't hurt to donate some as well to said project. Gapps after that. 3: Install XPrivacy if possible. This does an excellent job at stopping nosy apps cold. 4: Install AFWall+. This is a last resort, but a solid defense at keeping apps that phone home from doing so. 5: Enable mock locations, and set your GPS when on long trips. 6: Get a good VPN service. I am a fan of VyprVPN because they had a good Linux booth at a recent convention in Austin. There are others as well. Or, you can set up one yourself on a remote virtual machine hosting service. 7: Install F-droid and Ad-Away. 8: For a web browser, I have found Dolphin pretty decent, and good at stopping some of the nastier stuff. 9: Install Titanium Backup to back up apps and their data encrypted, then push them off to a cloud provider.
Yes, this takes time to set up, but it works well, and takes very little fussing or upkeep to keep things working.
It depends on who you are trying to protect from. If worried about another person on that machine, browse in a VM with encrypted filesystems [1], roll it back when done, and occasionally force a TRIM on the SSD to ensure any data on there is -gone-. With tools like Vagrant, one can even have the browsing VM be installed and provisioned, with one's bookmarks fetched/synced from another source.
If wanting to keep data away from ad-mongers, do your browsing in separate VMs and browsers. Banking goes into Firefox, everything else goes into a VM in Chrome that uses a VPN so IPs can't be correlated. Privacy-sensitive stuff, put it in a VM, or use a separate physical box so things like battery status can't be passed across the hypervisor barrier.
I wonder how tough it would be to have a sane implementation of it. First, a small stub that can copy back a version of UEFI from a ROM (not EEPROM... true ROM.) Perhaps, in addition, a pristine backup copy that is kept read-only, so an updated version can be kept ready to go. Neither of these two can be altered. This way, if the UEFI firmware gets fricasseed, it isn't too difficult to get the machine back to an operable state. Phones can do this with their bootloaders.
Ideally, it would be nice to have a hypervisor in UEFI that can be turned on, with it doing translation (where the files are shown, but not editable, or are virtualized). Someone blows away a filesystem, who cares. It would have to be done on the hypervisor layer to have any effect.
1: Legal issues. If the data center is located even remotely near international waters, that data center then belongs to who has the biggest guns. Plus, it doesn't take much for someone to destroy it out of spite. Unlike the land where there can be guards or at least a few Knightscope models to look for trespassers, sea patrols are pretty expensive.
2: People forget about barnacles and other critters calling intake ducts home. These things can clog pipes up very quickly, and it takes a lot of engineering and work to deal with these. Just tossing pipes in the sea without some method of cleaning them is asking for an eventual blockage.
3: Corrosion. There is a reason why a doodad at West Marine costs 10 times the same doodad that isn't marine grade at Camping World. Water chews things up quickly.
4: Upkeep. A data center on land is a solved problem. On water, economies of scale are not there, so it can be easily order of magnitudes more difficult to do basic tasks.
Slashdot Mirror
I wonder if a $10 dongle would remedy the situation with most laptops.
Realistically, in a dense office environment, it might be better to just go with wired devices, to minimize congestion on the airwaves.
This is a good point... realistically, why do the wireless keyboard/mouse makers use their own protocol, which is most likely far less secure than something designed by people who know what they are doing? BT is a relatively open protocol that has stood the test of time. Yes, it has had its security issues, but after 10+ years, it is pretty robust, and is definitely good enough, assuming proper pairing with 4-6 digit PINs (and re-pairing happens very infrequently.) If one needs more security, it can be handled at the application layer.
When I see some mouse or keyboard requiring its own dongle, I move on. If they are too cheap to use an industry standard for their stuff, then I'm suspecting they skimped on security somewhere else.
I personally am avoiding Samsung, and hoping for the HTC One M10 is as unlockable as the phones before it. My main issues are with Knox (permanently zapping a phone and rendering it forever unable to use services) only hurts legit owners of the device. I also despise the fact that it took a large bounty for someone to make a usable root for the S5, and the difficulty of a bootloader break on the latest models.
If Samsung allowed for an unlockable bootloader like the Nexus line, didn't fry parts of the phone with Knox (so it could be relocked/resold), their phones are very good in quality. But it is going to be a HTC, LG, or a Nexus phone for me, because of this.
Apple's model is at least honest. You pay for the hardware, and you also know that when OS support is pulled, you will wind up paying for hardware in a few years... but that is a lot better than finding any and every way to sell your data to third parties.
I have never understood the purpose of a "smart fridge". Does it help keep things cold better than a plain fridge? No. Does it provide a high temperature alarm? No. For the price of one of those overpriced units with fail-prone gewgaws, I can buy myself a fridge that runs on electric, but switches to natural gas or propane, and has an overtemp alarm. To boot, the only electricity the fridge needs if running on gas is the current to power the light bulb when the door is open.
I can see what -can- come with a smart fridge. Not just monitoring, with the data constantly sold, but having fridge doors lock until interactive ads are completed by the user, the fridge not allowing the door to open unless "authorized" food is stored (stuff packaged with encrypted RFID tags), and so on. Of course, there are the hacking implications. Turn a freezer off, let stuff get nice and full of botulism, turn freezer back on, the owners of the fridge would never be the wiser until they ate the food inside.
Of course, the smart fridge likely will have worse cooling performance than a regular one, just like a smartphone drops calls more often than an old flip phone.
No thanks... I'll take an absorption fridge that actually is worth the price premium any day over a smart fridge.
Even if wasn't a chip, one could always use a MicroSD card to stash firmware. An internal MicroSD reader is small and inexpensive, and can easily be made to be read-only. This might be a decent compromise between resistance from network/external attacks and the need to update. Of course, physical access can be an issue, but there is always requiring signed firmware and executables to deter that. If physical access isn't an issue, this might be an ideal way to upgrade firmware on devices that are somewhat accessible.
We have seen how voting can be changed with "trusted" computers and e-voting. Once a bit gets flipped, nobody will know about it. Online voting means that we can now add untrusted computers to the mix, and the next round of malware will go for this.
How about something actually secure? David Chaum has a verifiable means of voting. What is so wrong with paper ballots? No, they are not 100% secure, but it is a lot harder to get physical access to ballots to change entries than it is to add a few lines of code into a device's firmware, or have added functionality on a CPU mask that wasn't specified by the designers, but placed by the fab, just to change an election result.
Elections are too important to have them be "vote early, vote often" concepts. This isn't electing the next American Idol... this is a function critical to how a government works, and should be treated as such.
I'm just hoping this becomes officially supported in RedHat and downstreams (CentOS, Oracle UBL, SuSE, etc.) Backups will be easy, as I can just do a ZFS send, pipe it to a zbackup repository on a NAS, call it done.
RAID? For one pool, get a bunch of large, slow drives, add a pair of SSDs (as they will be hit heavily) for ZIL/L2ARC, and use RAID-Z2 for everything else. This way, if bit rot is encountered, ZFS can not just find it, but fix it. This way, random I/O is handled effectively, but most data can just migrate to the relatively slow spinning platters for safekeeping.
Probably the closest one can get, next to having the "secret sauce" software, would be to have a zpool with 20 drives, and have it configured as RAID-Z3, so it would take four drive failures to lose your data.
These are ideal for vast sums of low tier data... but Backblaze is based on storing stuff as cheaply as possible. For other needs like faster access, either add a "landing zone" for data in the pool with SSDs for ZIL/L2ARC, or as a compromise, go with smaller, faster HDDs for data being worked on fairly often.
Since iOS 4.x, if I use an all digit password, type it in on the full keyboard, I'll get the numpad and the OK button. I have used a longer PIN just for peace of mind, and with the fingerprint scanner, no excuse not to use a decent passphrase.
BitCoin will wind up between being the next best thing since sliced bread and refrigeration versus a tulip fad. It is a new sector for financial trade, and has already had its first tier of scammers and pump and dumpers.
What will happen is that it will evolve. Either BitCoin adds features, or a BTC 2.0 will come along to give more features to allow it to be used in more circumstances. Things like escrow where Charlie can independently inspect goods, then allow or decline an Alice -> Bob transaction. Or, allowing a transaction to have info in it, such as "sales tax/VAT is part of this payment" or a "For:" field, which shows that the seller did pay taxes, so a blockchain accounting can show the books are balanced.
I have read discussions on how to mitigate this. Perhaps some slight proof of work? Or, on the underlying protocol, use something like bcrypt and require a certain number of rounds to be run before the wallet is unlocked.
Brain wallets are useful. By having some key strengthening algorithm in place wouldn't stop brute-forcing, but it would at least slow them down.
I also develop, and I wonder how loud the fans are when I have a few VMs running, the GPUs being hammered, and a zbackup process going on in the background to save my home directory files to my NAS. The laptop can support up to 32 gigs of RAM, which is decent. It also can handle a PCIe based SSD, which also is a nice thing to have.
True. I'm assuming relatively low speed, due to congestion. Usually metro wrecks consist of rear-enders, light-runners, someone yielding into a car, not a lane, or other fender-benders. However, on country roads, there would be far fewer wrecks... but far more grievous. However, a vehicle's AI usually has fewer factors to figure out in those cases, and can react (brake, swerve, accelerate) far faster than a human can.
Regardless, the odds go up. Yes, one can wind up with the epic fail condition that a human could have avoided where an AI couldn't, but I'd suspect the other way round is far more likely.
If I have a 1 in ten thousand chance of getting in an accident with an automated vehicle, those are pretty good odds. On average, in the city I live in, I get nearly hit once every 100 times.
So, taking a 1 in 10,000 risk of an AI flub-up, even if it goes on my insurance, that's fine with me. It doesn't go on my driving record as a conviction, so I don't have to worry about points. With one free driver fsck-up every 3-5 years, where rates don't get hiked even if I am found culpable, I'll take those odds.
Toss in some dash cams, and it reduces those odds even more.
A while back, it was an excellent source for software... the closest thing Windows ever got to a repository. However when they started bundling foistware [1] with other people's downloads, they changed to yet another site that is not worth visiting.
[1]: Software that adds browser add-ons and toolbars, then adds a loopback VPN and a trusted root CA into Firefox's keystore is not exactly trustworthy.
Before or after being infected with Zika?
AV software is just for checking that box for the legal eagles. The real security comes from keeping the web browser from being hit by exploits. Toss in NoScript and AdBlock, and this will go a lot further, security-wise, than any AV product. Mainly because AV products are always trying to play catch-up, while if the malvertising doesn't make it to the browser, or get executed, even a zero-day is defeated.
RedHat, and SuSE have been given FIPS/Common Criteria/EAL certification in the past. Right now, it is pending for RHEL 7.x, but it will come eventually, and this shows the OS has seen independent validation by a very expensive lab that isn't just limited to one country.
CentOS, Oracle Linux, and other downstreams inherit this as well... maybe not the certification, but the structure.
Debian/Ubuntu isn't a slouch either, nor are the other mainstream variants, just because there are people who actually care about security scrutinizing the distributions. They won't catch everything, but it gives some assurance that the OS will pass muster.
Precisely. A browser needs to have security patches be ready for users almost immediately, so if a downstream fork doesn't get patches propagated, it becomes a security issue in waiting.
Because browsers are either the primary attack vector for malware, or at least comparable to Trojans, security is paramount, and firms forking a browser cannot take doing this lightly, because there will need to be maintainers who have to see what security issues are going on with the upstream and either copy code, or write code to fix them in their product.
The "furthest" I wind up straying is using Chromium on Ubuntu. Since Chrome and Chromium have a lot of cross-pollination, a bug in one will get patched in both.
This. Please.
Slashdot is one of a number of websites (Zam and bikeforums are others) which are worth supporting directly. I'd be more than willing to pay either by the page, or for periods of time.
I just wish it had Android 6.x support. :/
There is a balance, but it isn't easy for most:
1: Start with a decent phone that has an unlockable bootloader. HTC devices come to mind, as well as Google Nexus offerings.
2: Install CyanogenMod, or a good base ROM with support. It doesn't hurt to donate some as well to said project. Gapps after that.
3: Install XPrivacy if possible. This does an excellent job at stopping nosy apps cold.
4: Install AFWall+. This is a last resort, but a solid defense at keeping apps that phone home from doing so.
5: Enable mock locations, and set your GPS when on long trips.
6: Get a good VPN service. I am a fan of VyprVPN because they had a good Linux booth at a recent convention in Austin. There are others as well. Or, you can set up one yourself on a remote virtual machine hosting service.
7: Install F-droid and Ad-Away.
8: For a web browser, I have found Dolphin pretty decent, and good at stopping some of the nastier stuff.
9: Install Titanium Backup to back up apps and their data encrypted, then push them off to a cloud provider.
Yes, this takes time to set up, but it works well, and takes very little fussing or upkeep to keep things working.
It depends on who you are trying to protect from. If worried about another person on that machine, browse in a VM with encrypted filesystems [1], roll it back when done, and occasionally force a TRIM on the SSD to ensure any data on there is -gone-. With tools like Vagrant, one can even have the browsing VM be installed and provisioned, with one's bookmarks fetched/synced from another source.
If wanting to keep data away from ad-mongers, do your browsing in separate VMs and browsers. Banking goes into Firefox, everything else goes into a VM in Chrome that uses a VPN so IPs can't be correlated. Privacy-sensitive stuff, put it in a VM, or use a separate physical box so things like battery status can't be passed across the hypervisor barrier.
I didn't realize that UEFI is everything now.
I wonder how tough it would be to have a sane implementation of it. First, a small stub that can copy back a version of UEFI from a ROM (not EEPROM... true ROM.) Perhaps, in addition, a pristine backup copy that is kept read-only, so an updated version can be kept ready to go. Neither of these two can be altered. This way, if the UEFI firmware gets fricasseed, it isn't too difficult to get the machine back to an operable state. Phones can do this with their bootloaders.
Ideally, it would be nice to have a hypervisor in UEFI that can be turned on, with it doing translation (where the files are shown, but not editable, or are virtualized). Someone blows away a filesystem, who cares. It would have to be done on the hypervisor layer to have any effect.
Open waters are asking for trouble:
1: Legal issues. If the data center is located even remotely near international waters, that data center then belongs to who has the biggest guns. Plus, it doesn't take much for someone to destroy it out of spite. Unlike the land where there can be guards or at least a few Knightscope models to look for trespassers, sea patrols are pretty expensive.
2: People forget about barnacles and other critters calling intake ducts home. These things can clog pipes up very quickly, and it takes a lot of engineering and work to deal with these. Just tossing pipes in the sea without some method of cleaning them is asking for an eventual blockage.
3: Corrosion. There is a reason why a doodad at West Marine costs 10 times the same doodad that isn't marine grade at Camping World. Water chews things up quickly.
4: Upkeep. A data center on land is a solved problem. On water, economies of scale are not there, so it can be easily order of magnitudes more difficult to do basic tasks.