There's some theories about computers that transmit across airgaps using this method, like in stuxnet level command and control scenarios, but I doubt that it's something typically needed to be worried about.
Importantly though- isn't this a real company with a real thing? Are you claiming this is manufactured outrage to get attention? I mean, I didn't even stop to think that it might not be real. Strikes me as totally real. If it's physically impossible as you say, then "we are all of us deceived", sure. But not having expert knowledge about the transmission, it doesn't strike me as bullshit in the slightest.
Ios just disallows until you allow access explicitly, with a prompt. Does Android just grant permission by default?
Either way, it sounds like there's a workaround on Android, and that this will have a very low success rate in ios.
Also, just to be clear- "pairing" computer with phone, against my permission, with ultrasonic, is pig disgusting. There's absolutely no way that either Apple or Google should allow shit like this on their respective stores. This is vile spyware for certain.
If an app wants microphone access in ios, it has to explicitly request it. You get a popup and have to ok it. If you don't, it doesn't have access. It can refuse to work, if it wants, but fuck them.
Does that happen in Android? I feel it does not, and you probably can, in the latest version, explicitly disable mic access or something? An android user can correct me.
SO question: " 1- I want to record. 2- User disallowed. 3- I want to record again. 4- I call requestRecordPermission: 5- It simply returns granted=NO (without prompting for permission)
Can I prompt the permission Alert to user somehow? "
Make me VERY happy to see answers like: "There's no way to do this"
"I want to spam the user with access requests that are full screen OS level stuff until he says ok. How can I do this?" -> "Nnnnnnope!"
Anyway, if Android doesn't do this, that's sad, and hopefully they will soon. If Android and Ios both do this, I don't see how most programs will be able to get mic access at all in the first place.
No, he's not. If you google, you find that the architecture seems to be: key is created by manufacturer. Key is ideally locked up behind a user passphrase. User enters passphrase, key is available to drive. But you can't change the key, and they were the ones that made it.
"Passport drives that use the USB bridge for encryption rely on either AES-128 or AES-256 to create an encryption key. The researchers refer to this as the DEK (Data Encryption Key). The DEK is set at the factory (all of the drives tested used a 256-bit DEK). The user is then allowed to set an individual password, called the KEK. The factory-set DEK is itself protected by a static hash value, common to all WD Passport drives, called the KEK8. The KEK8 is hard-coded into the firmware of every drive. once you’ve cracked one WD Passport, you’ve cracked the DEK on every Passport. "
Ok! So, this this is crapping on the fact that once you have cracked the "KEK8" (kek!), then you can use that to get the DEK on any drive. Once you have the DEK, you can decrypt the data.
Now, pretend that they didn't fuck this up (which they did), but instead had a unique KEK8 on every drive. This vulnerability wouldn't exist then, and presumably all these articles would not have happened...
But...
The DEK is still HARDCODED. It is, absolutely, the key to the drive, and it is, absolutely, set at the factory. Now, why wouldn't they keep this little 32 bit value? You know, in case.
So, here's one drive type, from a major manufacturer, who generates the DEKs at factory, one for each drive, and they never ever change.
At no point does the drive generate a new encryption key with the password you supply- the DEK is constant for the life of the drive.
I'm pointing out a theoretical problem, and I call it out as such. Here's the issue: if they have access to the encryption key at any point, they could store it and have it later. That's a fundamental vulnerability with a system like this- why on earth would you trust anyone else but you to make your encryption key? It seems so unlikely that they wouldn't get NSLed to keep all the keys in case of later subpeona, at the very least.
Here's how you can disprove this theory: find some legally binding document that states that these keys are not being kept, preferably with large civil penalties attached explicitly or implied.
Why would you trust some machine you don't control, in a known location for an adversary to attack, to not keep the key? Think how easy that is, how small that key is. 256 bit key is just 8 precious bytes. That's smaller than the serial number- trivial to keep a hold on anywhere in that machine.
I don't need to prove they are keeping the keys for it to be a theoretical vulnerability. Each manufacturer needs to prove they aren't keeping the keys.
On the bright side, Microsoft is now claiming that the present-from-launch "disable telemetry" option for Enterprise, not present on anything you or I can buy with dollars, will actually disable telemetry. Previously, disable telemetry did not disable telemetry, only scripts from Russians disabled telemetry. Perhaps now it actually will- though, as always, I'd suggest you use wireshark on an intermediate device to be sure- after all, previously disable telemetry continued to send telemetry.
Spying continues unabated on home and pro- enterprise is corporate only. Corporations can now get some privacy. It would be madness to extend that to individuals, I guess.
I'm glad to hear that there's a physical generation for the random numbers, but do all the manufacturers do this?
If you use JUST software encryption, your vulnerability is to something scooping the RAM while you are mounted, or cold boot attacking your RAM. If you use JUST hardware encryption, you face similar attacks, but to the hard drive itself, which seems more secure- but the flipside is all the stuff about password banks.
I guess my point is- prove to me that the encryption key itself is not stored by the manufacturer. That seems like it would be hard even if you worked there (what if they don't want it common knowledge, but want to be able to respond to warrants?), and it seems REALLY hard to say it in general- even if the guys you work with are totally privacy oriented, that doesn't help us about them in 10 years, and it doesn't help us about every other company now.
I agree you'd get more security from hardware and software (with two passwords) than just one- but if you are going to have just one, the answer is an open source software solution, without any hesitation or argument.
I have a book of passwords. Some passwords (like forums) don't have ludicrous constraints, and those are uniform and I can remember them. Others I wouldn't want to reuse, so of course they end up written down.
Compare the following of your own passwords- you should have at least four of these, I'd assume.
Your paypal password Your bank password Your facebook password Your smartphone account password Your brokerage account password Your credit card account password Your ISP account password Your primary email password Your domain hosting account password
Is there some overlap? What's safer- memorizing all of these by having them generally be the same, or having a book and they are all different? The ideal solution, having each unique and memorized, is quite the challenge. I choose to not duplicate stuff like this remotely, because if any of these guys get hacked, I don't want to lose all the others. You generally want to assume that any remote server stores your password in plaintext, and will deliver this plaintext password to anyone with admin access to any of their machines. This may not literally be the case, but there's no legal assurance that it is not- nor any assurance that they would actually fess up to being hacked.
The other reason you need a password bank of some sort is that there's a bunch of "metapasswords". Many of the social engineering attacks go like this:
Step 1- Fraud calls up and claims to be You. Fraud forgot his password! Step 2- Important key account, such as your domain hosting account (which holds yourname@yourdomain.com, or your website), asks "authentication questions". Step 3- Unlike your password, which has two capitals two lowercase three specials two numbers no dictionary no repeat no keyboard pattern no sequential no common words, these "authentication questions" are available to anyone who knows the first thing about you, and / or has access to the internet. "First childhood pet" is guessable sometimes. "What was your high school" is almost always googlable. Even "first girlfriend name" can be guessed, and Fraud has plenty of tries. Step 4- Once he has a key account, he can send "forgot my password" requests to other places. This usually can result in a multi-own type of scenario, where your now redirected email acts as a key to totally own you.
So those dumb questions normally need to be selected to be something that can't be chosen, and in some cases, you have to make something up- better write that thing down too!
Super frustrating.
Fun fact: I was creating an account earlier this week. My password for this involves two made up (non dictionary) words, and a numeric sequence. It refused the password twice- first because I "repeated a character three times" (the letter "L" appeared twice in the first word, and once in the second, not adjacent or anything), and then because it was "too long" (we all know secure passwords are 12 characters or less, I guess?).
I'll add something to this- an open hardware platform, with the code and chips available to review, would avert this. Then hardware encryption would have merit, and even some advantages over software. To the best of my knowledge, this in no way exists.
Self encrypting hard drives require trusting the code in the drive to be correct. While there are places people are willing to trust proprietary code, this should not be one of them. Proprietary code creates a "break once, own anywhere" setup, in the one place where that is the most ludicrous thing.
Who has the keys? Does the manufacturer have the keys? That seems to be the case, and what your password becomes is a way to unlock the copy of the key that the device has. This means when you change the password, you aren't actually changing the encryption key (which in some of the vulnerable drives cases here, was actually available on the goddamned drive in plaintext, but in the best case is hashed, and in ALL cases is in theory known to the drive manufacturer).
If you have data worth encrypting, you should use software based encryption. It doesn't require special tools to uncover mistakes, and the mistakes that we've seen already (including *just leaving the fucking key plaintext*) are really amateur level shit.
Then we have another problem- even IF the key is properly maintained, and even IF the manufacturer doesn't have a cabinet full of keys, how did they generate those keys? How is their random number generator? Remember, it's going to be just ONE target for an attacker here, since the keys all have a common source, so any mistakes are much more likely to be discovered, and much more likely to function.
Open source software encryption or gtfo. Bonus: You can choose an algo, or stack algos. AES-128 / AES-256 not to your liking? Layer them with Twofish and Serpent, or drop it in favor of those. You may not need to take the performance hit, but shouldn't it be your choice?
Software encryption is actually encryption. Hardware encryption is someone's marketing stunt.
If you go through some effort to hack something, you are doing it for some reason.
1- You might be doing it for the lulz, in which case, you probably are taking some pains to not totally screw your victim. If you look at actual full fledged computer viruses from an era when the vector (floppy disk) and targets (DOS box) were pretty reliably similar, you'll see the majority of the viruses just screwed with you. They'd invert some text. One replaced every "Microsoft" string on your machine with "Machosoft". While there were ruinous ones, they weren't ludicrously common, and that brings us to...
2- You might be doing it to "teach them a lesson". Some people do think like this, and their goal is not entirely malicious, their sadism masked by some sense of superiority and purpose.
3- You could want to further an agenda- in the modern day, a group like Anonymous will seek out targets that they feel further their message, and, by their standards, improve the world- hacktivism.
4- You might just be doing it to learn more about it- for instance, you might want to gain access to a remote machine just to see what it looks like. This is extremely common.
5- You could gain financially.
6- Finally, you could want to just hurt people maliciously.
If you are (1), (2) or (4) you don't want to mess with medical machines because a screw up might hurt or kill someone, while you don't have anywhere near the sympathy for crashing a server or desktop. The server crash occupies IT for a few hours, the desktop crash has damage limited to one person, who may be occupied for several hours or have lost something of value (if no backups).
If you are in (3), you don't further an agenda by fucking with sick people.
If you are in (5), you don't gain anything that couldn't be obtained safer elsewhere.
This leaves (6)- purely malicious motivation- and it is frankly not common in people, and generally even rarer in hackers. There's generally much easier ways to hurt people, after all, and people wired this wrong are just so scarce.
And that's how we end up with a world where medical devices are stupendously insecure- black hat hackers don't fuck with hospitals, so the hospitals, like almost every other business, don't see a problem worth paying to fix.
It's definitely good that this event is calling attention to the fact. It gets reported on pages like slashdot reasonably often, but it doesn't seem to have really gotten to the mainstream yet as something that should be fixed.
> If linux had those features to begin with, there'd be a lot more disabling. So your point is moot.
What features, the spying?
The only actual features in my post are remote file sharing (which you 100% can do with Linux) and remote voice recognition / assist, which, if present, would be something that wouldn't be snuck into the active state.
If it honestly was just turning off One Drive, not using a Microsoft Account, and disabling Cortana, then I would actually be fine with it. But instead, YOU STILL CAN'T TURN IT OFF. Look at the rest of my post- NOTHING in there is a "feature" that benefits ANY GODDAMNED USER. It's just spy garbage.
So no, there are no features that come with all the services you have to disable, and all the spypacks you have to wusa away. Just noise and loss of privacy for no benefit to any user, any where, at any time.
I'm pretty sure you made a mistake. It's an easy mistake to make, apparently, because my calculator is bugged and says the same thing when I subtract 30 from 2015.
You could block the ability to access elements of certain types (if type is application/pdf, don't allow it to be appended to body or etc.).
You could block the ability of it to retrieve or view anything but a default set of variables (font list fingerprinting, end it pls- you could fix this in CSS with a setting too, while you are at it)
You could block the ability of it to EVER trigger a goddamned thing on the right mouse button. You could replace that with some alternate control, such that right mouse button continues to work.
You could disable the ability of it to load another page.
You could disable the ability of it to ever make a dialog box.
You could allow a hard limit on how much RAM any given script or its descendants can allocate.
You could have an option for the browser to zero any RAM that the javascript has allocated on deallocation, and before garbage collection.
Basically, type something into google like "javascript stop user from".
Now, everything that comes back from that, EVERY SINGLE THING should be able to be blocked in the browser.
Telemetry was dubious and untrusted in general, so everyone gives a shit. Most importantly, you know a lot of people give a shit, because Microsoft made it impossible to disable, AND snuck it in to Windows 7 and 8- even putting the updates that push telemetry in unlabelled updates in the spring, and didn't turn them on until the summer.
If it didn't matter, you could turn it off. If it didn't matter, it wouldn't be a big deal. If it didn't matter, they wouldn't be absolutely unwilling to let someone opt out. If it didn't matter, I bet I wouldn't see you posting here as AC.
It matters. Anyone who values their privacy gives a shit. And microsoft gives a shit, or they wouldn't have made it impossible to turn off.
> How do you know your OSX install isn't doing the same thing when it does its update checks with Apple servers? YOU DON'T!
I don't have OS X (though that might change), but I will offer this:
1- If OS X was doing this, people would know. 2- You can turn off updating in OS X. This isn't like the Windows version, where you don't turn off updating- this actually turns off updating. Like, you know the check for updates? It doesn't. And you know how it installs updates? That also does not occur. 3- You don't agree to this in the OS X TOS. You do in the Windows TOS. Apple would be able to be sued at a minimum.
So while it's possible that Apple is compressing a bunch of keylogged data and waiting for the user to connect and pushing it upstream, it's just as likely that Microsoft is doing that ON TOP OF their existing telemetry- much more likely, in fact, because Microsoft is at this point engaging in very deceptive behavior, and is clearly driven to deliver all the telemetry and keystrokes off of your box.
I want to reiterate that only (1) there is needed- if Apple was doing this shit, everyone would be talking about it, the same as they are for Windows. It might be less impactful because of the smaller market base, but it would ABSOLUTELY be documented, and the same way we know what Microsoft is doing- packet capture from an external box.
It's becoming quite obvious that Firefox and Chrome have become assimilated. Chrome and Firefox will become Internet Explorer 2.0- the browser you use when you need to access content that uses obsolete crap, like how Netflix can't stream to Linux without blah blah or how you will probably need Firefox to run Java applets. But I'm pretty sure we'll see a lot of people jumping to Pale Moon, and there's several chromium derivatives that should at some point be relevant enough to point to a semi-winner.
Slashdot Mirror
> I would argue that telemetry is the only way to get objective, meaningful, data about
Don't care. My computer, my rules.
The problem isn't that they have telemetry. Honestly, the problem isn't even that it's on by default.
The problem is that you can't turn it off. That's massive and ludicrous.
There's some theories about computers that transmit across airgaps using this method, like in stuxnet level command and control scenarios, but I doubt that it's something typically needed to be worried about.
Importantly though- isn't this a real company with a real thing? Are you claiming this is manufactured outrage to get attention? I mean, I didn't even stop to think that it might not be real. Strikes me as totally real. If it's physically impossible as you say, then "we are all of us deceived", sure. But not having expert knowledge about the transmission, it doesn't strike me as bullshit in the slightest.
Well, presumably it wouldn't. Many tablets do have a mic.
Ios just disallows until you allow access explicitly, with a prompt. Does Android just grant permission by default?
Either way, it sounds like there's a workaround on Android, and that this will have a very low success rate in ios.
Also, just to be clear- "pairing" computer with phone, against my permission, with ultrasonic, is pig disgusting. There's absolutely no way that either Apple or Google should allow shit like this on their respective stores. This is vile spyware for certain.
If an app wants microphone access in ios, it has to explicitly request it. You get a popup and have to ok it. If you don't, it doesn't have access. It can refuse to work, if it wants, but fuck them.
Does that happen in Android? I feel it does not, and you probably can, in the latest version, explicitly disable mic access or something? An android user can correct me.
I will say that questions like this:
http://stackoverflow.com/quest...
SO question:
"
1- I want to record.
2- User disallowed.
3- I want to record again.
4- I call requestRecordPermission:
5- It simply returns granted=NO (without prompting for permission)
Can I prompt the permission Alert to user somehow?
"
Make me VERY happy to see answers like: "There's no way to do this"
"I want to spam the user with access requests that are full screen OS level stuff until he says ok. How can I do this?" -> "Nnnnnnope!"
Anyway, if Android doesn't do this, that's sad, and hopefully they will soon. If Android and Ios both do this, I don't see how most programs will be able to get mic access at all in the first place.
Lololo god bless you for picking one with "meta-services".
I think you can also use ublock origin in pale moon? But abl is also good.
No, he's not. If you google, you find that the architecture seems to be: key is created by manufacturer. Key is ideally locked up behind a user passphrase. User enters passphrase, key is available to drive. But you can't change the key, and they were the ones that made it.
Like here:
http://www.extremetech.com/com...
Why not post a link to something that shows another hard drive with a key that is variable and never exposed in plaintext to the manufacturer?
> No one has "the key for the drive," it's generated by the drive on the fly.
Well, who knows? I mean, here's this:
http://www.extremetech.com/com...
Ok, lets look at some of this text:
"Passport drives that use the USB bridge for encryption rely on either AES-128 or AES-256 to create an encryption key. The researchers refer to this as the DEK (Data Encryption Key). The DEK is set at the factory (all of the drives tested used a 256-bit DEK). The user is then allowed to set an individual password, called the KEK. The factory-set DEK is itself protected by a static hash value, common to all WD Passport drives, called the KEK8. The KEK8 is hard-coded into the firmware of every drive. once you’ve cracked one WD Passport, you’ve cracked the DEK on every Passport. "
Ok! So, this this is crapping on the fact that once you have cracked the "KEK8" (kek!), then you can use that to get the DEK on any drive. Once you have the DEK, you can decrypt the data.
Now, pretend that they didn't fuck this up (which they did), but instead had a unique KEK8 on every drive. This vulnerability wouldn't exist then, and presumably all these articles would not have happened...
But...
The DEK is still HARDCODED. It is, absolutely, the key to the drive, and it is, absolutely, set at the factory. Now, why wouldn't they keep this little 32 bit value? You know, in case.
So, here's one drive type, from a major manufacturer, who generates the DEKs at factory, one for each drive, and they never ever change.
At no point does the drive generate a new encryption key with the password you supply- the DEK is constant for the life of the drive.
Sorry, 32 bytes. Argument unchanged, but two many 8s in my head.
> Have you got any evidence of this?
I'm pointing out a theoretical problem, and I call it out as such. Here's the issue: if they have access to the encryption key at any point, they could store it and have it later. That's a fundamental vulnerability with a system like this- why on earth would you trust anyone else but you to make your encryption key? It seems so unlikely that they wouldn't get NSLed to keep all the keys in case of later subpeona, at the very least.
Here's how you can disprove this theory: find some legally binding document that states that these keys are not being kept, preferably with large civil penalties attached explicitly or implied.
Why would you trust some machine you don't control, in a known location for an adversary to attack, to not keep the key? Think how easy that is, how small that key is. 256 bit key is just 8 precious bytes. That's smaller than the serial number- trivial to keep a hold on anywhere in that machine.
I don't need to prove they are keeping the keys for it to be a theoretical vulnerability. Each manufacturer needs to prove they aren't keeping the keys.
> a major update to Windows 10 called the Fall Update, November Update or Threshold 2
> Fall Update, November Update or Threshold 2
Get your "FU NUT 2" today!
> Have you updated your Windows 10 install yet?
Windows 10 is more of a downdate.
On the bright side, Microsoft is now claiming that the present-from-launch "disable telemetry" option for Enterprise, not present on anything you or I can buy with dollars, will actually disable telemetry. Previously, disable telemetry did not disable telemetry, only scripts from Russians disabled telemetry. Perhaps now it actually will- though, as always, I'd suggest you use wireshark on an intermediate device to be sure- after all, previously disable telemetry continued to send telemetry.
Spying continues unabated on home and pro- enterprise is corporate only. Corporations can now get some privacy. It would be madness to extend that to individuals, I guess.
I'm glad to hear that there's a physical generation for the random numbers, but do all the manufacturers do this?
If you use JUST software encryption, your vulnerability is to something scooping the RAM while you are mounted, or cold boot attacking your RAM.
If you use JUST hardware encryption, you face similar attacks, but to the hard drive itself, which seems more secure- but the flipside is all the stuff about password banks.
I guess my point is- prove to me that the encryption key itself is not stored by the manufacturer. That seems like it would be hard even if you worked there (what if they don't want it common knowledge, but want to be able to respond to warrants?), and it seems REALLY hard to say it in general- even if the guys you work with are totally privacy oriented, that doesn't help us about them in 10 years, and it doesn't help us about every other company now.
I agree you'd get more security from hardware and software (with two passwords) than just one- but if you are going to have just one, the answer is an open source software solution, without any hesitation or argument.
Honest question- don't you do this?
I have a book of passwords. Some passwords (like forums) don't have ludicrous constraints, and those are uniform and I can remember them. Others I wouldn't want to reuse, so of course they end up written down.
Compare the following of your own passwords- you should have at least four of these, I'd assume.
Your paypal password
Your bank password
Your facebook password
Your smartphone account password
Your brokerage account password
Your credit card account password
Your ISP account password
Your primary email password
Your domain hosting account password
Is there some overlap? What's safer- memorizing all of these by having them generally be the same, or having a book and they are all different? The ideal solution, having each unique and memorized, is quite the challenge. I choose to not duplicate stuff like this remotely, because if any of these guys get hacked, I don't want to lose all the others. You generally want to assume that any remote server stores your password in plaintext, and will deliver this plaintext password to anyone with admin access to any of their machines. This may not literally be the case, but there's no legal assurance that it is not- nor any assurance that they would actually fess up to being hacked.
The other reason you need a password bank of some sort is that there's a bunch of "metapasswords". Many of the social engineering attacks go like this:
Step 1- Fraud calls up and claims to be You. Fraud forgot his password!
Step 2- Important key account, such as your domain hosting account (which holds yourname@yourdomain.com, or your website), asks "authentication questions".
Step 3- Unlike your password, which has two capitals two lowercase three specials two numbers no dictionary no repeat no keyboard pattern no sequential no common words, these "authentication questions" are available to anyone who knows the first thing about you, and / or has access to the internet. "First childhood pet" is guessable sometimes. "What was your high school" is almost always googlable. Even "first girlfriend name" can be guessed, and Fraud has plenty of tries.
Step 4- Once he has a key account, he can send "forgot my password" requests to other places. This usually can result in a multi-own type of scenario, where your now redirected email acts as a key to totally own you.
So those dumb questions normally need to be selected to be something that can't be chosen, and in some cases, you have to make something up- better write that thing down too!
Super frustrating.
Fun fact: I was creating an account earlier this week. My password for this involves two made up (non dictionary) words, and a numeric sequence. It refused the password twice- first because I "repeated a character three times" (the letter "L" appeared twice in the first word, and once in the second, not adjacent or anything), and then because it was "too long" (we all know secure passwords are 12 characters or less, I guess?).
I'll add something to this- an open hardware platform, with the code and chips available to review, would avert this. Then hardware encryption would have merit, and even some advantages over software. To the best of my knowledge, this in no way exists.
Self encrypting hard drives require trusting the code in the drive to be correct. While there are places people are willing to trust proprietary code, this should not be one of them. Proprietary code creates a "break once, own anywhere" setup, in the one place where that is the most ludicrous thing.
Who has the keys? Does the manufacturer have the keys? That seems to be the case, and what your password becomes is a way to unlock the copy of the key that the device has. This means when you change the password, you aren't actually changing the encryption key (which in some of the vulnerable drives cases here, was actually available on the goddamned drive in plaintext, but in the best case is hashed, and in ALL cases is in theory known to the drive manufacturer).
If you have data worth encrypting, you should use software based encryption. It doesn't require special tools to uncover mistakes, and the mistakes that we've seen already (including *just leaving the fucking key plaintext*) are really amateur level shit.
Then we have another problem- even IF the key is properly maintained, and even IF the manufacturer doesn't have a cabinet full of keys, how did they generate those keys? How is their random number generator? Remember, it's going to be just ONE target for an attacker here, since the keys all have a common source, so any mistakes are much more likely to be discovered, and much more likely to function.
Open source software encryption or gtfo. Bonus: You can choose an algo, or stack algos. AES-128 / AES-256 not to your liking? Layer them with Twofish and Serpent, or drop it in favor of those. You may not need to take the performance hit, but shouldn't it be your choice?
Software encryption is actually encryption. Hardware encryption is someone's marketing stunt.
I mean, you can, but anti tamper is both expensive and subject to serious workarounds.
If you go through some effort to hack something, you are doing it for some reason.
1- You might be doing it for the lulz, in which case, you probably are taking some pains to not totally screw your victim. If you look at actual full fledged computer viruses from an era when the vector (floppy disk) and targets (DOS box) were pretty reliably similar, you'll see the majority of the viruses just screwed with you. They'd invert some text. One replaced every "Microsoft" string on your machine with "Machosoft". While there were ruinous ones, they weren't ludicrously common, and that brings us to...
2- You might be doing it to "teach them a lesson". Some people do think like this, and their goal is not entirely malicious, their sadism masked by some sense of superiority and purpose.
3- You could want to further an agenda- in the modern day, a group like Anonymous will seek out targets that they feel further their message, and, by their standards, improve the world- hacktivism.
4- You might just be doing it to learn more about it- for instance, you might want to gain access to a remote machine just to see what it looks like. This is extremely common.
5- You could gain financially.
6- Finally, you could want to just hurt people maliciously.
If you are (1), (2) or (4) you don't want to mess with medical machines because a screw up might hurt or kill someone, while you don't have anywhere near the sympathy for crashing a server or desktop. The server crash occupies IT for a few hours, the desktop crash has damage limited to one person, who may be occupied for several hours or have lost something of value (if no backups).
If you are in (3), you don't further an agenda by fucking with sick people.
If you are in (5), you don't gain anything that couldn't be obtained safer elsewhere.
This leaves (6)- purely malicious motivation- and it is frankly not common in people, and generally even rarer in hackers. There's generally much easier ways to hurt people, after all, and people wired this wrong are just so scarce.
And that's how we end up with a world where medical devices are stupendously insecure- black hat hackers don't fuck with hospitals, so the hospitals, like almost every other business, don't see a problem worth paying to fix.
It's definitely good that this event is calling attention to the fact. It gets reported on pages like slashdot reasonably often, but it doesn't seem to have really gotten to the mainstream yet as something that should be fixed.
> If linux had those features to begin with, there'd be a lot more disabling. So your point is moot.
What features, the spying?
The only actual features in my post are remote file sharing (which you 100% can do with Linux) and remote voice recognition / assist, which, if present, would be something that wouldn't be snuck into the active state.
If it honestly was just turning off One Drive, not using a Microsoft Account, and disabling Cortana, then I would actually be fine with it. But instead, YOU STILL CAN'T TURN IT OFF. Look at the rest of my post- NOTHING in there is a "feature" that benefits ANY GODDAMNED USER. It's just spy garbage.
What feature is this?
http://www.pcworld.com/article...
Who does a keylogger benefit?
So no, there are no features that come with all the services you have to disable, and all the spypacks you have to wusa away. Just noise and loss of privacy for no benefit to any user, any where, at any time.
But you know that, that's why you posted AC.
> 1985 = 30 years of age.
Uh, could you check that math again?
Please?
I'm pretty sure you made a mistake. It's an easy mistake to make, apparently, because my calculator is bugged and says the same thing when I subtract 30 from 2015.
You could block the ability to access elements of certain types (if type is application/pdf, don't allow it to be appended to body or etc.).
You could block the ability of it to retrieve or view anything but a default set of variables (font list fingerprinting, end it pls- you could fix this in CSS with a setting too, while you are at it)
You could block the ability of it to EVER trigger a goddamned thing on the right mouse button. You could replace that with some alternate control, such that right mouse button continues to work.
You could disable the ability of it to load another page.
You could disable the ability of it to ever make a dialog box.
You could allow a hard limit on how much RAM any given script or its descendants can allocate.
You could have an option for the browser to zero any RAM that the javascript has allocated on deallocation, and before garbage collection.
Basically, type something into google like "javascript stop user from".
Now, everything that comes back from that, EVERY SINGLE THING should be able to be blocked in the browser.
Javascript is vile garbage.
> It's telemetry, who gives a shit?
Telemetry was dubious and untrusted in general, so everyone gives a shit. Most importantly, you know a lot of people give a shit, because Microsoft made it impossible to disable, AND snuck it in to Windows 7 and 8- even putting the updates that push telemetry in unlabelled updates in the spring, and didn't turn them on until the summer.
If it didn't matter, you could turn it off. If it didn't matter, it wouldn't be a big deal. If it didn't matter, they wouldn't be absolutely unwilling to let someone opt out. If it didn't matter, I bet I wouldn't see you posting here as AC.
It matters. Anyone who values their privacy gives a shit. And microsoft gives a shit, or they wouldn't have made it impossible to turn off.
> How do you know your OSX install isn't doing the same thing when it does its update checks with Apple servers? YOU DON'T!
I don't have OS X (though that might change), but I will offer this:
1- If OS X was doing this, people would know.
2- You can turn off updating in OS X. This isn't like the Windows version, where you don't turn off updating- this actually turns off updating. Like, you know the check for updates? It doesn't. And you know how it installs updates? That also does not occur.
3- You don't agree to this in the OS X TOS. You do in the Windows TOS. Apple would be able to be sued at a minimum.
So while it's possible that Apple is compressing a bunch of keylogged data and waiting for the user to connect and pushing it upstream, it's just as likely that Microsoft is doing that ON TOP OF their existing telemetry- much more likely, in fact, because Microsoft is at this point engaging in very deceptive behavior, and is clearly driven to deliver all the telemetry and keystrokes off of your box.
I want to reiterate that only (1) there is needed- if Apple was doing this shit, everyone would be talking about it, the same as they are for Windows. It might be less impactful because of the smaller market base, but it would ABSOLUTELY be documented, and the same way we know what Microsoft is doing- packet capture from an external box.
Or Netscape Navigator!
It's becoming quite obvious that Firefox and Chrome have become assimilated. Chrome and Firefox will become Internet Explorer 2.0- the browser you use when you need to access content that uses obsolete crap, like how Netflix can't stream to Linux without blah blah or how you will probably need Firefox to run Java applets. But I'm pretty sure we'll see a lot of people jumping to Pale Moon, and there's several chromium derivatives that should at some point be relevant enough to point to a semi-winner.
Hard as crap to netflix on Pale Moon (this is 1000% Netflix's fault), but generally a solid experience otherwise.