Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document gives implementors advice on how to protect the privacy of a CC/PP user, and outlines how this can be applied using P3P in HTTP with the CC/PP Exchange protocol.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This document is a very preliminary public Working Draft made available by the World Wide Web Consortium (W3C) for discussion only. It is intended to become a W3C Note. This indicates no endorsement of its content. This is work in progress, may be updated, replaced, or obsoleted by other documents at any time. A list of current W3C working drafts can be found at http://www.w3.org/TR/.
This document is produced by the CC/PP working group (member only) (part of the Device Independence activity). The working group welcomes feedback and discussion, preferably on the public mailing list www-mobile@w3.org, although comments may also be sent to the authors. Public comments and their responses can be accessed at http://lists.w3.org/Archives/Public/www-mobile/.
Not included in this version.
CC/PP data is not in itself personal, i.e. tied to a named user, but since there are a number of ways for the user to be identified as the holder of the profile, e.g. by identity transmision in HTTP parameters, or through recognition of the IP-number or such, there is a need for a suggested privacy method for implementors.
Descriptions of single features in a description of a terminal or the users preferences for how that terminal should be used cannot in themselves be used to infringe on a users privacy. However, when a profile contains a collection of such properties, it can be used to personalize information; the closer the personalization, the bigger risk that the user can be identified from his specific use of the terminal; and the bigger the risk of misuse from a privacy standpoint. There is also a possible risk that a user can be identified as having certain abilities (e.g. if he constantly requests text in double-sized fonts, it is likely that he is hard of seeing), and this may be possible to misuse.
Generally speaking, a user may not want to share some or all of the data in a CC/PP profile, and may wish to have control over who receives that information and when. Origin servers customizing the content should therefore express to the user or user agent regarding their privacy practices with regard to the use of CC/PP data, so that, the user can make a decision on whether or not to share that data with the server.
P3P is a way for an origin server to express the privacy policy it adheres to for the user and/or his terminal. While the match between P3P and CC/PP is not perfect, and while the intent and implementation of the two are different, they can be used together to enhance the privacy protection of the user.
CC/PP is an abbreviation of "Composite Capability/Preference Profiles", and is an extensible format based on RDF [RDF] [RDF-Schema] for describing device capabilities and user preferences. In general, user preferences and device capabilities need to be protected from malicious use but there is no trust management framework for CC/PP so far. Without trust management, sensitive information opens to attacks by malicious servers or content providers.
We do not aim to create new technologies in terms of network security, authentication, message validation, personal privacy protection, and cryptography. We intend to employ the existing technologies in terms of trust management while considering how to apply such technologies well fit into the use cases of CC/PP.
This document is a discussion document, containing implementation advice for developers of services based on CC/PP. It demonstrates the interactions between CC/PP and P3P given the current state of implementations. However, since CC/PP only specifies a data structure and not a protocol, this work should be taken as future input to a formal specification, and currently be seen as advice to implementors only.
There is, currently, no CC/PP protocol. There are a number of proposals, but for various reasons, the group is not chartered to develop a protocol. It will do so as soon as possible, but it does require a rechartering. Meanwhile, there are two proposals: The CC/PP Exchange Protocol, and the W-HTTP protocol.
Note that it would be possible to use the "profile" header Mark Baker suggests in draft-baker-xhtml-media-reg-01.txt and draft-baker-xhtml-media-reg-02.txt to reference a CC/PP profile (the mechanism has been demonstrated by Kiniko Yasuda of Keio University).
There are two main ways of transporting CC/PP over HTTP: Using the CC/PP Exchange Protocol, or using the UAProf W-HTTP Protocol.
The CC/PP Exchange Protocol (CCPP-ex) was presented as a W3C Note on June 24, 1999. It uses the HTTP Extension Framework [RFC2396]. The intent was to provide a framework that was both possible to map into HTTP headers, and that can handle defaults as URIs. The idea was to minimize data transfer over the air, a goal that was accomplished, as has been demonstrated by Kiniko Yasuda of Keio University.
CCPP-ex uses two headers, one for the defaults and one for the updates (profile-diff:s), which are separated using MD5 hashes. A third header carries warning information. The protocol is documented in the W3C Note "CC/PP exchange protocol based on HTTP Extension Framework".
The CC/PP framework is a mechanism for describing the capabilities and preferences associated with users and user agents accessing the World Wide Web. Information about user agents includes the hardware platform, system software, applications and user preferences. The user agent capabilities and preferences can be thought of as metadata, or properties and descriptions of the user agent's hardware and software. The CC/PP descriptions are intended to provide information necessary to adapt the content and the content delivery mechanisms to best fit the capabilities and preferences of the user and its agents.
The major disadvantage of this format is that it is verbose. Some networks are very slow and this would be a moderately expensive way to handle metadata.
There are several optimizations possible to help deal with network performance issues. One strategy is to use a compressed form of XML, and a complementary strategy is to use references (URIs). Instead of enumerating each set of attributes, a reference can be used to name a collection of attributes such as the hardware platform defaults. This has the advantage of enabling the separate fetching and caching of functional subsets. Another problem is to propagate changes to the current CC/PP descriptions to an origin server, a gateway or a proxy. One solution is to transmit the entire CC/PP descriptions with each change. This is not ideal for slow networks. An alternative is to send only the changes.
The CC/PP exchange protocol does not depend on the profile format that it conveys. Therefore another profile format besides the CC/PP description format could be applied to the CC/PP exchange protocol. For example, a user agent issues a request with URIs which address the profile information, and if the user agent changes the value of an attribute, such as turning sound off, only that change is sent together with the URIs. When an origin server receives the request, the origin server inquires of CC/PP repositories the CC/PP descriptions using the list of URIs. Then the origin server creates a tailored content using the fully enumerated CC/PP descriptions. The origin server might not obtain the fully enumerated CC/PP descriptions when any one of the CC/PP repositories is not available. In this case, it depends on the implementation whether the origin server should respond to the request with a tailored content, a non-tailored content or an error. In any case, the origin server should inform the user agent of the fact.
A warning mechanism has been introduced for this purpose. It is likely that an origin server, a gateway or a proxy will be concerned with different device capabilities or user preferences. For example, the origin server may have responsibility to select content according to the users preferred language, while the proxy may have responsibility to transform the encoding format of the content. Therefore gateways or proxies might not forward all profile information to an origin server. The CC/PP exchange protocol might convey natural language codes within header field-values. Therefore internationalization issues must be considered. The internationalization policy of the CC/PP exchange protocol is based on RFC2277.
Considering how to maintain a session like RTSP (RFC2326) is worthwhile from the point of view of minimizing transactions (i.e. the session mechanism could permit the client to avoid resending the elements of the CC/PP descriptions that have not changed since the last time the information was transmitted). However a session mechanism would reduce cache efficiency, and requires maintaining states between a user agent and an origin server. An extension declaration is used to indicate that an extension has been applied to a message and possibly to reserve a part of the header namespace identified by a header field prefix.
The HTTP Extension Framework introduces two types of extension declaration strength: mandatory and optional, and two types of extension declaration scope: hop-by-hop and end-to-end. Which type of the extension declaration strengths and/or which type of the extension declaration scopes should be used depends on what the user agent needs to do.
The strength of the extension declaration should be mandatory if the user agent needs to obtain an error response when a server(an origin server, a gateway or a proxy) does not comply with the CC/PP exchange protocol.
The strength of the extension declaration should be optional if the user agent needs to obtain the non-tailored content when a server does not comply with the CC/PP exchange protocol. The scope of the extension declaration should be hop-by-hop if the user agent has a priori knowledge that the first hop proxy complies with the CC/PP exchange protocol.
The scope of the extension declaration should be end-to-end if the user agent has a priori knowledge that the first hop proxy does not comply with the CC/PP exchange protocol, or the user agent does not use a proxy.
The Profile header field is a request-header field, which conveys a list of references which address CC/PP descriptions.
The grammar for the Profile header field is as follows:
Header field | Grammar |
Profile | = profile-field-name ":" 1#reference |
profile-field-name | = "Profile" |
reference | = <"> ( absoluteURI | profile-diff-name ) <"> |
profile-diff-name |
= profile-diff-number "-" profile-diff-digest |
profile-diff-number | = 1#DIGIT |
profile-diff-digest | = sp; < MD5 message digest encoded by base64 > |
DIGIT | = <any US-ASCII digit "0".."9"> |
The Profile header field-value is a list of references. Each reference in the Profile header field represents the corresponding entity of the CC/PP description.
A reference is either an absolute URI or a profile-diff-name. An entity of a CC/PP description which is represented by an absoluteURI exists outside of the request, and an entity of a CC/PP description which is represented by a profile-diff-name exisits inside of the request (i.e. in the Profile-Diff header field. The profile-diff-name in the Profile header field addresses a CC/PP description in the corresponding Profile-Diff header within the same request.
When the Profile header field includes a profile-diff-name, the corresponding Profile-Diff header MUST be included within the same request. The main reason why the profile-diff-name is introduced is to specify the priority of each CC/PP description in the Profile header field-value. The priority is indicated by the order of references (i.e. absoluteURI or profile-diff-name) in the Profile header field-value. The latest reference in the Profile header field-value has the highest priority.
Therefore a CC/PP description which is represented by the latest reference can override CC/PP descriptions which are represented by the precedent references. This is the default behavior in the absence of schema rules. All profile information could be represented by absoluteURIs in the Profile header. In this case, the Profile-Diff header field does not have to be added to the request. On the other hand, only one Profile-Diff header can contain all profile information. In this case, the Profile header includes only the profile-diff-name which indicates the Profile-Diff header.
The WAP Forum UAProf group has defined a transport for CC/PP over W-HTTP (Wireless Profiled HTTP). It can be found in section 9 of the UAProf specification. In the case where the mobile terminal supports wireless profiled HTTP the profile is transported using meta data defined by this specification. The CC/PP Framework remains unaltered. The defined mechanism provides a functional equivalent for the CC/PP exchange protocol [CCPP-ex] but the definition of the syntax and semantics of the transport remains in this specification.
The following extension headers are defined to transport CC/PP in W-HTTP. The defined extension headers are considered to be end to end headers..
The x-wap-profile header is a general header field which MUST contain the following :
·a URI referencing the CC/PP profile, or
·a reference to a profile difference, transported using the x-wap-profile-diff or
·a combination of multiple instances of these two types of data. This data MAY be generated by the mobile terminal or attached by an intermediary point in a request to an origin server.
In the case of Push this header MAY be generated as a response to a request. In the case of Push this data may be cached. However this header MUST be present in any request or response when UAProf is used.
The x-wap-profile header MAY contain references to instances of the x-wap-profile-diff header (defined in the following section ). Each reference contains two parts, the sequence number and the profile-digest. The sequence number is used to determine the order of how the x-wap-profile-diff headers should be applied and the digest is used to validate that the profile-desc in the x-wap-profile-diff header value is correct.
The x-wap-profile-diff header is a general header and MAY be generated by the mobile terminal or an intermediate proxy to enhance or alter the CPI. There may be multiple profile differences, each profile difference must also have a reference in the x-wap-profile header which indicates the order in which differences should be applied. This header contains two parts, a sequence identifier and the entity which represents the part of the CC/PP description that is being enhanced. This header MAY be present in a request or response. In the case of Push this data may be cached.
The x-wap-profile-warning header is a general header. Essentially, it is the same as the X-WAP-PROFILE-WARNING header in the CC/PP Exchange Protocol. Its presence indicates the level to which the response has been tailored in relation to profile data that has been supplied in the request. This header MAY be present in a request or response. The warning codes that are defined fall into the following categories :
·1xx - reserved
·100 -- reserved
·2xx - indicates whether the content has been adapted depending on the profile
·5xx - indicates the server is incapable of processing CPI.
The x-wap-profile-warning may have the following values.
200Not applied
This value MUST be included if the content has not been tailored, and is sent in a representation, which is the only representation available in the server.
201Content selection applied
MUST be included if the included content has been selected from one of the representations available.
202 Content generation applied
MUST be included if the content has been tailored or generated as a result of applying the included profile.
203 Transformation applied
MUST be added by an intermediate proxy if it applies any transformation changing the content-coding based on the CPI data.
500Not Supported
Indicates that the entity sending this warning code does not support UAProf.
In this transport variant the headers and their values are not compressed for over the air transmission. It is recommended that the hardware and software manufacturer only use the x-wap-profile header to indicate an absoluteURI as the reference for CPI for the mobile terminal when transmitted over the air. However this specification does not preclude the use x-wap-profile-diff in this case.
If the x-wap-profile-diff header is included the profile-diff-seq MUST match a sequence number in the x-wap-profile header otherwise the associated profile-diff-desc MUST NOT be processed. The reference to each x-wap-profile-diff header contains two parts, a sequence number which governs the order in which the x-wap-profile-diff headers are processed and an MD5 message digest which is used to validate the profile-desc which is contained in the x-wap-profile-diff. If either the sequence or the MD5 validation do not match, the particular profile-diff MUST be ignored.
If the x-wap-profile-diff header is added by an intermediate proxy, it MUST NOT alter the existing sequence of x-wap-profile-diff headers, the proxy MUST append using the next available sequence number in numeric order. The digest associated with an x-wap-profile-diff MUST be generated by applying MD5 message digest algorithm [RFC1321] and base64 algorithm, section 6.8 in the MIME specification [RFC2045] to the corresponding profile-desc part of the header field-value.
The MD5 algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. The base64 algorithm takes as input arbitrary binary data and produces as output printable encoding data of the input.
The profile information referred to in the x-wap-profile and x-wap-profile-diff header does not supersede HTTP request or response header information.
The x-wap-profile-warning header MUST NOT be used for cache control purposes. If a server wishes to indicate a caching dependency based on these headers then hit should use the Vary header as defined in section 14.44 of the HTTP 1.1 specification [HTTP/1.1].
How CC/PP will be transported and handled in of XML Protocol/SOAP is not clear. This is something the working group wishes to investigate further.
The WAP Forum has provided a mapping to the headers of WSP, the Wireless Session Protocol (defined in the WAP UAPROF specification). Work is also ongoing in 3GPP to transport CC/PP over RSVP.
Since CC/PP is intended to be protocol neutral, it will work with any protocol which can transport it. Mappings have been produced for other protocols, most notably WSP. However, it is to be expected that it will be implemented for HTTP, using HTTP headers as a transport. The working group also intends to look at the transport of CC/PP over SOAP/XML Protocol as a future work item.
Policy publishing does not bring trust by itself. Trust has to be obtained in other ways, before it is even worth the trouble to publish a policy. In this context, P3P should rather be seen as a means to retrieve the user's consent for data storage and/or processing. It enables the client to retrieve a policy declaration from the server, and match this with the preferences of the client. However, P3P is not defined for other protocols than HTTP. No other mechanisms exist, to our knowledge, to communicate policies between client and server. Note, however, the known problem that P3P does nothing to enforce the policy - this is assumed to take place out of band.
In the document CC/PP exchange protocol [CCPP-ex] based on HTTP Extension Framework [HTTPext], a mechanism to transport CC/PP over HTTP is described. This document describes how that interaction could take place, given a P3P interaction as well.
Before a policy can be exchanged, the client must request it from a server. If this is not a proxy in a trusted domain, the client will expose his profile to a possibly malicious party if the CC/PP Exchange Protocol is used, since the profile is sent in its entirety with the first GET request. Thus, a malicious server could take this profile and do anything it wanted with it, since no relationship has been established.
One solution to this is to transmit a minimal profile as part of the first request, as described in [PEMI]. When the policy has been received and approved, a full profile is sent (as a profile-diff). Note that if the policy is rejected, there is currently no way for the server to maintain a state over users requests, and there is no way for the server to recognize that the client does not approve of the policy, since there is no fallback method in P3P.
Note that it is possible for the profile declared to be a null profile (i.e. without content), and the correct profile to be transferred as a diff upon approval of the servers policy. Note also that the state management mechanism in the server is currently is not specified. It should be possible to use cookies for this, although the ramifications of a discussion of this would lead too far.
The interaction with P3P might have two levels of granularity:
a) where the privacy policy includes all CC/PP vocabulary [generic statement stating that all data in the profile and profile diff headers will not be retained or misused, or will be used only for the purposes of content customization]
b) where the policy specifically states what attributes (data elements) from the CC/PP vocabulary is collected and state the purpose. This can be extended at a later date to include negotiation capabilities (which is currently out of the scope of P3P1.0) or alternately, the user agent can be smart enough to parse these elements out and send only those attributes (as indicated in the policy) in the profile and profile diff headers following the acceptable of the site's policy.
The P3P vocabulary is defined in XML. The CC/PP vocabularies are defined in RDF (using the XML encoding of RDF). The P3P specification [P3P] declares that an RDF encoding will be made available; when this happens, P3P elements can be used inside CC/PP profiles (and vice versa). For further information on mixing namespaces in profiles, see [CCPP] and [CCPP-vocab]. Since this effort has been advertised, the CC/PP working group has decided not to create any mapping of their own, but await the P3P working group efforts. An alternative solution is to create a CC/PP data schema in the P3P syntax, but that would seem redundant if an RDF version of P3P is forthcoming. The two working groups will continue to investigate this.
4.1.2.2 Safe Zone
The P3P specification defines a concept of a "safe zone". This concept does not exist a priori in CC/PP, since no protocol has been defined. However, the PIMI method as described in section 5.1 can be used to provide a safe zone in the way that is indicated in the P3P specification, section 2.4.3. As noted above, an empty profile can be used while negotiating within the safe zone, instead of a minimal one.
4.1.2.3 APPEL
No rules language is defined for CC/PP. Existing implementations make use of XSLT to predicate transformations (using Xpath, profile documents can be addressed from within a style sheet). In the future, it is foreseen that there will be a need for a more extensive rule system, such that decisions can concern not just the formatting, but the content itself as well. In that regard, synergies with the APPEL rules language for P3P could be investigated.
In the CC/PP Exchange protocol, profiles can be referenced and retrieved by an intermediary (a gateway or other proxy). It is also possible that this entity could handle the P3P negotiations, if a mechanism to delegate authority to it existed, and end-to-end security was not required. This may occur in situations where the user is in a trusted domain, which is interfaced with the Internet through the proxy or gateway.
In this case, the P3P negotiation will be terminated in the proxy. It will also be necessary for the proxy not just to keep a cache of documents, but to maintain a database of user state. It may even be necessary for the proxy to become the entity which performs not just transcoding, but also personalization on behalf of the origin server.
The advantage for the user of this would be that the personal information - including the CC/PP profile - stays in the trusted proxy. The advantage for the origin server owner is harder to identify, since the version of the document which has to be delivered will have to be "universal", and there will not be any record of the number of retrievals, who retrieved it, etc (which, conversely, can be seen as a privacy enhancement for the user).
As this type of system continues to emerge, e.g. in the scope of the IETF WEBI and APEX working groups, we foresee that the issue will become more important. However, since the mechanism is transparent to HTTP, and since it can be for CC/PP, we will not discuss it to any further extent here.
The idea behind the PIMI method is that the client has defined a minimal profile with non-contentious information (which cannot be used to infringe on the privacy of the client). This minimal profile is used in an initial request to get the privacy policy of the server. As demonstrated below, using the profile-diff headers of the CC/PP Exchange protocol, it becomes possible for the client to signal satisfaction or dissatisfaction with the policy by returning a profile difference or not. In response to the empty diff, the server can provide a document which does not contain the adaption which would have been done using the information which the client will not reveal.
What constitutes a "minimal profile" is most likely subjective. Ultimately, the user will have to determine what information he or she wants to give out. However, for the purposes of discussion, we will assume that the properties which enable a generic display and data input on the device, without expressing any preferences and without any modifications, will constitute a minimum. That would imply the following, using the properties defined by the WAP UAProf drafting committee:
Screen size
Color capable
In this document, we propose that an empty diff be sent as response (in a second GET), which would imply that the profile has not changed. Depending on the implementation, the server could return a document containing a different information set than the user would have got if he had accepted the policy; or returned nothing. This is not specified in the P3P specification, and out of scope for the CC/PP work.
This would apply when the client initially contacted the server during a session. During the rest of the session, it would be able to refer to the policy first retrieved, or to follow-up policies which can be added later during a session (using the LINK tag in HTTP, using a well-known location, or an HTTP header).
The interactions would look as follows:
1. Client sends request with minimal profile to server. This request can be directed to the well-known location of the P3P reference file, /w3c/p3p.xml. It can also be directed at another location, if this has been indicated in a LINK tag in a document that references this server. The reference file is returned. After that, another request will retrieve the policy file.
2. Server returns policy.
3. Client reads policy and matches against own rule set
3'. Client approves policy, sends diff with full information (or a GET with full information directed at the URI where the document resides, if the policy was retrieved from the well-known or LINK-ed location).
4'. Client receives document
3". Client rejects policy, resends request with empty diff
4". Client receives less important document.
With protocol interactions, this would look as follows:
1. Client sends request with minimal profile to server.
GET /a-resource HTTP/1.1 Host: www.w3.org Opt: "http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=19 19-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg==" Accept: */* Accept-Language: de, en
2. Server returns policy.
HTTP/1.1 200 OK P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml" Content-Type: text/html Content-Length: 7413 Server: CC-Galaxy/1.3.18
3. Client reads policy and matches against own rule set
(not shown)
3'. Client approves policy, sends diff with full information
GET /a-resource HTTP/1.1 Host: www.w3.org Opt:"http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=19 19-Profile:"http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg==" 19-Profile-Diff-1: <?xml version="1.0"?> <RDF xmlns="http://www.w3.org/TR/PR-rdf-syntax" xmlns:PRF="http://www.example.org/TR/WD-profile-vocabulary#"> <Description ID="SoftwarePlatform" PRF:Sound="On" /> </RDF>
4'. Client receives document
(not shown)
3". Client rejects policy, resends request with empty diff
GET /a-resource HTTP/1.1 Host: www.w3.org Opt:"http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=19 19-Profile:"http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg==" 19-Profile-Diff-1:
4". Client receives less important document
(not shown)
[HTTPext] HTTP Extension Framework
[CC/PP] Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation
[RDF] Resource Description Framework, (RDF) Model and Syntax Specification
[RDF-Schema] Resource Description Framework (RDF) Schema Specification
[P3P] Platform for Privacy Preferences P3P Project
[RFC2396] RFC 2396 : Uniform Resource Identifiers (URI): Generic Syntax
[CCPP-ex] CC/PP exchange protocol based on HTTP Extension Framework
[PEMI] Privacy Enhancements in the Mobile Internet, Mikael Nilsson, Helena Lindskog, Simone Fischer-Huebner, Karlstad University.(PDF format)
[CCPP-vocab] W3C Note, CC/PP Implementers Guide Harmonization with Existing Vocabularies and Content Transformation Heuristics, to be appeared.
Appendix
The basic requirements for the CC/PP trust management framework, which were discussed in the 1999 version of this document, are listed below.
For example, a user agent first sends non-private profile data to a server, which then responds with a privacy policy, as a result of which, the user agent may either choose to send or not send any additional (private) information to the server for the purposes of receiving tailored content.
This is an analysis of how the proposed use of P3P would fulfill the basic requirements for the CC/PP trust management framework (section 3).
Fulfilled, provided no private information is transmitted..
Protocol dependent. Not possible in the examples given.
Fulfilled, provided APPEL, a similar rules language, or a proprietary solution in the device, can be applied to profile construction (or various profiles can be selected). I.e. not in this version.
Not fulfilled (P3P can be used with other protocols than HTTP, as noted in the specification, but how has not been specified). .
For example, a user agent first sends non-private profile data (or an empty profile) to a server, which then responds with a privacy policy, as a result of which, the user agent may either choose to send or not send any additional (personal) information to the server for the purposes of receiving tailored content.
Fulfilled.
Fulfilled
Fulfilled, if the method above is used..
Fulfilled (although this is actually a strange requirement)
Not fulfilled.
Fulfilled? (Not sure)
Not sure what this requirement means.
Fulfilled.
Not fulfilled (since proxies can still be transparent).