Methods and systems of providing browser cross-page communication using ports

BACKGROUND

0001The advent of rich Internet applications that transfer a substantial amount of application logic to clients has resulted in the need for web pages from different origins to communicate with one another. To accomplish this communication, the inventors have discovered that a cross-browser secure transport mechanism is desirable.

SUMMARY

0002This disclosure is not limited to the particular systems, methodologies or protocols described, as these may vary. The terminology used in this description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope.

0003As used in this document, the singular forms “a,” “an,” and “the” include plural reference unless the context clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skill in the art. All publications mentioned in this document are incorporated by reference. All sizes recited in this document are by way of example only, and the invention is not limited to structures having the specific sizes or dimension recited below. As used herein, the term “comprising” means “including, but not limited to.”

0004In an embodiment, a method of establishing a communication channel between browser windows may include generating, by a client network comprising a plurality of browser windows that each serve as hosts for one or more peers, a discovery request that comprises a name of a requested service and instantiation information, sending the discovery request to a plurality of the peers, wherein each peer is a script unit, and receiving a response from one or more of the plurality of the peers. Each response may include an indication of a port associated with the peer that will serve as a reference to the requested service. The method may include accepting, by the client network, one of the received responses.

0005In an embodiment, a system for establishing a communication channel between browser windows may include a computing device configured to operate a plurality of browser windows, that each serves as a host for one or more peers, and a computer-readable storage medium in communication with the computing device. The computer-readable storage medium may include one or more programming instructions that, when executed, cause the computing device to generate a discovery request that comprises a name of a requested service and instantiation information, send the discovery request to a plurality of the peers, receive a response from one or more of the plurality of the peers, and accept one of the received responses. Each response may include an indication of a port associated with the peer that will serve as a reference to the requested service, and each peer may be a script unit.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> illustrates example network that includes four browser windows of a client according to an embodiment.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates an example method of locating a service provider according to an embodiment.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example diagram of sending and receiving discovery messages and responses among a network of peers according to an embodiment.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates a block diagram of example hardware that may be used to contain or implement program instructions according to an embodiment.

DETAILED DESCRIPTION

0010The following terms shall have, for purposes of this application, the respective meanings set forth below:

0011A “computing device” refers to a device that includes a processor and non-transitory, computer-readable memory. The memory may contain programming instructions that, when executed by the processor, cause the computing device to perform one or more operations according to the programming instructions. Examples of computing devices include personal computers, servers, mainframes, gaming systems, televisions, and portable electronic devices such as smartphones, personal digital assistants, cameras, tablet computers, laptop computers, media players and the like. When used in the claims, reference to “a computing device” may include a single device, or it may refer to several devices that together perform the claimed steps.

0012A “peer” refers to a single script unit that is associated with one or more web-based services. When a user of a browser selects a command that actuates a peer, the peer causes its associated web-based service to launch or otherwise activate.

0013A “web-based service” or “service” refers to a service provided via the Internet or other network. Example services may include, without limitation, email, social networking, electronic banking, e-commerce services and/or the like.

0014A “widget” refers to software that is embedded, installed and/or executed on a web site. A widget may be associated with a particular service, and may provide a user with certain functionality. A widget may be implemented as an icon, a menu, a button, a selection box, a scroll bar and/or the like. Example widgets may include, without limitation, social media buttons, weather applications, calendar applications and/or the like.

0015It may be beneficial for independent pieces or segments of code such as, for example, those running in different browser contexts, to communicate directly with one another. One way in which this communication may occur may be through channel messaging. Channel messaging may implement a two-way communication channel between a pair of code segments, with each channel having a port at each end. A message sent in one port may be delivered to the other port.

0016<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example network that includes four browser windows of a client according to an embodiment. A browser window may be a software application that retrieves, accesses and/or displays information from the Internet or other network.

0017As illustrated by <figref idref="DRAWINGS">FIG. 1</figref>, each browser window <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b> may act as a host for one or more peers <b>110</b>, <b>112</b>, <b>114</b>, <b>116</b>, <b>118</b>, <b>120</b>, <b>122</b>. A peer may have one or more ports connected to it. For example, as illustrated by <figref idref="DRAWINGS">FIG. 1</figref>, peer <b>116</b> is associated with ports <b>124</b>, <b>126</b>, <b>128</b> and <b>130</b>, and peer <b>118</b> is associated with port <b>132</b>. In an embodiment, a port may provide an endpoint for a communication channel with one or more other ports. The port or ports to which a port enables communication may be associated with one or more peers in the same or another browser window. For example, port <b>124</b> which is associated with peer <b>116</b> in browser window <b>106</b> may establish a channel to communicate with port <b>132</b> which is associated with peer <b>118</b> in browser window <b>108</b>.

0018In an embodiment, a port may establish a suitable communication channel with one or more other ports such as, for example, a MessageChannel object. A MessageChannel object may provide two-way asynchronous messaging through ports that enables intra-window and inter-window communication.

0019As an example, a browser page may have an indication, such as a button, associated with a social networking service and an indication, such as another button, associated with an electronic payment service. Each service may have a corresponding peer. If the button associated with the social networking service wants to interact with the button associated with the electronic payment service, such as, for example, to communicate information between the two services, then the social networking button may connect its peer to the electronic payment service's peer.

0020In an embodiment, a network may require a certain service. A peer may provide one or more services to one or more other peers in communication with the peer. For example, referring to <figref idref="DRAWINGS">FIG. 1</figref>, peer <b>116</b> may provide a service to peers <b>110</b>, <b>112</b>, <b>114</b> and <b>118</b>.

0021In an embodiment, peers may register with one another before they are able to communicate. For example, a first peer may send a message to a second peer, such as, for example, a child window peer or a worker peer. The message may include an initialization instruction or indication such as, for example “INIT”. In an embodiment, the message may include an indication of a port that can be used for further communication.

0022In an embodiment, a service may have an associated access control list (ACL). An ACL may specify for one or more ports, one or more services a port can provide, to which other ports it can provide the services and to which other ports the port can connect to provide one or more services.

0023In an embodiment, a client may need to locate a service provider in its network. <figref idref="DRAWINGS">FIG. 2</figref> illustrates an example method of locating a service provider according to an embodiment. As illustrated by <figref idref="DRAWINGS">FIG. 2</figref>, a peer may identify <b>200</b> a service to be requested. For example, a chat application client may want to locate a dialog service.

0024The peer may send <b>202</b> a discovery message to one or more other peers in its network. In an embodiment, a discovery message may include information about the requested service such as, for example, the name of the service. The name of the service may be provided in the format of a uniform resource identifier (URI).

0025In an embodiment, a discovery message may include instantiation information. Instantiation information may include information needed to instantiate the requested service. This information may include, without limitation, a scope of a service, an action to be performed by a service, a function associated with a service and/or the like. For example, the following pseudo code instruction may be used to find a service that authorizes a scope for an email application—port.findService(SERVICE, {scope: “https://www.service”}, function(res, port) { // ...}).

0026As another example, the following pseudo code instruction may be used to locate a PGP service that can decrypt a message's key—port.findService(PGP_SERVICE, {action: “DECRYPT”, message: “----BEGIN PGP MESSAGE---[...]----END PGP MESSAGE----”}, function(res, port) { // ...}). Additional and/or alternate instructions may be used within the scope of this disclosure.

0027In an embodiment, a peer may use an ACL to determine to which other peers to send a discovery message. For example, an ACL may identify one or more peers that are allowed to provide a requested service. The peer may identify these peers, and only send a discovery message to these peers.

0028In an embodiment, one or more other peers may receive <b>204</b> the discovery message. The peer may determine <b>206</b> whether it is able to provide the requested service. For example, a peer may use the service name and/or the instantiation information in the discovery message to determine <b>206</b> whether it is able to provide the requested service. In an embodiment, a peer may access an associated ACL to determine <b>206</b> whether it is able to provide the requested service. For instance, referring to the above example, a peer may receive a discovery request for a dialog service. The peer may access an ACL to determine <b>206</b> whether it is able to provide the service and fulfill the request.

0029In an embodiment, if the peer determines that it is able to provide the service, the peer may send <b>208</b> the requesting peer a response. The response may include an indication that the peer is able to provide the service. In an embodiment, the response may include an indication of the port that the requesting peer can use to access the instance of the requested service. In an embodiment, if the peer determines that it is not able to provide the services, the peer may not send a response.

0030<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example diagram of sending and receiving discovery messages and responses among a network of peers according to an embodiment. As illustrated by <figref idref="DRAWINGS">FIG. 3</figref>, Peer <b>0</b><b>300</b> may send a discovery message to each of Peer <b>1</b><b>302</b>, Peer <b>2</b><b>304</b> and Peer <b>3</b><b>306</b>. If the peers are able to provide the service, each of Peer <b>1</b><b>302</b>, Peer <b>2</b><b>304</b> and Peer <b>3</b><b>306</b> may respond to Peer <b>0</b><b>300</b> with a response.

0031Referring back to <figref idref="DRAWINGS">FIG. 2</figref>, the requesting peer may receive <b>210</b> the response. If the requesting peer receives <b>210</b> a response from more than one of the other peers, the requesting peer may decide which response to accept. In an embodiment, the requesting peer may accept <b>212</b> a response, and may invoke <b>214</b> the service via the peer associated with the accepted response.

0032In an embodiment, a remote procedure call (RPC) protocol may be used to provide inter-process or inter-peer communication between two or more peers. According to the RPC protocol, each call to a service instance may include an indication of a method and one or more arguments. An indication of a method may include information about the method that is being called in the service. In an embodiment, the one or more arguments may be arguments that are to be sent to the service.

0033In an embodiment, certain browsers may not support channel messaging as described above. In these situations, a transport layer polyfill may be used to provide security protection on top of the network layer. A network layer may refer to the network layer of the Open Systems Interconnection (OSI) model according to an embodiment.

0034In an embodiment, a polyfill may be used to create new channels on demand and send responses via the channels. Once a port is exported, messages may be reliably sent to their new destination, and a previous owner may not be able to read the messages.

0035A message may be sent through a network layer in the form of a public message. The message may be associated with one or more fields. An example field may be a transport mode field, which may indicate when and to what extend a window can be able to spoof of read messages that belong to another window. Example values for a transport mode field may be Insecure, Integrity, Privacy or Integrity+Privacy. In an embodiment, an Insecure value may indicate that a window that previously owned a port may spoof messages for a certain period of time between when an export occurs and when the port is verified from its new destination. An Integrity value may indicate whether a message was not tampered with during transmission. A Privacy value may protect message content from being revealed to unauthorized individuals or systems by nodes in a network that transfer the message.

0036Another example field may be a key identification field which may be used to identify a port. A key identification field may identify a key, and its value may be a truncated hash of a key. Another example field associated with a public message may be a protected message field. This field may include an internal message.

0037Yet another example field may be a forwarded origins field. Situations may arise when a port is exported and, before the export process is complete, a window may need to forward one or more messages to one or more final destinations. In these situations, the origin of the messages may not be correct. A list of forwarded origins may be maintained. In an embodiment, the list may only be trusted if the entire chain of origins is trusted by a recipient.

0038In an embodiment, a protected message may be extracted according to the transport mode field and/or the key identification field. Once extracted, the message may include a private message structure within it. This structure may include a sequence number. A sequence number may help protect against replay attacks and may make encryption of messages non-deterministic. A private message structure may include an indication of message type. In an embodiment, a data message, a control message and/or an export message may be used to export ports.

0039A private message structure may include a data packet and/or an indication of one or more ports. An export message may include a window path and the new origin of a port.

0040In an embodiment, a polyfill may encrypt a payload. For example, a polyfill may encrypt a payload in port communication situations when the two sides of a message can't obtain a reference to each other's window. A string representation of the message length may be prefixed to the message together with a separator, and may be stored as, for example, encodedMessage. A keyed-hash message authentication code (HMAC) may be applied to the encodeMessage with the port key. The encodedMessage may be encrypted in AES CBC mode with the port key, using the HMAC as its initialization vector.

0041<figref idref="DRAWINGS">FIG. 4</figref> depicts a block diagram of hardware that may be used to contain or implement program instructions. A bus <b>400</b> serves as the main information highway interconnecting the other illustrated components of the hardware. CPU <b>405</b> is the central processing unit of the system, performing calculations and logic operations required to execute a program. CPU <b>405</b>, alone or in conjunction with one or more of the other elements disclosed in <figref idref="DRAWINGS">FIG. 4</figref>, is an example of a production device, computing device of processor as such terms are used within this disclosure. Read only memory (ROM) <b>410</b> and random access memory (RAM) <b>415</b> constitute examples of non-transitory computer-readable storage media.

0042A controller <b>420</b> interfaces with one or more optional non-transitory computer-readable storage media <b>425</b> to the system bus <b>400</b>. These storage media <b>425</b> may include, for example, an external or internal DVD drive, a CD ROM drive, a hard drive, flash memory, a USB drive or the like. As indicated previously, these various drives and controllers are optional devices.

0043Program instructions, software or interactive modules for providing the interface and performing any querying or analysis associated with one or more data sets may be stored in the ROM <b>410</b> and/or the RAM <b>415</b>. Optionally, the program instructions may be stored on a tangible non-transitory computer-readable medium such as a compact disk, a digital disk, flash memory, a memory card, a USB drive, an optical disc storage medium and/or other recording medium.

0044An optional display interface <b>430</b> may permit information from the bus <b>400</b> to be displayed on the display <b>435</b> in audio, visual, graphic or alphanumeric format. Communication with external devices, such as a printing device, may occur using various communication ports <b>440</b>. A communication port <b>440</b> may be attached to a communication network, such as the Internet or an intranet.

0045The hardware may also include an interface <b>445</b> which allows for receipt of data from input devices such as a keyboard <b>450</b> or other input device <b>455</b> such as a mouse, a joystick, a touch screen, a remote control, a pointing device, a video input device and/or an audio input device.

0046It will be appreciated that various of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications or combinations of systems and applications. Also that various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.