EU data protection regulations are in force. There will no doubt be some scrutiny as to what data safe harbour companies have transfered outside the EU and what steps were taken to protect it.
I had the same question and it leads me to believe the companies saying they had no idea. Someone at Google/MS/Facebook would almost surely notice those extra servers over there, all that extra network traffic going somewhere, or those cables that seem to go into a locked closet.
I think it's far more likely this is built off the back of the data they're already known to be sucking down via major exchanges.
A national security letter for the TLS certs and you can take what you want, when you want off straight from the stream of packets.
This isn't true. Many people bike on footpaths and surfaces that are completely unsuitable for motorised vehicles. Almost anywhere you can walk you could ride a bike and cross the terrain faster.
If walking turns into scrambling or climbing the bike becomes a bit of a hinderance, but they're not that heavy and the benefits across most terrain outweigh the inconvenience. In fact on a bike you could probably avoid it altogether, not losing a great deal of time just going around.
You're not likely to still be travelling long distances long enough after whatever event that the roads and paths are in such a state of disrepair. You'd be talking years for that to happen and you probably would have had to sort out some sort of place to live and grow food long before you had to worry about it.
I'm not saying the tesla couldn't be better or that they couldn't learn something from Sony. But part of the author's complain was that he had one reading in the evening and when the temperature dropped overnight his reading the next morning was drastically lower.
Also a while a digital camera does get to spend some time outdoors it spends most of it's life in fairly people comfortable environment.
I thought that, then I installed nexus and let it proxy the remote repositories and really haven't looked back. Takes some time to setup (few hours). But makes life so much easier that it's well worth the effort, especially that with Java you WILL have a dependency on a 3rd party jar from Oracle that for whatever reason won't ever show up in maven central or want to include some other 3rd party repository.
The same thing that happens now. Malicious user can recover/reset their password.
I'd assume that if you used the email to login and since the article talks about also using cookies with expiry dates in the future the codes in emails would be single use.
A lot of the time it's because the implementations haven't even been agreed between the different browsers.
I can't remember any specific examples off the top of my head but I do remember that some of the -webkit and -moz prefixes were ever so slightly different.
I think once it made it into the draft most browsers start supporting it using the standard css without any prefix.
For raw storage Hadoop beats an RDBMS, sure I'll buy that argument. It's not the same thing though and it doesn't do the same job.
Hadoop excels at data processing, trawling vast quantities of unstructured or semi structured data and extracting information from it. It's a poor platform for random access to specific elements of that data though.
RDBMS are great in exactly the places Hadoop isn't, getting access to random elements of data in a structured manner. Executing structured queries on that data. Things you know you'll do a lot of and can optimise.
There are column and table data stores built on top of Hadoop, and it can be argued that they could be used as an alternative to an RDBMS but they aren't drop in replacements and for the most part they're not meant to do the same job.
The most interesting uses of Hadoop aren't going to come from replacing existing RDBMS infrastructure with a Hadoop cluster. They're going to come from pushing data into a Hadoop cluster to process it. Collecting data that would otherwise be impossible to collect because it's either unstructured or there is simply too much to put in a RDBMS at a cost effective scale.
Hadoop and the NoSQL movement is exciting when you start to think about processing that data and pulling what's useful back out into your existing infrastructure.
This is likely the reason, and probably not just as a cheap work around, in most day to day situations it's probably the desired effect since both sticks are independent and don't move in reaction to the other.
GPS can only tell you how fast you're moving over the ground. It can't tell you how fast you're moving through an airmass that might be moving with or against you, this is far more important to keeping a plane in the air than how fast you're moving between point a and point b.
Except the client id has to be generated so that you know which client was authorised with it - in the case of something like Facebook or twitter, so you can revoke their access.
That means you have to agree on a way of exchanging that client ID.
Which at it's simplest is what OAuth 2 does with bearer tokens. If you have no use for the other parts of the spec then just ignore them, it's all optional and you only need to implement it if you need it.
The problem with OAuth1 was that the complicated crypto dancing around was exactly that, complicated. Making sure you're using HTTPS is hardly a big ask for developers on either the client or the server and frankly is probably a much better idea given most of these services are more likely than not sending some form of private data.
The reason is OAuth1 is painful, the double encoded and signature requirements are strict and so easy to get wrong that everyone has jumped on OAuth2. Unfortunately they've all jumped on different versions of the spec which keeps changing , because it's still a draft.
I think they're only really harder to develop in so much as it's more like developing two applications. One backend that throws out JSON/XML or whatever and a frontend in HTML/Javascript.
I actually find that bit easier, because I can separate out the the parts and worry about things a piece at a time. The other benefit of this is if you chose to develop for iOS, Android or any other platforms you already have an API. Equally if you wanted a developer program, again it's already there.
The complexity comes when you make the decision as to whether or not to support clients that can't or won't execute Javascript, if you want to make it work for them too you're stuck with more work and things do get more difficult.
As far as testing goes, there are plenty of mature javascript unit testing frameworks and if your inclined to unit test your javascript already this doesn't add a great deal of overhead. Your really just testing something in JS you would have otherwise done and tested server-side.