Why do you want to pay for two separate systems when one could do the job? Is there some reason you couldn't plug in 4 USB/Bluetooth controllers and an HDMI cable to your computer and get the couch/beer/peanuts/large TV experience without also buying a second, limited-function computer?
There are reasons a manufacturer or publisher might want a system that's standardized (and therefore easy to code against) or cheaper than a desktop (and therefore more widely available). But if you already own a general-purpose computer there is no reason you should prefer to buy a second, special-purpose computer just to play games in the living room.
So what you're saying is that the public in general is too greedy to allow corporations to act ethically? The shareholders of a company are free to demand whatever they want from it -- if they demand the company give away teddy bears to underprivileged children the company would have the same legal mandate to forward that shared interest.
His point is reasonable, though probably a bit subtle for many audiences. "Access to communication" might well be a human right, but we shouldn't add "the Internet" to a special list for the same reason that we can be glad our predecessors didn't add "telegraph service" to the list.
I don't understand why it would be any easier for Netflix to migrate than Dropbox. Is Dropbox's data heavier or something? Does Netflix have a cousin with a truck that will help them move?
Also, dropbox has all sorts of automatic, off-site backups -- the original clients. So long as you remember to put the server in "don't delete everything from the client" mode before going back online users will automatically re-upload all their missing content.
Dropbox is buying external storage because it's a commodity and the cheapest way to do what they're doing. If someone else present a cheaper option they'll move to that. If no one sells that service at a reasonable price they'll build infrastructure themselves. It's pretty common for the modern business to not produce 100% of the components used in the their products -- there are clear economic benefits specialization, particularly in commodities, and Dropbox is just taking advantage of those advantages.
First, put away the PAT -- your Cisco is showing, and the kind of packet mangling done by virtually all home routers does both address and port translation.
Second, while it is possible to buy a WiFi bridge that isn't a router/NAT/firewall box there are actually very few consumer-grade devices that do this -- I sometimes want one and often have to spend extra time searching for one, or even for a device that comes with NAT enabled but can be placed in a bridging mode. It also seems unlikely to me that access point manufacturers in the consumer market would quickly move to IPv6-only devices, and so long as the device is dual-stack the router/NAT/firewall functionality will almost certainly continue to be on by default.
So I'm just not seeing this is a big problem. Yes it's possible, but it's also possible now for anyone that hooks up a switch to a cable modem that will dispense multiple real addresses (more common that you might think -- my low-end consumer cable service did this for years), or who hooks up their cable modem directly to their computer, or who disabled the firewall protections provided by their router, etc. It's not clear to my why the risk would increase substantially just because there are a handful of other scenarios where users could be exposed.
And in any case if you're worried about such things the solution isn't NAT for IPv6 or IPv4, because ultimately that relies on the clueless, penny-pinching end-user you're trying to protect. The solution is an ISP-side firewall that's on by default but can be disabled by customer request. Then even directly-connected users and people who broken their local firewall or otherwise got routable addresses from any family configured on their desktop would still be protected and anyone who had a clue could still use the Internet.
Which might be a fine stage 2, but in stage 1 if you're testing to see if these people will freak out and murder each other you maybe don't want to put them hours from help an in a precarious capsule -- the whole point of the test is to see if such a journey is safe, and it's not much of a test if a failure results in the same deaths you'd get on-mission.
What sort of SSL are you using that's not end-to-end (i.e. application to application, as you say)? Because mine sure doesn't work that way.
It's also not clear why, given a composite document, each of the component providers couldn't provide separate signatures for their pieces without any particular support at the composite level -- it's pretty trivial to embed a signatures in a JPEG, for example, and then you'd continue to get the signature with the image even if it was copied outside of the composite document, which seems much more useful for trust-chain usage.
At what point in history did the number of people believing the earth was flat exceed the number of people believing the earth was some sort of round shape (not necessarily a spheroid, but something you could circumnavigate) or the much, much larger number of people who had no opinion on the matter whatsoever? I can't name any such time myself.
However, it does appear that at least 10% of the current population has an unshakable belief that their ancestors believed the world was flat, so I guess this study explains why that myth won't die.
No, they don't all require pairing, at least not in any way that would concern the user -- the "just works" method requires no user interaction and can be re-established every time the devices come within range of each other without a huge amount of overhead (compared to the transmission speed in typical BT 2.1+ devices).
There are other issues with BlueTooth, like the fact that you can scan for hosts OR send data OR listen for scanning hosts. But pairing to begin BT communication is not an issue any more than your laptop needing to do ARP lookups before beginning Ethernet-IP communication is a pairing issue.
And I'd suggest that you (or at least I) *want* to require at the very least pairing if not fully manual activation for most things like door locks -- I don't want every random hacker I pass on the street scanning all the keys in my pocket and stealing their secrets, I want the keys to only send their secrets to the locks they're paired with, and I want them to only send the secret when I push a button (unless I specifically set a low-security mode) so that replay/range-extension attacks aren't plausible.
It doesn't. But how does AES-128 provide encrypted, authenticated communications? And if we're relying on some higher layer to provide security, how can I tell if it's working? Or ensure that my device is compatible with other NFC hosts using other security layers?
First, BlueTooth 2.1 and up supports Secure Simple Pairing, which has several security modes from "no-config encryption only" to "hardware authentication dongles": 1. Just works. A fully automatic encryption-only system that sacrifices protection against MitM attacks for the convenience of not requiring any user input. Think self-signed SSL certificates -- it's easy to use and secure against eavesdropping but vulnerable to active attacks. 2. Numeric comparison. Adds authentication to the "Just Works" method by displaying a passkey on both devices and asking the user to ensure they match. The only input required from the user is their acknowledgement that the displayed codes match. 3. Passkey entry. Like legacy pairing, but the passkey is 6 digits and is generated by one of the hosts and typed into the other (as opposed to the old 4-digit passkeys that may be user-selected and entered on both hosts). 4. Out-of-band. Bluetooth allows the exchange of authentication data entirely outside the BT data stream, allowing integration with other authentication and communications mechanisms. This allows for integration with hardware dongles or SSL certificates or whatever other sort trust system you'd like to establish for authentication.
Second, even for legacy pairing, isn't it easy enough to just try "0000" and "1234" when attempting to connect to a new device, and only prompt for user input of neither of those codes work?
If you put tar archives on tape in 1976 they'd still read with modern GNU tar on a standard linux distro today, assuming you had a working tape drive. There is *no* random-access filesystem for which the same thing can be said. Certainly not all tape formats survived the test of time, but if you choose wisely tape a safer bet for longevity than any random-access file system, if for no other reason than the format is physically easier to read and the filesystem is easier re-implement.
That being said, for data you don't want to spent $20k per tape/disk/etc. to recover, the only real option is to keep rotating it forward every time storage technology changes. If you keep a copy on two different kinds of "modern" storage (including file formats) and rotate to a newer version every ~5 years you'll always have your data. Anything short of that will almost certainly lead to eventual data loss for any data not in active use.
So shouldn't the driver/front-seat-passenger be able to make the call about whether or not they're willing to ride with an unrestrained passenger in the back? I still don't see what interest the state has in this situation.
I'm just going to pretend you aren't asking us to believe that there's any reasonable risk of an unrestrained driver/passenger being in an accident and their body, after penetrating the windshield, causing significant harm to someone outside the vehicle -- it's so unlikely you'd be better off banning coconut trees in terms of lives saved/year.
Microsoft originally wrote Office (or as it was sold at the time, separate programs for Word/Excel/etc.) for the Mac. It came out int 1984. The Windows version didn't come out until like 1989.
So if you first called a woman at home and told her you were going to grope her, then waited for her to head out to the bus stop and molested her there (using the back of your hands), that would be okay? It's just a matter of advanced notice and using the back your hand?
On the other hand, if we built software to be as reliable as planes we'd still be running System5. "Other designers" don't put out entirely new products over a period of a few months -- they make incremental tweaks to a product that's been in production for years. And when they do build something actually new it can take years to get the first model out the door.
It's not so much that people accept errors in software, it's that they'd rather have cheap, quickly-produced software than waiting 5 years and paying 10 time as much to get a perfect version. If it were as easy to re-bore your engine block as it is to apply a software update you'd probably see the same thing cars.
And there are plenty of customers that demand good software for certain applications, and they often get it. But they pay and wait for it too.
This has been tried before. Boeing put a lot of money into a program just like what you're suggesting.
But as it turns out, even in independent implementations, non-trivial bugs tend to pop up in the same places, so both are broken in the same way. That's because non-trivial bugs come from things like unclear specifications, missed edge cases, and other issues related to the programer's understanding of the problem and the types of solutions that people with a given system of programming tools are likely to find for those problems. The only thing independent implementations can reliably fix are coding errors, and they're probably an expensive way to get an extra set of eyes on the problem, particularly given the complications in reconciling the differences found between the two incompatible systems.
Is there some reason to believe that new machines will not ship with restore disks of some sort?
Existing machines already have a bootable OS -- you might have to install 10.6 before you re-upgrade to 10.7, but that's going to be true of any aftermarket upgrade on any platform.
So unless someone wants to link to a credible story that reads "Apple stops shipping bootable media with new computers" the only real the only problem here is people who want to create a 10.7 installer disk for existing machines. That is a legitimate concern in terms of doing re-installation directly and quickly, and it's certainly something I'd want, but it has nothing whatever to do with being able to get a dead machine to boot again, or with typical home user usage.
There are both x-ray backscatter and active millimeter-wave scanners in use for full-body security imaging. Even before the full-body scanners there were penetrating x-ray scanners in use for luggage, and the mere presence of those machines is worth some amount of dosage monitoring, radiation training, and periodic inspections. I'd demand the same from any machine that could kill (as does OSHA), even if it didn't use invisible death rays to do so -- if I worked inches from a big piece of industrial machinery I'd want to know the safety procedures, maintenance requirements and signs of eminent failure before I started working.
The millimeter-wave machines are probably safe, but it's a new technology and there is some evidence that there's a probabilistic risk of biological damage even without direct ionizing effects, so it's at least worth some study. It's probably not a big enough risk to avoid using it, particularly compared to the known ill effects of x-ray exposure, but given the cost of the machines we could probably divert some cash for a real safety study rather than just hoping.
The x-ray backscatter machines are actually sending out x-rays just like traditional x-ray imagining, but they are reading the reflected/scattered energy rather than the penetrating energy. But that doesn't change your x-ray absorption cross-section, and they rays that don't scatter off your skins are still absorbed someplace in your body or transmitted to the far side, just like in penetrative x-ray imaging.
So the cumulative risk from x-ray backscatter machines is real and verifiable with well-established science. Assuming the doses are as low as the TSA claims the risk is small, but it still exists. However, since there are virtually no controls or validation on either the intensity or the duration of dosage, other than the physical limitations of the machine and its use (i.e. the maximum power output of the x-ray tube, the amount of time you can convince someone to stand in the way of the beam, etc.), it's hard to say that we should trust the TSA on this.
It shouldn't be hard to run these machines safely, but the TSA has expressed in no interest in doing that. It would be trivial to provide cumulative dosage monitoring for the operators (which would indirectly protect travelers as well), and fairly easy/cheap to provide periodic validation of the proper operation of the system. We expect the corner gas station to keep their pumps verifiably calibrated, to monitor their storage tanks for signs of malfunction, to have mitigation procedures in place should there be some sort of failure, and to be strictly liable for most types of failures in their systems -- why isn't the TSA held to the same standard?
/ Also, risk vs. benefit is probably a worthwhile analysis, but even if there is a clear benefit there's no reason the TSA shouldn't have better safety procedures
I'd rather trust my mail server to keep track of my mail than hope the my phone/desktop/etc. all have valid, non-conflciting, easy-to-backup copies. And I need my mail to be sorted, or I would never be able to check "important" messages on a mobile client. But that's mostly personal preference.
The problem with the RIM "mail client" -- IMAP or POP -- is that it A) requires you to send your password to RIM B) only supports unread messages in a single folder, even with polling C) does not reliable sync read/unread/deleted/etc. between the phone and the server D) has very limited support for multiple accounts.
How did you do email? I like the security features on BB -- real encryption & wipe -- but the lack of a mail client makes it all but useless without third-party apps. And RIM's refusal to allow mail clients to integrate into the built-in messaging system make it even worse -- even once you get a mail app working the base OS still can't do email.
They could just let you change the secret. Then if you lost the DB you could make the tokens work again without recovering the data, just like using hashed passwords lets you reset lost passwords.
Is there some part of this I'm missing, that says all power supplies must work up to the maximum? The whole point of the negotiation is that the power supply can tell the power consumer if it can or cannot meet the demand. Hence you could produce a 50W power supply that's in-spec with this new standard, it would just tell higher-power devices that it's not big enough and refuse to power them.
Your blender has even higher voltages and was made by low-cost leaders turning out pure crap. So was every other blender clock for the last 50 years or so. I don't understand why these would be any different.
Also, the power supplies would continue to be made by the same people already making them, they would just be marketed under another brand. It's not like power supplies are currently made by a big-name company in Colorado -- they are already a near-commodity item made overseas by whoever puts in the lowest bid.
Slashdot Mirror
Why do you want to pay for two separate systems when one could do the job? Is there some reason you couldn't plug in 4 USB/Bluetooth controllers and an HDMI cable to your computer and get the couch/beer/peanuts/large TV experience without also buying a second, limited-function computer?
There are reasons a manufacturer or publisher might want a system that's standardized (and therefore easy to code against) or cheaper than a desktop (and therefore more widely available). But if you already own a general-purpose computer there is no reason you should prefer to buy a second, special-purpose computer just to play games in the living room.
So what you're saying is that the public in general is too greedy to allow corporations to act ethically? The shareholders of a company are free to demand whatever they want from it -- if they demand the company give away teddy bears to underprivileged children the company would have the same legal mandate to forward that shared interest.
His point is reasonable, though probably a bit subtle for many audiences. "Access to communication" might well be a human right, but we shouldn't add "the Internet" to a special list for the same reason that we can be glad our predecessors didn't add "telegraph service" to the list.
I don't understand why it would be any easier for Netflix to migrate than Dropbox. Is Dropbox's data heavier or something? Does Netflix have a cousin with a truck that will help them move?
Also, dropbox has all sorts of automatic, off-site backups -- the original clients. So long as you remember to put the server in "don't delete everything from the client" mode before going back online users will automatically re-upload all their missing content.
Dropbox is buying external storage because it's a commodity and the cheapest way to do what they're doing. If someone else present a cheaper option they'll move to that. If no one sells that service at a reasonable price they'll build infrastructure themselves. It's pretty common for the modern business to not produce 100% of the components used in the their products -- there are clear economic benefits specialization, particularly in commodities, and Dropbox is just taking advantage of those advantages.
First, put away the PAT -- your Cisco is showing, and the kind of packet mangling done by virtually all home routers does both address and port translation.
Second, while it is possible to buy a WiFi bridge that isn't a router/NAT/firewall box there are actually very few consumer-grade devices that do this -- I sometimes want one and often have to spend extra time searching for one, or even for a device that comes with NAT enabled but can be placed in a bridging mode. It also seems unlikely to me that access point manufacturers in the consumer market would quickly move to IPv6-only devices, and so long as the device is dual-stack the router/NAT/firewall functionality will almost certainly continue to be on by default.
So I'm just not seeing this is a big problem. Yes it's possible, but it's also possible now for anyone that hooks up a switch to a cable modem that will dispense multiple real addresses (more common that you might think -- my low-end consumer cable service did this for years), or who hooks up their cable modem directly to their computer, or who disabled the firewall protections provided by their router, etc. It's not clear to my why the risk would increase substantially just because there are a handful of other scenarios where users could be exposed.
And in any case if you're worried about such things the solution isn't NAT for IPv6 or IPv4, because ultimately that relies on the clueless, penny-pinching end-user you're trying to protect. The solution is an ISP-side firewall that's on by default but can be disabled by customer request. Then even directly-connected users and people who broken their local firewall or otherwise got routable addresses from any family configured on their desktop would still be protected and anyone who had a clue could still use the Internet.
Which might be a fine stage 2, but in stage 1 if you're testing to see if these people will freak out and murder each other you maybe don't want to put them hours from help an in a precarious capsule -- the whole point of the test is to see if such a journey is safe, and it's not much of a test if a failure results in the same deaths you'd get on-mission.
What sort of SSL are you using that's not end-to-end (i.e. application to application, as you say)? Because mine sure doesn't work that way.
It's also not clear why, given a composite document, each of the component providers couldn't provide separate signatures for their pieces without any particular support at the composite level -- it's pretty trivial to embed a signatures in a JPEG, for example, and then you'd continue to get the signature with the image even if it was copied outside of the composite document, which seems much more useful for trust-chain usage.
At what point in history did the number of people believing the earth was flat exceed the number of people believing the earth was some sort of round shape (not necessarily a spheroid, but something you could circumnavigate) or the much, much larger number of people who had no opinion on the matter whatsoever? I can't name any such time myself.
However, it does appear that at least 10% of the current population has an unshakable belief that their ancestors believed the world was flat, so I guess this study explains why that myth won't die.
No, they don't all require pairing, at least not in any way that would concern the user -- the "just works" method requires no user interaction and can be re-established every time the devices come within range of each other without a huge amount of overhead (compared to the transmission speed in typical BT 2.1+ devices).
There are other issues with BlueTooth, like the fact that you can scan for hosts OR send data OR listen for scanning hosts. But pairing to begin BT communication is not an issue any more than your laptop needing to do ARP lookups before beginning Ethernet-IP communication is a pairing issue.
And I'd suggest that you (or at least I) *want* to require at the very least pairing if not fully manual activation for most things like door locks -- I don't want every random hacker I pass on the street scanning all the keys in my pocket and stealing their secrets, I want the keys to only send their secrets to the locks they're paired with, and I want them to only send the secret when I push a button (unless I specifically set a low-security mode) so that replay/range-extension attacks aren't plausible.
It doesn't. But how does AES-128 provide encrypted, authenticated communications? And if we're relying on some higher layer to provide security, how can I tell if it's working? Or ensure that my device is compatible with other NFC hosts using other security layers?
First, BlueTooth 2.1 and up supports Secure Simple Pairing, which has several security modes from "no-config encryption only" to "hardware authentication dongles":
1. Just works. A fully automatic encryption-only system that sacrifices protection against MitM attacks for the convenience of not requiring any user input. Think self-signed SSL certificates -- it's easy to use and secure against eavesdropping but vulnerable to active attacks.
2. Numeric comparison. Adds authentication to the "Just Works" method by displaying a passkey on both devices and asking the user to ensure they match. The only input required from the user is their acknowledgement that the displayed codes match.
3. Passkey entry. Like legacy pairing, but the passkey is 6 digits and is generated by one of the hosts and typed into the other (as opposed to the old 4-digit passkeys that may be user-selected and entered on both hosts).
4. Out-of-band. Bluetooth allows the exchange of authentication data entirely outside the BT data stream, allowing integration with other authentication and communications mechanisms. This allows for integration with hardware dongles or SSL certificates or whatever other sort trust system you'd like to establish for authentication.
Second, even for legacy pairing, isn't it easy enough to just try "0000" and "1234" when attempting to connect to a new device, and only prompt for user input of neither of those codes work?
If you put tar archives on tape in 1976 they'd still read with modern GNU tar on a standard linux distro today, assuming you had a working tape drive. There is *no* random-access filesystem for which the same thing can be said. Certainly not all tape formats survived the test of time, but if you choose wisely tape a safer bet for longevity than any random-access file system, if for no other reason than the format is physically easier to read and the filesystem is easier re-implement.
That being said, for data you don't want to spent $20k per tape/disk/etc. to recover, the only real option is to keep rotating it forward every time storage technology changes. If you keep a copy on two different kinds of "modern" storage (including file formats) and rotate to a newer version every ~5 years you'll always have your data. Anything short of that will almost certainly lead to eventual data loss for any data not in active use.
So shouldn't the driver/front-seat-passenger be able to make the call about whether or not they're willing to ride with an unrestrained passenger in the back? I still don't see what interest the state has in this situation.
I'm just going to pretend you aren't asking us to believe that there's any reasonable risk of an unrestrained driver/passenger being in an accident and their body, after penetrating the windshield, causing significant harm to someone outside the vehicle -- it's so unlikely you'd be better off banning coconut trees in terms of lives saved/year.
Microsoft originally wrote Office (or as it was sold at the time, separate programs for Word/Excel/etc.) for the Mac. It came out int 1984. The Windows version didn't come out until like 1989.
So if you first called a woman at home and told her you were going to grope her, then waited for her to head out to the bus stop and molested her there (using the back of your hands), that would be okay? It's just a matter of advanced notice and using the back your hand?
You cannot compel them to return the photos. But you can probably require that they do not publish the photos.
On the other hand, if we built software to be as reliable as planes we'd still be running System5. "Other designers" don't put out entirely new products over a period of a few months -- they make incremental tweaks to a product that's been in production for years. And when they do build something actually new it can take years to get the first model out the door.
It's not so much that people accept errors in software, it's that they'd rather have cheap, quickly-produced software than waiting 5 years and paying 10 time as much to get a perfect version. If it were as easy to re-bore your engine block as it is to apply a software update you'd probably see the same thing cars.
And there are plenty of customers that demand good software for certain applications, and they often get it. But they pay and wait for it too.
This has been tried before. Boeing put a lot of money into a program just like what you're suggesting.
But as it turns out, even in independent implementations, non-trivial bugs tend to pop up in the same places, so both are broken in the same way. That's because non-trivial bugs come from things like unclear specifications, missed edge cases, and other issues related to the programer's understanding of the problem and the types of solutions that people with a given system of programming tools are likely to find for those problems. The only thing independent implementations can reliably fix are coding errors, and they're probably an expensive way to get an extra set of eyes on the problem, particularly given the complications in reconciling the differences found between the two incompatible systems.
Is there some reason to believe that new machines will not ship with restore disks of some sort?
Existing machines already have a bootable OS -- you might have to install 10.6 before you re-upgrade to 10.7, but that's going to be true of any aftermarket upgrade on any platform.
So unless someone wants to link to a credible story that reads "Apple stops shipping bootable media with new computers" the only real the only problem here is people who want to create a 10.7 installer disk for existing machines. That is a legitimate concern in terms of doing re-installation directly and quickly, and it's certainly something I'd want, but it has nothing whatever to do with being able to get a dead machine to boot again, or with typical home user usage.
There are both x-ray backscatter and active millimeter-wave scanners in use for full-body security imaging. Even before the full-body scanners there were penetrating x-ray scanners in use for luggage, and the mere presence of those machines is worth some amount of dosage monitoring, radiation training, and periodic inspections. I'd demand the same from any machine that could kill (as does OSHA), even if it didn't use invisible death rays to do so -- if I worked inches from a big piece of industrial machinery I'd want to know the safety procedures, maintenance requirements and signs of eminent failure before I started working.
The millimeter-wave machines are probably safe, but it's a new technology and there is some evidence that there's a probabilistic risk of biological damage even without direct ionizing effects, so it's at least worth some study. It's probably not a big enough risk to avoid using it, particularly compared to the known ill effects of x-ray exposure, but given the cost of the machines we could probably divert some cash for a real safety study rather than just hoping.
The x-ray backscatter machines are actually sending out x-rays just like traditional x-ray imagining, but they are reading the reflected/scattered energy rather than the penetrating energy. But that doesn't change your x-ray absorption cross-section, and they rays that don't scatter off your skins are still absorbed someplace in your body or transmitted to the far side, just like in penetrative x-ray imaging.
So the cumulative risk from x-ray backscatter machines is real and verifiable with well-established science. Assuming the doses are as low as the TSA claims the risk is small, but it still exists. However, since there are virtually no controls or validation on either the intensity or the duration of dosage, other than the physical limitations of the machine and its use (i.e. the maximum power output of the x-ray tube, the amount of time you can convince someone to stand in the way of the beam, etc.), it's hard to say that we should trust the TSA on this.
It shouldn't be hard to run these machines safely, but the TSA has expressed in no interest in doing that. It would be trivial to provide cumulative dosage monitoring for the operators (which would indirectly protect travelers as well), and fairly easy/cheap to provide periodic validation of the proper operation of the system. We expect the corner gas station to keep their pumps verifiably calibrated, to monitor their storage tanks for signs of malfunction, to have mitigation procedures in place should there be some sort of failure, and to be strictly liable for most types of failures in their systems -- why isn't the TSA held to the same standard?
/ Also, risk vs. benefit is probably a worthwhile analysis, but even if there is a clear benefit there's no reason the TSA shouldn't have better safety procedures
I'd rather trust my mail server to keep track of my mail than hope the my phone/desktop/etc. all have valid, non-conflciting, easy-to-backup copies. And I need my mail to be sorted, or I would never be able to check "important" messages on a mobile client. But that's mostly personal preference.
The problem with the RIM "mail client" -- IMAP or POP -- is that it A) requires you to send your password to RIM B) only supports unread messages in a single folder, even with polling C) does not reliable sync read/unread/deleted/etc. between the phone and the server D) has very limited support for multiple accounts.
How did you do email? I like the security features on BB -- real encryption & wipe -- but the lack of a mail client makes it all but useless without third-party apps. And RIM's refusal to allow mail clients to integrate into the built-in messaging system make it even worse -- even once you get a mail app working the base OS still can't do email.
They could just let you change the secret. Then if you lost the DB you could make the tokens work again without recovering the data, just like using hashed passwords lets you reset lost passwords.
Is there some part of this I'm missing, that says all power supplies must work up to the maximum? The whole point of the negotiation is that the power supply can tell the power consumer if it can or cannot meet the demand. Hence you could produce a 50W power supply that's in-spec with this new standard, it would just tell higher-power devices that it's not big enough and refuse to power them.
Your blender has even higher voltages and was made by low-cost leaders turning out pure crap. So was every other blender clock for the last 50 years or so. I don't understand why these would be any different.
Also, the power supplies would continue to be made by the same people already making them, they would just be marketed under another brand. It's not like power supplies are currently made by a big-name company in Colorado -- they are already a near-commodity item made overseas by whoever puts in the lowest bid.