It doesn't "automatically sync" it. Like many other things involving Handoff, it sets a promise. It tells devices in close proximity that there is data available.
Said data isn't actually transferred until used. This significantly reduces the amount of bandwidth (and thus power) involved when no other device actually cares about the Handoff data being advertised.
There is a help button in the dialog that appears when an app is missing a signature that tells you *exactly* how to permit the launch. Is it too much to expect a user to know to click the help button?
Again, why aren't you using Family Sharing? There's zero reason to be sharing your iCloud account. Especially since it gives everyone access to to things like email.
It also seems you need to read up on Handoff. The range of Handoff is about 10 meters (33 feet). All devices must be in this range for Handoff to work.
Handoff (which was added in iOS 8 and Mac OS X 10.10) also shares which webpage you are viewing and which apps you are using to devices logged in with the same Apple ID and in that range. So you have no legitimate reason to suddenly complain about the Universal Clipboard all of a sudden.
If you don't like the security of Handoff due to ignorance, then disable Handoff on your devices. Hell, if one specific shared device must be logged in with the same Apple ID (because you don't know better), then disable Handoff solely on that device.
The Transmission app uses the Sparkle Software Update mechanism. Sparkle uses certificate pinning to prevent exactly this type of attack. The auto-updater will not permit an application to be updated if the update is signed by a different entity.
So this malware only affected people that manually downloaded the app from the Transmission website.
The SSO bug in Ingress was fixed on April 19th. Not enough people use Ingress to notice beforehand, I guess. And Niantic was owned by Google until mid 2015, so they always had access.
While Apple isn't obligated to state while something was does, there are reasons other than a DDoS that seem more likely.
One is that various Apple services use both Amazon S3 and Microsoft Azure for file storage. Given that not every Apple service was down for everyone, it's possible the Amazon outage was related to the Apple outage.
Secondly, numerous other services on the internets were down, including numerous.gov websites belonging to states (California.gov, Connecticut.gov), it's possible a regional Internet backbone was having issues.
Although the most likely reason remains Apple that was working on some backend changes for new features and/or services they'll be announcing at WWDC and something went wrong.
A clean install may not work. There is a hook in Windows 8 and later that allows OEM firmware to supply a list of software to install after a clean install.
The feature was originally designed so Windows could automatically install necessary OEM-specific drivers without requiring a custom installer be used. Sadly, OEMs have used it to install vulnerable crapware.
itunes asked if she'd like to sync with the new device. she said yes. it deleted all of the music on her computer, including physical files
This did not occur. iTunes does not permit an iOS device to become the "master device" for songs. It will only copy songs to the iOS device (except for purchased songs, which it copies to the existing iTunes library). It's actually a very common complaint that iTunes won't copy all songs off an iOS device.
iTunes never accepted the iPod as a master copy. In fact, one of the main complains about iTunes is there's no way to copy songs off a device. iTunes only copy files to devices (although they eventually added the ability to copy only purchased songs off a device).
And that's exactly what Apple will be doing. Since Apple cannot reproduce the issue, and has no real idea if it ever occurs, is a user error, or is a bug, they basically have one option:
Go through all the code that uses FSDeleteObject(), FSUnlinkObject(), and unlink() (The function calls iTunes actually makes) and either replace them with calls to FSMoveObject() or fortify the code with additional error checking they can't confirm will help.
The issue is, under no circumstances is iTunes supposed to delete music files. Even when explicitly telling iTunes to delete files, the code uses FSFindFolder() and FSMoveObject() to move the files to the trash instead of outright deleting it. And for huge collections of files, like with 122GB, deleting items from the trash is not fast since Mac OS X uses assloads of error checking and notification sending to make sure none of the files are in use or lack the appropriate permissions (it doesn't simply unlink() files). This means the user will see a trash dialog counting up and then down the number of files to delete.
Even if there is a rare deletion bug, it's extremely likely most of the reports of iTunes deleting music are false. Even when songs "disappear from the iTunes library" (like if you modify a playlist on one device and have playlist syncing on through iTunes in the Cloud, iTunes Match, or Apple Music), the song files remain on disk.
iOS has an anti-replay counter to prevent reimaging like the type you suggest to assist with a brute force attack. Furthermore, the "secure enclave" is a marketing term Apple uses to group disparate security features under one umbrella. Most of the security features under the "secure enclave" umbrella still existed on previous iOS devices.
Finally, the Apple A6 SoC does have its own rewritable NVRAM that can be used to store the number of incorrect attempts without needing to store it on the NAND.
Not really sure that's necessary. As this is an iPhone, TouchID is disabled if the device is rebooted, 48 hours pass, or their are five incorrect attempts at fingerprint scanning.
That is, they're far more likely to burn through the 5 attempts than they are to hit the duress finger.
You haven't "wrecked" anything. All you've done is proven your unwillingness to learn.
At least you're finally acknowledging it's no where near as simple as brute forcing a 4 digit PIN, as your previous posts claimed repeatedly.
Now you've realized/learned there are other major, significant hurdles to doing a brute force attack, such as finding security holes in other parts of iOS that first allow you to run arbitrary code on the iOS device when you have physical access or getting access to the UID by physically decapping the SoC.
So I assume this means you've stopped claiming it's as simple as reading the NAND directly.
The core functionality of the encryption methods haven't changed much, as you can clearly see if you compare the iOS 7, Feb 2014 security paper to the 2015 iOS 9 security paper.
As reading the iOS Security Paper has proven too difficult for you, here's an excellent iOS Encryption Primer that discusses how iOS encryption actually works.
Slashdot Mirror
I'm unsure what cable has to do with Fox, ABC, CBS, et cetera. The only cable network listed in the summary was Disneyâ¦
Yes, I was giving it to you personally because you kept using your weird personal configuration in all of your examples.
A rational person would just use Family Sharing and be done with it.
It doesn't "automatically sync" it. Like many other things involving Handoff, it sets a promise. It tells devices in close proximity that there is data available.
Said data isn't actually transferred until used. This significantly reduces the amount of bandwidth (and thus power) involved when no other device actually cares about the Handoff data being advertised.
There is a help button in the dialog that appears when an app is missing a signature that tells you *exactly* how to permit the launch. Is it too much to expect a user to know to click the help button?
Again, why aren't you using Family Sharing? There's zero reason to be sharing your iCloud account. Especially since it gives everyone access to to things like email.
It also seems you need to read up on Handoff. The range of Handoff is about 10 meters (33 feet). All devices must be in this range for Handoff to work.
Handoff (which was added in iOS 8 and Mac OS X 10.10) also shares which webpage you are viewing and which apps you are using to devices logged in with the same Apple ID and in that range. So you have no legitimate reason to suddenly complain about the Universal Clipboard all of a sudden.
If you don't like the security of Handoff due to ignorance, then disable Handoff on your devices. Hell, if one specific shared device must be logged in with the same Apple ID (because you don't know better), then disable Handoff solely on that device.
Bad article is bad. It initiates a man-in-the-middle attack for network requests.
On Windows, this gets NTLM for a pass-the-hash attack if a network share is mounted or set to automatically connect.
The Transmission app uses the Sparkle Software Update mechanism. Sparkle uses certificate pinning to prevent exactly this type of attack. The auto-updater will not permit an application to be updated if the update is signed by a different entity.
So this malware only affected people that manually downloaded the app from the Transmission website.
I read the article.
The Dev ID used to sign it was not Transmission's Dev ID.
The build machine wasn't compromised. The Transmission web server was compromised and the Transmission binary was replaced on the server.
This has absolutely nothing to do with Xcode.
The SSO bug in Ingress was fixed on April 19th. Not enough people use Ingress to notice beforehand, I guess. And Niantic was owned by Google until mid 2015, so they always had access.
If you deny the permission on Android, the Pokémon GO will then ask you to log in manually with Google account credentials. That process also creates the OAuth token with the overzealous scope.
The fact is, all it is trying to do is activate a single sign on authentication method.
Err, "While Apple isn't obligated to state why something was down".
Sigh, I wish Slashdot supported preview mode on mobile.
While Apple isn't obligated to state while something was does, there are reasons other than a DDoS that seem more likely.
One is that various Apple services use both Amazon S3 and Microsoft Azure for file storage. Given that not every Apple service was down for everyone, it's possible the Amazon outage was related to the Apple outage.
Secondly, numerous other services on the internets were down, including numerous .gov websites belonging to states (California.gov, Connecticut.gov), it's possible a regional Internet backbone was having issues.
Although the most likely reason remains Apple that was working on some backend changes for new features and/or services they'll be announcing at WWDC and something went wrong.
A clean install may not work. There is a hook in Windows 8 and later that allows OEM firmware to supply a list of software to install after a clean install.
The feature was originally designed so Windows could automatically install necessary OEM-specific drivers without requiring a custom installer be used. Sadly, OEMs have used it to install vulnerable crapware.
You just can't win against crapware.
The compatibility issue is likely exactly why it's limited to Win32 applications with a manifest and Metro apps.
itunes asked if she'd like to sync with the new device. she said yes. it deleted all of the music on her computer, including physical files
This did not occur. iTunes does not permit an iOS device to become the "master device" for songs. It will only copy songs to the iOS device (except for purchased songs, which it copies to the existing iTunes library). It's actually a very common complaint that iTunes won't copy all songs off an iOS device.
iTunes never accepted the iPod as a master copy. In fact, one of the main complains about iTunes is there's no way to copy songs off a device. iTunes only copy files to devices (although they eventually added the ability to copy only purchased songs off a device).
And that's exactly what Apple will be doing. Since Apple cannot reproduce the issue, and has no real idea if it ever occurs, is a user error, or is a bug, they basically have one option:
Go through all the code that uses FSDeleteObject(), FSUnlinkObject(), and unlink() (The function calls iTunes actually makes) and either replace them with calls to FSMoveObject() or fortify the code with additional error checking they can't confirm will help.
The issue is, under no circumstances is iTunes supposed to delete music files. Even when explicitly telling iTunes to delete files, the code uses FSFindFolder() and FSMoveObject() to move the files to the trash instead of outright deleting it. And for huge collections of files, like with 122GB, deleting items from the trash is not fast since Mac OS X uses assloads of error checking and notification sending to make sure none of the files are in use or lack the appropriate permissions (it doesn't simply unlink() files). This means the user will see a trash dialog counting up and then down the number of files to delete.
Even if there is a rare deletion bug, it's extremely likely most of the reports of iTunes deleting music are false. Even when songs "disappear from the iTunes library" (like if you modify a playlist on one device and have playlist syncing on through iTunes in the Cloud, iTunes Match, or Apple Music), the song files remain on disk.
iOS has an anti-replay counter to prevent reimaging like the type you suggest to assist with a brute force attack. Furthermore, the "secure enclave" is a marketing term Apple uses to group disparate security features under one umbrella. Most of the security features under the "secure enclave" umbrella still existed on previous iOS devices.
Finally, the Apple A6 SoC does have its own rewritable NVRAM that can be used to store the number of incorrect attempts without needing to store it on the NAND.
On iOS, the TouchID bad guess counter is global. So even bad guesses in apps that ask for the fingerprint via TouchID count against the limit of 5.
Not really sure that's necessary. As this is an iPhone, TouchID is disabled if the device is rebooted, 48 hours pass, or their are five incorrect attempts at fingerprint scanning.
That is, they're far more likely to burn through the 5 attempts than they are to hit the duress finger.
You haven't "wrecked" anything. All you've done is proven your unwillingness to learn.
At least you're finally acknowledging it's no where near as simple as brute forcing a 4 digit PIN, as your previous posts claimed repeatedly.
Now you've realized/learned there are other major, significant hurdles to doing a brute force attack, such as finding security holes in other parts of iOS that first allow you to run arbitrary code on the iOS device when you have physical access or getting access to the UID by physically decapping the SoC.
So I assume this means you've stopped claiming it's as simple as reading the NAND directly.
The core functionality of the encryption methods haven't changed much, as you can clearly see if you compare the iOS 7, Feb 2014 security paper to the 2015 iOS 9 security paper.
There are many excellent guides on how iOS encryption works. There's no need for you to remain this ignorant about how iOS encryption works.
As reading the iOS Security Paper has proven too difficult for you, here's an excellent iOS Encryption Primer that discusses how iOS encryption actually works.