Patent Publication Number: US-10769285-B2

Title: Privacy enabled runtime

Description:
BACKGROUND 
     The present application relates to computer technology, and more specifically, to security and/or privacy of data used by applications executing on a computing device. 
     A number of computer-based services collect data associated with a user via one or more computing devices from which the user accesses the services. For example, the computer-based services may include services such as a searching web-content, accessing maps and directions, accessing consumer reviews, messaging, sharing data (text, images, audio, video and so on) with other users, and many other such services. The data collected when providing such services may include contextual data, such as a location of the user, search queries, items that the user clicked. Such collection of data may raise privacy concerns for the user. In addition, the user may be concerned about the data being transmitted to and/or being collected at repositories that the user did not authorize. 
     SUMMARY 
     According to one or more embodiments, a computer-implemented method for securing data by a communication apparatus includes receiving, by an encryption engine, a request to apply cryptography to input data. The computer-implemented method also includes generating metadata for the input data, where the metadata identifies characteristics of content included in the input data. The method further includes applying a cryptographic technique to the input data to generate output data, and outputting the output data and metadata in response to the request. 
     According to one or more embodiments, an apparatus for securing data includes a memory, a communication interface, and an encryption engine communicably coupled with the memory and the communication interface. The encryption engine receives a request to apply cryptography to input data. The encryption engine generates metadata for the input data, where the metadata identifies characteristics of content included in the input data. The encryption engine generates output data by applying a cryptographic technique to the input data. The encryption engine further returns the output data and the metadata in response to the request. 
     According to one or more embodiments, a computer program product for securing data by a communication apparatus includes a computer readable storage medium. The computer readable storage medium includes computer executable instructions to receive a request to apply cryptography to input data. The computer readable storage medium also includes computer executable instructions to generate metadata for the input data, where the metadata identifies characteristics of content included in the input data. The computer readable storage medium also includes computer executable instructions to generate output data by applying a cryptographic technique to the input data. The computer readable storage medium also includes computer executable instructions to return the output data and the metadata in response to the request. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The examples described throughout the present document may be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale. Moreover, in the figures, like-referenced numerals designate corresponding parts throughout the different views. 
         FIG. 1  illustrates an example a communication apparatus for preventing unauthorized transmission of data, in accordance with an embodiment. 
         FIG. 2  illustrates example components of a communication apparatus for preventing unauthorized transmission of data, in accordance with an embodiment. 
         FIG. 3  illustrates an example view of the communication apparatus for preventing unauthorized transmission of data, in accordance with an embodiment. 
         FIG. 4  illustrates a flowchart of example logic for generating metadata for the transmission data in accordance with an embodiment. 
         FIG. 5  illustrates a flowchart of example logic for preventing transmission of unauthorized private data in accordance with an embodiment. 
         FIG. 6  illustrates a flowchart of example logic to determine sensitivity level of content in transmission data in accordance with an embodiment. 
         FIG. 7  illustrates a flowchart of example logic to facilitate user review of transmission data requests that are labeled for blocking or modifying in accordance with an embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Disclosed here are technical solutions for facilitating a privacy enabled runtime environment for a communication apparatus. For example, the runtime environment according to the technical solutions described, together with programming constructs facilitate a user of the communication apparatus to identify which information is being collected from the communication apparatus. The runtime environment further facilitates the user to filter out specific information that the user may deem as being sensitive or private, at least for a particular operation. The technical solutions may further assist a firewall that operates in conjunction with the communication apparatus to decide whether to transmit or to block outbound data. 
     The technical solutions thus facilitate the user to identify applications, that is, computer executable software being executed on the communication apparatus, which are collecting information from the communication apparatus. Typically, an application, when being installed, requests access to one or more categories of information from the communication apparatus. For example, the application may request access to contacts, media (images, video, audio), network, incoming/outgoing phone calls, location, and other such categorical information, without specific clarity on the exact information being accessed, collected, or how the information is being used. The user has the choice to deny the request, which results in the user is giving up the benefits of that application, since the application may not install upon denial of the request to the information access. 
       FIG. 1  illustrates a communication apparatus  110  that includes a runtime environment  120  and multiple components  140 . The communication apparatus  110  may be a phone (such as a smartphone), a wearable device (such as a smartwatch), a tablet computer, a laptop computer, a desktop computer, a server computer, or any other apparatus that can communicate via one or more communication networks. 
     The runtime environment  120  may be part of an operating system of the communication apparatus  110 . The runtime environment  120  facilitates execution of an application  130  by the communication apparatus  110 . For example, the runtime environment  120  facilitates the application  130  to send instructions to a processing unit, and access the components  140  and other system resources of the communication apparatus  110 . In addition, the runtime environment  120  includes the operating settings (such as environment variables), common libraries, directory structure, network neighbors, and other settings that facilitate the execution of the application  130 . Alternatively or in addition, the runtime environment  120  may be a virtual machine. For example, the runtime environment  120  may be an instance of JAVA RUNTIME ENVIRONMENT™ (JRE™) COMMON LANGUAGE RUNTIME™ (CLR™), or any other runtime environment. The runtime environment  120  provides an application programming interface (API)  132  that the application  130  may use to access the system resources of the communication apparatus  110 . 
     For example, the application  130  includes computer executable instructions in a computer programming language that include calls to functions of the API  132 . The API  132  facilitates the application  130  to access and use the components  140  of the communication apparatus. A call to a function of the API  132  may be a request to operate on specific data. For example, the call to a function of the API  132  specifies the data in the form of one or more types of parameters and the values of the parameters. For example, the application  130  to transmit data to a server  160 , may issue a data transmission request to the runtime environment  120 . The data transmission request specifies the transmission data to be sent and an identifier of the destination of the data transmission request. For example, the identifier may be an IP address, a network name, or any other identifier associated with the server  160 . 
     The server  160  may be a remote computer server that collects data from the communication apparatus  110 . The server  150  may collect the data in lieu of providing a service to the user of the communication apparatus  110 . For example, the server  160  may be an email server that collects the data from the communication apparatus  110  to facilitate the user to send/receive email messages via the communication apparatus  110 . Alternatively or in addition, the server  160  may be an instant messaging server, a social media server, a navigation server, a backup server, a search-engine server, a media-streaming server, or any other such server that provides a corresponding service to the user via the communication apparatus  110 . Alternatively or in addition, the server  160  may be an advertising server that collects contextual information from the user to provide targeted advertisements to the user. 
     The contextual data may improve user experience, for example by predicting what the user may want to buy, or obtain help with. In some examples, as described earlier, the application  130  may not be installed without the user agreeing to share data with the server  160  and receive the application&#39;s services in exchange. For example, the application  130  may have permissions  150  to access one or more types of data or components  140  of the communication apparatus  110 . For example, the permissions  150  may include access to messages (such as text messages), network communication (the Internet), phone communications (incoming/outgoing calls), location (via global position sensor), storage (files stored on the apparatus), email, contacts, camera (images/video), and any other resources of the communication apparatus  110 . In an example, the application  130  may have permission to use one or more of the components  140  to generate data and access the data thus generated. The user may give the application  130  the permission  150  explicitly during installation. Alternatively or in addition, in case of malicious applications such as a Trojan horse, a malware, an adware, a virus, or other such notorious application types, the application  130  may gain the permissions  150  unbeknown to the user. Thus, in such cases, the application  130  may share data and information from the communication apparatus, including sensitive and/or private information about the user with the server  160 , without the user knowing about such sharing. 
     For example, the components  140  include hardware and/or software components of the communication apparatus  110 . The components  140  may include one or more different types of components C- 1   142 , C- 2   144 , C- 3   146 , among other components. The application  130 , using the API  132 , may access the components  140  of the communication apparatus and share the data from the components  140  with the server  160 . As described herein, the data may be shared with or without the user&#39;s authorization. The communication apparatus  110 , and/or the runtime environment  120  that implements the technical solutions described herein facilitates the user to control what data is shared by the application  130  with the server  160 . Thus, the technical solutions facilitate the user to own and control access to his/her data, and authorize one or more authorized applications to use the data to enhance user experience. 
       FIG. 2  illustrates example components of the communication apparatus  110 . The communication apparatus  110  includes, among other components, a processor  205 , memory  210  coupled to a memory controller  215 , and one or more peripheral devices  245  and/or output devices  240  that are communicatively coupled via a local I/O controller  235 . The peripheral devices  245  may include sensors and devices, for example, battery sensors, touch sensors, gyro meters, position sensors, accelerometers, cameras, depth sensors, indicator/identification lights, and the like. Input devices such as a conventional keyboard  250  and mouse  255  may be coupled to the I/O controller  235 . The I/O controller  235  may be, for example, one or more buses or other wired or wireless connections, as are known in the art. The I/O controller  235  may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. 
     The I/O devices  240 ,  245  may further include devices that communicate both inputs and outputs, for instance disk and tape storage, a network interface card (MC) or modulator/demodulator (for accessing other files, devices, systems, or a network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, and the like. 
     The processor  205  is a hardware device for executing hardware instructions or software, particularly those stored in memory  210 . The processor  205  may be a custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the communication apparatus  110 , a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or other device for executing instructions. The processor  205  includes a cache  270 , which may include, but is not limited to, an instruction cache to speed up executable instruction fetch, a data cache to speed up data fetch and store, and a translation lookaside buffer (TLB) used to speed up virtual-to-physical address translation for both executable instructions and data. The cache  270  may be organized as a hierarchy of more cache levels (L1, L2, and so on.). 
     The memory  210  may include one or combinations of volatile memory elements (for example, random access memory, RAM, such as DRAM, SRAM, SDRAM) and nonvolatile memory elements (for example, ROM, erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), disk, diskette, cartridge, cassette or the like). Moreover, the memory  210  may incorporate electronic, magnetic, optical, or other types of storage media. Note that the memory  210  may have a distributed architecture, where various components are situated remote from one another but may be accessed by the processor  205 . 
     The instructions in memory  210  may include one or more separate applications (such as the application  130 ), each of which comprises an ordered listing of executable instructions for implementing logical functions. In the example of  FIG. 2 , the instructions in the memory  210  include a suitable operating system (OS)  211 . The operating system  211  essentially may control the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. 
     Additional data, including, for example, instructions for the processor  205  or other retrievable information, may be stored in storage  220 , which may be a storage device such as a hard disk drive or solid state drive. The stored instructions in memory  210  or in storage  220  may include those enabling the processor to execute one or more aspects of the systems and methods of this disclosure. 
     The communication apparatus  110  may further include a display controller  225  coupled to a user interface or display  230 . In some embodiments, the display  230  may be an LCD screen. In other embodiments, the display  230  may include a plurality of LED status lights. In some embodiments, the communication apparatus  110  may further include a network interface  260  for coupling to a network  265 . The network  265  may be an IP-based network for communication between the communication apparatus  110  and an external server, client and the like via a broadband connection. In an embodiment, the network  265  may be a satellite network. The network  265  transmits and receives data between the communication apparatus  110  and external systems. In some embodiments, the network  265  may be a managed IP network administered by a service provider. The network  265  may be implemented in a wireless fashion, for example, using wireless protocols and technologies, such as Wi-Fi, WiMAX, satellite, or any other. The network  265  may also be a packet-switched network such as a local area network, wide area network, metropolitan area network, the Internet, or other similar type of network environment. The network  265  may be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN) a personal area network (PAN), a virtual private network (VPN), intranet or other suitable network system and may include equipment for receiving and transmitting signals. 
       FIG. 3  illustrates another view of the communication apparatus  110 . The runtime environment  120  may work with a firewall  310  and a privacy-processing engine  320  to prevent sensitive data being shared by the application  130  with the server  160 . The privacy-processing engine  320  may be part of the runtime environment  120  in an example. The privacy-processing engine  320  may determine whether to block the transmission data, by identifying sensitive content based on predetermined rules. The predetermined rules may be configured by the user. Alternatively or in addition, the privacy-processing engine  320  determines whether to block the transmission data based on a crowd sourced security information server  330 . 
     The crowd sourced security information server  330  may be a server computer or a data repository that contains identifying data that identifies content that may be sensitive. The identifying data is obtained from multiple other communication apparatus. For example, a second communication apparatus, other than the communication apparatus  110 , may identify that the application  130  transmits location identifier to the server  160 , without authorization to transmit location related content. The second communication apparatus may store, at the crowd sourced security information server  330  that the application  130  transmits data in a specific format or contains specific variables. For example, the crowd sourced security information server  330  may contain information that the transmission data transmits location identifier to the server  160  via a specific parameter in the transmission data. The privacy-processing engine  320 , thus blocks the location related content transmitted by the application  130  based on the information accessed from the crowd sourced security information server  330 . 
     Further, once the content to be blocked has been identified, the runtime environment  120  facilitates the user to review and modify the content using the display  230  of the communication apparatus  110 . Alternatively, the runtime environment  120  facilitates the user to review and modify the content using a separate user review device  340 . The user review device  340  is another communication apparatus, such as a phone, a laptop computer, a desktop computer, a tablet computer, or any other type of communication apparatus. Modifying the transmission data may include removing particular parts of the content or the entirety of the content from the transmission data. Alternatively or in addition, modifying the transmission data may include blanking out particular parts of the content or the entirety of the content from the transmission data. For example, blanking content may include replacing a character of the content to be blanked with a predetermined character. 
     The privacy-processing engine  320  may be a module that identifies content in the transmission data that is to be blocked. The privacy-processing engine  320  may include an electronic circuitry or any other hardware device that may be operated according to one or more computer executable instructions. The firewall  310  may be a module that is part of the communication apparatus  110 , for example a part of the operating system  211 . 
     The communication apparatus  110  may further include a cryptographic engine. The cryptographic engine is also referred to as an encryption engine  370 . The encryption engine  370  includes hardware, software, and firmware. For example, the encryption engine  370  may include electronic circuitry such as a processor and a memory. The encryption engine  370  may include additional components, which may be operable by computer executable instructions. The encryption engine  370  includes an encryption unit  372  and an analytics unit  374 . In one or more examples, the encryption engine  370  may include the encryption unit  372  and the analytics unit  374  as part of a single hardware unit. In other examples, the encryption unit  372  and the analytics unit  374  may be on separate hardware units. In other example, the encryption unit  372  could be a hardware unit, and the analytics unit could be a software unit. In other example, the encryption unit  372  could be collocated with the analytic unit and communicate through an internal bus. In other example, the encryption unit  372  could communicate with the analytic unit through a communication network. The encryption unit  372  facilitates encrypting a string, which may be a series of electronic data such as letters, numbers, binary data, symbols, (like $, %, #, and so on). The encryption unit  372  receives the string as an input, and provides an encrypted version of the string as output. The encryption unit  372  encrypts the input string using one or more encryption techniques. For example, the encryption unit  372  may include one or more encryption algorithms, which the application  130  accesses via the API  132 . In one or more examples, the application  130  may indicate the encryption technique and related parameters, such as a private key and/or a public key to be used with the encryption technique, along with the input string for encryption unit  372  to encrypt. The encryption unit  372  in response generates an output string, which includes the contents of the input string in encrypted form, according to the instructions from the application  130 . 
     The analytics unit  374  of the encryption engine  370  facilitates generating metadata associated with the input string. In one or more examples, the encryption engine  370  includes the metadata with the output string that is returned to the application  130  that requested encrypting the input string. In another example, the encryption engine  370  makes the metadata available separately from the output string and the metadata can be retrieved separately from the output string at a later time. The metadata is indicative of the one or more different types of data in the input string. In one or more examples, the analytics unit  374  generates the metadata by analyzing the input string. Alternatively or in addition, the analytics unit  374  generates the metadata by instructing the privacy-processing engine  320  to analyze the input string. The metadata may include one or more tags that the encryption engine  370  associated with the input string and the output string. In one or more examples, the encryption engine  370  includes the metadata with the output string, which includes the encrypted version of the input string and the metadata. 
     In one or more examples, the encryption unit  372  applies one or more cryptographic techniques to the metadata from the analytics unit  374 . The encryption unit  372  may apply the cryptographic techniques prior to the encryption engine  370  including the metadata in the output string. For example, the encryption unit  372  may encrypt the input string using an encryption technique different from an encryption technique for the metadata. For example, encryption unit  372  may use a first encryption algorithm, a first encryption key, or a combination thereof to encrypt the input string, and generate the output string. The encryption unit  372  may use a second encryption algorithm, a second encryption key, or a combination thereof to encrypt the metadata. The application  130  may specify the first encryption algorithm, and/or the first encryption key. The second encryption algorithm and/or the second encryption key, which the encryption unit  372  uses for encrypting the metadata, may be only decipherable by the firewall  310 . The second encryption key, for example, may be a predetermined encryption key that is specific to the firewall  310  of the communication apparatus  110 . Alternatively or in addition, the second encryption algorithm and/or key may be decipherable by a recipient or a specific entity, such as an auditor, an administrator, or the like, based on access to a specific deciphering key that decrypts the encrypted metadata. The cryptographic techniques may include encryption, and/or digitally signing the metadata or the encrypted metadata to facilitate the recipient of the metadata to validate the authenticity of the metadata. The cryptographic techniques may further include using multi-signature in a block-chain environment, and/or providing access control. 
     In one or more examples, the analytics unit  374  generates a plurality of metadata for the output string. For example, the analytics unit  374  generates two metadata, a first metadata that is decipherable by the firewall  310  and a second metadata that is decipherable by an entity, such as the auditor or the administrator. The encryption engine  370  may apply respective cryptographic techniques to the different metadata, such as respective encryption algorithms and/or respective encryption keys. For example, in the above scenario with two metadata, the encryption unit  372  encrypts the input string using a first encryption algorithm and/or key, encrypts the first metadata using a second encryption algorithm and/or key, and encrypts the second metadata using a third encryption algorithm and/or key. In another example, the first metadata may use a multi-signature with a first group of signers, and the second metadata may use a multi-signature with a second group of signers. 
     In one or more examples, the encryption engine  370  determines the different cryptographic techniques to be used by the encryption unit  372  based on the input parameters of the instructions to apply a cryptographic technique to the input string from the application  130 . Alternatively or in addition, the encryption engine  370  determines the cryptographic techniques based on the contents of the input string. For example, the encryption engine analyzes the metadata that the analytics unit  374  generates and determines the encryption technique if the metadata matches predetermined criteria. The predetermined criteria may depend on what type of content the input string includes. 
     As described earlier, the encryption engine  370  associates the metadata with the output string by including the metadata with the output string. Alternatively or in addition, the encryption engine  370  updates a data repository  376 , which maintains a mapping between the encrypted output string and the corresponding metadata. Accordingly, in one or more examples, the data repository  376  of the encryption engine  370  contains a mapping between each encrypted output string and the corresponding metadata that the encryption engine  370  has generated. The data repository  376  may maintain the metadata in unencrypted and/or encrypted format. Each entry in the data repository  376  may further include an identification of the application  130  that requested the encryption of the input string. The data repository  376  by maintaining the mapping facilitates determining, at a later time, identifying a source of each input string that the encryption engine  370  encrypts. Additionally, the data repository  376  facilitates, using the metadata in the entries, identifying output strings that contained specific type of metadata. 
     For example, the metadata may specify that the input string, and accordingly, the encrypted output string, contain specific type of information such as a social security number, a tax-identification number, an address, a phone number, a password, a username, an email-address, a birthdate, or any other such sensitive information. The metadata may specify the sensitivity level and type, such as privacy, confidentiality. The metadata could contain answers to questions such as who might be allowed to access the output string, what communication mechanism is required to share the output string, what network can this output string be exposed to, when the information from the output string expires, and so on. The metadata could contain external information such as the contact person related to the output string, the application, or device that requested generation of the output string. 
       FIG. 4  illustrates a flowchart of an example method to generate metadata of the transmission data received by the encryption engine  370  as an input string. The metadata is based on the sensitivity level of content in the transmission data. For example, the encryption engine  370  receives the unencrypted transmission data, as shown at block  405 . In an example, the runtime environment  120  monitors the function calls via the API  132 , and intercepts a data transmission request, for example a function call (for example DataOutputStream( ) in JAVA™) sending transmission data via a communication protocol such as Transmission Communication Protocol (TCP). The data transmission request identifies the transmission data and a destination to which to send the transmission data. The runtime environment  120  secures the transmission data by sending the transmission data for encryption by the encryption engine  370 . 
     The encryption engine  370 , via the analytics unit  374  generates the metadata for the input string. For example, the analytics unit  374  determines a type of the content in the transmission data, as shown at block  407 . For example, the content may be of the type of location information, contacts information, emails, messages, or other such types of content or a combination thereof. The metadata may include one or more tags, each respectively corresponding to a type of content included in the transmission data. For example, if the transmission data includes both a social security number and a date of birth, the metadata includes the corresponding two tags. In one or more examples, the metadata may be a binary word of a predetermined length. Each bit in the binary word may be associated with a specific type of content. For example, consider a metadata binary word with two bits, a first bit associated with a social security number, and a second bit associated with date of birth. In the above exemplary scenario, where the transmission data contains both, the two bits in the metadata binary word may both be set (to 1). That is, the first bit is set based on whether the transmission data includes a social security number, and the second bit is set based on whether the transmission data includes a date of birth. Other examples may include additional bits corresponding to additional content type. 
     The analytics unit  374  generates the metadata for the input string based on the types of the content in the transmission data, as shown at block  420 . In an example, each bit in the metadata binary word is initially set to OFF (or 0). A bit in the metadata binary word is set to ON (or 1) as a corresponding content type is identified. In other examples, the process may be reversed, that is the bits in the metadata binary word may be initialized to ON (1) and set to OFF (0), if the corresponding content type is not present. 
     For example, the analytics unit  374  determines a cause that prompted the application  130  to send the content in the transmission data, as shown at block  425 . For example, the analytics unit  374  uses recent incoming data for the application  130  to assist analysis of determining whether the application  130  is responding to a request with the identified content in the transmission data. Accordingly, the analytics unit  374  analyzes the incoming data and the transmission data for meaning and context of the content. If the analytics unit  374  determines that the content is being transmitted in response to a request for the type of the content, the analytics unit  374  deems that the content is a correct response to the cause of the transmission, as shown at block  530 . If the content is not the correct response, the analytics unit  374  marks a bit in the metadata binary word corresponding to the content type, such as ‘correct response’, as shown at blocks  430  and  415 . Alternatively, if the content is the correct response, the analytics unit  374  continues to analyze the content to determine if the transmission data is secure or is to be modified, as shown at block  430 . 
     For example, the analytics unit  374  determines a format of the content, as shown at block  535 . For example, the privacy-analytics unit  374  may check if the content uses a specific format, for example, “9.12.3.10” is likely an IP Address, abc@gmail.com is likely an email address, 123-456-785 is likely a phone number, 123-45-6789 is likely a social security number, and so on. The user may specify a set of predetermined formats of data that are to be identified in the metadata. Alternatively or in addition, the analytics unit  374  accesses the predetermined formats to be filtered from the crowd sourced security information server  330 . Alternatively or in addition, the analytics unit  374  may be preconfigured with predetermined formats for the metadata. If the content in the transmission data matches a predetermined format from the set of predetermined content formats to be filtered, the analytics unit  374  sets the corresponding bit in the metadata binary word, as shown at blocks  440  and  415 . The analytics unit  374  may determine multiple types of content based on corresponding predetermined formats and mark the corresponding bits in the metadata binary word. 
     The analytics unit  374  further analyzes the content to determine a programming language data-structure used by the content, as shown at block  445 . For example, the analytics unit  374  determines a type of the variable used by the content in the function call of the data transmission request. For example, the data-structure may be determined based on metadata (for example JAVA™ annotation) of the variable used to specify the content. In another example, the analytics unit  374 , via the API  132  requests the runtime environment  120  for a description of the data-structure being used by the content in the transmission data. For example, the runtime environment  120  provides a complimentary API function to facilitate the analytics unit  374  to determine the data-structure. An example of such a complimentary API function is provided in table  1 . The analytics unit  374  may further obtain the data-structure information from documentation of the application  130  and/or the documentation of the API function call (for example, JAVADOC™, MICROSOFT DEVELOPER NETWORK™) being used for the data transmission request. 
     
       
         
           
               
             
               
                 TABLE 1 
               
               
                   
               
             
            
               
                 Complimentary Method Example 
               
               
                 Original Method: Date getDate( ) 
               
               
                 Added Method in Runtime Environment: String getDate_description( ) 
               
               
                   
               
            
           
         
       
     
     The analytics unit  374  further analyzes the identified data-structure to determine if the transmission data contains grouped content. For example, the data-structure may combine GPS and Time data, which can be used to track the user&#39;s schedule, while the GPS data alone can only track the user&#39;s location. For example, the data-structure may be a JSON object, or any other such grouped data-structures that facilitate the application  130  to transmit multiple content-types as a combined package. The analytics unit  374 , by determining the data-structure, facilitates generating metadata for such grouped outgoing data. If the data-structure of the content is one of predetermined data-structures, the analytics unit  374  updates the metadata binary word accordingly, as shown at blocks  450  and  415 . 
     The analytics unit  374  further analyzes the transmission data to determine a specificity of the content, as shown at block  455 . For example, the analytics unit  374  compares the content with company-specific codenames, or other keywords in a company policy. The company-specific codenames may be associated with specific secrets, such as trade secrets, new products, marketing campaigns, or other information that a company, such as a business, prefers to be secret and not being disclosed outside the company. For example, the analytics unit  374  may determine that the content contains a codename “ABCXYZ,” which is a new hardware that company ACME is working on. Alternatively or in addition, the analytics unit  374  may determine that the content includes specific location or personal information, such as “south town mall,” which may be a location, or “Patrick,” which is likely a name. If the content provides specific information, the analytics unit  374  updates the corresponding bits in the metadata, such as for the content type ‘specific’ in the metadata, as shown at block  460 . 
     It is understood that the flowchart of  FIG. 4  provides one example of generating the metadata for the transmission data, and that other examples may generate the metadata in manners different than that in  FIG. 4 . For example, in cases where the metadata includes a set of tags instead of a binary word, the analytics unit  374  may generate the metadata by generating or selecting the tags corresponding to the types of the content in the transmission data. Further, in other examples, generating the metadata may use additional, fewer, or different checks than those illustrated in  FIG. 4 . For example, in another example, specificity of the content may not be checked. Or in yet another example, the format of the content may not be checked, and so on. 
     Further yet, the analytics unit  374  may generate two or more metadata binary words, or tag-sets, as described earlier. The analytics unit  374  updates the two metadata instances using similar process described above. For example, the analytics unit  374 , upon identifying content of a specific type, further checks which metadata is to be updated for that specific content type and updates the metadata accordingly. 
     In one or more examples, after generating the metadata, the encryption engine  370  outputs an output string that includes encrypted transmission data associated with the metadata, as shown at block  490 . 
       FIG. 5  illustrates a flowchart of an example method to associate the metadata with the output string. The encryption engine  370  receives an instruction to encrypt transmission data in the input string, as shown at block  505 . The encryption engine  370 , using the analytics unit  374 , generates the metadata for the transmission data as described herein, as shown at block  510 . The encryption engine  370 , using the encryption unit  372 , encrypts the transmission data in the input string, as shown at block  520 . The encryption engine  370 , using the encryption unit  372 , further encrypts the metadata, as shown at block  530 . The encryption engine  370  identifies which cryptographic technique (that is encryption algorithm and/or encryption key) to use for the metadata, as shown at block  532 . For example, the metadata may be encrypted using a different technique than the contents of the input string, as described herein. The encryption engine  370  informs the encryption unit  372  of the encryption technique to be used, which encrypts the metadata accordingly, as shown at block  534 . 
     Further, in one or more examples in which the analytics unit  374  generates more than one metadata instances, the encryption engine selects distinct encryption techniques for each of the metadata instances. For example, a first metadata may be encrypted using a first encryption technique and a second metadata may be encrypted using a second encryption technique. 
     The encryption engine  370  determines whether the metadata is to be included in the output string, as shown at block  540 . For example, the application  130  that requested the encryption of the transmission data may request that the metadata be returned with the encrypted contents. The application  130  may use the metadata for further analysis, such as to determine whether the transmission data is to be blocked or modified. If the metadata is requested, the encryption engine  370  generates an output string that includes the encrypted contents of the input string, and the encrypted metadata, as shown at block  560 . Alternatively, the output string only includes the encrypted contents of the input string, as shown at block  550 . The encryption engine  370  transmits the output string to with the encrypted contents in response to the initial request to encrypt the input string. The encryption engine  370  updates the data repository  376  with a mapping between the encrypted contents of the input string and the metadata, as shown at block  570 . 
     In an example, the encryption engine  370  also stores an identity of the application  130  that requested the encryption in the data repository. Additionally or alternatively, the encryption engine  370  may store an identity of a user that is executing the application  130 . In one or more examples, the data repository does not store the encrypted (or unencrypted) contents of the input string, rather a mapping between the encrypted metadata of the input string and the application identity and/or the user identity. 
     The runtime environment  120 , using the privacy-processing engine  320  may prevent transmission of private data to unauthorized destinations based on the metadata.  FIG. 6  illustrates a flowchart of an example method for preventing transmission of private data to unauthorized destinations. The runtime environment  120  receives a data transmission request, as shown at block  605 . In an example, the runtime environment  120  monitors the function calls via the API  132 , and intercepts the data transmission request, for example a function call (for example DataOutputStream( ) in JAVA™) sending transmission data via a communication protocol such as Transmission Communication Protocol (TCP). The data transmission request identifies the transmission data and a destination to which to send the transmission data. The runtime environment  120  secures the transmission data, as shown at block  610 . 
     For example, the runtime environment  120  sends the unencrypted transmission data to the encryption engine  370  for encryption, which generates the encrypted transmission data and the corresponding metadata, as shown at block  620 . The runtime environment  120  forwards the metadata to the privacy-processing engine  320  to determine the sensitivity level of the transmission data, as shown at block  630 . 
     The privacy-processing engine  320  identifies one or more specific content types in the transmission data, based on the metadata and assigns the respective sensitivity levels of the contents, as shown at block  640 . For example, the privacy-processing engine  320  may determine the sensitivity label based on predetermined criteria that identify the types of contents for each label. For example, a social security number may be labeled as ‘block’, which identifies that the transmission of the content is to be blocked. Alternatively, the transmission data that includes content that is deemed safe for transmission may be labeled ‘secure’. Further yet, specific types of content data may be labeled as ‘modify’, which initiates the runtime environment  120  to modify the content before transmission. The modification may be done automatically or by prompting a user to provide replacement content. 
     Once the sensitivity labels of the transmission data are assigned, the privacy-processing engine  320  notifies the runtime environment  120  of the label. If the label indicates secure, the runtime environment  120  sends the transmission data to the firewall  310  for further processing, as shown at blocks  640 , and  644 . Further, if the label indicates that the transmission data is to be modified, the runtime environment  120  generates modified transmission data as secured transmission data, as shown at blocks  640 , and  646 . The runtime environment  120  may forward the secured transmission data, which includes the modified transmission data to the firewall for further transmission, as shown at block  660 . 
     For example, the firewall  310  verifies whether the transmission data meets the preconfigured criteria of the firewall  310 . If not, the firewall  310  may handle the transmission data as potentially dangerous, using preconfigured firewall rules. Else, if the transmission data meets the preconfigured criteria, the firewall  310  forwards the transmission data to the server  160 . The firewall  310 , further, works with the privacy processing engine  320  to determine if the transmission data meets the preconfigured criteria. In addition, the firewall  310  uses the metadata to determine if the transmission data meets the preconfigured criteria. In one or more examples, the firewall  310  is a sole user of the metadata to determine if the transmission data can be transmitted. In such examples, the firewall  310  may be the only device that has access to decryption data that facilitates decrypting the metadata, which may be encrypted by the encryption engine  370 . 
     Alternatively, if the label indicates that the transmission data is to be blocked, the runtime environment  120  may not transmit the data to the firewall  310 , as shown at blocks  640 ,  642 , and  650 . The runtime environment  120  may raise an error and prevent the application  130  from transmitting the transmission data. Alternatively or in addition, the runtime environment  120  prompts the user to review the data transmission request and select whether to continue with the data transmission or to continue blocking the data transmission. 
       FIG. 7  illustrates a flowchart of an example method to facilitate user review of transmission data requests that are labeled for blocking or modifying. For example, if the label from the privacy-processing engine indicates that the transmission data is to be blocked or modified, the runtime environment  120  prompts the user to review the data transmission request and corresponding analysis data, as shown at blocks  710 , and  720 . Else, if the label indicates sending the data unchanged, the runtime environment  120  forwards the transmission data to the firewall  310 , as shown at block  715 , and as described herein. 
     For example, the runtime environment  120  may display an interactive prompt to the user. The runtime environment  120  may display the interactive prompt via the communication apparatus  110  or via the user review device  340 . The interactive prompt may display information about content, as shown at block  722 . For example, the runtime environment  120  may display crowd sourced preference associated with the content. For example, the crowd sourced preference may include a proportion (such as a percentage) of other users that reject (or accept) the sharing of such content, and/or a summary of the crowd-sourced rationale of such rejection (or acceptance). 
     In addition or alternatively, the interactive prompt may display information about the destination of the data transmission request, for example the server  160 , as shown at block  724 . For example, the runtime environment  120  may display information associated with the server  160  retrieved from the crowd-sourced security information server  330 . The information may be retrieved based on an identifier of the server  160 , such as an IP address. For example, the information may indicate a proportion of the other users that reject (or accept) sharing information with the server  160 . For example, the server  160  may be an advertising server, and hence the other users may have opted not to share the information with the server  160 . Thus, the technical solutions facilitate blocking transmission data from being sent to a specific advertising server. 
     In addition or alternatively, the interactive prompt may display information about the application  130  that initiated the data transmission request, as shown at block  726 . For example, the runtime environment  120  may display information associated with the server  160  retrieved from the crowd-sourced security information server  330 . The information may be retrieved based on an identifier of the application, such as a name of the application, an identity of the developer of the application, and other such information associated with the application  130 . For example, the information may indicate a proportion of the other users that reject (or accept) sharing information by the application  130 . 
     Further, based on whether the user-selection indicates to block or transmit a modified version of the transmission data, the runtime environment  120  either blocks the data transmission request or transmits the modified transmission data to the firewall  310 , as shown at blocks  740 ,  742 , and  744 . Alternatively, the firewall  310  generates the modified transmission data based on a request from the runtime environment  120 . Alternatively or in addition, the firewall  310  generates the modified transmission data based on information from the privacy-processing engine  320 , such as by receiving the modifications to be made to the transmission data from the privacy-processing engine  320 . 
     Thus, the runtime environment  120 , via the interactive prompt, facilitates the user to review the outbound transmission data. Together with the analysis results, recommendations from other users, and other metadata associated with the data transmission request, the user can review and select the behavior of the data transmission request, and thus the application  130 . For example, if the crowd sourced statistics indicated that 50% (or more) of the other users replace a User ID being sent by the application  130  to the server  160  with a one-time generated ID, the privacy-processing engine  320  automatically provides such a replacement as a recommendation to the user via the interactive prompt. 
     In addition, the runtime service may keep a log of all outbound data transmissions and facilitate the user to review the outbound data transmissions periodically (for example, every 24 hours, weekly, or any other frequency), and modify future behavior of the outbound data transmissions. 
     In response to the interactive prompt, the user can select to review a subset of the presented data, or a combination of the data. The interactive prompt may further include hyperlinks or other elements to facilitate the user to select whether to block or modify the transmission data. 
     The runtime environment  120  receives a user-selection whether to block the transmission data or to modify the transmission data, as shown at block  730 . For example, in case the user-selection indicates that the transmission data is to be modified, the runtime environment  120  further receives modified transmission data, as shown at block  732 . The user may manually provide modified transmission data. Alternatively or in addition, the runtime environment  120  automatically generates the modified transmission data. For example, content such as identifiers (like social security numbers, phone numbers, etc.) in the transmission data may be modified by assigning a generated trackable unique identifier, such as an identifier generated using a universally unique identifier (UUID) generation algorithm. Alternatively or in addition, if the content points to specific information, the transmission data may be modified so that the modified transmission data includes generalized information. For example, if the content was “Acme Supermarket,” the modified content may be “Acme Plaza,” or a name of the neighborhood, or city, of “Acme Supermarket.” Thus, the runtime environment  120  facilitates replacing a first location identifier in the transmission data with a second location identifier. The second location identifier may be a geographic area or neighborhood that includes the location identified by the first location identifier. Accordingly, the runtime environment  120  facilitates providing generic information in place of specific information. 
     In another example, if the content included a specific time such as 10:20 AM, the modified content may specify a range, such as 10:00 AM-10:30 AM, which includes the specific time. In another example, the transmission data may include a system snapshot, such as a First Failure Data Capture (FFDC), which may include attributes of the communication apparatus  110 . Such transmission data may be modified to eliminate particular information that may be characteristic to how the communication apparatus is used within a specific network, such as an internal network of the business or company to which the user belongs. 
     In an example, the runtime environment  120  indicates to the application  130  that specific content in the transmission data has been modified. The runtime environment  120  may identify the fields of the transmission data that include the content that is tampered. The application  130  may determine whether to continue with the data transmission request using the modified transmission data, or not to send the data altogether. Or, the server can decide to use a modified data, use the modified data differently, use the modified data based on the modification mechanism (for example, Store modified to City) or not to use the modified data. 
     Thus, the technical solutions described herein facilitates monitoring outgoing information from an application at the runtime environment level (such as a JVM™, PYTHON™ INTERPRETER, C RUNTIME LIBRARY™), perform filtering using a combination of user policy, analytics, and crowd sourcing. In exemplary implementations described herein, the runtime environment of a communication apparatus detects and modifies sensitive outbound sensitive information, even before the outbound data reaches a firewall. In addition to information filtering at the runtime environment level, the technical solutions further facilitate the transmission data to be blocked at the firewall, by inspecting the content of the outbound data. In addition, the technical solutions facilitate dynamically modifying the outbound data prior to transmission, and sending modified data in place of the outbound data. 
     Thus, the technical solutions described herein facilitate protecting data, such as personal, sensitive, or private data based on content/context of the outbound data. In an example, the runtime environment initiates modification of the transmission data upon detecting that the transmission data is being transmitted. In other words, the runtime environment enables the application to retrieve and use any data on the communication apparatus, which may be used to provide service(s) to the user, until the application initiates a transmission of data. Thus, only when the application tries to share data, such as with a server, the runtime environment initiates the detection and modification of sensitive information in the data that the application schedules for transmission. 
     Although the description describes the technical solutions being implemented as part of the runtime environment, it will be understood that the technical solutions may be implemented in various other manner such as a programming language, or as part of an existing runtime environment, communication apparatus, and so on. 
     The present technical solutions may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present technical solutions. 
     The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire. 
     Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device. 
     Computer readable program instructions for carrying out operations of the present technical solutions may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user&#39;s computer, partly on the user&#39;s computer, as a stand-alone software package, partly on the user&#39;s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user&#39;s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present technical solutions. 
     Aspects of the present technical solutions are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the technical solutions. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions. 
     These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks. 
     The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks. 
     The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present technical solutions. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions. 
     A second action may be said to be “in response to” a first action independent of whether the second action results directly or indirectly from the first action. The second action may occur at a substantially later time than the first action and still be in response to the first action. Similarly, the second action may be said to be in response to the first action even if intervening actions take place between the first action and the second action, and even if one or more of the intervening actions directly cause the second action to be performed. For example, a second action may be in response to a first action if the first action sets a flag and a third, action later initiates the second action whenever the flag is set. 
     To clarify the use of and to hereby provide notice to the public, the phrases “at least one of &lt;A&gt;, &lt;B&gt;, . . . and &lt;N&gt;” or “at least one of &lt;A&gt;, &lt;B&gt;, . . . &lt;N&gt;, or combinations thereof” or “&lt;A&gt;, &lt;B&gt;, . . . and/or &lt;N&gt;” are to be construed in the broadest sense, superseding any other implied definitions hereinbefore or hereinafter unless expressly asserted to the contrary, to mean one or more elements selected from the group comprising A, B, . . . and N. In other words, the phrases mean any combination of one or more of the elements A, B, or N including any one element alone or the one element in combination with one or more of the other elements, which may also include, in combination, additional elements, not listed. 
     It will also be appreciated that any module, unit, component, server, computer, terminal or device exemplified herein that executes instructions may include or otherwise have access to computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Such computer storage media may be part of the device, accessible, or connectable thereto. Any application or module herein described may be implemented using computer readable/executable instructions that may be stored or otherwise held by such computer readable media. 
     The descriptions of the various embodiments of the present technical solutions have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application, or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.