W3C home > Mailing lists > Public > public-privacy@w3.org > January to March 2015

DOJ asks Google to back off on https

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Wed, 28 Jan 2015 11:24:13 -0000
To: <public-privacy@w3.org>
Message-ID: <3b0101d03aec$f395ad70$dac10850$@baycloud.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I haven't got a subscription but this appears relevant to our discussions. Has anyone got more information?

http://www.lexisnexis.com/legalnewsroom/technology/b/newsheadlines/archive/2015/01/27/doj-atty-joins-call-for-google-to-back-off-data-encryption.aspx

Mike



> -----Original Message-----
> From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
> Sent: 28 January 2015 09:12
> To: 'David Singer'
> Cc: 'Danny Weitzner'; 'Rigo Wenning'; public-privacy@w3.org
> Subject: RE: On the european response to Snowden
> 
> *** gpg4o | Valid Signature from 7331532E2E5E6D89 Mike O'Neill
> <michael.oneill@btinternet.com> ***
> 
> David, comments to your comments inline
> 
> > -----Original Message-----
> > From: David Singer [mailto:singer@apple.com]
> > Sent: 27 January 2015 14:33
> > To: Mike O'Neill
> > Cc: Danny Weitzner; Rigo Wenning; public-privacy@w3.org
> > Subject: Re: On the european response to Snowden
> >
> > Thanks Mike, comments inline
> >
> > > 1) Signalling.
> > > 	We saw a bit of this in the DNT discussions. How to create a signal
> > conveying a user's explicit agreement for something or their preferences for
> > something to one or more entities that may exist across multiple origins, in a
> > secure untamperable way. This may eventually be superseded by:
> >
> > A challenging problem.  These signals and preferences tend to be small, and
> > padding them and then signing them digitally would seem to be using a
> > sledgehammer to crack a walnut.  But maybe the walnut is growing in
> > importance.  Other ideas?
> 
> I was meaning more the general problem of signalling between entities, i.e.
> between the UA acting for an individual and companies which control many
> domains/origins. There are several use-cases that came up in DNT and it
> requires authentication of identity which was also why it will be subsumed into
> point 2.
> 
> >
> > > 2) Anonymity.
> > > 	To ensure privacy we should be able to trawl the net anonymously, but
> > with some identity available through defined transactional processes. For
> > example we may allow a subset of our identity to be discovered by some
> parties
> > we know about and have reached agreement with. This might just be a broad
> > audience categorisation (male, geek, whatever) or it might be more specific
> > (MEP, a particular child's parent, member of a club). Visible identity changes
> with
> > circumstances i.e. I could anonymously apply for a loan or agree to pay for a
> > purchase but I would need to be accountable. My legal identity would have to
> be
> > discoverable in certain agreed circumstances. We may also agree, through
> > membership of a "rule of law" jurisdiction ,that our identity is discoverable by
> > law enforcement under agreed (by society) circumstances.
> > >
> > > This may go beyond HTTP, i.e. IPv6 anon. auto configuration everywhere or
> a
> > new internetworking layer, focus on stopping fingerprinting, and it is a big one.
> > It will need heavy guns.
> >
> > Online anonymity — secrecy — is hard, as you know. ToR is hardly an easy or
> > universal solution. I recently did the thought experiment “what if every router
> > was a NAT box?” — this would mean that IP addresses would be useless as
> > proxies for identity — and the answer is that anonymity would improve but
> > many other things (e.g. phone calls) would suffer. Again, ideas for this would
> be
> > good.
> 
> I think there should be an out-of-band identity exchange, non-trackable i.e. does
> not use UUIDs but established below the tunnel. Maybe in the https handshake
> or in an internetwork layer.
> The identity exchange should be under the control of both parties, but also
> visible to third-parties in defined circumstances for instance when accountability
> or law enforcement is required.
> 
> >
> > > 3) Encryption.
> > >
> > > There is talk about making end-to-end encryption illegal. While this may
> seem
> > silly and is probably a shot across the bows, https everywhere stirs the hornet's
> > nest. I think an answer involves some process whereby https is made more
> > secure (via certificate pinning etc.), available to anyone but that law
> > enforcement is given the means to determine identity through an
> internationally
> > agreed process i.e. along the lines of 2).
> > >
> > > I think any backdooring process will just end up helping the bad guys, so we
> > have full ETO encryption available but if the net can properly ensure privacy
> and
> > security only a minority will need it.
> >
> > So you envisage encryption that is end-to-end and backdoor free, but
> > nonetheless accessible to lawful intercept. Challenging in today’s
> environment,
> > but maybe there is a solution.
> 
> I was thinking more that the identity was visible to lawful intercept, not
> necessarily the encrypted content. But if privacy and security are guaranteed
> without encryption then there would be less need for it. I forgot to mention
> integrity, there should be a way to ensure integrity of the data (such as
> javascript) transmitted between mutually identified parties, without having to
> put everything through an encrypted tunnel.
> 
> >
> > David Singer
> > Manager, Software Standards, Apple Inc.
> >
> 
> Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.4.19.5391 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUyMbdAAoJEHMxUy4uXm2JT/MIANU1HsCIzE0NvqYGBerIZOGm
ccTLlJ5JPs9FqRQ2rmhUVDZ0I8SbhbP0mSiHOMtMkXRJKr6HzTDWgQES4NcUOs2j
qvN5075sbyc/iySfEFqBRYM/nBtYBTMNZRc5Arv5VBCPaJVSfSxqSaEZ3HtD0hbW
L/2McPaw3ZAnEDAU1Dz0mFfdn0f40Gog0EqOFpTUIXC5QuuFiyDmJOKwE5IfOfoH
4Ca9u4DHbyYAKn7H73wP3QfzLQUKNkgwPnH756RM3aGFhpHv/PRVAGhe7utRuPkP
r35134ey75dC+4aP9tNzDka5Vco+Nlk9TDfoGmPMCKr3UhHfu1P7GbWQajLC44o=
=C1+x
-----END PGP SIGNATURE-----
Received on Wednesday, 28 January 2015 11:33:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 28 January 2015 11:33:59 UTC