GPS requires a receiver.
How can you reasonably have 500 drivers vying for the same fare and also have 30 people in a 8 person minibus? What is the motivation to overcrowd?
The T&Cs are satisfied since the entity redeeming the ticket is identified -- just not as an individual person. The owner is set when the back of the ticket is signed (http://www.bna.com/taxpayer-pay-gift-b12884908246/) and that can be any legal entity from the looks of that article.
Isn't that equivalent to music companies having no obligation to supply a replacement if your CD is damaged? The theory as I understand it is the license is part of the media, in this case the 'media' is Steam -- I suspect they will not be moved if 'Steam' is damaged.
I recall the old floppy-based copy-protected games would sometimes offer to replace media if it failed, but not always.
I suspect it'll require some sort of signup and beacon placement for the drone to know where to place the package; say by placing multiple beacons in your yard / on your building roof (for larger buildings) that designate the boundaries where the objects can be placed. The beacons could also transmit the destination GPS coordinates for en-route navigation, but gps is probably not enough for the final drop. That would have to rely on a signal from the beacons themselves.
The beacons can also act as warnings that a flight is incoming (lights / sounds, etc) and be able to do some sort of sweep if anything is blocking the landing pad.
Or perhaps a 'landing tarp' that has a pattern on it that the drone computer vision can use to determine if anything is in the way (such as expect a regular grid pattern); if any of the grid is obscured then abort.
Lacking access to the password data base AND assuming a rate-limiter, the attacker can't realistically try a brute-force.
However, most of the time the password list is exposed in some way and attacked offline to get the original passwords.
Installing Open Connect means Comcast avoids costs in maintaining higher capacity edge routers, and can place the caching boxes wherever is efficient for their own network topology. For example, if placed in each geographic region hub, it means their own long-haul trunks are less stressed and do not need to be upgraded as soon. If you take as a given that customers will want to watch NetFlix, then the costs of hosting these cache boxes is supposed to be offset by the reduced pressure on the long-distance Comcast network connections.
The NSA can't subvert a keyserver. At least, at worst they can replace the keys with their own, but then the Web Of Trust would render those keys untrusted. Getting the key from a keyserver or copying it from a webpage is equivalent. The benefit of the keyserver is if you get an email from someone signed by key X, your client can fetch the key from the keyserver then calculate if you have any trust of that key.
Also, I see that your key is on a keyserver: http://pgpkeys.mit.edu/pks/loo... as any key can be published to a keyserver regardless if you have the corresponding private key.
It seems improbable that a 'Enterprise' Customer Relationship Management system that Comcast must be using wouldn't have a detailed history on account changes, such as who submitted a name change. There should be no mystery as to who is changed the names.
Unless someone has hacked in to the underlying database and is bypassing the business logic, in which case Comcast has a serious problem on their hands.
Hosted applications may or may not handle the passwords properly after they've been entered into the form. It is inescapable that the host must have the raw keys in order to decrypt the data. It may be impervious to 3rd parties *now* but there's nothing that prevents that from changing, and the user has no way of detecting it.
Similarly for mobile applications -- unless one has firsthand knowledge that the currently installed application will not transmit raw keys to a 3rd party, AND prevents all future updates to that application, then the security is fleeting.
It may be that the promise of security is enough for a given use case, but to be sure one needs to encrypted the data with keys that are never transmitted to a 3rd party prior to uploading the data.
Another way of looking at it: If an entity were to hold a figurative gun to the head of a mobile app developer / hosting provider, in such a way that you as a user were unaware of it (ie were still willing to use the application / provider in the normal course of usage), could the application be changed such that the data is exposed?
Every single-player exploration game falls under the 'could make exploration pointless' category, yet they are still fun games.
It doesn't make sense that a game with one player requires more CPU then a desktop can provide -- tracking that a NPC spawned some items on a market in various star systems is not that intensive. The CPU intensity of MMOs comes from tracking all the player interactions and routing/filtering those actions, not the spawn rates of various events.
The alternative is to say that one players interactions require more resources then a desktop CPU can provide, which bodes poorly for the scalability / longevity of the game if they need 1.5 cloud-nodes to run 1 player's simulation.
It had to be plugged in to operate, the manufacturer was directly involved in several parts of the test, and it sounds like the outputs were measured in a questionable way. It'd be awesome if it was true, but there is a lot of room for tricks in that.
Even if nobody knows how it works, it should be possible for one of these to be handed off to a disinterested 3rd party with the appropriate inputs detailed, and have it function such that it can be detached from external power and continue to generate significant heat.
But, having the manufacturer involved with setting up the test and fiddling with it partway through casts great suspicion on the claims.
Then you'd have people ransacking stores looking for serial #'s that test above their price level, buy them all up and resell them after unlocking them. Instead, perhaps publish a serial #/model catalog. That works so long as the serial # on the card is relatively tamper-evident, and the manufacture has to be ok with essentially exposing their exact manufacturing numbers. Probably not especially palatable.
Beware 'overdraft protection' on that account where they'll extend you some credit and come after you for it later, with a ton of fees on top.
You can use S3 to interact with glacier; create a 'VHS Archive' bucket with a bucket policy to migrate to Glacier after X days. Upload everything there and let it sit; this sort of use case is *exactly* the sort of thing Glacier was intended for.