Square Wallet[0] used to implement something similar to what you're describing. It used your phone's GPS to register you as near/inside a store and merchants selected you based on a photo you provided. It was pulled in May[1] in favour of Square Order.
As an aside, no USA banks issue chip and PIN cards. The EMV-capable cards being rolled out are chip and sign cards. This usually doesn't matter but can cause issues at fully automated tills (the common example being issues when trying to purchase transit tickets).
Wikipedia's article on EMV has a section explaining the technical differences[0] between the card types.
Yes they do. Wells Fargo issued me one to use on my trip to Paris. It worked fine in Paris, plug it in, enter the pin, and done. It does take some getting used to, but my Target Red Card works the same way now in the US (enter a pin, etc).
Also your link contradicts your point:
> As an aside, no USA banks issue chip and PIN cards. The EMV-capable cards being rolled out are chip and sign cards.
But if you actually read the very section you linked it says that they are Chip and Pin and not only are they Chip and Pin, but they're the exact same "EuroPay" compatible cards issued in much of Europe.
Did you even read what you linked to, like at all..? Because:
> The chips in these cards feature "PIN" ranked first in the list of possible cardholder verification methods (CVM), but with signature allowed as a fall-back option (or even no verification at unattended terminals).
So you're wrong. Every USA bank is issuing Chip and Pin you just cannot read.
I wasn't aware of Wells Fargo issuing Chip and PIN cards[0] and I appreciate you pointing that out!
The other USA banks that I've looked at (Bank of America[1], for example) issue signature-only cards. These not working in unattended kiosks is mentioned in the last paragraph of the Wikipedia section we're both referring to.
The main problem with Chip and PIN cards in the USA is PIN management. Since EMV was developed before every ATM was online, the card needs to be aware of its PIN. Not many USA ATMs support reading EMV cards, which makes changing the PIN on the card difficult.
This is why Wells Fargo[0] don't allow you to change your card's PIN and is why many USA banks simply chose to skip PINs altogether. The last sentence of the Wikipedia section we're referring to mentions this.
Each message is encrypted individually for each device that will be receiving the message. As a result, unless Apple slip a public key they have control over into the keys reported for the receiver, they cannot read your messages. (This is why abalone mentions that Apple do not have access to your old messages.)
> Digital Ocean, for example, won't give you more than 1 IPv4 address per VPS, which means you need a separate VPS for every side project, if you want to go HTTPS.
As long as you're not supporting clients running IE on WinXP or other similarly old web browsers, Server Name Indication (where the hostname is included as a part of the handshake) will work and it'll eliminate your need for more than one IP.
I just typed a similar comment at nearly the same time but this is interesting to learn. I had no idea XP didn't like this? I know Android 2.2 and older wouldn't take intermediate SSL certs so I've already written off some of my traffic. Now I'll add XP to the group. In fairness, running XP or Android 2.2 now and you have bigger problems than SSL not working...
Wildcard certificates are only valid for the subdomain level directly under it. [1]
If I get a wildcard certificate for example.com (the common name is set to *.example.com), foo.bar.example.com will throw an error.
The specification isn't particularly clear, but it seems to me that RFC 2818 section 3.1 [1] could permit some dangerously broad wildcards like ".com", "www..com", or even ".". Combined with subject alternate names, it may be possible to create a certificate that's valid for almost anything.
IIRC, top-level and "match all" wildcard certificates were originally permitted by design (e.g., for intranet and proxy applications), but most modern browsers block them for security reasons.
It's not. As https://developers.facebook.com/docs/chat/ explains, "Facebook Chat should be compatible with every XMPP client, but is not a full XMPP server. It should be thought of as a proxy into the world of Facebook Chat on www.facebook.com.
Er, so isn't that the exact same situation as Google? You can still connect with any XMPP client, but XMPP support is now just a proxy into the world of Hangouts.
Yes, my pidgin is working just fine right now. You have to log in through a google account now, you can't connect through a federated account, but AFAIK all previous XMPP clients still work just fine.
It supports client federation, not server federation. Server federation is what it allows XMPP servers to send messages between each other, while client federation allows for other clients to connect over XMPP.
What I don’t quite get is how server federation is much more difficult than ‘client federation’. s2s XMPP looks extremely similar to s2c XMPP, and since they still have s2c XMPP, they don’t seem to have a problem with only exposing parts of their architecture via XMPP.
Really, I can only think of laziness and trying to build a walled garden as reasons to support c2s but not s2s connections.
Both of which are not exactly good explanations for one of the largest companies in software engineering.
As stated by Google officially, and by all accounts of everyone using external clients, XMPP works fine. Federation doesn't, just like with Facebook as mentioned above.
Take a look at me.com, for example. Before Apple bought it, it was owned by SnappVille.com. If SSL certificates didn't expire, SnappVille could have continued using their certificates for me.com.
That still doesn't fully explain why they expire, as CRLs and OCSP allow certificates to be revoked. I can't quite explain why having an expiration date is safer, I just feel it's a good practice, to protect against possible key compromise.
But, they would have to get the private certificate? And if someone got that even while Apple still owned me.com, lots of nasty man in the middle attacks could have been made.
Yep. You'll normally see this happen if you restore an iPhone backup onto another iPhone then try to launch WhatsApp. Login will fail and you'll be asked to type in the SMS received.
[0]: http://allthingsd.com/20120430/paying-with-squares-new-mobil... [1]: http://www.theverge.com/2014/5/12/5709256/square-kills-squar...