The new problem here is that the centralization is pretty much the core value of these companies. Breaking them up would destroy that value. A way around is to first standardize and open all the protocols on which they internally operate, and then split them. But you could say that the standardization is in a way an indirect nationalization. If email was run by a company, it would easily be amongst the richest companies in the world.
As a python package developer, I'd assume that being able to install with pip in user space or in a virtual environment is a standard technique. Why duplicate the dozens of tutorials on the internet?
Rather than meaning “superb conductivity”, superconductivity is a specific electronic state of matter in which the conductivity drops to zero at a certain critical temperature, and magnetic fields are “expelled” from the material. In conventional (low-temperature) superconductors, this is caused by formation of electron pairs (Cooper pairs) that behave as bosons. There is no established mechanism for unconventional (high-temperature) superconductivity.
In any case, the present study does not mean that graphene is a superconductor.
Graphene does not appear to be a superconductor, but apparently the enhanced conductivity is due to electrons forming interesting structures which lower the scattering effects of the atomic lattice. It reminded me about Cooper pairs, hence the joke.
Very trivialized: in some sense, you could say that for light itself, there is no time. In the same sense as there is no space for things that do not move (in space).
In chemical physics, many of the most influential papers (tens of thousands of citations) have been published in The Journal of Chemical Physics, an absolutely non-flashy publication with impact factor ~3 and a myriad of uninteresting papers.
I use rsync [1] to backup my laptop to my server twice an hour. (Hard-linking files that already exist in previous images.) Then another script [2] on the server prunes old backups every night.
Apple Pay operates using network tokenization, which is part of the EMV standard. This works in two parts.
When you add a card to Apple Pay, your device checks if the bank can use Apple Pay, and gets a device token from your bank, along with some cryptographic data. The original card number your typed in is discarded; it is replaced by the device token, which looks like a credit card number. All this data is stored in the device’s Secure Enclave. It’s important to note that Apple does not store card data, and doesn’t even take part in the transaction flow.
When you pay with Apple Pay, your device generates a network token. In practice, this network token is your device token, which is sent along with a cryptographic signature, the cryptogram (generated using the data previously stored into the Secure Enclave). This data fits into traditional card fields (name/number/expiration date/cvv), plus an additional field for the cryptogram. The token is transmitted through the merchant to their gateway/acquirer, which sends passes it to the payment network (Visa/Mastercard). The network checks the cryptogram, does a reverse lookup of the device token and associates it with the real card number. The transaction proceeds like a normal transaction using the real card number.
IIRC, Android Pay works using the same standard, with Google storing the device tokens in the cloud and generating network tokens on the behalf of the user (not all Android devices have secure elements). May be inaccurate, I haven’t had the opportunity to implement it at the payment provider level (yet!).
From what you write and from the diagram in that pdf, it's the issuer bank that creates the device token, but then it's the network that does the reverse lookup. Do both the issuer bank and the network know the mapping between device tokens and cards?
Yes. The network needs of course to map tokens back to PANs (Primary Account Numbers). Tokens are included in authorization requests to issuing banks, in addition to the actual payment details.
Also, both issuers and networks need to be able to suspend and unlink tokens in case of fraud or if the end user loses their device, which implies that they know individual device tokens.
It seems that Android devices are allowed to store a few pre-generated tokens to use offline for a limited duration. I don't have a first-party source for that however.
