MacInTouch Amazon link...

Apple security and privacy

Channels
Apple, Security


Microsoft charges money for Windows. macOS is free. You cannot upgrade to a newer version of Windows without paying....
Not 100% true. If you have Windows 7 to 8.1, you could have used the free Accessibility upgrade. You only need your original key. (Note: Microsoft took the link down, but I kept the installer so....)

Please note, these were fresh installs... meaning I installed a new SSD, made a bootable USB media creation tool of Windows 7 (plus accessibility) installer, formatted the new SSD, and installed Windows 7 (key dictates version: e.g. Home vs. Pro), used the Win 7 key to validate via Internet and had a fresh Windows 10 machine, which then updated to the latest 1809.

This is not the same as an in-place upgrade, which unless you have the 3rd-party PC Mover, you are not as lucky as the Mac's Migration assistant - free but not very granular.

Complicated? Absolutely! But didn't cost me... except the SSD.
 


I may have missed something, but in all the years I've been monitoring security issues, I can't ever recall hearing of one where a VM host was leaking VM guest passwords or logins, but, of course, a security hole in a host network stack could lead to a problem. ....
Meltdown / Spectre / side channel du-jour.
 


Microsoft charges money for Windows. macOS is free. You cannot upgrade to a newer version of Windows without paying....
It would be well worth it if Apple charged a small fee ($20?) for the updates. Then they could keep security updates for more than two years' of operating systems.

Apple used to charge for OS updates. The lack of an upgrade fee came about the same time as the more limited security updates.
 


Setting up a new iPhone SE:
requires SIM card and Apple ID/password for activation (I didn't try doing it through iTunes without a SIM card)
You still need a SIM card installed to activate any iPhone. The only thing activating through iTunes does is obviate the need for setting up a WiFi connection first. Once the iPhone has been activated, you can then operate it without the need for any SIM card installed, until the next time the iPhone is erased and reset. You also don't need to enter an Apple ID to activate. That step happens several steps after activation. In fact, you don't even actually need an Apple ID to operate an iOS device. You can skip that step, and still use the device forever without ever logging into an Apple ID.
requires updating to iOS 12.1.3 in order to restore my backup (via iMazing), something I did not want to do but can't see how to avoid
I'm not sure how iMazing fits into this, as I do all my restores via iTunes from encrypted backups. For that, so long as your restore target iOS version is the same as or greater than the iOS version of the backup source, you don't need to update your iOS.
requires re-entering credit card info for Apple Pay (security code for Apple Store credit card)
Touch ID and Face ID protected information like this are tied to the Secure Enclave, and so are not transferrable to any other device.
After restoring a backup of my other phone, iOS demands credentials and security question answers and 2FA codes for an entirely different Apple ID that's not associated with this phone but used only for email - very confusing.
Some information is not transferrable to backups, even encrypted ones. I believe this can be designated by the app itself, as to whether something is backup-able or not. In this case, your Mail password cannot be transferred, so when the new phone tries to check the mail for that account, you need to re-enter the credentials, and because it's a new device, you must also provide the 2FA for signing into the Mail service with that Apple ID, exactly how 2FA is supposed to work.
Restoring the backup left all the apps unrestored, so the iPhone itself is now... very... slowly... downloading... all of those.
[...]
And... after all that, I checked the phone this morning and it had 42 updates pending. So all those downloads yesterday were out of date? I don't get it.
Apps are not included in iOS backups, not even iTunes backups. What is included, is a record of which apps and versions were installed at the time of the backup, and after restoring a backup, iOS downloads those exact versions from the App Store (even apps that are no longer available for purchase) to the newly restored device. So, if new app versions have come out between the time when your backup was taken and when your restore was done, you will have updates available.
Restoring the backup wiped out the Apple Pay and fingerprint data I'd just entered previously.
It sounds like, between this statement and your earlier statement about entering your Apple ID for activation, that you actually went through and completed the whole setup process before doing the restore from backup. If you do the restore at the first opportunity that it offers it to you during the setup process, you can avoid having to do a lot of this setup work twice (or even once).
 


It would be well worth it if Apple charged a small fee ($20?) for the updates. Then they could keep security updates for more than two years' of operating systems.
Agreed. I had no problem paying $130 (or $200 for a 5-license family pack) every 2-3 years for a rock-solid system upgrade.

This policy of shipping whatever happens to be ready by an arbitrary deadline (WWDC announcements, it seems) without regard to quality, usability, compatibility or even stability is just plain stupid.

I used to wait for 2-3 updates for an OS to stabilize before using it. Today, the next release ships first so the only way to run a stable OS is to be so far out of date that you can't run the applications you want.
 


It would be well worth it if Apple charged a small fee ($20?) for the updates. Then they could keep security updates for more than two years' of operating systems.
This made me laugh. Apple is one of the richest companies in the world. If they wanted to devote resources to maintaining security patches for older systems, they could, with or without $20 fees. Hell, there are volunteer OS projects out there that incorporate security updates for more items for a much longer period of time than macOS. This is a specific decision by Apple not to.
Apple used to charge for OS updates. The lack of an upgrade fee came about the same time as the more limited security updates.
The two things are unrelated. But, in fact, it actually happened in the opposite manner as you describe. Although they have never published a formal support policy, from the beginning of Mac OS X through Snow Leopard, Apple provided patches for the current release (n) and the previous release (n-1). Starting with Lion, that support was extended to the current policy of n-2 (Lion was being patched throughout the time that Mavericks was current). And that extension in support coincided with the price drop on OS X's price for Mountain Lion ($19.99, down from $29.99) and down to free for Mavericks.
 


99% of this vulnerability is pure social engineering, not the sort of technical flaws described in CVEs, and I know that this is a very widespread attack technique currently. (Maybe 1% of this attack might be attributable to a lack of updated web browser and/or antivirus software.)
I'm quoting from US-CERT here:

Five products in the National Cyber Awareness System offer a variety of information for users with varied technical expertise. Tips describe and offer advice about common security issues for non-technical computer users (including Avoiding Social Engineering and Phishing Attacks).

A subscription to any or all of the National Cyber Awareness System products ensures that you have access to timely information about security topics and threats. To learn more or to subscribe, visit the subscription system.
 


Sierra Security Update 2018-005 was released October 30, 2018 and makes no mention I could find of an update for SQLite. Not surprising - it was not known as insecure, yet. Security Update 2018-006 released December 5, 2018, and I found no reference to SQLite. We've already discussed 2019-001, which updates SQLite in Mojave but is silent about Sierra and High Sierra.
So, I ended up looking into this way more than I intended to. While it's true that in the past, Apple has sometimes decided not to roll out "difficult" fixes to older OS's that are technically still supported (ref. rootpipe vulnerability, initially fixed only for Yosemite, later for Mavericks, and never for Mountain Lion), I don't think that's the case here.

First, it's important to understand that the SQLite vulnerability, given the fancy brand name Magellan, requires the FTS3 extension to be enabled in order to work. FTS3 is not enabled by default at compile-time.

So, I went looking for FTS3 support. I had access to 4 systems to test. On Lion, El Capitan, and Sierra, I got the following results in Terminal:
Bash:
strings /usr/bin/sqlite3 | grep ENABLE_FTS
So, it appears that Sierra and earlier were not compiled with FTS3 support, and so are not vulnerable. On High Sierra, I got the following:
Bash:
strings /usr/bin/sqlite3 | grep ENABLE_FTS
ENABLE_FTS3
ENABLE_FTS3_PARENTHESIS
ENABLE_FTS3_TOKENIZER
ENABLE_FTS4
ENABLE_FTS5
So an unpatched High Sierra system would be vulnerable. I don't have a Mojave system, but I assume someone can confirm the same result as High Sierra.

As for High Sierra, I dug into the Security Update 2009-001 High Sierra package, and it does, in fact, contain the same updated sqlite3 binaries and libraries that the Mojave update contains. So, it's just that the "About the security content" page is not accurate (surprise, surprise) about the SQLite update not being available for High Sierra.

For iOS, as we know, Apple does not provide any updates for releases other than current. It's hard to test for the presence of FTS3 on iOS, but we can maybe make some reasonable assumptions given that iOS and macOS builds are usually closely related. Given that, and the SQLite versions provided earlier, we can say that any iOS 11 and iOS 12 (prior to 12.1.3) are probably vulnerable. iOS 10 and earlier are probably not vulnerable. Of course, it's harder to run arbitrary code and commands on iOS, so that mitigates the risks somewhat.
 


Ric Ford

MacInTouch
On High Sierra, I got the following:
Bash:
strings /usr/bin/sqlite3 | grep ENABLE_FTS
ENABLE_FTS3
ENABLE_FTS3_PARENTHESIS
ENABLE_FTS3_TOKENIZER
ENABLE_FTS4
ENABLE_FTS5
I get the identical result on Mojave 10.14.3 (well, after some software installation gyrations).
Bash:
strings /usr/bin/sqlite3 | grep ENABLE_FTS
xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools.
...
strings /usr/bin/sqlite3 | grep ENABLE_FTS
ENABLE_FTS3
ENABLE_FTS3_PARENTHESIS
ENABLE_FTS3_TOKENIZER
ENABLE_FTS4
ENABLE_FTS5
 


... This policy of shipping whatever happens to be ready by an arbitrary deadline (WWDC announcements, it seems) without regard to quality, usability, compatibility or even stability is just plain stupid. I used to wait for 2-3 updates for an OS to stabilize before using it. Today, the next release ships first so the only way to run a stable OS is to be so far out of date that you can't run the applications you want.
Can Apple Just. Stop. Already. Just... stop. This truly is reaching textbook insanity levels.
 



Ric Ford

MacInTouch
Who else would pay to keep Snow Leopard? ;)
I would absolutely pay to have a secure, supported version of Snow Leopard or Mavericks, but a major issue is web apps - the web is as much, or more, of our "platform" as the OS nowadays, but the web and its security issues are much more dynamic, diverse, dangerous, unstable, buggy, ephemeral, insecure, non-standard, user-hostile, badly designed and problematic in other ways... and that's where we probably need to focus our efforts (along with mitigating/preventing email and phone attacks).
 


Ric Ford

MacInTouch
I'm not sure how iMazing fits into this, as I do all my restores via iTunes from encrypted backups.
It sounds like, between this statement and your earlier statement about entering your Apple ID for activation, that you actually went through and completed the whole setup process before doing the restore from backup. If you do the restore at the first opportunity that it offers it to you during the setup process, you can avoid having to do a lot of this setup work twice (or even once).
When I tried to set up an iPhone SE last year (after having purchased and set up many iPhones over many years previously), it was an unmitigated disaster, such that I finally returned the iPhone to Apple, because I had been unable to unlock it and make it functional after many hours and steps of trying, including at least one DFU reset and a (brief) unsuccessful call with Apple Support. Gun-shy after that massive waste of time and effort, I tried this time to jump through the Apple hoops in a default manner but then used iMazing to restore a just-made backup from my existing phone, thinking that the iMazing backup would be more up-to-date and complete than an iCloud backup, and I didn't want to waste time doing both for a phone that was in current use. I don't know if iMazing was my best option, though, and I was surprised at having to download all the apps again wirelessly and reconfigure a number of things I had already configured on this new phone once. iMazing "erased" the iPhone as part of its restore process, so that may have wiped out all the identity data and settings I'd already added to the new phone. (At least I got it activated and functional this time....)
 


So, it appears that Sierra and earlier were not compiled with FTS3 support, and so are not vulnerable.
I appreciate what you did here, Todd... yet the link below shows that YapStudios is offering a database "solution" that's "built atop SQLite for iOS & Mac" and offers plugins including "Full Text Search," which is FTS3.
YapStudios said:
What is YapDatabase
YapDatabase is a comprised of 2 main features:
  • a collection/key/value store built atop sqlite for iOS & Mac (the foundation)
  • a plugin architecture that provides for advanced functionality such as Views, Secondary Indexes, Full Text Search, etc.
The SQLite website says "Although FTS3 and FTS4 are included with the SQLite core source code, they are not enabled by default." Yes, that supports the absence of FTS3 in Sierra, as shipped by Apple, but there's that YapDatabase "built atop" SQLite in iOS and Mac, and offering FTS through a plugin architecture. YapDatabase's access to FTS wasn't blocked by its not being enabled in macOS prior to macOS 10.14.3 / Security Update 2019-001.

I've tried to identify Apple's Mac applications that use SQLite and can't find a comprehensive list. I'm pretty sure they include Mail, iTunes, Photos, Keychain, App Store, and, possibly, Spotlight. What's unknown is if Apple's applications that do use SQLite might employ a plugin to take advantage of the faster "Full Text Search" in FTS3 / FTS4? If a third-party developer can do that, Apple could. What's also unknown: if other third-party internet-facing applications that use SQLite (e.g., Quickbooks for Mac, TurboTax) are limited by the lack of an enabled FTS in Sierra or activate it through a plugin?

My takeaway is uncertainty - on security, where "good enough" is really "best possible."
 


I appreciate what you did here, Todd... yet the link below shows that YapStudios is offering a database "solution" that's "built atop SQLite for iOS & Mac" and offers plugins including "Full Text Search," which is FTS3.
But we cannot hold Apple responsible for providing a patch required by the installation of a plugin by 3rd-party software.
 


the link below shows that YapStudios is offering a database "solution" that's "built atop SQLite for iOS & Mac" and offers plugins including "Full Text Search," which is FTS3.
YapDatabase implements its own FullTextSearch extension and does not rely on the presence of FTS3 being enabled on the system installation of SQLite. That's why it can run full text search on Sierra and earlier, where FTS3 is not installed and enabled. You can see the comments in the source code where it explains that it's its own extension, built on top of FTS:
YapDatabaseFullTextSearch.h
YapDatabaseFullTextSearch is an extension for performing text based search.
Internally it uses sqlite's FTS module which was contributed by Google.
What's also unknown: if other third-party internet-facing applications that use SQLite (e.g., Quickbooks for Mac, TurboTax) are limited by the lack of an enabled FTS in Sierra or activate it through a plugin?
Other applications do not have access to FTS3 through the system-installed SQLite in Sierra and earlier, since it's not present. They could implement their own FTS3 extension, like YapDatabase did. Then, only that specific application would be potentially vulnerable to the Magellan exploit, if it were using old FTS3 code.
 


Re: FTS3 vulnerability in SQLite3 versions before 3.26
But we cannot hold Apple responsible for providing a patch required by the installation of a plugin by 3rd-party software
Would concern about an FTS3 plugin vulnerability be moot if Sierra's SQLite had been updated to the "safer" 3.26 version in Mojave? I don't know. Since 3.26 is supposed to have fixed the known vulnerability, and adds macOS support for Full Text Search (FTS), any developers who had built an FTS plugin could abandon them and use SQLite as supported by Apple.
Other applications do not have access to FTS3 through the system-installed SQLite in Sierra and earlier, since it's not present. They could implement their own FTS3 extension, like YapDatabase did. Then, only that specific application would be potentially vulnerable to the Magellan exploit, if it were using old FTS3 code.
Sierra's SQLite version 3.16 isn't on the list, although other SQLite versions are, confirming Todd's exoneration of Sierra, as shipped by Apple.
SecurityFocus said:
SQLite 'FTS3' extension Remote Code Execution Vulnerability
Vulnerable: {long list much of which is older software, clipped here to the two most pertinent}
Apple macOS 10.14.2​
Apple iTunes 12.9.2​
I also note that the current version of iTunes on my updated Sierra install is 12.8.2. Listed on the "vulnerable" list is iTunes 12.8, which was released with High Sierra 10.13.6. Is it safe to presume subsequent updates patched the vulnerability in 12.8? It persisted through iTunes 12.9.2 (which I think is Windows only). iTunes 12.9.3 (Windows) is explicitly patched for SQLite and WebKit vulnerabilites.

I've focused on SQLite, because it is something I've used and which has its own independent-of-Apple documentation. Quoth Yoda, "No pretense do I that SQLite programmer am I!" On the other hand, SQLite is a "part" of Apple's operating systems, more accessible to discuss than what's in the kernel patches.

I've found this thread interesting, informative, and the kind of back and forth exchange of information for which I value MacInTouch. Much as I don't want to "upgrade" from Sierra that's working very well, I am concluding "better practice" is to update the Internet/network-connected Macs I'm supervising to Mojave. Sierra may in fact be adequately secure now, but its life-expectancy is short.
 


Would concern about an FTS3 plugin vulnerability be moot if Sierra's SQLite had been updated to the "safer" 3.26 version in Mojave? I don't know.
If the software you use implements its own FTS3 implementation, it could be vulnerable, regardless of the status of the system SQLite. For example, since YapDatabase implements its own FTS plugin, if you are using an older version of YapDatabase on a fully patched Mojave system, YapDatabase could still be vulnerable. Apple didn't update Sierra's SQLite, because it's not vulnerable, and doing so would not have changed the scenario you're describing.
I also note that the current version of iTunes on my updated Sierra install is 12.8.2. Listed on the "vulnerable" list is iTunes 12.8, which was released with High Sierra 10.13.6. Is it safe to presume subsequent updates patched the vulnerability in 12.8? It persisted through iTunes 12.9.2 (which I think is Windows only). iTunes 12.9.3 (Windows) is explicitly patched for SQLite and WebKit vulnerabilites.
I think the raft of iTunes versions listed there are only applicable to the Windows versions. The Windows version of iTunes includes an embedded implementation of SQLite, because Windows does not have a system implementation of SQLite.
macOS iTunes uses the system-provided SQLite.

That's why Windows iTunes was revved to 12.9.3 (to fix the embedded SQLite), but macOS iTunes did not have a corresponding 12.9.3 update (its SQLite is the system SQLite fixed by the macOS 12.14.3 update). macOS iTunes is still at 12.9.2, included with Mojave 10.14.2 and 10.14.3.
 


Ric Ford

MacInTouch
A disturbing and timely article:
Motherboard said:
How Hackers and Scammers Break into iCloud-Locked iPhones
... In 2013, Apple introduced a security feature designed to make iPhones less valuable targets to would-be thieves. An iPhone can only be associated to one iCloud account, meaning that, in order to sell it to someone else (or in order for a stolen phone to be used by someone new) that account needs to be removed from the phone altogether. A stolen iPhone which is still attached to the original owner's iCloud account is worthless for personal use or reselling purposes (unless you strip it for parts), because at any point the original owner can remotely lock the phone and find its location with Find My iPhone. Without the owner's password, the original owner's account can't be unlinked from the phone and the device can't be factory reset. This security feature explains why some muggers have been demanding passwords from their victims.

The iCloud security feature has likely cut down on the number of iPhones that have been stolen, but enterprising criminals have found ways to remove iCloud in order to resell devices. To do this, they phish the phone’s original owners, or scam employees at Apple Stores, which have the ability to override iCloud locks. Thieves, coders, and hackers participate in an underground industry designed to remove a user’s iCloud account from a phone so that they can then be resold.

Making matters more complicated is the fact that not all iCloud-locked phones are stolen devices...
 


Ric Ford

MacInTouch
The all-important Apple Keychain apparently has a big, unpatched vulnerability:
Forbes said:
Teenage Hacker's Evil App Steals Apple Mac Passwords
Yet another teenager has uncovered a serious weakness in Apple technology.

Just last week it emerged that a 14-year-old uncovered a bug that allowed snooping on iPhone and Mac users thanks to a problem in FaceTime. Now German 18-year-old Linus Henze has uncovered a vulnerability affecting the latest Apple macOS that leaves stored passwords open to malicious apps. That could include logins for your bank website, Amazon, Netflix, Slack and many more apps. And even though this is a Mac-only bug, if you’re using the iCloud keychain, passwords synced across iPhones and Macs may also be in danger.

To make matters worse, it’s likely that no fix is in the works. Henze isn’t disclosing his findings to Apple, telling Forbes the lack of payment for such research was behind his decision to keep the hack’s details secret from the Cupertino giant.

The researcher, who has uncovered other iOS and macOS bugs in the recent past, discovered a way into the Apple “keychain.”
 


Ric Ford

MacInTouch
Another undocumented update to Apple's invisible anti-malware mechanism:
Howard Oakley said:
Apple has pushed an update to MRT
Apple has just pushed an update to its malware removal tool, MRT, for macOS, bringing its version number to 1.39. Apple doesn’t provide any information on what changes this update brings. As it now obfuscates the names of malware which it can detect and remove, it appears impossible to correlate changed strings in the app with any malware known outside Apple.
 


Ric Ford

MacInTouch
And another side of Apple security (thanks to Richard S for the tip):
Stratfor said:
An Arrest at Apple Shows How Corporate Spies Worm Their Way Into the System

Highlights
  • Two cases in which engineers working on Apple's autonomous vehicle program allegedly stole trade secrets show that corporate espionage will continue to be a major threat to companies.
  • Nevertheless, the prosecution of an insider may not necessarily discourage future employees from following the same path.
  • The differences in the tactics in the two cases demonstrate that corporate spies will learn from the mistakes of predecessors, and adapt to changes in security policy.
 


The two things are unrelated. But, in fact, it actually happened in the opposite manner as you describe. Although they have never published a formal support policy, from the beginning of Mac OS X through Snow Leopard, Apple provided patches for the current release (n) and the previous release (n-1). Starting with Lion, that support was extended to the current policy of n-2 (Lion was being patched throughout the time that Mavericks was current). And that extension in support coincided with the price drop on OS X's price for Mountain Lion ($19.99, down from $29.99) and down to free for Mavericks.
Thank you for the clarification. I was just going from memory (not so good anymore). It just seems as though Apple is pushing through updates to the OS, and, when your device (Mac, iPhone, etc.) can no longer update, then you have to buy new (expensive, poorly constructed) hardware. For those of us using older equipment (and software), it comes down to "If it isn't broke, don't fix it". All the new "benefits" (how many emojis do you need?) just don't appeal to me and many others (as evidenced by some of the discussions here).
 


The Windows version of iTunes includes an embedded implementation of SQLite, because Windows does not have a system implementation of SQLite. macOS iTunes uses the system-provided SQLite.
Yes, and no. Windows 7, which iTunes still supports, does not have a system implementation of SQLite but Microsoft is updating SQLite in Windows 10, and that relieves developers of the need to update their applications in response to SQLite updates. Should make the developer's life easier, and possibly make applications that use SQLite to store data safer.
Windows (.com) said:
Using SQLite databases in UWP apps
Since the Windows 10 Anniversary Update (Build 14393), SQLite has also shipped as part of the Windows SDK. . . . This comes with some advantages:
  • Your application size reduces since you don’t download your own SQLite binary and package it as part of your application . . .
  • You can depend on the Windows team to update the version of SQLite running on the operating system with every release of Windows.
Over on our Mac side of the fence, if there are Mac applications that "call" the embedded 3.16 SQLite in Sierra, then add their own FTS3 plugin, those developers would have to go further, disconnect from the 3.16 version in Sierra, and package SQLite into their applications. Not going to happen with the black crepe for Sierra already on order.

As to Todd's comments that the listed versions of iTunes with SQLite vulnerabilities were "Windows only", iTunes 12.8 is listed. There's a Windows 12.8 and, apparently, a Mac 12.8. Confusion reigns, when I'd like certainty on security issues.
The Mac Observer said:
Apple Releases iTunes 12.8 with AirPlay 2 Support (July 10, 2018)
Along with macOS High Sierra 10.13.6, Apple released iTunes 12.8 . . .
Even as I was typing this post, Ric added more about macOS vulnerabilities, the most stunning the hack into Keychain on Mojave 10.14.3 - with an app that looks a lot like an SQLite interface (?).

Another undocumented update to Apple's invisible anti-malware mechanism: . . . it now obfuscates the names of malware which it can detect and remove
That obfuscation is classic Apple secrecy-obsession. It won't keep "bad guys" from testing their malware against a patched Mac, but it doesn't allow end-users to know if Macs are vulnerable to the latest known threats. Be interesting to know if developers of known applications like Malwarebytes are informed by Apple what MRT is blocking. Might save duplicate work, and avoid complications when two different applications are trying to intercept the same malware.

Wander thorough Apple's "security pages" and in a couple of clicks you'll confront the one security Mac recommendation highlighted above all others: "Upgrade to Mojave 10.14.3"

Could it be that the keychain on my MacBook Pro orphaned on El Capitan is safer than on the latest version of Mojave?
 


When I tried to set up an iPhone SE last year (after having purchased and set up many iPhones over many years previously), it was an unmitigated disaster ... I don't know if iMazing was my best option, though, and I was surprised at having to download all the apps again wirelessly and reconfigure a number of things I had already configured on this new phone once. iMazing "erased" the iPhone as part of its restore process, so that may have wiped out all the identity data and settings I'd already added to the new phone....)
Ack, that sounds painful! About two weeks ago, I got a new iPad and wondered how to set it up and get my old iPad Air data on it efficiently. I found that Apple now has instructions for switching to a new device. There are three methods so I tried transfer using Quick Start, which worked amazingly well. Everything (apps, data, mail accounts - except passwords) transferred and looked much as my old iPad.

However, one of my email signatures was wrong, so I tried to correct it, but the Mail setting kept crashing each time I tapped it. I tried reset all contents to no avail. Thinking it was a random transfer glitch, I erased all content and did the quick start again, but the problem persisted.

Then I thought to erase and try "Transfer using iCloud/iTunes" but wonder if the glitch resides in the backups. I spoke with Apple Support, who said it probably would be in the backup. So, I could erase and start from the very beginning or do a quick start using my iPhone. I did the latter, and all apps (and some data) transferred over. None of the mail accounts info transferred.

Although I have more and some different apps on my iPhone than iPad, this setup method worked for me. I think the original glitch might have to do with the iPad Air being 5+ years old. Oh, the new iPad Pro works with iTunes 12.6.5. I hope this helps, and your milage may vary.
 


I had not realized that Apple does not have a bounty program for reporting macOS bugs, only for iOS.
Engadget said:
Researcher finds macOS bug but won’t share details with Apple
Yet Henze won't help Apple patch the exploit because its bug bounty program only pays out to researchers for disclosing bugs on iOS and not macOS. "It's like they don't really care about macOS," he told Forbes. "Finding vulnerabilities like this one takes time, and I just think that paying researchers is the right thing to do because we're helping Apple to make their product more secure."
Forbes said:
Teenage Hacker's Evil App Steals Apple Mac Passwords
Henze found he could create an app that was able to read what was in the keychain without requiring explicit permission from the victim. His mock malware didn’t require special privileges, like administrator-level permissions. “Running a simple app is all that’s required,” Henze said.
As for how the malware could get onto the Mac in the first place, a malicious hacker could hide the keychain exploit in a legitimate app, Henze hypothesized. Or a user could be directed to a webpage that would launch rogue code. And because the attack could grab tokens for accessing the iCloud, it would be possible to take over an Apple ID and download they keychain from the company’s servers, said Henze.
...Forbes had Apple Mac security specialist Patrick Wardle test the exploit. Wardle, a former NSA analyst, was impressed with the young researcher’s find. “Big kudos to Linus. It’s a really lovely bug," he said, joking that “until Apple wraps its head around security, I’m shutting off my Mac and going surfing.
 


Ric Ford

MacInTouch
And the hits just keep coming...
TechCrunch said:
Many popular iPhone apps secretly record your screen without asking
Many major companies, like Air Canada, Hollister and Expedia, are recording every tap and swipe you make on their iPhone apps. In most cases you won’t even realize it. And they don’t need to ask for permission.

... The App Analyst, a mobile expert who writes about his analyses of popular apps on his eponymous blog, recently found Air Canada’s iPhone app wasn’t properly masking the session replays when they were sent, exposing passport numbers and credit card data in each replay session. Just weeks earlier, Air Canada said its app had a data breach, exposing 20,000 profiles.

“This gives Air Canada employees — and anyone else capable of accessing the screenshot database — to see unencrypted credit card and password information,” he told TechCrunch.

... Apps that are submitted to Apple’s App Store must have a privacy policy, but none of the apps we reviewed make it clear in their policies that they record a user’s screen. Glassbox doesn’t require any special permission from Apple or from the user, so there’s no way a user would know.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts