Patent Description:
Privacy is becoming a major industry concern as more wireless transmit/receive units (WTRUs) are connected directly or indirectly to the Internet. Ubiquitous connectivity, together with poorly secured protocol stacks and a lack of privacy education of many users makes it easy to track/monitor the location of users and/or eavesdrop on the users' activity. Many factors contribute to this phenomenon, such as the vast digital footprint that users leave on the Internet (e.g., sharing information on social networks, cookies used by browsers and servers to provide a better navigation experience, connectivity logs that allow the tracking of a user's layer-<NUM> (L2) or layer-<NUM> (L3) address, and the like) and/or weak (or even null in some cases) authentication and encryption mechanisms used to secure communications.

Internet privacy has also become an important topic after several recent incidents of widespread and pervasive Internet surveillance have been revealed. Users have become aware of the fact that their communications, habits, and routines may be followed without their consent by different commercial, criminal, and governmental organizations. This issue has created mistrust of the Internet and may affect the acceptance of Internet technology.

For example, a device, and its associated owner, may be tracked by observing the device's Layer-<NUM> (L2) and/or Layer-<NUM> (L3) address communications. L2 addresses may be observed by a third party. The third party may be the operator of the access infrastructure, a passive device listening to communications in the same network, for example over-the-air transmissions performed by <NUM> Wi-Fi devices, and the like. In an <NUM> network, a station (STA) may expose its L2 address in various situations. For example, when a STA is associated with an access point (AP), the L2 address is used in frame transmission and reception, as one of the addresses used in the address fields of an <NUM> frame. In another example, when a STA actively scans for available networks, the L2 address is used in probe request frames sent by the STA.

Traditional L3 address assignment techniques, such as the Internet Protocol version <NUM> (IPv6) stateless auto-configuration techniques (SLAAC), generate the interface identifier (IID) of the address from its L2 address (via the <NUM>-bit Extended Unique Identifier (EUI-<NUM>)), which then becomes visible to all peers with an active IP communication. This visible IID allows for the tracking of a device at L3. The prefix part of the address may also generally provide the physical location of the device, which together with the L2 address-based IID, allows for global device tracking.

Privacy cannot be completely provided by a single communication layer in isolation, as open hooks in other layers may affect the user's privacy overall. The use of temporary addresses, opaque IIDs or even the use of random L2 addresses (as some operating systems do when performing active scanning), may partially mitigate the privacy threat, however these techniques do not completely address all privacy issues.

Privacy concerns affect all layers of the protocol stack, from the lower layers involved in actual access to the network (e.g., the L2/L3 addresses can be used to obtain the location of a user) to the application layers, especially when browsing or getting involved with social networks (e.g., cookies may be used to find out the identity of a user accessing a particular webpage or website). Document <CIT> is a relevant document in the field of privacy concerns affecting L2/L3 addresses.

The invention is disclosed in the independent claims <NUM>, <NUM>, <NUM>, and <NUM>. A method for use in a wireless transmit/receive unit (WTRU) for configuring a privacy protocol stack profile, including private addresses for the WTRU is described herein. The WTRU may determine if it is in an unknown or untrusted location and may set a profile of the WTRU to public network, and may set the MAC and IP addresses and other protocol identifiers to random, opaque and non-persistent. Alternatively, the WTRU may determine it is in a known and trusted location and may set a profile of the WTRU to home or office. The WTRU may then set the MAC and IP addresses and other protocol identifiers to permanent and well-known values. Alternatively, the WTRU may determine it is at an untrusted but known network where a persistent identifier is required. The WTRU may set a profile of the WTRU to authenticated hotspot and may set the MAC and IP addresses, and other protocol identifiers, to random, opaque but persistent.

The method also includes receiving information about neighboring networks by a privacy manager. The privacy manager may then determine privacy profile options based on the context of the neighboring networks, location, etc. The privacy manager may then display available privacy profile options based on the determination. The privacy manager may then receive a selection of a profile, which may be sent via a user input or a network policy. The privacy manager may then instruct each layer of a protocol stack with privacy and security settings based on the selected privacy profile. Alternatively, the privacy manager may select the privacy profile based on a policy.

As shown in <FIG>, the communications system <NUM> may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) <NUM>, a core network <NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer (PC), a wireless sensor, consumer electronics, and the like.

The communications systems <NUM> may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network <NUM>, the Internet <NUM>, and/or the other networks <NUM>. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like.

The base station 114a may be part of the RAN <NUM>, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). In another embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

<FIG> is a system diagram of an example WTRU <NUM>. As shown in <FIG>, the WTRU <NUM> may include a processor <NUM>, a transceiver <NUM>, a transmit/receive element <NUM>, a speaker/microphone <NUM>, a keypad <NUM>, a display/touchpad <NUM>, non-removable memory <NUM>, removable memory <NUM>, a power source <NUM>, a global positioning system (GPS) chipset <NUM>, and other peripherals <NUM>.

The RAN <NUM> may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN <NUM> may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface <NUM>. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in <FIG>, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

The core network <NUM> shown in <FIG> may include a mobility management entity gateway (MME) <NUM>, a serving gateway <NUM>, and a packet data network (PDN) gateway <NUM>.

The MME <NUM> may be connected to each of the eNode-Bs 140a, 140b, 140c in the RAN <NUM> via an S1 interface and may serve as a control node. The MME <NUM> may also provide a control plane function for switching between the RAN <NUM> and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

The serving gateway <NUM> may be connected to each of the eNode Bs 140a, 140b, 140c in the RAN <NUM> via the S1 interface. The serving gateway <NUM> may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway <NUM> may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

Other network <NUM> may further be connected to an IEEE <NUM> based wireless local area network (WLAN) <NUM>. The WLAN <NUM> may include an access router <NUM>. The access router may contain gateway functionality. The access router <NUM> may be in communication with a plurality of access points (APs) 170a, 170b. The communication between access router <NUM> and APs 170a, 170b may be via wired Ethernet (IEEE <NUM> standards), or any type of wireless communication protocol. AP 170a is in wireless communication over an air interface with WTRU 102d.

The methods and apparatuses described hereinafter may be deployed in a network as described above, or any other network known to one of skill in the art. As used in the embodiments described hereinafter, a WTRU may include, but is not limited to, a STA, an AP, a laptop PC, a smartphone, a server, or other communication device capable of operating in a network.

Privacy techniques, such as those set forth in request for comment (RFC) <NUM> and RFC <NUM>, work in a non-coordinated fashion, which limits the effectiveness of these privacy techniques. Generally, privacy should be tackled at all layers to avoid privacy information leaking. Privacy techniques should also be flexible, allowing for automatic, pseudo-automatic, or manual privacy protection activation. In some cases, a permanent address may be required, for example due to operational operations (e.g. address-based authentication, access control lists, and the like). Therefore, privacy techniques should allow for enabling and disabling the use of privacy mechanisms depending of the context, such as the location of the device or the characteristics of the network where the device is attaching.

RFC <NUM>, entitled Privacy Extensions for Stateless Address Auto-configuration in Internet Protocol version <NUM> (IPv6), identifies and describes the privacy issues associated with embedding L2 stable addressing information into IPv6 addresses (as part of the IID). RFC <NUM> also describes some mechanisms to mitigate the associated problems. RFC <NUM> is meant for IPv6 nodes that auto-configure IPv6 addresses based on the L2 address (EUI-<NUM> mechanism).

RFC <NUM> also defines how to create additional addresses (generally known as temporary addresses) based on a random interface identifier for the purpose of initiating outgoing sessions. These random or temporary addresses are meant to be used for a short period of time (e.g. minutes, hours, or days) and are then deprecated. Deprecated addresses may continue to be used for already established connections but are not used to initiate new connections. New temporary addresses may be generated periodically to replace temporary addresses that expire. In order to do so, a node may produce a sequence of temporary global scope addresses from a sequence of interface identifiers that appear to be random in the sense that it is difficult for an outside observer to predict a future address (or identifier) based on a current one, and it is difficult to determine previous addresses (or identifiers) knowing only the present one.

Temporary addresses should generally not be used by applications that listen for incoming connections (as these applications are generally waiting on permanent/well-known identifiers). If a node changes networks and comes back to a previously visited one, the temporary addresses that the node would use may be different, and this may be an issue in certain networks where addresses are used for operational purposes (e.g. filtering or authentication in a corporate network, or access to a paying network where access has been purchased for a certain time as done in some hotels).

RFC <NUM>, entitled a Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Auto-configuration (SLAAC) describes and defines a method for generating IPv6 IIDs to be used with IPv6 SLAAC, such that an IPv6 address configured using this method is stable within each subnet, but the corresponding IID changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on L2 addresses, such that the benefits of stable addresses may be achieved without sacrificing the security and privacy of users.

The method defined to generate the IPv6 IID is based on computing a hash function, which takes as input information that is stable and associated to the interface (e.g. L2 address or local interface identifier), stable information associated to the visited network (e.g., IEEE <NUM> SSID), the IPv6 prefix, and a secret key, plus some other additional information. This generally ensures that a different IID is generated when any of the input fields change (such as the network or the prefix), but that the IID is the same within each subnet.

RFC <NUM>, entitled Host Identity Protocol (HIP) Architecture, proposes a new host identity namespace, and a new protocol layer, being the HIP, between the internetworking and transport layers, which inherently provides some privacy features. However, this protocol has not seen market adoption and the potential to make it widely used for Internet communications is minimal.

L2 address randomization is one example privacy feature. The Institute of Electrical and Electronics Engineers (IEEE) <NUM> addressing includes one bit to specify if the hardware address is locally or globally administered. This allows generating local addresses without any global coordination mechanism ensuring that the address is unique. This feature may be used to generate random addresses and therefore may make a user device more difficult to be tracked from its L2 address. This feature is partially being used by some devices. These devices may be enabled to use random addresses during active WiFi probe scanning.

L2 address randomization is a powerful tool that may become an industry standard to make user tracking more difficult. However, as it has to be selectively enabled/disabled, a default "always on" or "always off" policy may not be enough. For example, many networks use L2 address access filtering as part of their security policy or use it to identify allowed users in a public hotspot (i.e. once the user provides the required credentials on a captive portal, an L2 address may be used to identify and authorize the user). In this scenario, L2 address randomization may have to be performed more carefully.

Methods may be used to mitigate and/or tackle some privacy and/or security threats. However, there is also a need for the coordination of different actions taken at different layers in the protocol stack. This is because privacy is a global issue, and as such, it is hard to solve this issue by tackling it locally at different layers without proper coordination among them. For example, it may not be enough to only randomize L2 addresses, as L3 addresses and identifiers, such as the ones used by dynamic host configuration protocol (DHCP), might also disclose information allowing an attacker to find out the user's location and identity. Another example is the use of cookies, which may be disabled to avoid unwanted user profiling.

There is also a need for flexibility and dynamic adaptation. For example, a policy that involves L2/L3 address randomization may be appropriate when connecting to a public untrusted network, but might not be appropriate when the user is accessing a corporate network. Similarly, using and storing HTTP cookies may be suitable on certain sites (or when browsing logged in by a certain account) but may not be for others.

There is also a need for enhanced configurability. For example, privacy and security mechanisms may be configurable and customizable, taking into account multiple inputs, such as user's preferences, WTRU administrator preferences, network context, geo location, and the like. These inputs may imply different actions regarding how to configure the protocol stack to provide privacy. For example, the user may want to enable L2/L3 randomization when connecting to every network using their corporate laptop, but an administrator of the corporate laptop may have a policy that imposes the use of fixed and well-known L2/L3 addresses because of authentication and logging reasons. Another example would be to prefer using browser incognito mode when accessing certain sites, or using transport layer security (TLS) by default on certain networks.

Privacy profiles may also be used. In order to provide comprehensive privacy features to (e.g. wireless) internet users, a contextual configuration of the protocol stack may be employed. Features may be enabled (or disabled) in different parts of the protocol stack. These features may provide a much better result than when applied in an uncoordinated manner (in which case the results can become counterproductive). Different connectivity scenarios (or profiles) that may be applied to enable/disable different stack privacy features depending on the network context may be used.

Scenarios with different privacy requirements are described in the embodiments herein. These serve as examples to show how context influences the privacy settings for the entire protocol stack.

Connectivity scenarios are described herein. An important piece of context may come from the network to which the WTRU is attached. For example, the privacy context may vary when connecting to a corporate or home network where the access infrastructure is relatively private and trusted, and to a public hotspot at a coffee shop, or even at a known hotel. Connectivity scenarios that are involved in the embodiments described herein include, but are not limited to the following:.

The specific WTRU used by a user to access a given service may be important. For example, using a public PC that is shared by many different people may impose additional privacy requirements than using a corporate laptop or a personal PC at home. Examples of scenarios from the WTRU point of view that are involved in the embodiments described herein include, but are not limited to the following:.

Another dimension to be considered includes application scenarios. For certain applications, disclosing some information may not be critical (e.g., corporate applications), while for other applications, it may be desirable to increase privacy when using them (e.g., social networks). Of course, the importance of the application used has to be linked with other pieces of context, such as the WTRU, and the network (e.g., a corporate application might require more privacy protection when running outside the corporate network).

The methods that may be enabled at each layer of the protocol stack may be combined in different ways depending on the context and preferences of the different actors involved. The term "context" is used to refer to the information that may be used to take a decision at a given place and time for a given user and service. The following are examples of "context":.

The above list is not intended to be exhaustive or limiting in any manner and is provided just as an example.

The term "actors" refers to the entities that may trigger an action or take an active decision maker role when selecting the privacy mechanisms to be used. The following are examples of "actors":.

The above list is not intended to be exhaustive or limiting in any manner and is provided by way of example.

Methods and apparatuses for protocol stack extensions providing a context-aware protocol stack that flexibly enables privacy protection depending on the environment (e.g., context) and different preferences (e.g., user's, admin's, network's, and the like) are described herein. The methods and apparatuses described herein not only address the network connectivity in a static manner, but they also provide a framework that provides a fully configurable, flexible and dynamic protocol stack configuration that may provide different levels of privacy. Privacy and security may be provided at different layers of the protocol stacks. This may be accomplished by enabling different features at different layers of the protocol stack, with the goal of making the behavior of the whole system (e.g., from PHY to APP layers) suit a given set of privacy requirements.

Providing privacy and security to a user when accessing a service may not be the responsibility of one single layer of the protocol stack. The methods and apparatuses described herein address many different aspects of privacy and security in many different ways, are flexible, and address different use cases because not all the situations/use cases may require the same type of actions.

Methods and apparatus for managing privacy by taking context and preferences into account are described herein. <FIG> is a diagram of an example context-aware privacy protocol stack architecture and application programming interfaces (APIs) <NUM> enabling privacy protection in accordance with one embodiment, which may be used in combination with any of the embodiments described herein. The actors involved in the example of <FIG> include the applications <NUM>, the user <NUM>, and the administrator <NUM>.

The example of <FIG> also shows the configurations that may be performed at each layer of the protocol stack including but not limited to the following examples:.

Physical layer (L1/PHY) <NUM>: At this layer, methods such as encryption may be used. Profiling based on passive monitoring may also be minimized by randomizing parameters that may be changed at each connection. Examples of randomization at L1 that may make it more difficult to conduct WTRU profiling include but are not limited to: not always using or preferring to use the same technology/frequency (e.g., <NUM>. 11a vs <NUM>) when connecting to a multi-technology/band access point, changing the preferred rates negotiated when establishing the connection, and the like.

Link layer (L2/MAC) <NUM>: At this layer, the L2 (MAC) address may be randomized, encryption at L2 may be used (e.g., WPA/WPA2), authentication may be used, untrusted or non-encrypted networks may be black listed, active scanning may be minimized, and the like.

Network layer (L3/NET) <NUM>: At this layer, the L3 address (IP address) may be randomized, internet protocol security (IPsec) may be used, a virtual private network (VPN) may be used, parameters used for DHCP signaling may be anonymized, and the like. For example, the DHCP identifiers, such as hostname of client ID may be anonymized or randomized.

Transport layer (L4/TRA) <NUM>: At this layer datagram transport layer security (DTLS), TLS, other variations of TLS, TCP security, UDP security, secure sockets layer (SSL), and the like may be used.

Application layer (L5/APP) <NUM>: At this layer Domain Name System Security Extensions (DNSsec) may be used, application privacy methods such as "incognito mode" (e.g. not using previously stored cookies, nor storing any upon exit, and/or not storing browsing history) and other restrictions on cookies may be used, connections between apps and social networks may be prevented, updating a status at given locations by wearable WTRUs may be blocked, HyperText Transport Protocol Secure (HTTPS) (based on transport layer security) may be used, valid web certificate use may be enforced, and the like.

<FIG> also shows the interactions among each entity. The privacy manager <NUM> and connection manager <NUM> may reside on a WTRU of the user. Alternative locations (e.g. on a dedicated secure server/cloud) are also possible, as long as the connection between the different layers of the protocol stack, the connection manager, and the privacy manager are properly secured. It should be noted that the privacy manager <NUM> may be a logical construct used to host the intelligence required to coordinate the privacy features of the protocol stack and collect context information from the different actors. The methods and apparatuses described herein may also apply to other kinds of solutions not involving a privacy manager <NUM> but still offering the same kind of functionality.

Applications <NUM> may indicate application preferences to the privacy manager <NUM>. The user <NUM> may configure user preferences with the privacy manager <NUM> and connection manager <NUM>. The administrator <NUM> may configure policies with the privacy manager <NUM> and connection manager <NUM>. The privacy manager <NUM> and connection manager <NUM> may synchronize policies. The privacy manager <NUM> also may configure the protocol stack, and the protocol stack may provide context information to the privacy manager <NUM>. The connection manager may manage connectivity with the protocol stack. The network <NUM> may provide context information such as public or private network information to the protocol stack.

The privacy manager <NUM> may offer different privacy profiles to the user <NUM>, each implying different sets of configurations at each layer of the protocol stack. These profiles depend on the context, i.e. some profiles may only be available under certain scenarios and/or may behave differently based on the context. Each profile may contain a specific set of preferred (or default) parameters, avoiding the manual intervention of less technical users that may not be aware of the privacy risks that exist in each specific context. The privacy manager may automatically select a default privacy profile to be used and may offer the privacy profiles available to the user, which may select a different one.

Context-based privacy address configuration mechanisms may also be used in the architecture described above. The privacy address configuration mechanisms described herein may allow users to manually override any automatic decisions, for example by selecting a type of address generation that is to be used. The level of granularity may be all the contexts or specific contexts.

A context-based privacy address configuration may be based on an automatic selection of the type of privacy address generation scheme. The scheme may adapt to the context of the device in order to provide the required flexibility to meet all the requirements imposed by the privacy concerns of the user (i.e. user preferences) and by the potential operational constraints imposed by the specific network context.

The following are some non-limiting example methods for context-based privacy address configuration based on manual configuration/profiles:.

Context-based privacy address configuration may also be based on information provided by a trusted entity of the network (e.g. a local entity or a central entity). For example, information available on the generic advertisement service (GAS), the access network query protocol (ANQP), or generic <NUM> beacons, may be used to automatically decide which privacy address generation scheme may be used. Similarly, the device may consult trusted repositories or policy databases (e.g., the access network discovery and selection function (ANDSF)), and dynamically learn what to do which may include but is not limited to determining which context to apply.

Context-based privacy address configuration may also be based on information provided by auto-configuration mechanisms, including but not limited to DHCP, neighbor discovery (e.g., based on information contained on router advertisements), point-to-point protocol (PPP), domain name server (DNS), and the like. In this case, some level of trust with the network element may exist in order to apply the policies recommended via these mechanisms. Otherwise, any network node may have a negative impact on the privacy address scheme used by the device.

In any of the examples described herein, in which the device does not know which approach to use before gaining connectivity, the device may follow a default conservative approach when first attaching to the network, such as setting up a private session. For example, the device may use a randomized L2 address and a random and opaque IPv6 IID, and then may reconfigure if a different scheme is required. It should be noted that this default conservative approach may also be configurable and different approaches may be used depending on some existing context information. For example, if the device is aware that a captive portal is being used to complete some user authentication, the device may know that the randomized L2 address may need to be persistent on that network at least during the lifetime of the authentication performed by the user. The lifetime of this connection may be indicated by the network or manually configured by the user.

In the case of Wi-Fi networks (and similar wireless local area network (WLAN) and wireless personal area network (WPAN) technologies), the former considerations mainly affect the L2 address generation for association and authentication with an access point (AP) and the subsequent data transmission.

For active scanning (based on sending probe requests), similar considerations may be applied, defining context-based approaches.

Another protocol interaction that poses privacy concerns is IP configuration via DHCP. For example, DHCP clients include the "hostname" or "client ID" in the DHCP exchange, so the server can perform updates on the DNS on behalf of the clients. The inclusion of the "hostname" in DHCP signaling is an example of a privacy leak that may be prevented. Therefore, similar to the scenarios described before, the protocol stack may make use of the privacy context to decide whether or not to include parameters such as the "hostname" or "client ID" in the DHCP signaling.

Likewise, higher protocols may benefit from the privacy context definition. For instance, publishing an IP address and hostname in the DNS (registry), HTTP cookies, and in general unencrypted web browsing, especially when using social networks, may be done differently when operating in a private context. Several protocol layers may make use of the privacy context to decide whether to include sensitive information or not.

<FIG> is a diagram of an example privacy context-based protocol stack enabling context-based privacy configuration of addresses and other protocol identifiers and parameters. <FIG> provides examples of the API interaction at each layer of the protocol stack L1 (PHY) <NUM>, L2 (MAC) <NUM>, L3 (NET) <NUM>, L4 (TRA) <NUM>, and L5 (APP) <NUM>. Addresses may be locally managed and configured based on the type of network detected and information received about the network. In the example of <FIG>, if the device recognizes that it is at a public or unknown location, the profile may be set to a public network, such as Bob@Airport <NUM> indicating a public network. The MAC address may be set to random, opaque and non-persistent, as shown by @MAC_rand_addrX <NUM>. Similarly, the IP address may be set to random, opaque and non-persistent as shown by @IP_addrY <NUM>.

Another example may be a profile used when connecting to the corporate network of the user or the home network of the user, in which permanent and well known L2/L3 addresses are used (often to authenticate the user/WTRU) and end-to-end security may be established by default at the network or transport layer. In the example of <FIG>, if the device knows that it is at home (e.g. by geolocation), the profile may be set to home, such as Bob@Home <NUM> indicating a home network. The MAC may be set to permanent and well-known, as shown by @MAC_addr_Bob <NUM>. The IP address may be set to permanent and well-known, as shown by @IP_addr_Bob <NUM>.

In another example, a profile may exist for an untrusted public network such as the one deployed in a hotel. This profile may select a random L2 (random MAC address) address for the initial connection (so no association of the identity of the user may be performed based on observing the used addresses), select random identifiers when using DHCP to acquire the IP configuration, and avoid any dynamic update of DNS while attached to this network. For example, the DHCP identifiers, such as hostname or client ID may be anonymized or randomized. On the upper layers, the privacy manager might offer the user different options regarding the use of cookies, for example entering a privacy mode by default. In the example of <FIG>, if the device knows it is at an untrusted network where a persistent identifier may be required (e.g. for authentication) the profile may be set to authenticated hotspot, such as Bob@Hotel <NUM> indicating an untrusted network where a persistent identifier may be required. The MAC address may be set to random, opaque, but not persistent, as shown by @MAC_rand_addrW <NUM>. The IP addresses may be set to random, opaque, but not persistent, as shown by @IP_addrZ <NUM>.

<FIG> is a signaling diagram of an example operation using a context-based protocol stack <NUM>. In the example of <FIG>, a WTRU <NUM> of a user is about to attach to a network <NUM>. Prior to any kind of connection taking place, the administrator <NUM> of the WTRU may have configured a set of default policies/preferences, which may then be taken into account when configuring the protocol stack. Referring to <FIG>, different actors are shown: the WTRU <NUM> of the user, the administrator <NUM> (admin) of the user's equipment (the administrator <NUM> may be the user itself, for example, in the case of a home computer), the network <NUM>, privacy manager <NUM>, and connection manager <NUM>. The different layers of the protocol stack are also shown: L5/APP <NUM>, L4/TRA <NUM>, L3/NET <NUM>, L2/MAC/RRM <NUM>, and L1/PHY <NUM>.

In the example of <FIG>, prior to any kind of communication, the administrator <NUM> may pre-configure policies <NUM> on the privacy manager <NUM> (e.g., (<NUM>) always use VPN when outside the corporate network with L2/L3 address randomization, (<NUM>) use well known L2/L3 addresses when connecting within the corporate network, and the like). In each connectivity scenario, the different layers of the protocol stack, L5/APP <NUM>, L4/TRA <NUM>, L3/NET <NUM>, L2/MAC/RRM <NUM>, and L1/PHY <NUM>, may provide to the privacy manager information about supported privacy and security mechanisms and settings <NUM> (e.g. L2 address randomization support, IPsec support, etc.). The connection manager <NUM> may obtain information about neighboring networks <NUM>. The connection manager <NUM> may then provide the information about neighboring networks to the privacy manager <NUM>. Other context information (such as geo-location for example) may also be used by the privacy manager at this stage.

With the context information, the privacy manager <NUM> computes available profile options based on context, administration policies, network, information, etc. <NUM>, and may take into consideration the limitations and preferences of the different involved actors. The privacy manager <NUM> may then provide the user (WTRU <NUM>) with the available profile options for the context <NUM>. The user (WTRU <NUM>) may then choose a profile or a default profile for that specific context that may be used if the user (WTRU <NUM>) does not select any specific profile <NUM>. Additionally or alternatively, the privacy manager <NUM> may decide independently the profile to be applied in this specific context without interacting with the user. Then the privacy manager <NUM> may then instruct each layer of the protocol stack with the right privacy and security settings as specified by the chosen profile <NUM>, which may be done via interaction with the connection manager <NUM>. It should be noted that a profile may imply different privacy settings at different layers (e.g., "use incognito mode when browsing foo. net or any new site, but not when browsing company. As shown in <FIG>, the privacy manager <NUM> may instruct an L1/PHY configuration, such as "use modulation x" <NUM>. The privacy manager <NUM> may instruct an L2/MAC configuration, such as "use random address" <NUM>. The privacy manager <NUM> may instruct an L3/NET configuration, such as "use random DHCP parameters" <NUM>. The privacy manager <NUM> may instruct a L4/TRA configuration, such as "use TLS with connection X" <NUM>. The privacy manager <NUM> may instruct an L5/APP configuration, such as "use virtual keyboard" <NUM>.

<FIG> is a flow diagram for an example procedure <NUM> to enable selection of a profile such as a privacy profile for use in the privacy manager, which may be located within a WTRU and may be used in any of the embodiments described herein. The privacy manager within the WTRU may receive information about neighboring networks <NUM>. This information may be sent by the connection manager or be sent from another network source and received by a receiver or transceiver of the WTRU. The privacy manager within the WTRU may then determine privacy profile options based on the context of the neighboring networks <NUM>. This determination may be computed by a processor of the WTRU. The privacy manager within the WTRU may then display available privacy profile options based on this determination <NUM> in order to enable a user to view and select available privacy profile options. The available privacy profile options may be displayed on a display device of the WTRU. The privacy manager within the WTRU may then receive a selection of a privacy profile <NUM>. The selection may be received from an input from the user of the WTRU. Alternatively, the privacy manager may determine the privacy profile selection, for simplicity or convenience to the user, or based on a policy and guidelines of the policy. The privacy manager within the WTRU may then instruct each layer of the protocol stack with privacy and security settings based on the selected privacy profile <NUM>. The selected privacy profile may include a different configuration at each layer of the protocol stack. The privacy and security settings instructions may be transmitted via a transmitter or transceiver of the WTRU or sent to another entity within the WTRU that has an interface to the network. The instructed privacy and security settings may be based on any of the examples described herein.

In another example, the user may select a network and adjust a privacy profile based on the selected network. In this procedure, the privacy manager within the WTRU may receive information about neighboring networks. This information may be sent by the connection manager or be sent from another network source and received by a receiver or transceiver of the WTRU. The privacy manager within the WTRU may then select a network from the plurality of networks. This selection may be based on a determination by a processor of the WTRU. The privacy manager within the WTRU may then adjust a privacy profile based on the context of the selected network. The context may be based on the received information associated with the selected network. The privacy manager within the WTRU may then instruct each layer of the protocol stack with privacy and security settings based on the adjusted privacy profile. The privacy and security settings instructions may be transmitted via a transmitter or transceiver of the WTRU or sent to another entity within the WTRU that has an interface to the network. The instructed privacy and security settings may be based on any of the examples described herein.

The embodiments described above support various use cases. In an example use case, a user may use her work laptop and personal phone, both equipped with the privacy mechanism described herein. Three exemplary locations (showing different contexts) may be considered:.

The above description is an example demonstrating how the profiles may change between WTRUs and locations (and available networks). Depending on the context and involved actors, different situations may take place.

As described above, the profiles offered to the user may be dynamically computed based on the context information (e.g., current location, account used to log in, network connectivity, capabilities of the protocol stack layers, and the like) and the preferences/limitations imposed by the involved actors. These profiles imply actions that may affect each protocol stack layer, e.g., not only being restricted to L2/L3. The privacy manager may not offer the same set of predetermined profiles to every user at any location, but rather may take into account context and actors' preferences to generate a customized set of profiles dynamically and/or automatically.

Claim 1:
A method for use in a wireless transmit/receive unit, WTRU, the method comprising:
selecting a privacy profile based on a context at least dependent on an active scanning for use by the WTRU, wherein the privacy profile includes privacy and security settings for a plurality of layers of a protocol stack of the WTRU, wherein the privacy and security settings include using a random medium access control, MAC, address, and at least one of (<NUM>) using anonymous dynamic host configuration protocol, DHCP, signaling parameters, the anonymous DHCP signaling parameters including an anonymous hostname, or (<NUM>) using a random Internet protocol, IP, address;
instructing the plurality of layers of the protocol stack of the WTRU with the privacy and security settings based on the selected privacy profile;
transmitting a probe request to one or more networks available to the WTRU, the probe request including a MAC address configured in accordance with the privacy and security settings of the selected privacy profile; and
in accordance with the privacy and security settings of the selected privacy profile:
transmitting a DHCP message to acquire an IP configuration, the message including the anonymous hostname; or
setting an IP address of the WTRU to the random IP address.