Monthly Archives: April 2017

Facebook Including on augmented reality

Facebook apps these days have a camera button built in? Well, says Facebook CEO Mark Zuckerberg, now it’s time to use those buttons to turn on augmented reality for just about everything you’re doing in Facebook’s world.

“We are making the camera the first augmented reality platform,” Zuckerberg said, kicking off Facebook’s F8 developer conference in San Jose this morning. “I used to think glasses would be the first mainstream augmented reality platform,” he said. But he’s changed his mind.

By “camera,” Zuckerberg really means the camera button (which allows users to directly access a mobile device’s actual camera) and related photo processing tools in Facebook and related apps. Now, Zuckerberg said, Facebook is going to roll out tools to allow developers to create augmented reality experiences that can be reached through that photo feature. These tools will include precise location mapping, creation of 3D objects from 2D images, and object recognition.

Developers, he expects, will be able to apply these tools to generate virtual images that appear to interact directly with the real environment. For example, fish will swim around on your kitchen table and appear to go behind your real cereal bowl, virtual flowers will blossom on a real plant, virtual steam will come out of a real coffee mug, or a virtual companion’s mug will appear next to yours on your table in order to make your breakfast routine feel a little less lonely. Augmented reality will also allow users to leave notes for friends in specific locations—say, at a table in a particular restaurant—or let them view pop-up labels tagged to real world objects.

“Augmented reality will let us mix the digital and the physical,” Zuckerberg said in his keynote address to 4000 developers, “and that will make our physical reality better.”

Zuckerberg also predicted the advent of augmented reality street art, and suggested that as technology makes people working in traditional jobs more productive, more and more people will contribute to society through the arts.

Give Individuals Control Over Their Online Identities

Today, for the most part, we lack that control. We have surrendered ourselves to the likes of Facebook, Google, Twitter and Amazon, whose profiles on their customers are so extensive that they are now, themsleves, used as standard identity verifiers across most Internet domains. Want to leave a comment? Just sign in with Facebook. Trying to get into your Medium account? Just login with Twitter.

And if those companies suddenly disappear, so too does your online identity.

Meanwhile, asserting more important things about yourself online is just as difficult as ever. You can efile your taxes, but first you’ll need that PIN from the IRS that you set up a bajillion years ago that somehow proves you are who you say you are.

It’s a terrible mess. And according to Phil Windley, the chair of the Sovrin Foundation, the best way to fix it is to use distributed ledger technology to make something that looks more like what we have offline.

“In the physical world I go to my pharmacy and they ask for my driver’s license to prove I’m over 18 and I supply it to them. They don’t have to have a direct connection to the Department of Motor Vehicles. They don’t have to have any kind of API integration to make that work. Because I am the conveyer of this verifiable claim called a driver’s license. That hasn’t been possible on the Internet and Sovrin makes that possible,” says Windley.

In this alternate view, it is the individual who possesses all the pieces of their identity, which ranges from mundane testimonials about what your favorite movie is, to critical information like age and date of birth.

In Sovrin, these facts about you (or pointers for where to find these facts) would all reside on a distributed public ledger which you alone had the authority to access and share. Other entities, however, could modify your claim by signing off on them with a cryptographic key, thereby adding weight and credibility to the pieces of your identity. For example, you may have an identity on the Sovrin network which specifies your driver’s license number and that information might be signed by your state’s DMV.

The technology has a slight whiff of blockchain, but doesn’t really have a blockchain. Rather, it is a ledger that is replicated over mulitple nodes that all coordinate to make updates and police the system and which together make up the Sovrin network. The nodes are invite-only, meaning that the ledger is public, but permissioned. As a result, Sovrin functions without the participation of miners, which makes it less expensive and less energy hungry than your typical open blockchain.

Windley says that he envisions the first applications coming from the financial sector. Banks could participate as node operators to maintain the ledger and provide it as the repository for their customers’ identities. If given permission by the customer, multiple banks could access this information in a single place in order to comply with Know-Your-Customer (KYC) regulations.

In joining Hyperledger Indy, Sovrin is donating all of its code and getting back developer power in return.

There are currently many other groups working in the blockchain and distributed ledger space to build self-sovereign identity systems. Bitnation began using the blockchain to issue its own nation state-independent version of a passport in 2014. That project now resides on the Ethereum network which also supports another identity management tool called uPort. And Civic is building out a similar project on Bitcoin.

Content-Centric Networking

In today’s Internet, there is only one kind of data packet—one that carries both content and requests for content between users. But in a CCN network, there are two types: content packets and interest packets. They work together to bring information to users. Content packets are most like traditional data packets. The bits in a content packet may specify part of an ad on a Web page, a piece of a photo in an article, or the first few seconds of a video. Interest packets, on the other hand, are like golden retrievers that a user sends out onto the network to find a specific content packet and bring it back.

When you visit a Web page, your computer needs to fetch about 100 pieces of content on average. A piece of content could be a block of text, a photo, or a headline. With CCN, when you navigate to a website or click on a link, you automatically send out interest packets to specify the content you would like to retrieve. Typing in a single URL, or Web address, can trigger a user’s browser to automatically send out hundreds of interest packets to search for the individual components that make up that page.

Both interest and content packets have labels, each of which is a series of bits that indicate which type of packet it is, the time it was generated, and other information. The label on a content packet also includes a name that designates what bits of content it holds, while the label on an interest packet indicates which content it wishes to find. When a user clicks on a link, for example, and generates a flurry of interest packets, the network searches for content packets with matching names to satisfy that request.

The name on a packet’s label is called a uniform resource identifier (URI), and it has three main parts. The first part is a prefix that routers use to look up the general destination for a piece of content, and the second part describes the specific content the packet holds or wishes to find. The third part lists any additional information, such as when the content was created or in what order it should appear in a series.

Suppose a Web surfer’s browser is using CCN to navigate to this article on IEEE ­Spectrum’s website. The network must find and deliver all the content packets that make up the complete article. To make that process easier, URIs use a hierarchical naming system to indicate which packets are needed for the page, and in what order. For example, one content packet might be named spectrum.ieee/2017/April/ver=2/chunk=9:540. In this example, spectrum.ieee is the routable prefix for the second version of the article, and the specific packet in question is the ninth packet of 540 that make up the complete article.

Once a CCN user has clicked that link or typed it in as a Web address, the user’s machine dispatches an interest packet into the network in search of that content, along with other interest packets to search for packets 10 and 11. As the interest packet for number 9 travels along, each router or server it encounters must evaluate that interest packet and determine whether it holds the content packet that can satisfy its request. If not, that node must figure out where in the network to forward the interest packet next.

To do all of this, every node relies on a system known as a CCN forwarder. The forwarder operates on components that are similar to what you’d find in a traditional router. A CCN forwarder requires a processor, memory, and storage to manage requests. The forwarder also runs a common software program called a forwarding engine. The forwarding engine decides where to store content, how to balance loads when traffic is heavy, and which route between two hosts is best.

The forwarding engine in a CCN network has three major components: the content store, the pending interest table, and the forwarding information base. Broadly speaking, CCN works like this: A node’s forwarding engine receives interest packets and then checks to see if they are in its content store. If not, the engine next consults the pending interest table and, as a last resort, searches its forwarding information base. While it’s routing information, the engine also uses algorithms to decide which content to store, or cache, for the future, and how best to deliver content to users.

To understand how that system improves on our existing Internet protocols, consider what happens when a new interest packet arrives at a node. The forwarding engine first looks for the content in the content store, which is a database that can hold thousands of content packets in its memory for quick and easy access, like the cache memory in a conventional router. But CCN has a key difference. Unlike the traditional Internet protocols, which permit content to be stored only with the original host or on a limited number of dedicated servers, CCN permits any node to copy and store any content anywhere in the network.

To return to our example, if the forwarder finds the content it’s looking for in the node’s content store, the system sends that content packet back to the user through the same “face,” or gateway, by which the interest packet entered the system. However, when an interest packet arrives, that node might not hold a copy of the needed content in its content store. So for its next step, the forwarding engine consults the pending interest table, a logbook that keeps a running tally of all the interest packets that have recently traveled through the node and what content they were seeking. It also notes the gateway through which each interest packet arrived and the gateway it used to forward that content along.

By checking the pending interest table (PIT) whenever a new interest packet arrives, the forwarding engine can see whether it has recently received any other interest packets for the same—or similar—content. If so, it can choose to forward the new interest packet along the exact same route. Or it can wait for that content to travel back on its return trip, make a copy, and then send it to all users who expressed interest in it.

The idea here is that these PIT records create a trail of bread crumbs for each interest packet, tracing its route through the network from node to node until it finds the content it’s seeking. This is very different from conventional networks, where routers immediately “forget” information they’ve forwarded. Then, that forwarder consults the PIT at each node to follow the reverse path back to the original requester.

Suppose, though, that an interest packet arrives at a node and the forwarding engine can’t find a copy of the requested content in its content store, nor any entry for it in the pending interest table. At this point, the node turns to the forwarding information base—its last resort when trying to satisfy a new request.

Ideally, the forwarding information base (FIB) is an index of all the URI prefixes, or routable destinations, in the entire network. When an interest packet arrives, the forwarding engine checks this index to find the requested content’s general whereabouts. Then it sends the interest packet through whatever gateway will move it closer to that location and adds a new entry to the pending interest table for future reference. In reality, the FIB for the entire Internet would be too large to store at every node, so just like today’s routing tables, it is distributed throughout the network.

In a traditional network, routers perform a similar search to find the IP address of the server that holds the bits of information a user wishes to retrieve and figure out which gateway to send the request through. The difference here is that with CCN, the forwarding information base finds the current location of the information itself on the network rather than the address of the server where it’s stored.

By focusing on the location of content rather than tracking down the address of its original host, a CCN network can be more nimble and responsive than today’s networks. In fact, our studies indicate that the CCN model will outperform [PDF] traditional IP-based networks in three key aspects: reliability, scalability, and security.

CCN improves reliability by allowing any content to be stored anywhere in the network. This feature is particularly useful in wireless networks at points where bit-error rates tend to be high, such as when data is transmitted from a smartphone to a cell tower, or broadcast from a Wi-Fi access point. Current Internet protocols leave error recovery to higher levels of the protocol stack. By keeping a copy of a content packet for a short while after sending it along, a CCN node reduces the upstream traffic for packets that need to be retransmitted. If a packet fails to transmit to the next node, the previous node does not need to request it again from the original host because it has its own copy on hand to retransmit.

The pending interest table can also make it easier for networks to scale. By grouping similar interest packets together, it can reduce the bandwidth needed to satisfy each request. Instead of sending a new request back to the original host for each identical interest packet that arrives, a node could satisfy all those requests for interest packets with identical copies of the content it has stored locally. If the record shows that there has been a lot of demand for a viral cat video, the algorithms within that node may prompt it to keep an extra copy of all those packets in its content store to more quickly satisfy future requests.

Boosting reliability and making it easier to scale networks are two important benefits. But to us, the most important advantage of CCN is the extra securityit offers. In traditional networks, most security mechanisms focus on protecting routes over which information travels (similar to the strategies used in early ­circuit-switched telephone networks). In contrast, CCN protects individual packets of information, no matter where they flow.

Currently, two users can establish a secure connection through established Internet protocols. The two most common of these are HTTPS and Transport Layer Security. With HTTPS, a user’s system examines a digital certificate issued by a third party, such as Symantec Corp., to verify that the other user is who she claims to be. Through TLS, users negotiate a set of cryptographic keys and encryption algorithms at the start of each session that they both use to transfer information securely to each other.

With CCN, every content packet is encrypted by default, because each content packet also comes with a digital signature to link it back to its original creator. Users can specify in their interest packets which creator they would like to retrieve content from (for example, Netflix). Once they find a content packet with that creator’s matching signature, they can check that signature against a record maintained by a third party to verify that it is the correct signature for that piece of content.

With this system in place, creators can allow other users to copy and store their content, because packets will always remain encrypted and verifiable. As long as users can verify the signature, they know that the content packet originated with the creator and that users can securely access the content—a motion picture, say—from anywhere it happens to be.

This security feature brings another bit of good news: Distributed denial-of-service attacks—in which hackers send a large volume of requests to a website or server in order to crash it—are more difficult to execute in CCN. Unusual traffic patterns are easier to discern in a CCN network and can be shut down quickly. On the other hand, clever attackers may just try to figure out a way to flood the network with interest packets instead. This security challenge would have to be solved before CCN could be widely adopted.

Another significant challenge [PDF] is figuring out how to integrate CCN’s protocols into routers running at the speeds used on current networks. Analysts are especially concerned that routers in a CCN system would have to store rather large FIB and PIT tables to track the many moving content objects on the network, which will present major computational and memory-related challenges. However, researchers are now working on this problem at Cisco, Huawei, PARC, and Washington University in St. Louis, which have all demonstrated prototype routers supporting various elements of the CCN protocols.

 

Networks Take to Space

Quantum physics makes possible a strange phenomenon known as entanglement. Essentially, two or more particles such as photons that get linked or “entangled” can, in theory, influence each other simultaneously no matter how far apart they are. Entanglement is essential to the workings of quantum computers, the networks that would connect them, and the most sophisticated kinds of quantum cryptography—a theoretically unhackable means of information exchange.

Back in 2012, Pan Jianwei, a quantum physicist at the University of Science and Technology of China at Hefei, and his colleagues set the distance record for quantum entanglement. A particle on one side of China’s Qinghai Lake influenced one on the other side, 101.8 kilometers away. However, entanglement gets easily disrupted by interference from the environment, and this fragility has stymied efforts at greater distance records on Earth.

Now, Pan and his colleagues have set a new record for entanglement by using a satellite to connect sites on Earth separated by up to 1,203 km. The main advantage of a space-based approach is that most of the interference that entangled photons face occurs in the 10 km or so of atmosphere closest to Earth’s surface. Above that, the photons encounter virtually no problems, the researchers say.

The researchers launched the quantum science experiment satellite (nicknamed Micius) from Jiuquan, China, in 2016. It orbits the planet at a speed of roughly 28,800 kilometers per hour and an altitude of roughly 500 km. “Through ground-based feasibility studies, we gradually developed the necessary toolbox for the quantum science satellite,” Pan says.

The experiments involved communications between Micius and three ground stations across China. Beacon lasers on both the transmitters and receivers helped them lock onto each other.

Micius generated entangled pairs of photons and then split them up, beaming the members of a pair to separate ground stations. The distance between the satellite and the ground stations varied from 500 to 2,000 km.

The record distance involved photons beamed from Micius to stations in the cities of Delingha and Lijiang. The experiments transmitted entangled photons with a 1017 greater efficiency than the best optical fibers can achieve. “We have finally sent entanglement into space and established a much, much larger quantum optics laboratory, which provides us a new platform for quantum networks as well as for probing the interaction of quantum mechanics with gravity,” Pan says.

Although these experiments generated roughly 5.9 million entangled pairs of photons every second, the researchers were able to detect only about one pair per second. Pan’s team expects a thousandfold improvement in this rate “in the next five years,” he says. He also notes that the current transmission rate for entangled pairs is close to what’s necessary to provide quantum cryptography for very brief texts; five years from now, networks of satellites and ground stations could successfully transmit at megahertz rates.

In another study, researchers in Germany found they could measure the quantum features of laser signals transmitted by a satellite a record 38,600 km away. These findings suggest that satellites could play a role in quantum networks that use less sophisticated forms of quantum cryptography that do not rely on entanglement.

Quantum physicist Christoph Marquardt from the Max Planck Institute for the Science of Light, in Erlangen, Germany, and his colleagues experimented with the Alphasat I-XL satellite, which is in geostationary orbit. Alphasat used laser signals to communicate with a ground station at the Teide Observatory in Tenerife, Spain.

Marquardt notes that the laser communications technology they experimented with is already used commercially in space. That, combined with the success of his and his colleagues’ experiments, suggests that quantum networks that do not rely on entanglement could be set up “as soon as five years from now,” he says.