Most of what's on Thingiverse appears to be available under CC-Attribution, all that's needed would be to do that attribution and he'd be in the clear. Thingiverse even has an API to get the information automatically, to verify license status.
Instead, he seems to think that anything on the Internet is public domain and he can do whatever he wants. Good luck with that!
I don't know if the "no commercial use" CC licenses would bar this - sell it as a service to print designs for an individual rather than selling the item. Charge for materials and time to print.
One thing to note is that there appear to be many many copyright violations on Thingiverse itself, so just assuming that having a CC license on Thingiverse means you're in the clear would be a big mistake.
Why would the NSA put in a back door that could be used by anyone? Only allow a connection that has the right private key. Sure, the key might be stolen, but it's a lot more secure than a wide open vulnerability. The NSA is more competent than that.
Condorcet voting has some significant advantages, including being able to create a simple matrix of results from each precinct that can be sent up the line to be totalled with other precincts. You do have to resolve cycles, but they're very rare in practice.
I think both are about as easy to explain, and both (usually) choose the same winner.
If the Secure Enclave has non-volatile storage it can access directly, the boot ROM can do this.
Adding additional hardware support (e.g. a write-once write-only key register) could make it easier, but even without that you could require that the passcode be entered in order to mark a new SE firmware image as being usable without wiping all keys.
I'm not. I'm perfectly aware that the 5c can be easily compromised to make a brute force attack more feasible.
Tim Cook's letter seems to be saying that ALL phones could be compromised by Apple, even current ones with a Secure Enclave. If the SE already protects against an attack like this, then Tim Cook's letter is overstating the case. If it doesn't, then the promise of the Secure Enclave wasn't fulfilled.
If Apple prevails, there will still be other cases, they're just waiting on this one to see what specifically the courts find acceptable and not acceptable, and what they leave open.
If the FBI prevails, that doesn't mean all those other cases get automatically approved, either.
The only thing that needs to be written is a new request over USB to submit a passcode and report the result. The rest of ut is removing code, not writing it. I'm not sure that there's much difference, at that level, between writing code and clicking a button to change a setting or typing in a password or signing a firmware image.
You're right that the primary issue is how far does the All Writs Act go, what are the limits on what they can require, but this case doesn't really show a very high burden on Apple.
And then there's a whole case of cyberattackers wanting to look at the firmware and find ways to break it - through jailbreaking if need be. Imagine the havoc caused if this firmware was released as part of a jailbreak tool for iOS.
Jailbreaking is a lot more difficult and complex than what this firmware would be. Having the firmware wouldn't allow anyone (except for Apple) to sign it for any other device.
If you have a jailbroken device, you could already do this. However, AFAIK, there's no way to jailbreak current phones without having the passcode in the first place.
So, no, without Apple's signing keys, the firmware is useless. With Apple's signing keys, it's unnecessary.
People already can do this, if only they had Apple's signing keys.
If Apple's signing keys get out, it's game over. Without the keys, there's nothing to "get out", Apple just needs to protect their keys as they're already doing. Signing attack firmware for one device doesn't create any new capability except against that one device.
Nonsense. If China wants to demand that Apple hack a phone, they don't need a US court to say they can.
There's no automatic "now you can submit any request you want" that would be granted to any law enforcement organization if the FBI prevails in this case. Each one will have its own facts, just as the facts in this case are different from earlier All Writs Act orders. Apple can object to them just as they have here. If the facts in this case (dead terrorists, government owned device, more than adequate grounds for a valid warrant) justify allowing a brute force attack on the phone, that doesn't mean Apple would lose if they object to a completely different set of facts.
If Apple prevails in this case, how does that affect in any way whether other requests/demands will be made?
How would it deter other countries from requiring Apple to do the same thing for them? It's not like it's a big secret that Apple CAN do this.
You can't prevent an attack on older devices, the backdoor already exists (Apple's signing key), the only issue is if Apple can be forced to sign with it. Since signing attack firmware only allows it to run on a single device, and there are plenty of people who could hack the OS to do this (see any of the jailbreak hackers), the issue has nothing to do with opening a Crypto-Pandora's box but establishing exactly how far an All Writs Act order can go. Yes, Apple could do the modifications more easily, and if they write it then that actually gives them more assurance of what they're signing, but ultimately it comes down to the simple act of signing some firmware.
If Tim Cook is right and even current devices are vulnerable, then the Secure Enclave also has a backdoor in the signing keys. The only way to prevent attacks is to fix the hardware so they really are impossible, even for Apple, which is what I thought Apple already promised.
What's being asked for isn't a forensic tool, even less so than "a simple lab service, like dumping a phone". It doesn't dump or analyze anything, it simply reports whether a passcode is correct. You strip out most of the normal OS, disable the delay and wipe code (in fact, remove the code that allows ANY write to non-volatile memory), and add in to the iTunes communication routines a simple submit-passcode request. That's all. You'd then need a slightly modified version of their existing tools to load a test version onto a device and add a routine to do the passcode submission.
HOW they get the passcode isn't of any relevance to the validity of what the passcode unlocks, the only thing you need to show is that the device wasn't modified while doing the brute forcing, and that's no different from something that merely dumps all the data. Dumping all the data has more requirements, it also has to show that it dumped everything and did so accurately. It's much easier to prove that it accurately discovered the passcode: it works. If a data dumper isn't a "forensic tool", a passcode brute force enabler also is not.
That's no different from the current situation. The new firmware could still just brute force the passcode, the only difference is that you need modified firmware for the Secure Enclave as well.
In order to be able to prevent modified firmware from running in the SE, it would need some hardware support that allows the SE boot ROM to do something that the loaded firmware can't, such as a write-once (per reset) write-only register where the SE boot ROM code can store the current SE firmware signature in, and some non-volatile values inside the Secure Enclave itself (or the equivalent, if the SE can directly access the Effaceable Memory without going through the main processor, that would work, but everything I've seen indicates that the SE is almost totally isolated without direct access to anything except through the main processor).
Apple doesn't say. They've said before that even Apple, with their signing keys, can't attack the encryption in the Secure Enclave, but now Tim Cook is saying that modified firmware CAN change the rules after the fact, which implies that they do NOT have any such hardware protection in the SE to prevent running modified firmware in there to remove delays and auto-wipe.
Does that say whether that's enforced by the hardware and/or SE boot code, or is that just enforced by the firmware itself?
What stops the processor, running modified firmware, from just loading a different (signed) firmware blob into the SE on restart, one that doesn't have all the restrictions of the normal SE firmware? The firmware isn't flashed into the SE, as I understand it, it's loaded from the boot file system by the main processor during the boot sequence, and as long as it's properly signed it will be accepted.
I'd certainly think Apple would have thought of that and guarded against such an attack, but there hasn't been any confirmation that it's so.
Apple's security is pretty good, with newer phones they move all the crypto into a separate isolated processor, the Secure Enclave, which does enforce retry delays and wipes.
The request isn't to modify the firmware, but to use DFU mode to basically load the equivalent of a rescue disk using something similar to an initcpio ram disk. It is specifically not supposed to modify the device in any way.
Apple's hardware encrypts all files sent to disk with a different random 256-bit key for each file, and encrypts the file key with a class key (based on the protection it's supposed to have), and then encrypts THAT with a random 256-bit key that's unlocked by the passcode using a PBKDF2 with an unreadable 256-bit random hardware key (UID) that's burned in to the processor and enough iterations to take 80ms per attempt. The brute force attack must be done on the phone itself, the UID is unknown and unknowable unless you use a physical attack that might not work and would leave the processor unusable.
If you use a 10-character lower-case-only non-dictionary passcode, it doesn't matter what firmware is loaded, it's not brute-forcing anything for quite a while (average time around 179 thousand years).
How does Android security compare to that? How does it prevent arbitrary code from being loaded, who holds the signing keys, can it be executed without either entering a passcode or doing a full wipe, and how does it enforce retry delays or device wipes?
One open question I haven't seen addressed is how Apple prevents arbitrary (signed) firmware from being loaded into the Secure Enclave (on newer devices) that could do something similar, changing the protection rules after the fact without requiring either a passcode or a full wipe. Does the Secure Enclave boot loader have a way to (securely) store the firmware signature of a new version that can only be set with the current passcode, and not allow any other version to be able to access the keys? Perhaps a write-once (per reset) write-only register that the bootloader can store the current firmware signature in, and encrypt/decrypt instructions which allow arbitrary encryption but only allow decryption using the stored value (signature would be mixed with passcode and UID in a way that couldn't be done outside the hardware using the other instructions which utilize the UID).
Everyone's income wouldn't go up by 25%, where do you get that?
You wouldn't institute a UBI without changes to taxes. First, you'd probably eliminate the personal exemption and standard deduction, roll that into the UBI instead. Second, you'd be eliminating a lot of support payments, e.g. SNAP. Third, you'd raise the tax rate overall - people below a certain income level would have a net gain, above would show a net loss. I'd guess it might be calibrated to be break-even here around $100K (single).
Money is a proxy for control of allocation of resources. People with a lot of money got there in a variety of ways. They may have just been lucky (by birth or otherwise). They may even have worked very hard, but it's unlikely that Bill Gates worked 4.5 million times harder than someone working a couple part-time minimum wage jobs. The rewards you get are not proportionate to the effort you put in.
Does that mean that people shouldn't be able to make a lot of money? No. It just means they should give back more to the society that let them succeed than just a straight equal percentage of their income.
A UBI is equivalent to a negative income tax, since everyone gets that standard deduction. With a UBI you'd eliminate the standard deduction, just roll it into the UBI itself. I first came up with the idea (before I found out that it had been around for a long time) when thinking of ways to simplify the income tax system.
A flat tax is really simple, everything can simply be deducted, no forms to fill out, no worries about multiple jobs changing your tax bracket or deductions. A flat tax is regressive, so to fix it you put in a large standard deduction, but that ends up complicating withholding again.
So, instead, just have the government automatically refund you the tax on your deductible amount. If you allow that even for people who didn't make that much, you have a UBI.
With a flat tax, you get much higher compliance and much lower cost of enforcing compliance. My goal would be to eliminate all tax forms for anyone who isn't actually self employed or running a business. That includes things like having charitable organizations receive tax money directly from the government instead of the donor taking a deduction (which also means a contribution from a poor person is just as valuable as from a wealthy person, who can donate more since the government pays them back a significant portion).
Fortunately for all the tax preparation people, there'd be a UBI to hold them over until they could find work that's actually useful.
One could argue that the people with the majority of the income and wealth are there because they "forced people to give the fruits of their labor" to them. Most people living paycheck to paycheck work a lot harder than a lot of the fabulously wealthy ever did.
A Basic Income doesn't have to be "barracks-style living". My thinking on a UBI is something on the order of $2000/month. Sure, in some places that won't get you much, in others you'll be quite comfortable. Yet, how many people here yearn to live on $24K/year and wouldn't take a job (if available) to improve your condition?
As a study there will surely be some aspects that won't be properly handled. A true UBI, however, would replace all oher direct forms of government support. There would still be some government supported benefits, such as Universal Health Care, and you'd either take care of people with disabilities or other special needs through that or a specific program for such needs.
You'd also want government support for education, perhaps not totally free (you want people to feel like they have a stake and not waste resources), but something available to everyone who wants it, although online courses (requiring no individual attention) should be totally free. I'd class affordable housing, food, communication and a few other things as areas where the government should take steps to ensure access.
With a UBI, you can go to a straight flat tax. The UBI makes up for the regressive nature of a flat tax. You can also eliminate the minimum wage. As jobs become scarce, it shouldn't be expected that you have a job or be seen as a leech, you'll work at a job in order to be able to buy more stuff, not because you have to to survive. As such, having a true free market for labor no longer has to be countered with a minimum wage.
As automation increases productivity enormously, there's no reason the only beneficiaries should be the upper levels, everyone should benefit. A relatively high (flat) income tax, combined with a VAT-like sales tax, would stabilize the economy. One scheme would be to have the tax rates automatically set based on the budget (which includes the UBI). Set rates such that half the revenue comes from the VAT and half comes from the income tax (including corporations). A spending bill is automatically a tax bill.
There will still be plenty of people who will want more stuff and will be willing to work for it. There will also be plenty of people who use the freedom to do amazing things. Taking care of people who do need assistance would be much cheaper, and would remove the stigma of being "on the dole".
I think the Protestant work ethic (in fine form with some of the comments here) is one of the biggest threats to our economy and society as we advance to more automation and fewer available jobs.
Reading the paper further, while they do discuss overclocking, they are also allowing for occasional errors in an adder, specifically by assuming that long carry chains won't occur, thus avoiding the need for carry lookahead circuits to ripple the whole word length. That means occassionally an add will get the wrong result, but not very often, but the add circuit can be made faster. It's still deterministic, just that a few specific bit patterns aren't handled correctly.
From reading the linked page (which is woefully short on details), this isn't approximation, it's more akin to overclocking hardware so it goes faster even though it occassionally will make a mistake. If it can run twice as fast, but only create 10% false positives and negatives, it's worth it (as long as the overclocking doesn't use twice as much power).
Sending it on to the network without double-checking that it's valid would be stupid, though, considering it takes less than a microsecond to check a result, and even the false positives would be very rare.
The real problem isn't the false positives but the false negatives, as those are missed wins. The nature of the hash probably makes the false positive and negative rates the same, absent some specific failure mode of the hardware.
If you distribute full sources used to produce a GPL binary you're distributing, you have no further obligations.
If you don't, you must provide a written offer to produce such source, good for 3 years. The offer is open to anyone, not just the person you gave the offer to, you can charge a fee, but only to cover the actual cost of providing a copy.
Having the sources available for download at the time the binary is provided is accepted as having distributed it, if the person chooses not to download it you've still fulfilled your obligation under the GPL.
Slashdot Mirror
Most of what's on Thingiverse appears to be available under CC-Attribution, all that's needed would be to do that attribution and he'd be in the clear. Thingiverse even has an API to get the information automatically, to verify license status.
Instead, he seems to think that anything on the Internet is public domain and he can do whatever he wants. Good luck with that!
I don't know if the "no commercial use" CC licenses would bar this - sell it as a service to print designs for an individual rather than selling the item. Charge for materials and time to print.
One thing to note is that there appear to be many many copyright violations on Thingiverse itself, so just assuming that having a CC license on Thingiverse means you're in the clear would be a big mistake.
Why would the NSA put in a back door that could be used by anyone? Only allow a connection that has the right private key. Sure, the key might be stolen, but it's a lot more secure than a wide open vulnerability. The NSA is more competent than that.
Condorcet voting has some significant advantages, including being able to create a simple matrix of results from each precinct that can be sent up the line to be totalled with other precincts. You do have to resolve cycles, but they're very rare in practice.
I think both are about as easy to explain, and both (usually) choose the same winner.
If the Secure Enclave has non-volatile storage it can access directly, the boot ROM can do this.
Adding additional hardware support (e.g. a write-once write-only key register) could make it easier, but even without that you could require that the passcode be entered in order to mark a new SE firmware image as being usable without wiping all keys.
I'm not. I'm perfectly aware that the 5c can be easily compromised to make a brute force attack more feasible.
Tim Cook's letter seems to be saying that ALL phones could be compromised by Apple, even current ones with a Secure Enclave. If the SE already protects against an attack like this, then Tim Cook's letter is overstating the case. If it doesn't, then the promise of the Secure Enclave wasn't fulfilled.
What about "should Apple be required to sign (for a specific single phone) a specific firmware image provided by the FBI"?
If Apple prevails, there will still be other cases, they're just waiting on this one to see what specifically the courts find acceptable and not acceptable, and what they leave open.
If the FBI prevails, that doesn't mean all those other cases get automatically approved, either.
The only thing that needs to be written is a new request over USB to submit a passcode and report the result. The rest of ut is removing code, not writing it. I'm not sure that there's much difference, at that level, between writing code and clicking a button to change a setting or typing in a password or signing a firmware image.
You're right that the primary issue is how far does the All Writs Act go, what are the limits on what they can require, but this case doesn't really show a very high burden on Apple.
And then there's a whole case of cyberattackers wanting to look at the firmware and find ways to break it - through jailbreaking if need be. Imagine the havoc caused if this firmware was released as part of a jailbreak tool for iOS.
Jailbreaking is a lot more difficult and complex than what this firmware would be. Having the firmware wouldn't allow anyone (except for Apple) to sign it for any other device.
If you have a jailbroken device, you could already do this. However, AFAIK, there's no way to jailbreak current phones without having the passcode in the first place.
So, no, without Apple's signing keys, the firmware is useless. With Apple's signing keys, it's unnecessary.
People already can do this, if only they had Apple's signing keys.
If Apple's signing keys get out, it's game over. Without the keys, there's nothing to "get out", Apple just needs to protect their keys as they're already doing. Signing attack firmware for one device doesn't create any new capability except against that one device.
Nonsense. If China wants to demand that Apple hack a phone, they don't need a US court to say they can.
There's no automatic "now you can submit any request you want" that would be granted to any law enforcement organization if the FBI prevails in this case. Each one will have its own facts, just as the facts in this case are different from earlier All Writs Act orders. Apple can object to them just as they have here. If the facts in this case (dead terrorists, government owned device, more than adequate grounds for a valid warrant) justify allowing a brute force attack on the phone, that doesn't mean Apple would lose if they object to a completely different set of facts.
If Apple prevails in this case, how does that affect in any way whether other requests/demands will be made?
How would it deter other countries from requiring Apple to do the same thing for them? It's not like it's a big secret that Apple CAN do this.
You can't prevent an attack on older devices, the backdoor already exists (Apple's signing key), the only issue is if Apple can be forced to sign with it. Since signing attack firmware only allows it to run on a single device, and there are plenty of people who could hack the OS to do this (see any of the jailbreak hackers), the issue has nothing to do with opening a Crypto-Pandora's box but establishing exactly how far an All Writs Act order can go. Yes, Apple could do the modifications more easily, and if they write it then that actually gives them more assurance of what they're signing, but ultimately it comes down to the simple act of signing some firmware.
If Tim Cook is right and even current devices are vulnerable, then the Secure Enclave also has a backdoor in the signing keys. The only way to prevent attacks is to fix the hardware so they really are impossible, even for Apple, which is what I thought Apple already promised.
What's being asked for isn't a forensic tool, even less so than "a simple lab service, like dumping a phone". It doesn't dump or analyze anything, it simply reports whether a passcode is correct. You strip out most of the normal OS, disable the delay and wipe code (in fact, remove the code that allows ANY write to non-volatile memory), and add in to the iTunes communication routines a simple submit-passcode request. That's all. You'd then need a slightly modified version of their existing tools to load a test version onto a device and add a routine to do the passcode submission.
HOW they get the passcode isn't of any relevance to the validity of what the passcode unlocks, the only thing you need to show is that the device wasn't modified while doing the brute forcing, and that's no different from something that merely dumps all the data. Dumping all the data has more requirements, it also has to show that it dumped everything and did so accurately. It's much easier to prove that it accurately discovered the passcode: it works. If a data dumper isn't a "forensic tool", a passcode brute force enabler also is not.
That's no different from the current situation. The new firmware could still just brute force the passcode, the only difference is that you need modified firmware for the Secure Enclave as well.
In order to be able to prevent modified firmware from running in the SE, it would need some hardware support that allows the SE boot ROM to do something that the loaded firmware can't, such as a write-once (per reset) write-only register where the SE boot ROM code can store the current SE firmware signature in, and some non-volatile values inside the Secure Enclave itself (or the equivalent, if the SE can directly access the Effaceable Memory without going through the main processor, that would work, but everything I've seen indicates that the SE is almost totally isolated without direct access to anything except through the main processor).
Apple doesn't say. They've said before that even Apple, with their signing keys, can't attack the encryption in the Secure Enclave, but now Tim Cook is saying that modified firmware CAN change the rules after the fact, which implies that they do NOT have any such hardware protection in the SE to prevent running modified firmware in there to remove delays and auto-wipe.
Does that say whether that's enforced by the hardware and/or SE boot code, or is that just enforced by the firmware itself?
What stops the processor, running modified firmware, from just loading a different (signed) firmware blob into the SE on restart, one that doesn't have all the restrictions of the normal SE firmware? The firmware isn't flashed into the SE, as I understand it, it's loaded from the boot file system by the main processor during the boot sequence, and as long as it's properly signed it will be accepted.
I'd certainly think Apple would have thought of that and guarded against such an attack, but there hasn't been any confirmation that it's so.
Apple's security is pretty good, with newer phones they move all the crypto into a separate isolated processor, the Secure Enclave, which does enforce retry delays and wipes.
The request isn't to modify the firmware, but to use DFU mode to basically load the equivalent of a rescue disk using something similar to an initcpio ram disk. It is specifically not supposed to modify the device in any way.
Apple's hardware encrypts all files sent to disk with a different random 256-bit key for each file, and encrypts the file key with a class key (based on the protection it's supposed to have), and then encrypts THAT with a random 256-bit key that's unlocked by the passcode using a PBKDF2 with an unreadable 256-bit random hardware key (UID) that's burned in to the processor and enough iterations to take 80ms per attempt. The brute force attack must be done on the phone itself, the UID is unknown and unknowable unless you use a physical attack that might not work and would leave the processor unusable.
If you use a 10-character lower-case-only non-dictionary passcode, it doesn't matter what firmware is loaded, it's not brute-forcing anything for quite a while (average time around 179 thousand years).
How does Android security compare to that? How does it prevent arbitrary code from being loaded, who holds the signing keys, can it be executed without either entering a passcode or doing a full wipe, and how does it enforce retry delays or device wipes?
One open question I haven't seen addressed is how Apple prevents arbitrary (signed) firmware from being loaded into the Secure Enclave (on newer devices) that could do something similar, changing the protection rules after the fact without requiring either a passcode or a full wipe. Does the Secure Enclave boot loader have a way to (securely) store the firmware signature of a new version that can only be set with the current passcode, and not allow any other version to be able to access the keys? Perhaps a write-once (per reset) write-only register that the bootloader can store the current firmware signature in, and encrypt/decrypt instructions which allow arbitrary encryption but only allow decryption using the stored value (signature would be mixed with passcode and UID in a way that couldn't be done outside the hardware using the other instructions which utilize the UID).
Everyone's income wouldn't go up by 25%, where do you get that?
You wouldn't institute a UBI without changes to taxes. First, you'd probably eliminate the personal exemption and standard deduction, roll that into the UBI instead. Second, you'd be eliminating a lot of support payments, e.g. SNAP. Third, you'd raise the tax rate overall - people below a certain income level would have a net gain, above would show a net loss. I'd guess it might be calibrated to be break-even here around $100K (single).
Money is a proxy for control of allocation of resources. People with a lot of money got there in a variety of ways. They may have just been lucky (by birth or otherwise). They may even have worked very hard, but it's unlikely that Bill Gates worked 4.5 million times harder than someone working a couple part-time minimum wage jobs. The rewards you get are not proportionate to the effort you put in.
Does that mean that people shouldn't be able to make a lot of money? No. It just means they should give back more to the society that let them succeed than just a straight equal percentage of their income.
A UBI is equivalent to a negative income tax, since everyone gets that standard deduction. With a UBI you'd eliminate the standard deduction, just roll it into the UBI itself. I first came up with the idea (before I found out that it had been around for a long time) when thinking of ways to simplify the income tax system.
A flat tax is really simple, everything can simply be deducted, no forms to fill out, no worries about multiple jobs changing your tax bracket or deductions. A flat tax is regressive, so to fix it you put in a large standard deduction, but that ends up complicating withholding again.
So, instead, just have the government automatically refund you the tax on your deductible amount. If you allow that even for people who didn't make that much, you have a UBI.
With a flat tax, you get much higher compliance and much lower cost of enforcing compliance. My goal would be to eliminate all tax forms for anyone who isn't actually self employed or running a business. That includes things like having charitable organizations receive tax money directly from the government instead of the donor taking a deduction (which also means a contribution from a poor person is just as valuable as from a wealthy person, who can donate more since the government pays them back a significant portion).
Fortunately for all the tax preparation people, there'd be a UBI to hold them over until they could find work that's actually useful.
One could argue that the people with the majority of the income and wealth are there because they "forced people to give the fruits of their labor" to them. Most people living paycheck to paycheck work a lot harder than a lot of the fabulously wealthy ever did.
A Basic Income doesn't have to be "barracks-style living". My thinking on a UBI is something on the order of $2000/month. Sure, in some places that won't get you much, in others you'll be quite comfortable. Yet, how many people here yearn to live on $24K/year and wouldn't take a job (if available) to improve your condition?
As a study there will surely be some aspects that won't be properly handled. A true UBI, however, would replace all oher direct forms of government support. There would still be some government supported benefits, such as Universal Health Care, and you'd either take care of people with disabilities or other special needs through that or a specific program for such needs.
You'd also want government support for education, perhaps not totally free (you want people to feel like they have a stake and not waste resources), but something available to everyone who wants it, although online courses (requiring no individual attention) should be totally free. I'd class affordable housing, food, communication and a few other things as areas where the government should take steps to ensure access.
With a UBI, you can go to a straight flat tax. The UBI makes up for the regressive nature of a flat tax. You can also eliminate the minimum wage. As jobs become scarce, it shouldn't be expected that you have a job or be seen as a leech, you'll work at a job in order to be able to buy more stuff, not because you have to to survive. As such, having a true free market for labor no longer has to be countered with a minimum wage.
As automation increases productivity enormously, there's no reason the only beneficiaries should be the upper levels, everyone should benefit. A relatively high (flat) income tax, combined with a VAT-like sales tax, would stabilize the economy. One scheme would be to have the tax rates automatically set based on the budget (which includes the UBI). Set rates such that half the revenue comes from the VAT and half comes from the income tax (including corporations). A spending bill is automatically a tax bill.
There will still be plenty of people who will want more stuff and will be willing to work for it. There will also be plenty of people who use the freedom to do amazing things. Taking care of people who do need assistance would be much cheaper, and would remove the stigma of being "on the dole".
I think the Protestant work ethic (in fine form with some of the comments here) is one of the biggest threats to our economy and society as we advance to more automation and fewer available jobs.
Reading the paper further, while they do discuss overclocking, they are also allowing for occasional errors in an adder, specifically by assuming that long carry chains won't occur, thus avoiding the need for carry lookahead circuits to ripple the whole word length. That means occassionally an add will get the wrong result, but not very often, but the add circuit can be made faster. It's still deterministic, just that a few specific bit patterns aren't handled correctly.
From reading the linked page (which is woefully short on details), this isn't approximation, it's more akin to overclocking hardware so it goes faster even though it occassionally will make a mistake. If it can run twice as fast, but only create 10% false positives and negatives, it's worth it (as long as the overclocking doesn't use twice as much power).
Sending it on to the network without double-checking that it's valid would be stupid, though, considering it takes less than a microsecond to check a result, and even the false positives would be very rare.
The real problem isn't the false positives but the false negatives, as those are missed wins. The nature of the hash probably makes the false positive and negative rates the same, absent some specific failure mode of the hardware.
If you distribute full sources used to produce a GPL binary you're distributing, you have no further obligations.
If you don't, you must provide a written offer to produce such source, good for 3 years. The offer is open to anyone, not just the person you gave the offer to, you can charge a fee, but only to cover the actual cost of providing a copy.
Having the sources available for download at the time the binary is provided is accepted as having distributed it, if the person chooses not to download it you've still fulfilled your obligation under the GPL.