In the USA, there's already some case law regarding the relationship between warranties and third-party software modifications which basically says that the warranty applies unless the manufacturer can show that the modification affected the warranted part. Modifying LiIon batteries to use deeper discharge cycles can easily be shown to do that, so your addition would likely void the warranty on the battery.
The problem is not your doing this, it's what happens to the person who buys your car second hand. If it's obvious that you've hacked the battery controller in a way that will reduce the battery lifetime, then that's fine. If it isn't, then when they take it in for a warranty repair when the battery dies they're in for an expensive surprise.
The battery can put through a total of X kWh power in it's entire life (through charge/discharge).
From the cited table, the total number of full discharge-equivalents (NMC, LiPO4 ) for can be calculated as:
100% (full discharge): 300, 600
80%: 320, 720
60%: 360, 900
40%: 600, 1,200
20%: 300, 1,800
10%: 1,000, 1,500
I'm not sure what the discontinuity at 20% for NMCs is about - I suspect a copy-and-paste type in their table. Most large LiIon battery installations advertise 60% capacity in the underlying storage as empty. From the cited table, you get twice as much total storage (five times as many 40% cycles than 100% cycles) by doing this. Discharging only down to 80-90% capacity will be even more efficient, but has the downside that you need twice the mass of battery if you're going to 80% than discharging to 60% for the same per-charge capacity, which is prohibitive in automotive applications (though not for fixed storage for renewable power plants - they cost might be).
These aren't lead acid cells which get damaged with a 100% discharge
No, they get completely destroyed. This is why the charging circuit doesn't let you completely discharge any LiIon batteries. If you want to see what happens, get a laptop battery, run the laptop until it reports empty, and then leave the battery for a few months for the remaining charge to leak. Don't store it near anything flammable...
Not true. The two political parties in the US are beholden to different special interest groups. For example, the Democrats will never refuse a request from Hollywood and the Republicans will never refuse a request from the oil industry.
Not really possible with most Windows phones. My partner has a Lumia 1020 that she's just replaced with a newer Android phone. The 1020 still has a much better camera and similar other specs. She'd much rather run Android on the 1020, but there's no port.
Someone builds a system for the express stated purpose of building psychological profiles for large-scale manipulation. Companies jump on it, because they can use it to persuade people to buy their crap. Eventually someone figures out that it can be used to manipulate elections. Everyone acts shocked.
Second, Google's tried the 3rd party vendor route and gotten shit products out of it and continues watching Apple reap 95% of the mobile profit
Are you sure about that? Apple makes some profit on the hardware and a big chunk on iAds and on their 30% cut from the App Store. Google takes a similar cut from the Play store, and a lot more from their mobile advertising platform, without having to be in the low-margin hardware business.
I think the problem was that Nokia thought their customers were AT&T, Verizon
I suspect part of the reason for this is that Nokia's customers were and still are AT&T, Verizon, and so on. Even after they sold their handset business, they're still selling a lot of the back-end infrastructure (which has much higher margins and less annoying customers). The handsets, to them, were just part of a system that they were selling to a network operator, not a device owned by an individual.
At the end of the day that is what killed them along with some weapon's grade stupid management decisions relating to Microsoft
I'm still not convinced that the decision to go with Windows Phone was particularly bad. My partner had a Nokia Windows phone and it was a nice device with a good UI and solid hardware (and the Nokia Here maps app was actually good). If they'd gone with Android, they'd have been stuck in a race-to-the-bottom in a market with razor-thin margins were Google is the only company that makes serious money. They had nothing internal, because they had six competing internal replacements for S60, all of which were more focused on sabotaging the other five groups than on producing something to compete with Apple or Google. The surprising thing was that Microsoft, a company that achieved a monopoly position by doing everything in its power to encourage third-party development for their platform, completely failed to attract third-party apps to Windows Phone.
They're the same problem. DRM empowers the distributor at the expense of the content creator. By insisting on DRM, they allowed companies like Amazon and Netflix to ship clients on dozens of different devices, often with no sensible software upgrade mechanism (think: 'Smart' TVs), over which they then have complete control.
They completely failed to learn the lesson from the music industry: First the big four record labels insisted on DRM. Apple included some DRM in iTunes and the iPod and so were allowed to sell the music. Then they realised that the only way of having both access to the large installed base of iPod owners and to DRM was to agree to whatever terms Apple wanted. By insisting on DRM, they'd given Apple a huge bargaining advantage. For once, they picked the sensible solution: they allowed Amazon to sell their music without DRM. Instant end to Apple's monopoly on digital music distribution, the downloaded files worked on hundreds of different devices (computers, portable and fixed music players, mobile phones) with no extra cost for the music sellers, and their sales shot up.
Newsflash to anyone selling mass-market digital goods: Some people will always pirate them. Often these are people who couldn't afford them anyway and you'll probably get some free advertising from them, if nothing else. If one person pirates them, anyone could, but the vast majority of your target audience won't if you are willing to sell to them at a reasonable price and in a convenient format.
If the movie industry wants to prevent Amazon and Netflix from controlling their channel, then the solution is simple. Define an open standard for listing available media files and downloading them, with account authentication and registration for payment information. Let anyone write apps to use this and publish your content with it. If you're a small publisher, team up with others to provide aggregate services. Don't try to control how people watch your content, try to encourage them to give you money for it.
How long will that keep going? Amazon has announced (in the UK, at least) they they're shutting down their DVD rental service, after buying their largest competitor.
There's increasing talk of regulating the fuel. Ships are already required to burn cleaner fuel near coastlines in a lot of places and some have been caught not doing this. I wouldn't be surprised if the end result is a requirement that any ships going to or from a nation's ports or travelling through its territorial waters must only burn cleaner fuel, because that would be a lot easier to enforce. That gives a big incentive to switch to more efficient propulsion.
There have been a few designs in recent years for ships with electric drivetrains, large solar arrays and wind turbines, and backup diesel generators (or primary diesel generators that are only expected to provide 50-90% of the total power depending on conditions).
If the update came from the carrier, then there's probably a class-action lawsuit waiting to happen. If the carrier pushes you an update that makes your device do something that allows them to charge you money, then it's probably a good argument to be made in court that you're not liable for any of that extra cost.
Waiting makes even more sense if you're not buying the latest. The price of the older models drops a lot as people sell their old iPhone to buy a new one in the month or two after the release of a new model.
One of their phones and three of their tablets are supported by LineageOS. At this point, I've given up on first-party support from any Android vendor. None of them support the software for anything like the lifetime of the hardware, so if if you don't want it to die prematurely then third-party support is the only thing that matters.
Not correct. Nokia very much did NOT ignore the smartphone market. The problem was that their product offerings were not well aligned with what it turned out customers actually wanted
Nokia proved that being first mover isn't always an advantage. They released their first smartphone in 1996 with a massive 4MB of RAM (the minimum requirement for Windows 95, though in practice 8MB was a more realistic minimum and 16MB was recommended). They redesigned their kernel (EKA2) in 1998 to allow the UI and the baseband to run on the same ARM core, giving hard realtime and isolation guarantees to the baseband, which became irrelevant when small ARM cores became cheap (modern SoCs have a huge number of M-profile cores, so adding something like an M5 or M7 to run the baseband is of negligible cost). A lot of their APIs were designed for environments where 4MB of RAM was a lot.
In contrast, iOS is basically the same kernel that they use on laptops and a very similar window server and set of userspace APIs. Apple's mobile UIs are actually less memory-saving than their desktop ones, because AppKit inherits a lot of optimisations from NeXT workstations with 8MB of RAM that are simply not worth it on an iPhone with gigabytes (and counterproductive, because they consume extra CPU to save RAM, which ends up being worse for battery life).
In The Humane Interface (second chapter, as I recall), Jef Raskin draws a lot of parallels between computer games and bad UIs. Adventure games are basically bad UIs: there's a set of tasks that must be completed in one of a small number of orders and the user interface is designed in such a way that the user has to think hard about how to perform each interaction, often with lots of navigation in the middle. A good UI is the exact opposite of this (though an adventure game designed in this way would have about a dozen mouse clicks and be quite boring) and I cringe whenever I hear a UI designer extolling the fact that their design is 'like a game'.
Most importantly: in Windows 95, all UI elements that were clickable were visually distinct from ones that were not. They were (mostly) raised if they were one-shot actions (buttons, sliders) or lowered if they were selectable (input fields). This is a huge visual clue for the user, but is completely gone in a lot of newer UI designs.
He was still pushing this idea much later. This is what the Semantic Web and XHTML 2 were about: complete separation of data and presentation. The idea was that you'd provide XML data and web APIs and you'd also provide a default renderer for this information. For example, an online store's web interface would be backed by a set of queries to their inventory-control system and all of these would be exposed publicly. If someone didn't like your UI, they were free to substitute their own.
Google killed this with their push to HTML5 and co-mingling of data and presentation because it was a threat to advertising revenue: if every web site allows you to choose how you render the core data, it's almost impossible to insert ads in a way that the user can't trivially remove.
Apple was originally backing Sir Tim's vision. They included a tool called Sherlock that allowed you to easily provide rich native renderings for web-provided data, including things like eBay and flight tracking by default.
My UI designs were subjected to usability testing a few times, with customers video recorded while attempting to accomplish a task.
This is really the key part. Watch the users, don't ask them questions. MS did some research in the '90s where they asked users which of two options was faster, and then they timed them doing both. In almost all cases, the users reported that the slower one was faster.
Fortunately, the incompetent ones are easy to spot. Only an incompetent user interface designer self-identifies as a UX specialist. Competent ones self-identify as HCI specialists or similar.
And this scheme is unnecessary. You can have security without an 'enclave' too. If I don't install stupid apps on android - it is secure too.
Not true. The Linux kernel used in Android has had multiple privilege escalation vulnerabilities and the Android browser has had multiple arbitrary code execution vulnerabilities. For example, Stagefright allowed a maliciously crafted video that played in a web page to run arbitrary code with root privilege. At that point, all encryption keys and other credentials owned by any app (the mail client, IM, mobile banking) can be exfiltrated and sent to any remote network location (unless the device is using an equivalent of the secure element to implement Android's keychain service, which I think some Samsung devices are). In contrast, on an Apple device an equivalent compromise would allow the attacker to encrypt and decrypt data on the device, but would not allow them to extract the keys. Once the vulnerability is patched and the malware removed, the Android attacker would still have full control over the keys, whereas the iOS attacker would only have access to data that they'd decrypted during the compromise.
I don't want "secure" bootloaders, I want the ability to load whatever firmware I want on to a device.
I want both. When I install LineageOS, I want to have to reboot into a special mode and add their public key to the bootloader, and I then don't want anyone to be able to install an OS from a different vendor on the phone without completely erasing all of my data.
So it's a separate little room, with obscure methods used to hold it's little secrets.
No. Security by obscurity means that you rely on other people not knowing the implementation details for security. This is not the case for the Apple secure element: its memory is physically inaccessible from the main core. It is not using the normal memory bus and has a simple communication channel with the main core for performing a fixed set of services. This is documented by Apple.
I realize that Apple probably has the term 'Secure Enclave' copyrighted
First, you can't copyright a term, though you could trademark it. Second, given that 'Secure Enclave' is an Intel marketing term used to define a region protected by SGX, I think that you're very likely to be wrong there.
The enclave can and will have it's security penetrated. It's a matter of time.
Of course it will. Any security mechanism can be bypassed, it's just a question of how much you want to spend on it. One of my colleagues has been having fun popping the tops of the chips and trying to get keys out of the secure element with an electron microscope. If he doesn't succeed, someone else will. Or they might find a vulnerability in the secure element's software (it runs an L4 microkernel and a small amount of userspace software and is quite well audited, though nothing's perfect) that can convince it to dump keys on the wire for the CPU core to hoover up.
Go and re-read that story. The keys weren't exfiltrated from the enclave, they managed to acquire a copy of the firmware that had not been encrypted (which didn't impact the security at all, because Apple is using encryption for signing there, so it doesn't matter if you get the plaintext it matters if you get the private key).
Slashdot Mirror
In the USA, there's already some case law regarding the relationship between warranties and third-party software modifications which basically says that the warranty applies unless the manufacturer can show that the modification affected the warranted part. Modifying LiIon batteries to use deeper discharge cycles can easily be shown to do that, so your addition would likely void the warranty on the battery.
The problem is not your doing this, it's what happens to the person who buys your car second hand. If it's obvious that you've hacked the battery controller in a way that will reduce the battery lifetime, then that's fine. If it isn't, then when they take it in for a warranty repair when the battery dies they're in for an expensive surprise.
The battery can put through a total of X kWh power in it's entire life (through charge/discharge).
From the cited table, the total number of full discharge-equivalents (NMC, LiPO4 ) for can be calculated as:
I'm not sure what the discontinuity at 20% for NMCs is about - I suspect a copy-and-paste type in their table. Most large LiIon battery installations advertise 60% capacity in the underlying storage as empty. From the cited table, you get twice as much total storage (five times as many 40% cycles than 100% cycles) by doing this. Discharging only down to 80-90% capacity will be even more efficient, but has the downside that you need twice the mass of battery if you're going to 80% than discharging to 60% for the same per-charge capacity, which is prohibitive in automotive applications (though not for fixed storage for renewable power plants - they cost might be).
These aren't lead acid cells which get damaged with a 100% discharge
No, they get completely destroyed. This is why the charging circuit doesn't let you completely discharge any LiIon batteries. If you want to see what happens, get a laptop battery, run the laptop until it reports empty, and then leave the battery for a few months for the remaining charge to leak. Don't store it near anything flammable...
Not true. The two political parties in the US are beholden to different special interest groups. For example, the Democrats will never refuse a request from Hollywood and the Republicans will never refuse a request from the oil industry.
Not really possible with most Windows phones. My partner has a Lumia 1020 that she's just replaced with a newer Android phone. The 1020 still has a much better camera and similar other specs. She'd much rather run Android on the 1020, but there's no port.
Someone builds a system for the express stated purpose of building psychological profiles for large-scale manipulation. Companies jump on it, because they can use it to persuade people to buy their crap. Eventually someone figures out that it can be used to manipulate elections. Everyone acts shocked.
Second, Google's tried the 3rd party vendor route and gotten shit products out of it and continues watching Apple reap 95% of the mobile profit
Are you sure about that? Apple makes some profit on the hardware and a big chunk on iAds and on their 30% cut from the App Store. Google takes a similar cut from the Play store, and a lot more from their mobile advertising platform, without having to be in the low-margin hardware business.
I think the problem was that Nokia thought their customers were AT&T, Verizon
I suspect part of the reason for this is that Nokia's customers were and still are AT&T, Verizon, and so on. Even after they sold their handset business, they're still selling a lot of the back-end infrastructure (which has much higher margins and less annoying customers). The handsets, to them, were just part of a system that they were selling to a network operator, not a device owned by an individual.
At the end of the day that is what killed them along with some weapon's grade stupid management decisions relating to Microsoft
I'm still not convinced that the decision to go with Windows Phone was particularly bad. My partner had a Nokia Windows phone and it was a nice device with a good UI and solid hardware (and the Nokia Here maps app was actually good). If they'd gone with Android, they'd have been stuck in a race-to-the-bottom in a market with razor-thin margins were Google is the only company that makes serious money. They had nothing internal, because they had six competing internal replacements for S60, all of which were more focused on sabotaging the other five groups than on producing something to compete with Apple or Google. The surprising thing was that Microsoft, a company that achieved a monopoly position by doing everything in its power to encourage third-party development for their platform, completely failed to attract third-party apps to Windows Phone.
They're the same problem. DRM empowers the distributor at the expense of the content creator. By insisting on DRM, they allowed companies like Amazon and Netflix to ship clients on dozens of different devices, often with no sensible software upgrade mechanism (think: 'Smart' TVs), over which they then have complete control.
They completely failed to learn the lesson from the music industry: First the big four record labels insisted on DRM. Apple included some DRM in iTunes and the iPod and so were allowed to sell the music. Then they realised that the only way of having both access to the large installed base of iPod owners and to DRM was to agree to whatever terms Apple wanted. By insisting on DRM, they'd given Apple a huge bargaining advantage. For once, they picked the sensible solution: they allowed Amazon to sell their music without DRM. Instant end to Apple's monopoly on digital music distribution, the downloaded files worked on hundreds of different devices (computers, portable and fixed music players, mobile phones) with no extra cost for the music sellers, and their sales shot up.
Newsflash to anyone selling mass-market digital goods: Some people will always pirate them. Often these are people who couldn't afford them anyway and you'll probably get some free advertising from them, if nothing else. If one person pirates them, anyone could, but the vast majority of your target audience won't if you are willing to sell to them at a reasonable price and in a convenient format.
If the movie industry wants to prevent Amazon and Netflix from controlling their channel, then the solution is simple. Define an open standard for listing available media files and downloading them, with account authentication and registration for payment information. Let anyone write apps to use this and publish your content with it. If you're a small publisher, team up with others to provide aggregate services. Don't try to control how people watch your content, try to encourage them to give you money for it.
How long will that keep going? Amazon has announced (in the UK, at least) they they're shutting down their DVD rental service, after buying their largest competitor.
This just in: remote filesystems are not as good as distributed revisions control systems at being a distributed revision control systems. Film at 11.
There's increasing talk of regulating the fuel. Ships are already required to burn cleaner fuel near coastlines in a lot of places and some have been caught not doing this. I wouldn't be surprised if the end result is a requirement that any ships going to or from a nation's ports or travelling through its territorial waters must only burn cleaner fuel, because that would be a lot easier to enforce. That gives a big incentive to switch to more efficient propulsion.
There have been a few designs in recent years for ships with electric drivetrains, large solar arrays and wind turbines, and backup diesel generators (or primary diesel generators that are only expected to provide 50-90% of the total power depending on conditions).
If the update came from the carrier, then there's probably a class-action lawsuit waiting to happen. If the carrier pushes you an update that makes your device do something that allows them to charge you money, then it's probably a good argument to be made in court that you're not liable for any of that extra cost.
Waiting makes even more sense if you're not buying the latest. The price of the older models drops a lot as people sell their old iPhone to buy a new one in the month or two after the release of a new model.
One of their phones and three of their tablets are supported by LineageOS. At this point, I've given up on first-party support from any Android vendor. None of them support the software for anything like the lifetime of the hardware, so if if you don't want it to die prematurely then third-party support is the only thing that matters.
Not correct. Nokia very much did NOT ignore the smartphone market. The problem was that their product offerings were not well aligned with what it turned out customers actually wanted
Nokia proved that being first mover isn't always an advantage. They released their first smartphone in 1996 with a massive 4MB of RAM (the minimum requirement for Windows 95, though in practice 8MB was a more realistic minimum and 16MB was recommended). They redesigned their kernel (EKA2) in 1998 to allow the UI and the baseband to run on the same ARM core, giving hard realtime and isolation guarantees to the baseband, which became irrelevant when small ARM cores became cheap (modern SoCs have a huge number of M-profile cores, so adding something like an M5 or M7 to run the baseband is of negligible cost). A lot of their APIs were designed for environments where 4MB of RAM was a lot.
In contrast, iOS is basically the same kernel that they use on laptops and a very similar window server and set of userspace APIs. Apple's mobile UIs are actually less memory-saving than their desktop ones, because AppKit inherits a lot of optimisations from NeXT workstations with 8MB of RAM that are simply not worth it on an iPhone with gigabytes (and counterproductive, because they consume extra CPU to save RAM, which ends up being worse for battery life).
In The Humane Interface (second chapter, as I recall), Jef Raskin draws a lot of parallels between computer games and bad UIs. Adventure games are basically bad UIs: there's a set of tasks that must be completed in one of a small number of orders and the user interface is designed in such a way that the user has to think hard about how to perform each interaction, often with lots of navigation in the middle. A good UI is the exact opposite of this (though an adventure game designed in this way would have about a dozen mouse clicks and be quite boring) and I cringe whenever I hear a UI designer extolling the fact that their design is 'like a game'.
Most importantly: in Windows 95, all UI elements that were clickable were visually distinct from ones that were not. They were (mostly) raised if they were one-shot actions (buttons, sliders) or lowered if they were selectable (input fields). This is a huge visual clue for the user, but is completely gone in a lot of newer UI designs.
He was still pushing this idea much later. This is what the Semantic Web and XHTML 2 were about: complete separation of data and presentation. The idea was that you'd provide XML data and web APIs and you'd also provide a default renderer for this information. For example, an online store's web interface would be backed by a set of queries to their inventory-control system and all of these would be exposed publicly. If someone didn't like your UI, they were free to substitute their own.
Google killed this with their push to HTML5 and co-mingling of data and presentation because it was a threat to advertising revenue: if every web site allows you to choose how you render the core data, it's almost impossible to insert ads in a way that the user can't trivially remove.
Apple was originally backing Sir Tim's vision. They included a tool called Sherlock that allowed you to easily provide rich native renderings for web-provided data, including things like eBay and flight tracking by default.
My UI designs were subjected to usability testing a few times, with customers video recorded while attempting to accomplish a task.
This is really the key part. Watch the users, don't ask them questions. MS did some research in the '90s where they asked users which of two options was faster, and then they timed them doing both. In almost all cases, the users reported that the slower one was faster.
Fortunately, the incompetent ones are easy to spot. Only an incompetent user interface designer self-identifies as a UX specialist. Competent ones self-identify as HCI specialists or similar.
Looks nice, but unfortunately amazon.co.uk has them for about £300 and few places have them much cheaper in the UK.
And this scheme is unnecessary. You can have security without an 'enclave' too. If I don't install stupid apps on android - it is secure too.
Not true. The Linux kernel used in Android has had multiple privilege escalation vulnerabilities and the Android browser has had multiple arbitrary code execution vulnerabilities. For example, Stagefright allowed a maliciously crafted video that played in a web page to run arbitrary code with root privilege. At that point, all encryption keys and other credentials owned by any app (the mail client, IM, mobile banking) can be exfiltrated and sent to any remote network location (unless the device is using an equivalent of the secure element to implement Android's keychain service, which I think some Samsung devices are). In contrast, on an Apple device an equivalent compromise would allow the attacker to encrypt and decrypt data on the device, but would not allow them to extract the keys. Once the vulnerability is patched and the malware removed, the Android attacker would still have full control over the keys, whereas the iOS attacker would only have access to data that they'd decrypted during the compromise.
I don't want "secure" bootloaders, I want the ability to load whatever firmware I want on to a device.
I want both. When I install LineageOS, I want to have to reboot into a special mode and add their public key to the bootloader, and I then don't want anyone to be able to install an OS from a different vendor on the phone without completely erasing all of my data.
So it's a separate little room, with obscure methods used to hold it's little secrets.
No. Security by obscurity means that you rely on other people not knowing the implementation details for security. This is not the case for the Apple secure element: its memory is physically inaccessible from the main core. It is not using the normal memory bus and has a simple communication channel with the main core for performing a fixed set of services. This is documented by Apple.
I realize that Apple probably has the term 'Secure Enclave' copyrighted
First, you can't copyright a term, though you could trademark it. Second, given that 'Secure Enclave' is an Intel marketing term used to define a region protected by SGX, I think that you're very likely to be wrong there.
The enclave can and will have it's security penetrated. It's a matter of time.
Of course it will. Any security mechanism can be bypassed, it's just a question of how much you want to spend on it. One of my colleagues has been having fun popping the tops of the chips and trying to get keys out of the secure element with an electron microscope. If he doesn't succeed, someone else will. Or they might find a vulnerability in the secure element's software (it runs an L4 microkernel and a small amount of userspace software and is quite well audited, though nothing's perfect) that can convince it to dump keys on the wire for the CPU core to hoover up.
But whatever. I'm dumb.
Ignorant and confrontational, at least.
Go and re-read that story. The keys weren't exfiltrated from the enclave, they managed to acquire a copy of the firmware that had not been encrypted (which didn't impact the security at all, because Apple is using encryption for signing there, so it doesn't matter if you get the plaintext it matters if you get the private key).