The Cloudflare DDoS stuff is really annoying. You have to enable JavaScript (and it takes a few seconds) to load pages that would otherwise display fine w/ NoScript blocking just about everything. I'm at the point where I just close most pages that use it and treat them like clickbait crap on Facebook. Yeah, that headline sounds interesting but not worth the frustration and security risk.
Your silly is my nice convenience. Open the windows from my office on a hot sunny day. Car isn't a million degrees by the time I get out there. Forget to close my windows and it starts raining? Close them remotely, and I stay dry.
Leaf HVAC is the same thing, and is actually more important for an electric, assuming you're plugged in. You can start the heat or A/C when you're parked, still plugged in. The car gets up or down to your desired temperature while still running on the grid instead of draining your battery. Not having to ride around in a cold/hot car is just a nice perk.
Of course there should be a secret to go with the known value of the VIN. VIN is readable in the windshield, so if you want to get back at someone who's parked like an ass, just start his A/C & kill his battery...
Caveat Emptor is limited by sanity in areas where the state of the art is well beyond what you could reasonably expect the average consumer to know or be able to appraise for themselves.
Car analogy: It's unlikely that most readers could look at a vehicle they desire to purchase and determine whether its brakes work properly or are likely to fail under normal driving conditions, whether its airbag might be badly designed and not deploy (or deploy at inappropriate times), etc. So we trust government regulators to establish certain minimal safety standards and enforce car manufacturers' compliance with them.
Many readers here might be able to evaluate a router we have in our hands for obvious security issues. Few of our parents or grand parents could do so. Likewise, none of us could evaluate such things before purchase for a device we've never powered on. Given the importance and ubiquity of consumer network routers, it seems reasonable to hold manufacturers to a higher standard than, "Oops... Sorry we left your entire home network open to the Internet and anyone driving by. Here's a patch (maybe)."
Not strange... I've got MS keyboards plugged into both of my Macs. Feels like ordering a Coke & Pepsi cocktail, but they're decent keyboards. Still holding out hope for finding a decent clicky microswitch (like IBM XT period keyboards) that has an ergonomic split and doesn't cost my first born, but until then... MS keyboards, Logitech mice.
Used to be the case that the reaction time on non-BT wireless was quicker. It wasn't necessarily cheaping out as the proprietary solution actually provided a benefit. More overhead in the BT protocol meant more lag. Not sure if that's still true with current BT hardware/software stacks.
Not something you'd notice typing in the office, but gamers...
The problem is that people don't keep things updated
I've got a big problem with that idea. If WordPress is only secure today because you had to install a critical update a week to keep it that way, that means WordPress is NOT secure. It doesn't matter if at 10:07 EDT as I write this, a fully updated WP install is free of known security issues. The fact that there were a dozen issues that I had to patch for previously means there were inevitably stretches of time when there *were* known issues. Even if I script it so every update is installed the instant they drop it, there's still time between reporting and fixing, and zero-days are a thing...
WordPress is not a secure platform. Even just core, with no add-ons. It happens to be one of the most usable and featureful platforms, but it's not secure. Just adding an add-on to auto-update isn't the same thing as having secure code to run.
Security update treadmills aren't a valid security posture. It's better than not updating, and you're practicing risk mitigation at that point, but I don't think it's the least bit valid to say, "You got hacked because you didn't update." You got hacked because WP can't manage to release secure code. The longer you run unpatched, the greater your chances of actually getting hit, but "you didn't update" is plain old victim blaming.
And then of course you add add-ons (because WP as a platform is a huge part of why it's useful), and you might as well just give up at that point...
Pretty simple, though potential for bad user experience for people who suffer from CRS...
Device shouldn't boot to a ramdisk unless passcode is provided. Passcode check is executed in the secure element from mask ROM on the secure element that can't be updated and always increments the fail count then wipes if necessary.
Recovery scenario for lost passcode would basically be a 10-failed wipe. The secure element wipes its key storage (thus erasing the NAND for all intents & purposes) then falling to the current DFU mode where it accepts a signed ramdisk and runs it to restore a fresh OS install on the NAND w/ newly generated AES encryption keys. Keep the same increasing time out on passcode checks so someone can't just quick-wipe your device on you by failing updates. Means worst case is it would take you a long time to do a restore on a device that you forgot the code for. Pro tip: Don't forget your passcode (and pick a long one. PIN's are dead!)
If you ever enable dedupe on a pool, it's on forever. You can't actually turn off the extra RAM requirements since there *could* be de-duped blocks, and ZFS must check for those on every pool import. On a system with insufficient RAM, it's possible to end up with a pool that can take hours or days to import with no indication that it's actually still importing and not just dead.
Unless you have truly epic levels of duplication, it'll be cheaper to buy more disk to hold the extra copies than to buy enough RAM. (Also keeping in mind that with snapshots & copy-on-write clones, you essentially get dedupe of those blocks for "free" without enabling pool-wide dedupe.)
Oracle considers ZFS a competitive advantage. It's their answer to NetApp's WAFL. Not sure the reasoning behind creating btrfs (other than possibly just merger schedules resulting in them owning both), but it's very likely they consider the GPL/CDDL incompatibility and resulting copyright FUD/trolling to be a feature. Having an in-tree ZFS module on Linux isn't something Oracle wants to see.
ZFS on Linux doesn't support native encryption yet either. ZFS on Solaris does, but that code was added after OpenSolaris was killed and has never been released under a clearly CDDL license. (It *has* been leaked, but not with clear CDDL license assignment, thus nobody in their right mind has touched it.)
You *can* easily do ZFS on LUKS-based encryption on Linux. It works great, but it's a very different thing with a different feature set than native ZFS encryption. Native ZFS crypto allows encrypting individual zfs filesystems with different user-owned keys. It's possible to boot the host with only part of the zpool accessible with the encrypted parts only accessible to the owning (mortal) users when they provide key material. ZFS on LUKS is full disk encryption with no way to import the pool at all without keys. It's all-or-nothing access to the encrypted zpool. Once it's unlocked and imported, anyone on the system can access anything on the zpool. On the other hand, ZFS native crypto leaves filesystem metadata (filenames, paths, sizes, mtimes, etc.) in the clear, even without the key. ZFS on LUKS encrypts everything.
I've been using ZFS on LUKS for about six years now. It's a stable and reliable approach, but it's not fair to say ZFS "supports" encryption where BTRFS doesn't. You can BTR your LUKS just as easily I'd think (never tried though).
On 64-bit hosts, the ARC cache is a non-issue. Java needs contiguous *virtual* memory space. Physical memory fragmentation isn't a problem w/ the MMU translating contiguous 64-bit address space to possibly non-contiguous physical pages. On 32-bit hosts, that gets dicey. On 64-bit, you've got plenty of room even w/ ARC.
That said, I'd love to see ARC & the native Linux disk cache functionality either merge or at least have ARC behave more like the normal caching mechanism (IE free up RAM more eagerly), but it's not actually caused me significant problems on 64-bit.
The part that wipes isn't the NAND. The Secure Element both verifies the entered PIN and acts as a read-through crypto processor for access to the flash.
Every time you enter a bad passcode, the secure element increments its own internal counter without accessing flash in any way. Hit the limit, and the chip wipes its internal storage of the AES keys necessary to access the flash.
You can certainly desolder or otherwise protect the physical NAND chip, but doing so means you need to brute force the several 128-bit encryption keys used to secure data on it, not the 4-6 digits PIN or passphrase.
The existing phone won't take a software update without the passcode OR wiping the existing encryption keys to go back to factory fresh. My understanding of Apple's crypto platform is that it's intentionally not possible to install a subverted version of the OS without destroying the keys stored in the current device.
I actually know how DNS works... Yes, they could still out source to a tracking company. Their privacy policy says they donâ(TM)t, and I trust them.
My point was by hosting the images on a sub domain, blocking them is trivial, if thatâ(TM)s what I wanted to do.
I've never looked at a 19th century newspaper, but I'mma go out on a limb here...
I'm pretty sure the ads didn't:
1) Make noise.
2) Move around annoyingly trying to get my attention.
3) Make me sit and wait to read the rest of the page while they loaded.
4) Cost me additional money (mobile bandwidth) to load.
5) Report my location & reading habits back to the advertiser as I walked about London.
6) Take up 80% of the page, requiring me to flip page after page to read a sentence or two surrounded by half a dozen ads.
7) Cause an actual danger to me in damaging the device I was using to read them.
Did I forget anything? I'll take 19th century advertising standards.
There's a certain red-on-black alternative social networking site that does advertising right. Hosted on their own server, static simple images, reasonably sized, no animation, no sound, no JScript, no Flash, no BS. They actually host the images on a sub-domain of their main site. It would be trivial to block them. I don't because they're not annoying or dangerous. Occasionally they even advertise something interesting, and I (intentionally!) click/tap on an ad.
And having now read TFS, I sheepishly rescind my previous post... This is the Prime photos thing, not the actual Cloud Drive storage thing. Previous post applies to Cloud Drive Unlimited. Yes, storing unlimited data for the photos only service is being a dick. Shell out the $60/year.
(And if you do, pushing ZFS backups into it is a thing I'm working on... zfs-acd-backup)
If you read the full Cloud Drive Terms of Service, you'll find nothing in it that associates the word "unlimited" with "photos".
The Service provides storage, retrieval, management and access features and functionality for your photos, videos, and other files ("Your Files"). -- CloudDrive ToS
Everything they've put in writing makes it clear that you're permitted to use unlimited storage to store whatever files you like, so long as you don't resell access, use it as the backing store for another cloud service, etc. Personal use == A-OK.
That's a joke, right? Tell me that's a joke... Ordered mine on April 15, 2015. Still nadda... Debating if their vapor will ever coalesce or if I have any chance getting a chargeback considering they hit my card & missed their more-than-thirty-days-later ship date.
I've tried (and tried (and tried...)) to like NinType. Main differentiating point is that it allows you to use gesture based typing with two fingers. So you can hold the phone in two hands and use two thumbs to type. Less stretching to reach the opposite side (especially on phablets) when you can just finish a word with your other thumb.
I've never quite been able to get comfortable with it, and honestly it has an interface only a Gentoo user (or nuclear control room tech) could love. Soooo many buttons...
article seems to imply that Apple's primary security model is to first verify the apps and then give them at runtime unlimited access
The implication (which I agree is what I got reading the article) is utterly false. Many sensitive API's are secured in the runtime sandbox by the presence of crytographically signed "entitlements." Apple won't approve an entitlement unless the app has a legitimate need for it. Calling those secured API's through any mechanism when the app bundle lacks the necessary entitlement just fails. Entitlement-secured API's include background execution and iCloud access among others.
Other less-sensitive APIs such as photos/camera access, microphone access, contacts, calendar, etc. don't require an entitlement, but still trigger an OS-provided permission dialog on first use. If the user doesn't approve, access to those API's just fails. It doesn't matter if the app didn't trigger those API's during the review process. The first time it does at runtime, the dialog pops up. Granted less savvy users might just hit "Approve," but if you read dialogs before mashing your thumb on the screen, a JSPatch app can't just run off with your data.
As for the suggestion in the article that the app would modify system settings etc? Pure FUD. In order to expose that functionality to JavaScript, the JSPatch library itself would have to contain references to those symbols. Any binary that refs non-public API symbols is rejected. Whether the code actually calls them or not is immaterial*. If JSPatch did anything polymorphic to conceal the presence of those symbols, I'm pretty confident the thing would get blacklisted double quick.
*Source: I had an app rejected once because one of my own function names happened to match a private API. Had to rename my function to get it approved.
Nothing wrong with a DRM-free digital copy. I can back that up wherever I like, format convert it, etc.
iTunes music purchases have been DRM-free for years. I have my purchases backed up in several places. As an added benefit, for at least as long as Apple chooses to let me, I can re-download those purchases any time on new devices where ever I have Net access. That's a nice convenience for me.
iTunes video is a different story, which is why I have very few video purchases of things I just had to watch right now. Two seasons of Dollhouse, and one episode of Glee (don't just me, it was the one with N.P.H. in it...).
Slashdot Mirror
The Cloudflare DDoS stuff is really annoying. You have to enable JavaScript (and it takes a few seconds) to load pages that would otherwise display fine w/ NoScript blocking just about everything. I'm at the point where I just close most pages that use it and treat them like clickbait crap on Facebook. Yeah, that headline sounds interesting but not worth the frustration and security risk.
Well... I mean... There are parties like that... Maybe it'd be okay...
Is this ad acceptable?
*grumpy cat macro*: NO
Determination made. That was easy.
Your silly is my nice convenience. Open the windows from my office on a hot sunny day. Car isn't a million degrees by the time I get out there. Forget to close my windows and it starts raining? Close them remotely, and I stay dry.
Leaf HVAC is the same thing, and is actually more important for an electric, assuming you're plugged in. You can start the heat or A/C when you're parked, still plugged in. The car gets up or down to your desired temperature while still running on the grid instead of draining your battery. Not having to ride around in a cold/hot car is just a nice perk.
Of course there should be a secret to go with the known value of the VIN. VIN is readable in the windshield, so if you want to get back at someone who's parked like an ass, just start his A/C & kill his battery...
Caveat Emptor is limited by sanity in areas where the state of the art is well beyond what you could reasonably expect the average consumer to know or be able to appraise for themselves.
Car analogy: It's unlikely that most readers could look at a vehicle they desire to purchase and determine whether its brakes work properly or are likely to fail under normal driving conditions, whether its airbag might be badly designed and not deploy (or deploy at inappropriate times), etc. So we trust government regulators to establish certain minimal safety standards and enforce car manufacturers' compliance with them.
Many readers here might be able to evaluate a router we have in our hands for obvious security issues. Few of our parents or grand parents could do so. Likewise, none of us could evaluate such things before purchase for a device we've never powered on. Given the importance and ubiquity of consumer network routers, it seems reasonable to hold manufacturers to a higher standard than, "Oops... Sorry we left your entire home network open to the Internet and anyone driving by. Here's a patch (maybe)."
Not strange... I've got MS keyboards plugged into both of my Macs. Feels like ordering a Coke & Pepsi cocktail, but they're decent keyboards. Still holding out hope for finding a decent clicky microswitch (like IBM XT period keyboards) that has an ergonomic split and doesn't cost my first born, but until then... MS keyboards, Logitech mice.
Used to be the case that the reaction time on non-BT wireless was quicker. It wasn't necessarily cheaping out as the proprietary solution actually provided a benefit. More overhead in the BT protocol meant more lag. Not sure if that's still true with current BT hardware/software stacks.
Not something you'd notice typing in the office, but gamers...
I've got a big problem with that idea. If WordPress is only secure today because you had to install a critical update a week to keep it that way, that means WordPress is NOT secure. It doesn't matter if at 10:07 EDT as I write this, a fully updated WP install is free of known security issues. The fact that there were a dozen issues that I had to patch for previously means there were inevitably stretches of time when there *were* known issues. Even if I script it so every update is installed the instant they drop it, there's still time between reporting and fixing, and zero-days are a thing...
WordPress is not a secure platform. Even just core, with no add-ons. It happens to be one of the most usable and featureful platforms, but it's not secure. Just adding an add-on to auto-update isn't the same thing as having secure code to run.
Security update treadmills aren't a valid security posture. It's better than not updating, and you're practicing risk mitigation at that point, but I don't think it's the least bit valid to say, "You got hacked because you didn't update." You got hacked because WP can't manage to release secure code. The longer you run unpatched, the greater your chances of actually getting hit, but "you didn't update" is plain old victim blaming.
And then of course you add add-ons (because WP as a platform is a huge part of why it's useful), and you might as well just give up at that point...
Pretty simple, though potential for bad user experience for people who suffer from CRS...
Device shouldn't boot to a ramdisk unless passcode is provided. Passcode check is executed in the secure element from mask ROM on the secure element that can't be updated and always increments the fail count then wipes if necessary.
Recovery scenario for lost passcode would basically be a 10-failed wipe. The secure element wipes its key storage (thus erasing the NAND for all intents & purposes) then falling to the current DFU mode where it accepts a signed ramdisk and runs it to restore a fresh OS install on the NAND w/ newly generated AES encryption keys. Keep the same increasing time out on passcode checks so someone can't just quick-wipe your device on you by failing updates. Means worst case is it would take you a long time to do a restore on a device that you forgot the code for. Pro tip: Don't forget your passcode (and pick a long one. PIN's are dead!)
Do not, repeat DO NOT ENABLE DE-DUPE unless you have gargantuan amounts of RAM.
Rule of thumb is 5GB of RAM per 1TB of ZFS data: http://constantin.glez.de/blog...
If you ever enable dedupe on a pool, it's on forever. You can't actually turn off the extra RAM requirements since there *could* be de-duped blocks, and ZFS must check for those on every pool import. On a system with insufficient RAM, it's possible to end up with a pool that can take hours or days to import with no indication that it's actually still importing and not just dead.
Unless you have truly epic levels of duplication, it'll be cheaper to buy more disk to hold the extra copies than to buy enough RAM. (Also keeping in mind that with snapshots & copy-on-write clones, you essentially get dedupe of those blocks for "free" without enabling pool-wide dedupe.)
Oracle considers ZFS a competitive advantage. It's their answer to NetApp's WAFL. Not sure the reasoning behind creating btrfs (other than possibly just merger schedules resulting in them owning both), but it's very likely they consider the GPL/CDDL incompatibility and resulting copyright FUD/trolling to be a feature. Having an in-tree ZFS module on Linux isn't something Oracle wants to see.
ZFS on Linux doesn't support native encryption yet either. ZFS on Solaris does, but that code was added after OpenSolaris was killed and has never been released under a clearly CDDL license. (It *has* been leaked, but not with clear CDDL license assignment, thus nobody in their right mind has touched it.)
You *can* easily do ZFS on LUKS-based encryption on Linux. It works great, but it's a very different thing with a different feature set than native ZFS encryption. Native ZFS crypto allows encrypting individual zfs filesystems with different user-owned keys. It's possible to boot the host with only part of the zpool accessible with the encrypted parts only accessible to the owning (mortal) users when they provide key material. ZFS on LUKS is full disk encryption with no way to import the pool at all without keys. It's all-or-nothing access to the encrypted zpool. Once it's unlocked and imported, anyone on the system can access anything on the zpool. On the other hand, ZFS native crypto leaves filesystem metadata (filenames, paths, sizes, mtimes, etc.) in the clear, even without the key. ZFS on LUKS encrypts everything.
I've been using ZFS on LUKS for about six years now. It's a stable and reliable approach, but it's not fair to say ZFS "supports" encryption where BTRFS doesn't. You can BTR your LUKS just as easily I'd think (never tried though).
On 64-bit hosts, the ARC cache is a non-issue. Java needs contiguous *virtual* memory space. Physical memory fragmentation isn't a problem w/ the MMU translating contiguous 64-bit address space to possibly non-contiguous physical pages. On 32-bit hosts, that gets dicey. On 64-bit, you've got plenty of room even w/ ARC.
That said, I'd love to see ARC & the native Linux disk cache functionality either merge or at least have ARC behave more like the normal caching mechanism (IE free up RAM more eagerly), but it's not actually caused me significant problems on 64-bit.
January 19, 2016.
Source: https://support.apple.com/en-u...
The part that wipes isn't the NAND. The Secure Element both verifies the entered PIN and acts as a read-through crypto processor for access to the flash.
Every time you enter a bad passcode, the secure element increments its own internal counter without accessing flash in any way. Hit the limit, and the chip wipes its internal storage of the AES keys necessary to access the flash.
You can certainly desolder or otherwise protect the physical NAND chip, but doing so means you need to brute force the several 128-bit encryption keys used to secure data on it, not the 4-6 digits PIN or passphrase.
The existing phone won't take a software update without the passcode OR wiping the existing encryption keys to go back to factory fresh. My understanding of Apple's crypto platform is that it's intentionally not possible to install a subverted version of the OS without destroying the keys stored in the current device.
I actually know how DNS works... Yes, they could still out source to a tracking company. Their privacy policy says they donâ(TM)t, and I trust them. My point was by hosting the images on a sub domain, blocking them is trivial, if thatâ(TM)s what I wanted to do.
I've never looked at a 19th century newspaper, but I'mma go out on a limb here...
I'm pretty sure the ads didn't:
1) Make noise.
2) Move around annoyingly trying to get my attention.
3) Make me sit and wait to read the rest of the page while they loaded.
4) Cost me additional money (mobile bandwidth) to load.
5) Report my location & reading habits back to the advertiser as I walked about London.
6) Take up 80% of the page, requiring me to flip page after page to read a sentence or two surrounded by half a dozen ads.
7) Cause an actual danger to me in damaging the device I was using to read them.
Did I forget anything? I'll take 19th century advertising standards.
There's a certain red-on-black alternative social networking site that does advertising right. Hosted on their own server, static simple images, reasonably sized, no animation, no sound, no JScript, no Flash, no BS. They actually host the images on a sub-domain of their main site. It would be trivial to block them. I don't because they're not annoying or dangerous. Occasionally they even advertise something interesting, and I (intentionally!) click/tap on an ad.
And having now read TFS, I sheepishly rescind my previous post... This is the Prime photos thing, not the actual Cloud Drive storage thing. Previous post applies to Cloud Drive Unlimited. Yes, storing unlimited data for the photos only service is being a dick. Shell out the $60/year.
(And if you do, pushing ZFS backups into it is a thing I'm working on... zfs-acd-backup)
If you read the full Cloud Drive Terms of Service, you'll find nothing in it that associates the word "unlimited" with "photos".
Everything they've put in writing makes it clear that you're permitted to use unlimited storage to store whatever files you like, so long as you don't resell access, use it as the backing store for another cloud service, etc. Personal use == A-OK.
That's a joke, right? Tell me that's a joke... Ordered mine on April 15, 2015. Still nadda... Debating if their vapor will ever coalesce or if I have any chance getting a chargeback considering they hit my card & missed their more-than-thirty-days-later ship date.
I've tried (and tried (and tried...)) to like NinType. Main differentiating point is that it allows you to use gesture based typing with two fingers. So you can hold the phone in two hands and use two thumbs to type. Less stretching to reach the opposite side (especially on phablets) when you can just finish a word with your other thumb.
I've never quite been able to get comfortable with it, and honestly it has an interface only a Gentoo user (or nuclear control room tech) could love. Soooo many buttons...
Maybe time for another try...
The implication (which I agree is what I got reading the article) is utterly false. Many sensitive API's are secured in the runtime sandbox by the presence of crytographically signed "entitlements." Apple won't approve an entitlement unless the app has a legitimate need for it. Calling those secured API's through any mechanism when the app bundle lacks the necessary entitlement just fails. Entitlement-secured API's include background execution and iCloud access among others.
Other less-sensitive APIs such as photos/camera access, microphone access, contacts, calendar, etc. don't require an entitlement, but still trigger an OS-provided permission dialog on first use. If the user doesn't approve, access to those API's just fails. It doesn't matter if the app didn't trigger those API's during the review process. The first time it does at runtime, the dialog pops up. Granted less savvy users might just hit "Approve," but if you read dialogs before mashing your thumb on the screen, a JSPatch app can't just run off with your data.
As for the suggestion in the article that the app would modify system settings etc? Pure FUD. In order to expose that functionality to JavaScript, the JSPatch library itself would have to contain references to those symbols. Any binary that refs non-public API symbols is rejected. Whether the code actually calls them or not is immaterial*. If JSPatch did anything polymorphic to conceal the presence of those symbols, I'm pretty confident the thing would get blacklisted double quick.
*Source: I had an app rejected once because one of my own function names happened to match a private API. Had to rename my function to get it approved.
How many people could even afford enough wheelbarrows to carry the amount of cash they'd need to buy a Mini. Or an iPhone for that matter...
Nothing wrong with a DRM-free digital copy. I can back that up wherever I like, format convert it, etc.
iTunes music purchases have been DRM-free for years. I have my purchases backed up in several places. As an added benefit, for at least as long as Apple chooses to let me, I can re-download those purchases any time on new devices where ever I have Net access. That's a nice convenience for me.
iTunes video is a different story, which is why I have very few video purchases of things I just had to watch right now. Two seasons of Dollhouse, and one episode of Glee (don't just me, it was the one with N.P.H. in it...).