Abstract: Techniques for leveraging legacy code to deploy native-code desktop applications over a network (e.g., the Web) are described herein. These techniques include executing an application written in native code within a memory region that hardware of a computing device enforces. For instance, page-protection hardware (e.g., a memory management unit) or segmentation hardware may protect this region of memory in which the application executes. The techniques may also provide a narrow system call interface out of this memory region by dynamically enforcing system calls made by the application. Furthermore, these techniques may enable a browser of the computing device to function as an operating system for the native-code application. These techniques thus allow for execution of native-code applications on a browser of a computing device and, hence, over the Web in a resource-efficient manner and without sacrificing security of the computing device.

Abstract: Techniques for providing intuitive feedback to a user regarding which applications have access to a data stream captured by a privacy-sensitive device, such as a camera, a microphone, a location sensor, an accelerometer or the like. These techniques apprise the user of when an application is receiving potentially privacy-sensitive data and the identity of the application receiving the data. In some instances, this feedback comprises a graphical icon that visually represents the data stream being received and that dynamically alters with the received data stream. For instance, if an application receives a data stream from a camera of a computing device of the user, the described techniques may display an image of the video feed captured by the camera and being received by the application. This graphical icon intuitively alerts the user of the data stream that the application receives.

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: A virtual machine monitor (VMM) is configured to enforce deterministic execution of virtual machines in a multiprocessor machine. The VMM is configured to ensure that any communication by physical processors via shared memory is deterministic. When such VMMs are implemented in a distributed environment of multiprocessor machines coupled via a logical communication link, non-deterministic server applications running on virtual machines using the VMM may be replicated.

Abstract: Techniques for leveraging legacy code to deploy native-code desktop applications over a network (e.g., the Web) are described herein. These techniques include executing an application written in native code within a memory region that hardware of a computing device enforces. For instance, page-protection hardware (e.g., a memory management unit) or segmentation hardware may protect this region of memory in which the application executes. The techniques may also provide a narrow system call interface out of this memory region by dynamically enforcing system calls made by the application. Furthermore, these techniques may enable a browser of the computing device to function as an operating system for the native-code application. These techniques thus allow for execution of native-code applications on a browser of a computing device and, hence, over the Web in a resource-efficient manner and without sacrificing security of the computing device.

Abstract: Techniques for leveraging legacy code to deploy native-code desktop applications over a network (e.g., the Web) are described herein. These techniques include executing an application written in native code within a memory region that hardware of a computing device enforces. For instance, page-protection hardware (e.g., a memory management unit) or segmentation hardware may protect this region of memory in which the application executes. The techniques may also provide a narrow system call interface out of this memory region by dynamically enforcing system calls made by the application. Furthermore, these techniques may enable a browser of the computing device to function as an operating system for the native-code application. These techniques thus allow for execution of native-code applications on a browser of a computing device and, hence, over the Web in a resource-efficient manner and without sacrificing security of the computing device.

Abstract: Software code of a software system (e.g., a software stack) may be verified as conforming to a specification. A high-level language implementation of the software system may be compiled using a compiler to create an assembly language implementation. A high-level specification corresponding to the software system may be translated to a low-level specification. A verifier may verify that the assembly language implementation functionally conforms to properties described in the low-level specification. In this way, the software system (e.g., a complete software system that includes an operating system, device driver(s), a software library, and one or more applications) may be verified at a low level (e.g., assembly language level).

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: Software code of a software system (e.g., a software stack) may be verified as conforming to a specification. A high-level language implementation of the software system may be compiled using a compiler to create an assembly language implementation. A high-level specification corresponding to the software system may be translated to a low-level specification. A verifier may verify that the assembly language implementation functionally conforms to properties described in the low-level specification. In this way, the software system (e.g., a complete software system that includes an operating system, device driver(s), a software library, and one or more applications) may be verified at a low level (e.g., assembly language level).

Abstract: A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

Abstract: Digital maps can be composed of a series of image tiles that are selected based on the context of the map to be presented. Independently hosted tiles can comprise additional details that can be added to the map. A manifest can be created that describes the layers of map details composed of such independently hosted tiles. Externally referable mechanisms can, based on the manifest and map context, select tiles, from among the independently hosted tiles, that correspond to map tiles being displayed to a user. Subsequently, the mechanisms can instruct a browser, as specified in the manifest, to combine the map tiles and the independently hosted tiles to generate a more detailed map. Alternatively, customized mechanisms can generate map detail tiles in real-time, based on an exported map context. Also, controls instantiated by the browser can render three-dimensional images based on the combined map tiles.

Abstract: Techniques for providing intuitive feedback to a user regarding which applications have access to a data stream captured by a privacy-sensitive device, such as a camera, a microphone, a location sensor, an accelerometer or the like. These techniques apprise the user of when an application is receiving potentially privacy-sensitive data and the identity of the application receiving the data. In some instances, this feedback comprises a graphical icon that visually represents the data stream being received and that dynamically alters with the received data stream. For instance, if an application receives a data stream from a camera of a computing device of the user, the described techniques may display an image of the video feed captured by the camera and being received by the application. This graphical icon intuitively alerts the user of the data stream that the application receives.

Abstract: Techniques for providing intuitive feedback to a user regarding which applications have access to a data stream captured by a privacy-sensitive device, such as a camera, a microphone, a location sensor, an accelerometer or the like. These techniques apprise the user of when an application is receiving potentially privacy-sensitive data and the identity of the application receiving the data. In some instances, this feedback comprises a graphical icon that visually represents the data stream being received and that dynamically alters with the received data stream. For instance, if an application receives a data stream from a camera of a computing device of the user, the described techniques may display an image of the video feed captured by the camera and being received by the application. This graphical icon intuitively alerts the user of the data stream that the application receives.

Abstract: This document describes techniques for allowing a computing device that provides a minimal execution environment to execute legacy applications that rely on rich functionality that the computing device does not natively provide. For instance, a device may initially receive a request to execute an application and may determine whether the application is directly executable. In response to determining that the application is not directly executable, the computing device may determine whether the application specifies another application to provide the functionality. If the application specifies another application to provide this functionality, then the computing device retrieves the specified application and executes the specified application on the client computing device. If the application does not specify such an application, then the computing device may execute a default application for providing the functionality.

Abstract: Digital maps can be composed of a series of image tiles that are selected based on the context of the map to be presented. Independently hosted tiles can comprise additional details that can be added to the map. A manifest can be created that describes the layers of map details composed of such independently hosted tiles. Externally referable mechanisms can, based on the manifest and map context, select tiles, from among the independently hosted tiles, that correspond to map tiles being displayed to a user. Subsequently, the mechanisms can instruct a browser, as specified in the manifest, to combine the map tiles and the independently hosted tiles to generate a more detailed map. Alternatively, customized mechanisms can generate map detail tiles in real-time, based on an exported map context. Also, controls instantiated by the browser can render three-dimensional images based on the combined map tiles.

Abstract: Techniques for enabling client computing devices to leverage remote server pools for increasing the effectiveness of applications stored on the client computing device are described herein. In some instances, the server pools comprise a “cloud”, “cluster” or “data center” that comprises hundreds or thousands of servers connected together by a network that has an extremely low latency and high bandwidth relative to the network through which the client computing device connects to the server pool. The client computing device may request that the server pool perform a certain task for an application whose canonical state resides on the client. After computation of a result of the task, a server of the server pool then provides the result to the client. By doing so, the techniques dramatically increase the amount of resources working on the request of the client and, hence, dramatically increase the speed and effectiveness of the client-side application.

Abstract: A system including a plurality of servers, a client, and a metadata server is described herein. The servers each store tracts of data, a plurality of the tracts comprising a byte sequence and being distributed among the plurality of servers. To locate the tracts, the metadata server generates a table that is used by the client to identify servers associated with the tracts, enabling the client to provide requests to the servers. The metadata server also enables recovery in the event of a server failure. Further, the servers construct tables of tract identifiers and locations to use in responding to the client requests.

Abstract: A client device configured to write to both a growth server and a live server replica that the growth server is replacing during a growth phase is described herein. The client device first determines the growth server designated to replace a corresponding live server replica of a set of server replicas associated with a storage index. The client device then transmits a write request associated with the storage index to the set of server replicas and to the growth server. The client device may perform the determining based on storage assignment mappings. The storage assignment mappings are provided to the client device by a metadata server while the growth server retrieves data associated with the storage index from the live server replica.

Abstract: A system including at least one storage node and at least one computation node connected by a switch is described herein. Each storage node has one or more storage units and one or more network interface components, the collective bandwidths of the storage units and the network interface components being proportioned to one another to enable communication to and from other nodes at the collective bandwidth of the storage units. Each computation node has logic configured to make requests of storage nodes, an input/output bus, and one or more network interface components, the bandwidth of the bus and the collective bandwidths of the network interface components being proportioned to one another to enable communication to and from other nodes at the bandwidth of the input/output bus.