This morning the NY Times published an article entitled "Apple Can Skate by Taylor Swift, but Not Product Missteps." I challenge you to explain to me what the heck Brian X. Chen is talking about.
Showing posts with label Apple. Show all posts
Showing posts with label Apple. Show all posts
Sunday, June 28, 2015
Friday, September 26, 2014
8.0.1-gate: A Postmortem
So what the heck happened?
Apple isn't saying, at least not yet, so we can only speculate. The facts seem to be these:
Apple isn't saying, at least not yet, so we can only speculate. The facts seem to be these:
- Folks who updated their iPhone 6's and iPhone 6+'s to 8.0.1 lost the ability to connect to the cell networks and the use of Touch ID.
- This appears to have affected everyone who updated an iPhone 6 or 6+.
- This appears not to have affected anyone who updated earlier models. (There are some accounts to the contrary, but I'm guessing with every update there are a handful of folks who have issues like these, so let's assume these are outliers).
- This appears not to have affected anyone who updated via iTunes (as opposed to "over the air").
So how did this happen? Well, let's guess.
Thursday, September 25, 2014
Wednesday, September 24, 2014
Wow.
Hard to believe this is the official Apple solution to the 8.0.1-gate.
I did this hours ago, and it worked, but it's shocking that Apple couldn't rush out an over-the-air fix for those who don't have access to iTunes.
http://support.apple.com/kb/HT6487?viewlocale=en_US&locale=en_US
I did this hours ago, and it worked, but it's shocking that Apple couldn't rush out an over-the-air fix for those who don't have access to iTunes.
http://support.apple.com/kb/HT6487?viewlocale=en_US&locale=en_US
Do not update iPhone 6's to iOS 8.0.1!!!
You will not be able to connect to the cell network, and touch ID will break. Don't do it!
Damn, Apple. Get some quality control!
Damn, Apple. Get some quality control!
Tuesday, September 23, 2014
No, I don't think Samsung is fabbing any A8s
There have been some reports today that Samsung is producing 40% of the A8 dies. (Apparently sourced from IHS iSuppli to Re/code). I've seen no photographic evidence of this, whereas I have seen evidence (from ChipWorks) that A8 is manufactured by TSMC.
I doubt this Samsung "news."
First, it's not clear to me that IHS iSuppli even has the technical capability to make this determination, so they may simply be reacting to whispers from the magical "supply chain sources."
Second, TSMC and Samsung have different "design rules." "Design Rules" refers to the set of rules that chip designers must follow. For example, a design rule may specify that the minimum surface area of any piece of metal must be "X" or the spacing between two pieces of metal must be "Y" on metal layer 3. Different fabs also use different processes, meaning wire heights are different, transistors have different properties, etc.
It would be extremely difficult to design for two different fabs, each using a different process, simultaneously. The design effort would be around 90% of the design effort of designing two completely different chips. The only way to do it practically would be for Apple to create their own "worst case" design rules - a sort of "least common denominator." This would leave a lot of performance and power savings on the table. This would still entail difficulties as path timings will differ between the fabs, and fixing a critical path on Fab A's chip could cause a hold time violation on Fab B's chip.
Anything's possible, but this seems unlikely.
If it's true, it goes a long way toward explaining why A8 didn't make a much bigger leap in performance over A7.
I doubt this Samsung "news."
First, it's not clear to me that IHS iSuppli even has the technical capability to make this determination, so they may simply be reacting to whispers from the magical "supply chain sources."
Second, TSMC and Samsung have different "design rules." "Design Rules" refers to the set of rules that chip designers must follow. For example, a design rule may specify that the minimum surface area of any piece of metal must be "X" or the spacing between two pieces of metal must be "Y" on metal layer 3. Different fabs also use different processes, meaning wire heights are different, transistors have different properties, etc.
It would be extremely difficult to design for two different fabs, each using a different process, simultaneously. The design effort would be around 90% of the design effort of designing two completely different chips. The only way to do it practically would be for Apple to create their own "worst case" design rules - a sort of "least common denominator." This would leave a lot of performance and power savings on the table. This would still entail difficulties as path timings will differ between the fabs, and fixing a critical path on Fab A's chip could cause a hold time violation on Fab B's chip.
Anything's possible, but this seems unlikely.
If it's true, it goes a long way toward explaining why A8 didn't make a much bigger leap in performance over A7.
Monday, September 22, 2014
Security and Privacy: Apple's Practices and Techniques
Introduction
In a series of posts investigating various Apple patents and patent applications, we happened to touch upon certain aspects of the security and privacy techniques that are built into Apple's products:
On Sept. 17, Apple rolled out an entire section of its website devoted to explaining its privacy policies and technologies. This coincided with several important improvements to the techniques it is using.
The reaction to this was bipolar. On the one hand, many applauded Apple not just for taking strong steps to secure and protect users' data, but for being open and transparent about what is protected and how. On the other hand, many doubted Apple's motives, insisting that there must be some sort of loophole, or that Apple is lying, or that this is all some sort of insidious Apple plot. Some mistakenly compared to Google's disclosures, which do little to explain how things are actually protected (and which, by the way, are substantively less protected than in Apple's systems).
In this report we'll take a closer look at Apple's practices, with a careful review of Apple's recently-published iOS Security white paper.
Saturday, September 20, 2014
A Day at the Mall
Valley Fair Mall, San Jose/Santa Clara California
Sept. 20, 2014
Samsung:
200' Away - Microsoft:
Just across from the Microsoft Store, the Apple Store:
Friday, September 19, 2014
Wednesday, September 17, 2014
Update on Apple Security Technologies
Apple has posted a lengthy white paper describing the various security and privacy methods it uses in its software and hardware. The paper may be found here:
http://images.apple.com/privacy/docs/iOS_Security_Guide_Sept_2014.pdf
I will have a full report once I've had an opportunity to digest it, but I note that, as I surmised in this post, based on one of Apple's patents, Apple is indeed using a "mailbox" technique to isolate its Secure Enclave from the CPU.
http://images.apple.com/privacy/docs/iOS_Security_Guide_Sept_2014.pdf
I will have a full report once I've had an opportunity to digest it, but I note that, as I surmised in this post, based on one of Apple's patents, Apple is indeed using a "mailbox" technique to isolate its Secure Enclave from the CPU.
Pay Technology - Use of NFC
Once again we take a peek at the technology behind Apple's latest innovations, again focussing on Pay. This time we get some insight into the use of NFC courtesy of a recent Apple patent application, U.S. Pat. Pub. No. 2014/0019367.
See previous posts in this series:
Pay Technology: The Secure Enclave Processor
Pay - Tokenization for Security
See previous posts in this series:
Pay Technology: The Secure Enclave Processor
Pay - Tokenization for Security
Trouble in HealthKit land?
According to this article at MacRumors, HealthKit apps have been pulled from the App Store as iOS 8.0 is released, apparently because of some flaw in HealthKit itself.
I've been working on a HealthKit app all summer (and have lost 40 pounds and 15 mg/mm off my blood pressure because of it), and will report on my app soon.
In the meantime, based on my (now) extensive experience with the HealthKit API's, which act as a sort of central database for health-related information, I think there are two possibilities:
Update: Looks like it was either data loss or leakiness due to side channel, since Apple is saying it may take a couple of weeks to fix via software update.
I've been working on a HealthKit app all summer (and have lost 40 pounds and 15 mg/mm off my blood pressure because of it), and will report on my app soon.
In the meantime, based on my (now) extensive experience with the HealthKit API's, which act as a sort of central database for health-related information, I think there are two possibilities:
- Data loss. From time-to-time with various iOS betas I've experienced problems where data has disappeared from my device.
- Leakiness. Two sub-possibilities. Either there is some side channel vector that allows unauthorized access to HealthKit data (which would obviously be problematic) or Apple just discovered some flaw in the app review system that should probably be checking to make sure HealthKit apps don't do things like take HealthKit data and put it in the cloud.
Depending on what the issue is, it sounds like an iOS point update may be required to resolve it, which could result in delay of at least a week.
Update: Looks like it was either data loss or leakiness due to side channel, since Apple is saying it may take a couple of weeks to fix via software update.
Why Macs Will Get ARM'd, Part III
This is Part III of continuing series of articles that explain why it is likely that Apple will port its Mac line of desktop and laptop computers from x86 to the ARM architecture, and why it would be beneficial, both to customers and to Apple, for it to do so.
Here are quick links to the prior parts. I suggest reading them before reading this part.
Part I: Why Apple is Motivated
Part II: Why ARM is a Better Solution for Apple
In this Part III, I will discuss how this could work from a software point of view. Part IV will discuss hardware options.
Here are quick links to the prior parts. I suggest reading them before reading this part.
Part I: Why Apple is Motivated
Part II: Why ARM is a Better Solution for Apple
In this Part III, I will discuss how this could work from a software point of view. Part IV will discuss hardware options.
Monday, September 15, 2014
Pay Technology: The Secure Enclave Processor
This is part of a continuing series of articles focussing on discrete technologies developed by Apple in support of its products. The first article examined Apple's patent relating to tokenization and extrapolated from this how Pay appears to work.
This time we'll look at the Secure Enclave, basing the analysis on Apple's U.S. Patent No. 8,832,465 invented by, among others, my former colleague Manu Gulati.
This time we'll look at the Secure Enclave, basing the analysis on Apple's U.S. Patent No. 8,832,465 invented by, among others, my former colleague Manu Gulati.
iOS 9 "Predictions"
Okay, maybe more like a wishlist.
iOS 8 goes a long way toward making iOS devices more useful for more types of tasks, but there is still a lot of low hanging fruit that can be picked. Here are a few things I hope we see demoed at the next WWDC.
iOS 8 goes a long way toward making iOS devices more useful for more types of tasks, but there is still a lot of low hanging fruit that can be picked. Here are a few things I hope we see demoed at the next WWDC.
Apple sells 4 million iPhone 6's on first day of preorders
How's the latest iPhone killer - I guess it's Amazon's Fire Phone - doing?
Saturday, September 13, 2014
Shipping of initial iPhone 6's Beginning
Judging by my own order status, which was set at "Processing" a few hours ago, Apple is getting ready to ship iPhones for deliveries on Sept. 19.
Friday, September 12, 2014
Pay - Tokenization for Security
Apple's new payment system, Pay, incorporates numerous technologies to improve security. As someone who's had to try and remember all of his credit-card autopay's and go through them one-by-one to update account information - twice in a year - due to theft of credit card information from various retailers, I appreciate this. Contrary to a dumb article at the New York Times (no link to dumbness), part of the cost of security breaches is born by the consumer, in the time and energy spent dealing with the aftermath.
One of the techniques used in Pay is "one time tokens."
What's that?
One of the techniques used in Pay is "one time tokens."
What's that?Thursday, September 11, 2014
Watch: Design is What You Leave On the Cutting Room Floor
Absence reveals purpose
Looking at what isn't (as far as we know) in the Watch tells us a lot about the problem the device is designed to solve. Unfortunately, unlike in some past keynotes, this time Apple didn't start their presentation by telling us what real-world problems the device is intended to solve. Which is not the same as saying that Apple didn't have such a vision in mind before they started designing; the fact that they left so many "features" on the cutting-room flaw tells me they had a clear understanding of what the watch was intended to be. This is not surprising, as it's part of Apple's DNA. Apple ruthlessly cuts features that don't further their products' ability to solve the problems that Apple intends them to solve.
Subscribe to:
Posts (Atom)




