Re: [arch-d] <draft-lazanski-consolidation-00>
Christian Huitema <huitema@huitema.net> Thu, 12 November 2020 16:18 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4732C3A1384 for <architecture-discuss@ietfa.amsl.com>; Thu, 12 Nov 2020 08:18:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSxp1MlPG-GM for <architecture-discuss@ietfa.amsl.com>; Thu, 12 Nov 2020 08:18:40 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F12E3A1382 for <architecture-discuss@ietf.org>; Thu, 12 Nov 2020 08:18:39 -0800 (PST)
Received: from xse477.mail2web.com ([66.113.197.223] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kdFIu-0007va-AB for architecture-discuss@ietf.org; Thu, 12 Nov 2020 17:18:38 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CX6GY2wtsz53BK for <architecture-discuss@ietf.org>; Thu, 12 Nov 2020 08:18:29 -0800 (PST)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kdFIr-0006Q3-9P for architecture-discuss@ietf.org; Thu, 12 Nov 2020 08:18:29 -0800
Received: (qmail 27017 invoked from network); 12 Nov 2020 16:11:48 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.90]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <architecture-discuss@ietf.org>; 12 Nov 2020 16:11:48 -0000
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>, Martin Thomson <mt@lowentropy.net>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
References: <3B4C73E8-1215-43CB-B969-56A2554F1348@lastpresslabel.com> <2bfceb63-1b94-de6f-72e8-4d80eef356f5@digitaldissidents.org> <c18b290b-b0c1-4056-b678-3f07475279c0@www.fastmail.com> <MN2PR11MB4366ED6DFF38BE9663C9AF04B5E80@MN2PR11MB4366.namprd11.prod.outlook.com> <76dada1c-652b-4d4d-8b7f-ba836660c1d0@www.fastmail.com> <f81060f0-56cf-2ad2-4ccf-f0324890261f@huitema.net> <1455858417.18508.1605192383942@appsuite-gw1.open-xchange.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <b96fd124-a2e7-e7e3-e2d2-d8dde34bcda5@huitema.net>
Date: Thu, 12 Nov 2020 08:11:50 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <1455858417.18508.1605192383942@appsuite-gw1.open-xchange.com>
Content-Type: multipart/alternative; boundary="------------D2085F4983AADEFEFA2FD346"
Content-Language: en-US
X-Originating-IP: 66.113.197.223
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0cThwnZT+ODcFyeCwCHoUjupSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX72RtenPYdNk8FG35Wb7HiAFO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKPxtCheh5C7lovH0u37yux7G8pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pVPbmg7CD5DvTXFdlFnYu62DYH7JT8ICzD3ld7Lkg0SVZ1+rsC5ZGVYG+AECQYSXUVY dGBMwvH1Yva9EPhd1Mo0MYjMUqZL6iBLUS97OHj8b53ugII7ouYCgfwcsP8qn8jymNgFzWRkuRvd 2hsh/DKjJTkETFTHdBwnk7JDmeUy/GQ+48t7tOgPZxfWe3xH0dE14O9uIBc4R2FHvu2iptL1qPwK bbuRXw5Q3vRBmasazU4vidrAbzPztKfs4s5XguL2uhT3KQx41zCmSSvPnIYmCmnFEKPAYhTMxt8K 3A07ru3E7PNP9hZ2YPyDLCAHXnUsy647Mn0zwmGzAi3Zn+Ydr38cN0L29hpYqOQomv/Sn4OJCdFr QGG66XtzjgLUDW/OzgRwsx26JIrnuz41QdUugEEc+Eql4Tj+X3YkLe5buSZuZ5OAUoGBziSYFLZu u6wUZYupFCxOQUA2Zz77xVbE
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/d22BykjfjYfy3sw9bejzW0qrL6Y>
Subject: Re: [arch-d] <draft-lazanski-consolidation-00>
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 16:18:42 -0000
On 11/12/2020 6:46 AM, Vittorio Bertola wrote: > >> Il 12/11/2020 04:29 Christian Huitema <huitema@huitema.net> ha scritto: >> >> >> On 11/11/2020 4:37 PM, Martin Thomson wrote: >> >>>> I am more concerned about the loss of privacy that seems to be >>>> occurring at the application layer via extensive tracking of users and >>>> sharing of user information, rather than my perception of what is now >>>> occurring at the network layer. >>> A totally legitimate concern, but that line of argumentation sounds like whataboutism. Improvements in privacy with respect to the network do not drive privacy violations at the application layer. >> >> What Martin says. The draft is supposedly about consolidation. There >> is definitely a relation between concentration and privacy: if >> traffic gets consolidated on a small number of big platforms, the >> owners of these platforms see a lot of data and metadata, which >> affects privacy. But the relation between that and end-to-end >> encryption is tenuous. For example, Google was getting just as many >> cookies before web pages started being sent over HTTPS. The >> differences is that before encryption other actors were also able to >> read these cookies. That was hardly a better privacy posture. >> > I note one big risk to privacy that is generated by the introduction > of end-to-end encryption, together with the IoT and cloudification > trends: end-users - not just network administrators - lose the ability > to scrutinize what their applications and devices actually send to > their makers, or - in case of self-masquerading technologies like DoH > - even to detect that a communication is happening and to block it if > they want so. There was a talk about this at the IETF 105 plenary: > https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sesse-lessons-from-privacy-measurement-arvind-narayanan-00 Device inspection is an interesting issue, but it is far to being as clear-cut as you present it. Take the example of a doorbell camera. It sends motion activated video streams to a cloud server, from which they can be accessed by the home owners using their cell phone. If the traffic was in the clear, inspection would reveal exactly that: motion activated video streams to a cloud server. It will not reveal whether the cloud servers provide a copy of the video streams to the police. It will not tell whether the servers perform face recognition on the incoming images, and use that for tracking the movement of people walking nearby. Encryption will prevent that inspection, but it will also prevent third parties from tapping into the video stream and performing their own parasitic surveillance. From a privacy point of view, encryption there is a net gain -- but the presence of the devices themselves may well be a huge loss. The inspection performed by researchers revealed that some devices where performing extra tasks, not described in the public specification of the device. Maybe a child's toy also sending data about the children to its manufacturer. Inspection by researchers has revealed such shenanigans in the past, and the inspection was typically done by breaking the device encryption using spoofed server certificates. Should we then recommend that all devices should accept spoofed server certificates? That would be opening the gates to a free-for-all of hacking and banditry. It would also not solve the "cloud connection" problem shown with the doorbell cameras. The device problem is real, but the solution certainly is not to make the devices easy to break by third parties. Instead I would rather see consumer bureaus stepping in and providing "clean device" certification labels, after inspecting devices and services in which the protections have been lifted by the manufacturer. Or, law enforcement could step in and severely punish device manufacturers engaged in deceptive practices, either on the device or in the cloud servers. > > Indeed, one of the side effects of DoH for some (more technical) users > is to disrupt their Pi-holes and other DNS-based tracker blockers. > > Consolidation underpins all of this, as in the "surveillance > capitalism" business model whoever has more opportunities to acquire > information wins. There is definitely a relation between surveillance capitalism and consolidation, but you don't need to discuss the encryption of communication to make that point. -- Christian Huitema > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com <mailto:vittorio.bertola@open-xchange.com> > Office @ Via Treviso 12, 10144 Torino, Italy
- Re: [arch-d] <draft-lazanski-consolidation-00> Niels ten Oever
- [arch-d] <draft-lazanski-consolidation-00> Dominique Lazanski
- Re: [arch-d] <draft-lazanski-consolidation-00> Martin Thomson
- Re: [arch-d] <draft-lazanski-consolidation-00> Rob Wilton (rwilton)
- Re: [arch-d] <draft-lazanski-consolidation-00> Vittorio Bertola
- Re: [arch-d] <draft-lazanski-consolidation-00> Eric Rescorla
- Re: [arch-d] <draft-lazanski-consolidation-00> Martin Thomson
- Re: [arch-d] <draft-lazanski-consolidation-00> Christian Huitema
- Re: [arch-d] <draft-lazanski-consolidation-00> Christian Huitema
- Re: [arch-d] <draft-lazanski-consolidation-00> Vittorio Bertola
- Re: [arch-d] <draft-lazanski-consolidation-00> Christian Huitema