w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire [Call for Objections] UA requirement to handle exceptions
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: team-tracking-chairs@w3.org
This questionnaire was open from 2014-01-08 to 2014-01-22.
15 answers have been received.
Jump to results for question:
- Objections to Option A: no change
- Objections to Option B: mark feature as optional
- Objections to Option C: add a MUST in introduction
1. Objections to Option A: no change
Option A: no change to editors' draft
No change to existing editors' draft text of the User-Granted Exceptions section.If you have an objection to this option, please describe your objection, with clear and specific reasoning.
Details
| Responder | Objections to Option A: no change |
|---|---|
| Walter van Holst | I object to this option since a mandatory UGE as described contradicts the notion of the DNT signal representing an informed preference. Initiating the UGE does in fact mean that the server considers the received preference not to be tracked as something about which the user may change his or her mind given additional information to be provided by the server. Which implies that the server considers the expressed preference as an uninformed opt-out. |
| Brooks Dobbs | I oppose this option because we need be clear, per Option C, that offering a minimum of two preference options is the only way of establishing a valid preference. Specific reasoning why both options must be mandatory is found as answer to Option B. |
| Sid Stamm | I do not object to the text in the current editor's draft. |
| David Singer | |
| Mike O'Neill | It should be optional for a user agent to support the UGE because it relies on JavaScript to implement it and this may not always be possible. An e-book reader or similar device may not have a JavaScript engine in the first place, and other user agents may have their support for JavaScript disabled by the user for privacy protection reasons. In native mobile applications that are stand alone and not executed within a browser application there also will probably also not be a JavaScript execution capability. DNT has been designed around a simple DNT signal using an HTTP request header and this is just as applicable to native applications in mobile devices as it is to traditional desktop browser based applications. Native apps also use HTTP and not raw TCP because they need to communicate through firewalls and utilise existing HTTP based server farm mechanisms, and so the DNT header signal is just as useful to them. To require UGE supply would be to seriously limit the applicability of DNT to traditional browsers and deny it to native mobile applications or embedded applications such as connected devices (Internet of Things) which are both becoming major ways users interact with the Internet, and both of which primarily use HTTP. I agree that the UGE is useful way for servers supporting browser applications to establish a user's consent for tracking to a specific data controller, different to their general preference expression, which may in be some circumstances be web-wide, but DNT should not be denied to the burgeoning population of devices that are incapable of JavaScript. It would be better for us to define HTTP based mechanisms, such as those based on other headers (like Cookie: or Set-cookie: i.e. well-known cookie names), to extend such fine-grained consent capability to other device types. If the UGE is implicitly or explicitly required it may give some implementers a reason to refuse to honour DNT from particular user-agents by examining the user-agent header, which would seriously weaken it as a useful signal in the eyes of users. I support Option B (the feature should be entirely optional), and object for these reasons to both Option A and C, though between these 2 I would prefer Option A. |
| Rob van Eijk | |
| Bryan Sullivan | Clarification: the current text is silent on whether UGE support is required, so this is effectively the same as Option B. |
| John Simpson | I object to the current draft because there have been numerous conflicting interpretations expressed on the email list about exactly what the text means and what would be expected if a UA couldn't handle exceptions. Clarification is necessary. |
| Brad Kulick | I strongly object to this option because staying silent is functionally equivalent to option B. |
| Shane Wiley | I object to this option as it is no different than Option B. |
| Adrian Bateman | I do not object to the text in the editors' draft, subject to some clean-up such as completing the change from navigator.doNotTrack to window.doNotTrack. IE11 aims to provide an implementation of this spec. |
| Alan Chapell | I object to this option. The current editor's draft is not sufficiently clear - as evidenced by the myriad of interpretations cited on the mailing list. To the extent that this feature is interpreted as optional, I object to it for the reasons expressed in my response to Option B. |
| Jack Hobaugh | I respectfully object to Option A because the User-Granted Exceptions Section (“UGES”) needs additional clarification to (1) provide a balance for the Internet ecosystem to address DNT signals that are not explicitly set by an informed user, (2) require intermediary devices and software to adhere to a user’s informed choice, and (3) provide consistency across the TPE. Balance It is generally acknowledged within the Tracking Protection Working Group (“TPWG”) that the DNT signal cannot be “locked down.” Here, “locked down” means that the server receiving the DNT signal would be assured that the DNT signal has been explicitly set by an informed user without modification from an intermediary device or software. Because the DNT signal cannot be locked down, language should be added to the TPE wherever possible to ensure that an explicit and informed user’s choice is respected by intermediary devices and software. Such language is currently missing from the UGES. Intermediary Devices and Software Must Honor UGEs In its current form, the UGES only addresses user agents. User agents only refer to “any of the various client programs capable of initiating HTTP requests . . . .” (TPE: Section 2.3 Terminology). Thus, there is no language available within the UGES to address how or whether an intermediary device or software (which do not initiate the HTTP requests) should implement a user-granted exception. Indeed, without additional UGES language, an intermediary device or software could turn on the DNT signal without user knowledge or preference, and then not provide a mechanism for granting a user exception. Without the proper balancing language as proposed in Option C, an intermediary device or software that does not provide a UGE capability could advertise itself as being a W3C TPE compliant device or software without providing user choice. The UGES is Inconsistent with the Other TPE Sections that Require a User Choice Also, the UGES needs the additional clarification to be consistent with TPE Sections 3 and 4. TPE Section “3. Determining User Preference” requires that a user agent “MUST offer users a minimum of two alternative choices for a ‘Do Not Track’ preference . . . .” Similarly Section “4.1 Expression Format” dictates that the “tracking preference is expressed as either: DNT meaning 1 This user prefers not to be tracked on the target site. 0 This user prefers to allow tracking on the target site.” It is clear from these requirements that a user must have a minimum of two alternative choices for “Do Not Track,” one that equates to DNT On and one that equates to DNT Off. Further, it is a requirement of the TPE in Section 4.2 that an intermediary device or software should conform to the user’s preference: “An HTTP intermediary MUST NOT add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making the requests.” Thus, it would reason that a user who provides a user-granted exception at the user agent must also have that UGE choice honored at the intermediary level. And to honor that UGE, the intermediary must be able to comply with Section 6: User-Granted Exceptions. In summary, the TPE UGE requirements must be extended to intermediary devices and software for balance and consistency. |
| Chris Mejia | I strongly object to Option A. As I recall, this working group has already decided that User Granted Exceptions (UGEs) need to be required (not optional) in the TPE. This was a nonnegotiable position for industry, advocating on behalf of informed user choice. UGEs work in parallel to the tracking preference indicator (DNT signal), to further enhance a user's expression of choice, and as a necessary balance to the broad sweeping DNT signal setting which is either "on" or "off". The UGE mechanism provides the user with a more granular control tool; a tool that benefits the user. If a UA is asked to persist a DNT request, it must also be able to persist user exceptions to that signal-- otherwise this entire protocol is simply not workable. Accordingly, signals from UAs that do not offer both mechanisms to a user should be considered invalid (not in compliance with this TPE). In Option A, we are asked to essentially stay "silent" on this issue-- which is functionally no different than Option B in this poll (to which I also strongly object). |
| Vinay Goel | If a UA doesn't provide consumers with the ability to express trust in brands/websites they know, the DNT mechanism is ignoring a significant use case. Without support of this use case, the standard would be penalizing websites that have strong privacy practices that some brands employ while also ignoring consumers' preferences to get customized content from certain websites. In addition, by not providing exceptions, the standard will unfairly expect websites to recognize a preference to not track, while not allowing that website the opportunity to recognize preferences for that specific website to track. I would suspect one of two things to happen if support for exceptions is not required: 1) very few consumers select the DNT preference because a website they trust tell them the only way to get the customized content they want is to select DNT:0 for all websites; or 2) companies that employ strong privacy practices will have no incentive/reason to employ competitive privacy features because they are effected the same as untrusted companies. |
2. Objections to Option B: mark feature as optional
Option B: mark feature as optional
Add to beginning of User-Granted Exceptions section:
This feature is OPTIONAL for user agent implementations.
If you have an objection to this option, please describe your objection, with clear and specific reasoning.
Details
| Responder | Objections to Option B: mark feature as optional |
|---|---|
| Walter van Holst | |
| Brooks Dobbs | I oppose this option. If you start by building a choice mechanism that offers only two choices, you cannot allow for a compliant mechanism to present only one of the two potential choices or you have specifically NOT built a choice mechanism. Choice (or establishing a preference) requires, at minimum, two options. The “choice“ not to avail oneself of a mechanism, where the mechanism itself only offers one choice, does not imbue the mechanism itself with two choices. When Henry Ford stated that customers could have their car painted whatever color they wished, so long as their choice was black, no one believed buyers had communicated a preference for black. Not purchasing a car is not equivalent to another color preference, just as failure to enable a DNT signal has not been determined to be equivalent to DNT:0. Lack of meaningful choice has downstream implications. If a site is required to honor a preference, this presupposes that a choice is in fact offered and creates a serious compliance dilemma for the site where it knows no preference choice was offered. If the site MUST honor a preference and receives a signal with reasonable knowledge that no option in preferences was presented to a user, an argument is made that the site is non-compliant by processing any signal (0 or 1) not resultant of the choice presupposed by the standard. Additionally where we make DNT:0 optional we should appreciate that we are making an implicit statement about the appropriateness of the available options relative to each other. It is not the job of a standards organization to prejudice or presuppose a consumer's preference. User’s may very much wish to grant an exception to advertiser data collection rather than pay for content using alternative methods. This is as "valid" a preference as the alternative and must be available as such. |
| Sid Stamm | I do not object to Option B. I've always been a proponent of out-of-band exception management (site maintains UGE data), but understand an in-browser UGE system may be more "sticky" and surely less work for sites. Perhaps it's not important if "OPTIONAL" is in the technical spec, since whether or not DNT is implemented by certain sites may depend on whether a given UA implements this part or not. So I don't think adding "OPTIONAL" makes much of a difference here either way. |
| David Singer | |
| Mike O'Neill | I support this Option. |
| Rob van Eijk | |
| Bryan Sullivan | |
| John Simpson | Clearly marking the text optional allows the specification to be drafted for implementers who wish to develop UAs that contain the feature. It would also allow UAs that don't use Java script to be developed. That seems to me to be something that is necessary. I support this option in the strongest possible terms -- but then I suggested it, you'd expect that. |
| Brad Kulick | I strongly object to this option. The working group has already agreed upon the need and value of user granted exceptions (UGAs) as user choice controls. So this is not a question of whether UGAs are appropriate, but rather whether they are required. UGAs work in conjunction with tracking preference, not only enhancing users' choice control, but providing a necessary balance to the control set available. If a user agent (UA) can persist a DNT signal, it must be able to persist exceptions. If a UA cannot provide both of these controls, they are not providing a balanced choice to the user... and if the choice isn't balanced it would be fair to question whether a choice was really provided. Furthermore, we are working to achieve completion on a technical specification where wide adoption is desired. Reducing the balance within the signaling can only serve to erode at adoption rates. |
| Shane Wiley | I object to this option. Providing balance and parity in an open, voluntary technical standard is critical to its success. DNT is an "all or nothing" proposition as stated today - users simply flip a single switch and DNT is sent to all online parties for all online interactions. This setting is persistent within the browser, will survive upgrades, and where centralized identity is leveraged by a browser, will likely extend beyond a single device. To bring a modicum of balance to this situation, it's imperative that browsers support user generated exceptions WHERE JAVASCRIPT IS SUPPORTED. This will avoid fringe arguments about screen readers that may not support javascript. As we've already seen one browser implement this capability, we know it's possible and goes a far way to bring a small degree of balance back to the DNT equation. This requirement is a MUST. |
| Adrian Bateman | I can live with this option. |
| Alan Chapell | I object to this option. This feature should be a MUST. By all accounts, the DNT protocol is designed to be a) an expression of a User's choices and b) persistent over time. As such, Users need the flexibility to be able to modify their DNT choices - as it seems likely that Users will want to adjust their DNT settings with respect to their favorite websites while keeping DNT in tact for other sites. Given that DNT is persistent is all the more reason for the specification to offer Users with this flexibility. To enable tools that enact DNT but don't offer the capability for User's to create exceptions to tracking is counter intuitive and circumvents the trusted relationship between websites and Users. The FTC has advocated for DNT to be an expression of "consumers choices" - not the expression of a consumers choice. This working group should follow the Commission's lead in this area. |
| Jack Hobaugh | I respectfully object to Option B because user agent implementations cannot be optional and still (1) provide an actual choice to the user needed for balance in the Internet ecosystem, and (2) provide consistency across the TPE. Balance It is fundamentally unfair for a device to support the turning on of the DNT signal without also providing an exception mechanism. And to that end, the User-Granted Exception Section (“UGES”) is not contemplated as an optional section: 6.1 Overview This section is non-normative User-granted exceptions to Do Not Track, including site-specific exceptions, are agreed between the site and the user, and stored by the user agent. A resource ought to rely on the DNT header it receives to determine the user’s preference for tracking with respect to that particular request. An API is provided so that sites may request and check the status of exceptions for tracking. (Section 6.1 of TPE). Indeed, it is well established that the intent, understanding, and previous work of the TPWG has been to add a non-optional exception mechanism to the technical protocol. And the co-chairs have set a precedent that the intent, work and understanding of the TPWG are a significant factor to be considered in analyzing the call for objections: “However, this definition is still more closely scoped to the work and understanding of the Working Group than Option []” (Co-Chairs’ Response to the Call for Objections on ISSUE-5). “Based on these comments received in the Call for Objections, the co-chairs conclude that Option . . . portrays more adequately the intent and previous work of the Working Group.” Id. “This definition is consistent with the common understanding that the group has operated under for most of the past two and a half years.” (Co-Chairs’ Response to the Call for Objections on ISSUE-10). “Moreover, this definition marked a radical departure from the understanding that the Working Group had operated under for a long period of time.” Id. Applying the co-chairs’ precedent for honoring the past work, understanding, and intent of the TPWG, providing a user-granted exception in the TPE must remain non-optional as doing otherwise would be a “radical departure” from the past work, understanding and intent of the TPWG. The only question then remains as to whether intermediary devices and software must also honor UGEs. This question is addressed in Option C. The UGES would be Inconsistent with the Other TPE Sections that Require a User Choice Also, the UGES needs to be consistent with TPE Sections 3 and 4. TPE Section “3. Determining User Preference” requires that a user agent “MUST offer users a minimum of two alternative choices for a ‘Do Not Track’ preference . . . .” Similarly Section “4.1 Expression Format” dictates that the “tracking preference is expressed as either: DNT meaning 1 This user prefers not to be tracked on the target site. 0 This user prefers to allow tracking on the target site.” It is clear from these requirements that a user must have a minimum of two alternative choices for “Do Not Track,” one that equates to DNT On and one that equates to DNT off. Further, it is a requirement of the TPE in Section 4.2 that an intermediary device or software should conform to the user’s preference: “An HTTP intermediary MUST NOT add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making the requests.” Thus, it would reason that a user who provides a user-granted exception at the user agent must also have that UGE choice honored at the intermediary level. And to honor that UGE, the intermediary must be able to comply with Section 6: User-Granted Exceptions. In summary, the TPE UGE requirements must remain non-optional and also be extended to intermediary devices and software for balance and consistency, and to remain consistent with the past work, understanding and intent of the TPWG. Claims that Technology cannot Support a UGE are Misguided A few TPWG participants have expressed concerns that adding a UGE requirement for intermediary devices and software could mean that those devices and software could not implement the TPE in their current configurations. But respectfully, that conception is misguided. Although technical specifications are written with the current technological capabilities in mind, a solid specification does not and cannot take into consideration every piece of legacy equipment resident in the Internet ecosystem. Most, if not all, new technical protocols require at least some modifications by those devices implementing the new protocol. This protocol will be no different. |
| Chris Mejia | I strongly object to Option B. Again, this working group has already decided that User Granted Exceptions (UGEs) need to be required (not optional) in the TPE. This was a nonnegotiable position for industry, advocating on behalf of informed user choice. UGEs work in parallel to the tracking preference indicator (DNT signal), to further enhance a user's expression of choice, and as a necessary balance to the broad sweeping DNT signal which is either "on" or "off". The UGE mechanism provides the user with a more granular control tool; a tool that benefits the user. If a UA is asked to persist a DNT request, it must also be able to persist user exceptions to that signal-- otherwise this entire protocol is simply not workable. Accordingly, signals from UAs that do not offer both mechanisms to a user should be considered invalid (not in compliance with this TPE). |
| Vinay Goel | Same objections as Option A. |
3. Objections to Option C: add a MUST in introduction
Option C: add a MUST in introduction
Add to beginning of User-Granted Exceptions section:
The goal of this protocol is to provide balance in both the setting of the DNT signal and possible user-granted exceptions to that DNT preference. To be compliant with this specification any software that changes user preference requests MUST provide the facility for a server to record granted exceptions utilizing the services described in this section and alter DNT signals for those servers appropriately going forward (DNT: 0).
If you have an objection to this option, please describe your objection, with clear and specific reasoning.
Details
| Responder | Objections to Option C: add a MUST in introduction |
|---|---|
| Walter van Holst | As said in my objection to option A, explicitly requiring support of UGEs in UAs is fundamentally at odds with the workgroup's assumption that DNT:1 must reflect an informed opt-out. If that precondition is met, a requirement of the UGE API implies that a received DNT:1 signal does not necessarily reflect an informed opt-out. Furthermore, this requirement does preclude the use of DNT:1 by users that have audiovisual limitations and for that reason must rely on screen readers that are a) tied to legacy UAs and/or UAs that do not support javascript at all and/or b) often require javascript to be turned off to function properly. As such this requirement would undermine the work that is done in W3C accessibility working groups, if not be in violation of the W3C's charter that speaks of a 'web for all'. |
| Brooks Dobbs | I do NOT object to this. It is only sensible that a choice system be required to offer an actual choice. Preference is not established where there are no competing options. A single choice is a default choice. A default choice does not establish a preference. Compliant origin servers must react to a user established preference. Where no preference can be determined, owing to absence of real choice, implementation problems are sure to follow. |
| Sid Stamm | I object to adding a MUST to this section. As it currently reads, the UGE system is part of the spec, and adding a "MUST provide this" is redundant. This additional text explains how to technically comply with the spec, when technical compliance means "follows the rules defined here". So this new language redundant and clutters up the document. Regardless of how the spec reads, it is the implementers' responsibility to handle partial or technically incomplete implementations of any spec (on either end) and decide how to handle them. The current editor's draft does not state UGE support is optional, so should be considered part of the "feature." |
| David Singer | There is no functional difference between these three user-agents, from the site’s point of view: a) A UA that implements exceptions, but Javscript (JS) is disabled b) A UA That implements exceptions, but the user has told it “I never grant exceptions, so always say no and never ask me” c) A UA that does not implement exceptions. In all three cases, the site does not get the exception that they need. They are required to determine user-consent, so the user is already in dialog: “The call to store an exception must reflect the user's intention to grant an exception, at the time of the call. This intention must be determined by the site prior to each call to store an exception, at the time of the call. (This allows the user to change their mind, and delete a stored exception, which might then trigger the site to explain, and ask for, the exception again). It is the responsibility solely of the site making the call to determine that a call to record an exception reflects the user's informed consent at the time of the call.” There is also non-normative text that suggests that the best practice is to use the ‘confirm exception’ API as the gateway to determine whether to allow the user to proceed and do whatever the exception is required for: "Sites can call the 'Confirm' APIs to enquire whether a specific exception has been granted and stands in the user agent. This is the call to make to determine whether the exception exists, and hence to control access to the function or operation; if it fails (the exception has been deleted, or not yet granted), then the user is ideally again offered the information needed to give their informed consent, and again offered the opportunity to indicate that they grant it. As stated in the normative text, the site needs to explain and acquire consent immediately prior to calling the Store API, and not remember some past consent; this allows the user to change their mind. If they do grant it (using some positive interaction such as a button), the site can return to checking the 'Confirm' API. In this way the site: • does not assume that the storage is instantaneous, and mistakenly grant access when the exception does not (yet) stand; • does not call the Confirm API repeatedly without a user-interaction between each call, in a loop; • permits the user the opportunity to delete a previously granted exception. “ If, after the user apparently consented, the site is unable to record the exception, then it will also be unable to confirm it, and in this flow, will return to asking the user again, and probably noting “Using your current browser and/or settings, I cannot record that you have granted an exception, so I cannot give you [XX]. Please change your settings or browser in order to enable this record and hence access this feature.” There is no technical link between the DNT header, validly derived from the user, and the exception APIs. This is a technical specification and mandates should be justified by a need for correct protocol operation; that if a mandate is not followed, some protocol operation fails. No such protocol behavior exists or is mentioned in the justification. Instead, there is an appeal to some vague concept of “balance”, though this is not explained either (“if it is hard for us, it must be hard for you too”?). This is probably a thinly-veiled attempt to insert a mandate into the specification that some actors want to think will enable them to ignore validly derived and validly expressed user preferences for DNT (using “Disregard”). It is out of place for a technical specification to have mandates solely to enable such behavior. “Disregard” can only be used when the signal itself either cannot be trusted, or cannot be followed; the lack of the ability to record an exception neither makes the DNT header itself untrustworthy, nor does it make it any harder to comply with the DNT header’s request. The lack of an exception should merely prohibit access to the function or feature which cannot be offered without the site having consent to, and being able to, track the user. |
| Mike O'Neill | I object to Option C for the same reasons I describe under Option A. |
| Rob van Eijk | I Object to adding a MUST in introduction with regard to UA requirement of ability to handle an exception request. In accordance with the note in par 6.1, I envision that the exceptions may also be usable as a consent mechanism. I envision a wide range of HTML based devices, including e-book readers and devices that use UA's without interactive JavaScript that assist special groups of users, including the visually impaired. Making it a MUST requirement would disqualify a lot of the special group UA's and exclude these users from benefiting the DNT protocol. Walter has raised this issue on the list and the call. The burden of compliance should not shift to the UA's of special needs user groups. Instead, the burden of compliance should be on the shoulders of the sites. If this issue remains a problem, I suggest to raise an issue where we discuss whether UA's without interactive JavaScript are in or out of scope for the spec. Since we are talking about a MUST in the introduction I do see a different place where it adds to clarity of the section of User-Granted Exceptions: par. 6.1 "A resource (..) particular request" => s/ought/MUST: A resource MUST rely on the DNT header it receives to determine the user's preference for tracking with respect to that particular request. |
| Bryan Sullivan | I object to this proposal. DNT much be supportable for UAs that have no JavaScript support, or are configured to disable JavaScript by the user. |
| John Simpson | This suggestion is totally unacceptable and I object. It introduces the concept of "balance" as a goal of the protocol. This is utter nonsense. The protocol is about expressing user preferences' about tracking. This language is nothing more than an attempt to put language in the specification that would allow servers to ignore a user's clear preference if things were "out of balance" -- whatever that may be. Can we not agree that the TPE ought to be simply about how technically to expressing the user's tracking preference? |
| Brad Kulick | I strongly support this option. |
| Shane Wiley | I strongly support this option for the reasons called out in my objection to Option B (and Option A as being technically the same as Option B). |
| Adrian Bateman | I object to adding text to the spec that implies you only have to do something if the spec says "we really mean this part". If you want to be compliant with the full spec and say you are compliant with the full spec then you have to implement the full spec. Adding a clause to a spec that says "To be compliant with this specification..." doesn't change anything. Either you do something or you don't. In this specific case, we actually allow browsers to choose to prompt users to confirm the exception before storage. This means we allow the user to make the browser not store the exception and not send a DNT:0. That seems at least somewhat in conflict with this statement. |
| Alan Chapell | I support this option for the reasons outlined in my response to Option B. |
| Jack Hobaugh | I strongly support Option C for the reasons stated in my objections to Options A and B. |
| Chris Mejia | I adamantly support Option C. Requiring the User Granted Exception (UGE) mechanism as a "MUST" in this TPE brings much needed balance to the protocol; and it’s a control mechanism that users will expect. Sites will need to be able to register user exceptions with UAs that send DNT preference signals. Otherwise we run the risk of annoying users with a “Groundhog Day” experience where users must grant an exception every single time they visit a site or use a service that doesn’t store their exception preference—that would be a horrific user experience. I hope we are all here to serve the best interests of users, so if that’s true, let’s ensure that users have the tools they need to ensure privacy where requested, and to share data with websites and services they trust. |
| Vinay Goel | I support this option. |
More details on responses
- Walter van Holst: last responded on 14, January 2014 at 19:11 (UTC)
- Brooks Dobbs: last responded on 21, January 2014 at 17:50 (UTC)
- Sid Stamm: last responded on 22, January 2014 at 02:00 (UTC)
- David Singer: last responded on 22, January 2014 at 02:42 (UTC)
- Mike O'Neill: last responded on 22, January 2014 at 03:24 (UTC)
- Rob van Eijk: last responded on 22, January 2014 at 14:34 (UTC)
- Bryan Sullivan: last responded on 22, January 2014 at 18:14 (UTC)
- John Simpson: last responded on 22, January 2014 at 23:57 (UTC)
- Brad Kulick: last responded on 23, January 2014 at 00:51 (UTC)
- Shane Wiley: last responded on 23, January 2014 at 01:38 (UTC)
- Adrian Bateman: last responded on 23, January 2014 at 02:59 (UTC)
- Alan Chapell: last responded on 23, January 2014 at 03:45 (UTC)
- Jack Hobaugh: last responded on 23, January 2014 at 03:48 (UTC)
- Chris Mejia: last responded on 23, January 2014 at 03:57 (UTC)
- Vinay Goel: last responded on 23, January 2014 at 04:23 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project