I am shocked that he did not include amnesty for Snowden. I think it is a distinct possibility for his last day in office. For Obama to have to rewrite public policy because of Snowden's action - and essentially admit the government was wrong (by virtue of the fact that he is correcting actions) - Snowden should be given Amnesty and the Presidential Medal of Freedom. He risked a LOT more than Oprah did - and did a LOT more to assure the freedom of all Americans.
I agree that the credit card info should NOT be there - but by virtue of the fact that he didn't say it was - I'd assume it is not. I'd also assume Starbucks would just keep CC info on their own web site, not on the phone.
So - knowing that the app needs to somehow either cache this info in a way it can get it back to login, or have you re-enter the password every time, I'll ask again:
If the app needed to "store the encrypted password" - what options would it have? It could encrypt and store it - but then it would need some sort of encryption key to do so - and the app would need that key (which would then have to be stored in the app.
So, what's the solution? We're NOT talking about a password file that can be stored in a hashed manner - that's receiving and verifying passwords, not sending them. Web browsers don't store cookies/tokens in an encrypted manner - if you got them you could use them elsewhere (assuming they weren't tied to IP address or whatever).
So - (and I'm asking literally, not rhetorically) what should they have done?
Yes and no. There are many well-educated, foreign countries in which US companies (several I have worked for) try to hire-in, in an attempt to lower labor costs. India is one, there's also Russia, Singapore, etc. It's all about supply and demand. US companies flock to these countries and start hiring. This increases demand and decreases supply. After a while, the salary offset isn't as large, and there becomes less incentive to do so. This is starting to happen in many countries, and it's a good thing for workers everywhere. (Foreign employees get paid more, less desire to ship US jobs overeases = Good for US workers).
Though I see this as being useful, it I am sure is also expensive, but the worst think about it is the inconvenience factor.
I couldn't imagine having to deal with syncing my iPhone to my toothbrush all the time to pull reports. As this type of "smart" technology becomes more and more ubiquitous - we'd start to do this with everyhing. Our bathroom scale. Our electrical meter. Our themostat, our car, whatever. Having everything talk Wifi ("The Internet of Things") is one thing - and even has its own issues - but this clearly is getting out of hand.
When I can get the damn bluetooth speakerphone in my car (or any car) to work reliably - I'll think about it...
Put a (USB) keyboard and mouse connector on it - and maybe a stand to hold the screen upright. Maybe instead of "tablet" or "laptop" the could call it a "desktop"...
It's too cold? Override. Too hot? Override. In the end, the programmable thermostat reverts to a plain old one because no one can be bothered to reprogram the damn thing..
Damn straight! That's why I did this with my Honeywell!;-)
The next is rediculously expensive. I use a Honneywell Wifi which is better.
From what I know about the Nest from a lot of my friends that have it - the "smart" and "adaptive" stuff doesn't really work too well at all. The Honewell give you a basic schedule - and lets you access it remotely - which is what and all I really need. I don't need all the fancy display, UI, bells/whistles of the Nest. I hope/assume Google will go the "chromecast" route - in delivering an inexpensive, Wifi connected product that just works.
>> The bill will require patent holders who are filing a suit to identify the specific products and claims which are being infringed
It's a good start - in the "trolls" who hold patents but don't have any actual products wouldn't be able to meet this bar. However, it still would not prevent a troll from selling said patents to someone who HAS such an infringing product - to whom violation of such a patent would be valuable, and valid for suit.
I want to just make this incredibly clear to people: Type-1 and Type-2 diabetes are two completely different diseases. They have different causes and different treatments. IMHO, they shouldn't even share the same name.
I pushed the "stupid" button as soon as I read that. You can't just compare something to "drugs" - because different drugs work differently - and have differing levels of addictive qualities for very different reasons. For example, diploids (like Heroin) jack with your dopamine levels and are highly addictive, whereas stimulants (like cocaine) or depressants (like alcohol) can have very different affects in different people due to things like genetic factors, and mechanisms for ADD (which affect how stimulants affect you) - but in general are less addictive. Then there are things like tobacco that aren't "drugs" - but are also highly addictive.
So in other words...WTF??
(P.S. I'm not really educated in any of this kind of stuff and don't really know what I'm talking about - so don't bother correcting me)
Worst idea ever. There are "computers" and there are "mobile devices". The do different things and serve different purposes. History keeps repeating this. Tablets are not laptops. Tablets are great for watching porn, but people don't use them for serious, high-end productivity. (I am at work, typing this on a workstation, not an iPad).
Just because the two may have the same CPU ( which let's say for the sake of argument - they will) - it'doesn't mean people want an "iOS experience" on a MacBook pro. Chances are if they did - they would have bought an iPad. If they want a keyboard and a mouse (which they probably do - or they'd by an iPad) - they are probably doing things that are less condicive to the iOS-type "touch" interface. They want mouse control (which is more accurate than "touch", and doesn't require lifing one's hands up or far from the keyboard for extended or repetitive sets of time) - a keyboard - and possibly a multi-windowed environment - which they can do for a lot of stuff. They might be doing a lot of word processing, layout - or running XCode. They need to install their OWN SOFTWARE (without the restrictions and complications of Apple's certificates, licensince, AppStore, etc).
So I could see them packaging it as an "iPad with a keyboard" - but it would be a different product - and not a "replacement" for the Air or any other laptop.
But people still DO use it. It may not have been a "good" solution, but it was *a* solution. Today however, (just like with Flex), it is *not* a solution, because it would yield a web site which doesn't work with a lot of popular devices. That wasn't the case before iOS.
I think much of Java's *lack* of decline is attributable solely to it's "native support" (use) in the Android platform - just as the sudden rise of Objective-C (See Tiobe index) is obviously attributable to the iPhone and iPad devices.
Outside of Android - I believe use and acceptance is waning heavily. As a client-side web tool (where it got most of it's early predominance) it has been cockblocked by iOS, and is becoming overshadowed by native HTML5 (JavaScript) stuff. As a server-side tool it has been getting taken over by Ruby/Rails, Python and the stuff mentioned in the OP.
I can (half) see using "biometric" data in something like a grocery store. You swipe your card, and have to press your finger against the scanner in the store. No fingerprint match - no groceries.
But to insist on using "biometric" data for "online" purchases - how are they expecting to receive the biometric data? Through a scanner on the *users* computer? Even if it was done by some sort of credit-card hardware - you are now relying on not *biometric* data - but just *data* - as the users' computer has to send the data - and therefore who's to say if it's really "biometric" or not. (i.e. Some sort of reply attack - or something like it). My point is - there is no way to assure that it's really the user's fingerprint - just data matching the user's fingerprint. So how is this different than a conventional password?
At least a the grocery store - if you stick a "fake" finger on the scanner - you're going to at least create some suspicion - at minimum.
The current electronic electronic insulin pump and Continuous Glucose Monitor do everything described here (and even appear physically identical to the ones in this article) - EXCEPT for the fact that they will not AUTOMATICALLY suspend insulin delivery if your blood glucose level is too low. It will detect it - and give you an alarm - it just won't AUTOMATICALLY stop it.
The only "new" thing here is that the pump can AUTOMATICALLY stop delivery. This is a very small software tweak. The only thing that's different about this than getting a new firmware update for your iPhone - is that it requires BOAT LOADS of FDA certification to simply add the trivial (and obvious) feature - because hey, it is automatically messing with medication delivery.
There are two other less obvious things about it that really makes it a non-story:
1. Blood Glucose (BG) levels can rise or fall fast for one of many reasons. (Most "short-acting") insulins that are delivered from such a device take about 2 hours to reach their peak. So if the device realizes you are low and cuts off delivery - there is a good chance you could have "active" insulin already in your body which has yet to take affect. So the fact that delviery has been cut-off doesn't buy you too much - you still need to probably get some fast-acting carbs or glucogon to deal with the low blood sugar condition - or the fact that the "active" insulin could make you go even *lower* over the next 2 hours.
2. Most people who own the "Continuous Glucose Monitor" (CGM) piece very rarely use it. It is expensive, and yet another device to wear. They use them occasionally to get an idea of long-term trends, and for help in adjusting overall insulin levels that they program into the pump. It is also very inaccurate. (Blood tests taken from fingertips are the most accurate, though not even completely accurate themselves). Blood tests taken from a CGM worn on the abdomen or back, etc. are even less-so. So it suffers an inaccuracy which is like a time-lag" - i.e. your blood glucose level might rapidly falling and low - but a measurement from that site might not indicate that - just yet.
The "Artificial Pancreas" projects that people are referring to are ones in which the pump can deliver both insulin *and* glycogen - and have the intelligence to AUTOMATICALLY deliver them both as need. This is difficult, because now you have to "tell" the pump what your eating, and things like fat, protein and carbs will raise the BG. So for a device to do this without "knowing" what your eating, and to be able to do it with CGM data which isn't very accurate and not very timley, and to adjust it by delivering insulin which has a relatively slow absorption curve (over the course of hours) - makes for a difficult and messy problem.
Apple invented HTTP Live Streaming (HLS) which breaks up assets (media) into individual "fragments" which can be downloaded via individual TCP requests - in a way in which they are easily and transparently spliced back together on the player. Thus, when an individual fragment download failed it is retried. i.e. If it failed because Wifi had gone away - the retry would (automagically) go over 3G via even the current network stack.
Furthermore HLS has provisions to tell when bandwidth is too restricted - and to allow pulling in subsequent fragments at a lower bitrate until more bandwidth becomes better (i.e. gong from crappy 3G connection to a good Wifi connection).
Thus - HLS would be a much more ideal way of handling something like iTunes radio. "Internet Radio" is even described as an ideal use case in Apple's own docs.
Pandora I can totally see. It's the antithesis of Siri. Very long, persistent, lots of data - a continuous stream. (Though other technologies, such as fragmentation at the application/asset level are often used here too - especially for video).
As for Siri - you have quite the edge case. It is an *extremely* small window between the transmission and then reception of the Siri transaction that you lose your Wifi.
It seems to me that Siri is a bad use case for Multipath TCP. Siri transactions seem to be fast and short-lived. i.e. You wouldn't need a persistent connection that could service transitions between Wifi and 3G. So why use MultipathTCP on it?
Slashdot Mirror
"Marc Andreessen’s venture capital firm, Andreessen Horowitz, has invested just under $50 million in Bitcoin-related start-ups."
i.e. Even if he doesn't believe a damn word he's saying - he's heavily invested enough to need to make it work.
I am shocked that he did not include amnesty for Snowden. I think it is a distinct possibility for his last day in office. For Obama to have to rewrite public policy because of Snowden's action - and essentially admit the government was wrong (by virtue of the fact that he is correcting actions) - Snowden should be given Amnesty and the Presidential Medal of Freedom. He risked a LOT more than Oprah did - and did a LOT more to assure the freedom of all Americans.
I only checked the posts here to read the impending "In Soviet Russia..." jokes.
So - knowing that the app needs to somehow either cache this info in a way it can get it back to login, or have you re-enter the password every time, I'll ask again:
What SHOULD they have done differently.
So, what's the solution? We're NOT talking about a password file that can be stored in a hashed manner - that's receiving and verifying passwords, not sending them. Web browsers don't store cookies/tokens in an encrypted manner - if you got them you could use them elsewhere (assuming they weren't tied to IP address or whatever).
So - (and I'm asking literally, not rhetorically) what should they have done?
Yes and no. There are many well-educated, foreign countries in which US companies (several I have worked for) try to hire-in, in an attempt to lower labor costs. India is one, there's also Russia, Singapore, etc. It's all about supply and demand. US companies flock to these countries and start hiring. This increases demand and decreases supply. After a while, the salary offset isn't as large, and there becomes less incentive to do so. This is starting to happen in many countries, and it's a good thing for workers everywhere. (Foreign employees get paid more, less desire to ship US jobs overeases = Good for US workers).
Real cowboys ride bareback!
I couldn't imagine having to deal with syncing my iPhone to my toothbrush all the time to pull reports. As this type of "smart" technology becomes more and more ubiquitous - we'd start to do this with everyhing. Our bathroom scale. Our electrical meter. Our themostat, our car, whatever. Having everything talk Wifi ("The Internet of Things") is one thing - and even has its own issues - but this clearly is getting out of hand.
When I can get the damn bluetooth speakerphone in my car (or any car) to work reliably - I'll think about it...
Put a (USB) keyboard and mouse connector on it - and maybe a stand to hold the screen upright. Maybe instead of "tablet" or "laptop" the could call it a "desktop"...
Are these outdated specs worth your privacy and freedom?
No - but the Market will ultimately decide that.
It's too cold? Override. Too hot? Override. In the end, the programmable thermostat reverts to a plain old one because no one can be bothered to reprogram the damn thing..
Damn straight! That's why I did this with my Honeywell! ;-)
http://www.bradgoodman.com/thermostat/
The next is rediculously expensive. I use a Honneywell Wifi which is better. From what I know about the Nest from a lot of my friends that have it - the "smart" and "adaptive" stuff doesn't really work too well at all. The Honewell give you a basic schedule - and lets you access it remotely - which is what and all I really need. I don't need all the fancy display, UI, bells/whistles of the Nest. I hope/assume Google will go the "chromecast" route - in delivering an inexpensive, Wifi connected product that just works.
It's a good start - in the "trolls" who hold patents but don't have any actual products wouldn't be able to meet this bar. However, it still would not prevent a troll from selling said patents to someone who HAS such an infringing product - to whom violation of such a patent would be valuable, and valid for suit.
I want to just make this incredibly clear to people: Type-1 and Type-2 diabetes are two completely different diseases. They have different causes and different treatments. IMHO, they shouldn't even share the same name.
So, how do I snap the QR code - if I am logging into the website - on my phone...?
So in other words...WTF??
(P.S. I'm not really educated in any of this kind of stuff and don't really know what I'm talking about - so don't bother correcting me)
I read on the Internet that they are....
Just because the two may have the same CPU ( which let's say for the sake of argument - they will) - it'doesn't mean people want an "iOS experience" on a MacBook pro. Chances are if they did - they would have bought an iPad. If they want a keyboard and a mouse (which they probably do - or they'd by an iPad) - they are probably doing things that are less condicive to the iOS-type "touch" interface. They want mouse control (which is more accurate than "touch", and doesn't require lifing one's hands up or far from the keyboard for extended or repetitive sets of time) - a keyboard - and possibly a multi-windowed environment - which they can do for a lot of stuff. They might be doing a lot of word processing, layout - or running XCode. They need to install their OWN SOFTWARE (without the restrictions and complications of Apple's certificates, licensince, AppStore, etc).
So I could see them packaging it as an "iPad with a keyboard" - but it would be a different product - and not a "replacement" for the Air or any other laptop.
But people still DO use it. It may not have been a "good" solution, but it was *a* solution. Today however, (just like with Flex), it is *not* a solution, because it would yield a web site which doesn't work with a lot of popular devices. That wasn't the case before iOS.
Outside of Android - I believe use and acceptance is waning heavily. As a client-side web tool (where it got most of it's early predominance) it has been cockblocked by iOS, and is becoming overshadowed by native HTML5 (JavaScript) stuff. As a server-side tool it has been getting taken over by Ruby/Rails, Python and the stuff mentioned in the OP.
But to insist on using "biometric" data for "online" purchases - how are they expecting to receive the biometric data? Through a scanner on the *users* computer? Even if it was done by some sort of credit-card hardware - you are now relying on not *biometric* data - but just *data* - as the users' computer has to send the data - and therefore who's to say if it's really "biometric" or not. (i.e. Some sort of reply attack - or something like it). My point is - there is no way to assure that it's really the user's fingerprint - just data matching the user's fingerprint. So how is this different than a conventional password?
At least a the grocery store - if you stick a "fake" finger on the scanner - you're going to at least create some suspicion - at minimum.
The only "new" thing here is that the pump can AUTOMATICALLY stop delivery. This is a very small software tweak. The only thing that's different about this than getting a new firmware update for your iPhone - is that it requires BOAT LOADS of FDA certification to simply add the trivial (and obvious) feature - because hey, it is automatically messing with medication delivery.
There are two other less obvious things about it that really makes it a non-story:
1. Blood Glucose (BG) levels can rise or fall fast for one of many reasons. (Most "short-acting") insulins that are delivered from such a device take about 2 hours to reach their peak. So if the device realizes you are low and cuts off delivery - there is a good chance you could have "active" insulin already in your body which has yet to take affect. So the fact that delviery has been cut-off doesn't buy you too much - you still need to probably get some fast-acting carbs or glucogon to deal with the low blood sugar condition - or the fact that the "active" insulin could make you go even *lower* over the next 2 hours.
2. Most people who own the "Continuous Glucose Monitor" (CGM) piece very rarely use it. It is expensive, and yet another device to wear. They use them occasionally to get an idea of long-term trends, and for help in adjusting overall insulin levels that they program into the pump. It is also very inaccurate. (Blood tests taken from fingertips are the most accurate, though not even completely accurate themselves). Blood tests taken from a CGM worn on the abdomen or back, etc. are even less-so. So it suffers an inaccuracy which is like a time-lag" - i.e. your blood glucose level might rapidly falling and low - but a measurement from that site might not indicate that - just yet.
The "Artificial Pancreas" projects that people are referring to are ones in which the pump can deliver both insulin *and* glycogen - and have the intelligence to AUTOMATICALLY deliver them both as need. This is difficult, because now you have to "tell" the pump what your eating, and things like fat, protein and carbs will raise the BG. So for a device to do this without "knowing" what your eating, and to be able to do it with CGM data which isn't very accurate and not very timley, and to adjust it by delivering insulin which has a relatively slow absorption curve (over the course of hours) - makes for a difficult and messy problem.
Furthermore HLS has provisions to tell when bandwidth is too restricted - and to allow pulling in subsequent fragments at a lower bitrate until more bandwidth becomes better (i.e. gong from crappy 3G connection to a good Wifi connection).
Thus - HLS would be a much more ideal way of handling something like iTunes radio. "Internet Radio" is even described as an ideal use case in Apple's own docs.
As for Siri - you have quite the edge case. It is an *extremely* small window between the transmission and then reception of the Siri transaction that you lose your Wifi.
It seems to me that Siri is a bad use case for Multipath TCP. Siri transactions seem to be fast and short-lived. i.e. You wouldn't need a persistent connection that could service transitions between Wifi and 3G. So why use MultipathTCP on it?