[Ohttp] OHTTP applications I've seen
Watson Ladd <watsonbladd@gmail.com> Wed, 28 July 2021 06:17 UTC
Return-Path: <watsonbladd@gmail.com>
X-Original-To: ohttp@ietfa.amsl.com
Delivered-To: ohttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34D63A1F23 for <ohttp@ietfa.amsl.com>; Tue, 27 Jul 2021 23:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 C7Ll_t-np2lz for <ohttp@ietfa.amsl.com>; Tue, 27 Jul 2021 23:17:27 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A893A1F20 for <ohttp@ietf.org>; Tue, 27 Jul 2021 23:17:27 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id ga41so2696820ejc.10 for <ohttp@ietf.org>; Tue, 27 Jul 2021 23:17:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=J9IJ5g3QLZTP/iOQEKcbgzbK7M9rwWSL945+wMuKOYc=; b=IlZRyZ9/ZuwmRFOXpBs0x30dpKlCH9GUVboWypif5ecVDE5QYvHeHW0ipvbxfS1GN+ Cvm9oqxrlntBshnVtOBp6v2j08jZp0v75b41GRi75mExFYpfKXjO6rKh4/78HUHDnO7n 5QNU4BR2f2xwDMti61Iyp6WXy72bR3PIzkeEYqp5Sx+eRhM4r00FhnATUpxoP18MNHxD yG7qj/nseXBpblaW1WiJRqSEgK9frXweilXDL5SIPo58xrUn34VI8i011OPNwCDSAl3o a5J05bLGQsVZvYXMQokevIkCsJxzlhIgEKerWOa0MCAZpYaUD8QT8I9UhLPp2rSWWk62 wlCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=J9IJ5g3QLZTP/iOQEKcbgzbK7M9rwWSL945+wMuKOYc=; b=m3qOfHqYct709DpVOj+WOax5P2A1eyGDt5ZjGER64B6HXAfNuN7BAGA230fflRnHSv mqnH3Z/aWOBYCBj0FN9RyJpvjNyiMC960nO0s+9B6/pmLxp2+/YIECGAQfUF8PQSJwbo zi6zEdnUtcaK0w1NnT31Z3EvRvpqQM2sdXgWrXL4D3gwWFYLQJi2N3jMoJh11liuOOoP VpWxUvzOjYDiIDX3j5OLq6EWWAEqOA3huOIBrqGGgD1ynkQbDzNIgTV9t4QguxvqU4eN LNCCEOUIjqPjLNrJsl+FZvyHsDmI/+GFfcgOqxDbo9edpm2osRjyJxhpxFh+5dU2Dm8e A4iA==
X-Gm-Message-State: AOAM533yON9+Ro5xKs58kJ70DbwTF1l3QadwlHQvTh2+RplO4q3soVKr bHlT2+7z4H3ymmrbt18LY5on5ALlDxTt4v1SOmTy3rz4
X-Google-Smtp-Source: ABdhPJy5jfLBUSDL2ciRHdB+5/G6SJQSH8gx7CCjuSnuYoNaCIAb/Qr36KwwQS7a5nkGKvm3wxlTIZixSrb6KpNJ1Ig=
X-Received: by 2002:a17:906:2bd3:: with SMTP id n19mr2247762ejg.232.1627453044118; Tue, 27 Jul 2021 23:17:24 -0700 (PDT)
MIME-Version: 1.0
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 27 Jul 2021 23:17:12 -0700
Message-ID: <CACsn0ckC9trR_HsFfn37=+rTTBhe-Z_hGiZJZ6GWPXiS_eanZw@mail.gmail.com>
To: ohttp@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/XN6mMVTDxV8u6ZkVc4MTJe0zCEY>
Subject: [Ohttp] OHTTP applications I've seen
X-BeenThere: ohttp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Oblivious HTTP <ohttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ohttp>, <mailto:ohttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ohttp/>
List-Post: <mailto:ohttp@ietf.org>
List-Help: <mailto:ohttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ohttp>, <mailto:ohttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jul 2021 06:17:29 -0000
Back in 2015 Matthew Green, Ian Miers, and I came up with a privacy preserving advertising system that was completely impractical to deploy. We solved the impression reporting issue thanks to application of Groth-Kohlweiss and some implementation tricks, but we could not serve the creative in a privacy preserving way. Our paper cited PIR, private information retrieval. The PIR lower bound comes from an elementary observation that the response has to depend on the entire database. It's a slow process, and completely insuitable for deployment due to information theoretic lower bounds. Tor would have melted down under the load. If Oblivous HTTP had been available, this would have been solved. Request the creative through Oblivious HTTP, and there is no way for the server, the request resource, or the proxy resource to infer client characteristics as no one sees the request and the client IP together. Without Oblivious HTTP there isn't a way to make these sorts of design work. And unlike MASQUE Oblivious HTTP is easy to use from Javascript in the browser, which is nice for prototyping and other reasons. In another privacy enhancing technology I've been working on, which you'll hear about in a few weeks, Oblivious HTTP is the natural solution to an information gathering problem in edge cases where a server needs some more information. The information could identify a client if connected to other requests, but if separated from that is innocuous. Applying Oblivous HTTP would simplify the issue massively. I hope these two examples illuminate what use cases the protocol is for and help advance the charter discussion. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim
- [Ohttp] OHTTP applications I've seen Watson Ladd
- Re: [Ohttp] OHTTP applications I've seen Vittorio Bertola
- [Ohttp] renaming the WG-to-be? Jim Reid
- Re: [Ohttp] OHTTP applications I've seen Eliot Lear
- Re: [Ohttp] renaming the WG-to-be? Martin Thomson
- Re: [Ohttp] OHTTP applications I've seen Martin Thomson