- From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
- Date: Thu, 11 Jul 2013 21:43:55 +0300
- To: <Frederick.Hirsch@nokia.com>
- Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, <public-privacy@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This also reflects my experience. Getting this difference between generic building blocks and the complete system across is crucial but incredibly difficult (particularly when talking to non-technical people). While we like to believe that we are in full control of everything (as standardization experts) we have to realize that is not even close to the reality. The Internet development process is quite complex and a very distributed (+ often unpredictable) process. Similarly as you, Fredrick, I also think that there is a lot of value in providing guidance and to gain a better understanding of what can be done from a standardization point of view regarding privacy. That's why I have been spending so much time on this privacy considerations document in the IAB. Often, the biggest challenge is to make others understand that they are making tradeoff decisions. I have run into a number of scenarios during the last 1-2 years where a significant loss in privacy protection was considered acceptable compared to the value that was gained with the proposed functionality. Still, almost everyone argued in favor of maintaining the functionality and against investigating other solution alternatives. My expertise is mostly with the IETF (and not with the W3C); I am sure the W3C is not any better in that regard (just to get that point clear). I think if I get document authors to understand that they make a tradeoff decision and capture it in their documents I believe we would already be a major step forward. For others I might be aiming for goals that are not ambiguous enough. Maybe I have just been involved too long in standardization.... On Jul 11, 2013, at 9:18 PM, <Frederick.Hirsch@nokia.com> wrote: > On today's PING call we mentioned that it is sometimes difficult to get specification groups to devote the time and resources to performing privacy assessments and that some flexibility is required. > > In the course of chairing DAP I've observed that the specification process includes two groups that are not always the same (but with some overlap): > > 1. The working group producing the specification > > 2. Implementers and adopters of the specification. > > In order to advance a specification to standard some number of implementers will need to participate in interoperability testing to advance beyond CR but the exact criteria are decided by the working group (e.g. the number of implementations, the degree of testing etc) > > I've also observed (and contributed this as a position paper in one of the earlier W3C privacy workshops) that specifications tend to cover only a portion of an overall system, being a component or module that can be composed into a variety of larger systems. Usually data retention etc may be relevant in that larger system, for example. This can make it hard or impossible for a working group to perform much of an assessment, depending on the size and complexity of the individual specification. > > Frank mentioned incentives for performing assessments. It seems these often directly apply to organizations creating complete systems for a business purpose. > > Thus, while it is valuable and important for working groups to note privacy considerations, often the implementers are the ones that are in the best position to consider an entire system and have the incentives to perform the assessment work. > > For this reason I think we can expect to see informative notes in specifications (referring to an earlier email from Nick) as implementers expect latitude based on the overall system. > > As a concrete proposal, from a W3C perspective I wonder whether we should encourage implementers to share privacy assessment information before exiting CR, similar to sharing interop results? > > regards, Frederick > > Frederick Hirsch > Nokia > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR3vzrAAoJEGhJURNOOiAt1MQH/1Gq/9GLYPcmJz6azwQBddXc I2IVbJG/W7H1SAcu9TsB8ql0l7q8DHgJ3kq0sJGO9Fwl/9brWZeXvvVp0kTBwdD1 Jk0CWTIT3lAD30QK101+nticAXK6v1XyeL69pqo+mSJdGfGCL+KsQoELCAiFLZLS R+kmL+mkNLAUm+ggvgenJuXjRBz5fd4VhyPH8EuEVBPlp8mhrq24xRXviDm9kvLc SvVNqTOSPWtIReKwFI26BJNWQpkArljhBi41T/ZLjv+XgH1nnLiykHr840T1pg0b x/7ZjRbzMRYIpJRDo9wWIEabBKfzT8RgRV7qBG7ZlluD2lSSqM9plrEg5BIMKhg= =Xo6H -----END PGP SIGNATURE-----
Received on Thursday, 11 July 2013 18:44:25 UTC