Re: [rtcweb] Notes on security for browser-based screen/application sharing

Martin Thomson <martin.thomson@gmail.com> Fri, 22 March 2013 17:10 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A977321F8F06 for <rtcweb@ietfa.amsl.com>; Fri, 22 Mar 2013 10:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MDv1R1VyDXl for <rtcweb@ietfa.amsl.com>; Fri, 22 Mar 2013 10:10:38 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C5D9921F8E7E for <rtcweb@ietf.org>; Fri, 22 Mar 2013 10:10:37 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id d46so1593117wer.16 for <rtcweb@ietf.org>; Fri, 22 Mar 2013 10:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o6GM+Qj+s7lm3u9hclRI90Y5vQ+QXugJEphFYf92eJo=; b=OByNoS0OnWg0n8EH3OLQeId8+ixb6tGFwGQ9BZqrz48RF6uWvxQvWofIGgugtUxDlr PHlyz0eQwInaqD8WQgqFDcooSNsA/evo+P/Cec0msKK4VXORK91a7t87RadDe4GE3Aqz xeSQtsc5V3nM/fM6l60mt2i7ziqA6kX9R8MoYe4KHD8SiRofTLJzCOKv8FxPJyN76Vo/ wfn05zhYD10Ju0HghRmi8EYqftPoL01xEEwdZ083eUNYeEDFNbI1K/gKINuPG3AirDXf rhhjy+ri9SCBWIo+KSBJcAGxdIq6RE40sVGxojroHwFkFx+qVpsdMRBGuBaO63h4l5cN 9AUQ==
MIME-Version: 1.0
X-Received: by 10.180.103.40 with SMTP id ft8mr12783100wib.28.1363972236862; Fri, 22 Mar 2013 10:10:36 -0700 (PDT)
Received: by 10.194.5.135 with HTTP; Fri, 22 Mar 2013 10:10:36 -0700 (PDT)
In-Reply-To: <CABcZeBN2R=dKYtoLEstNuT2K89k+Y_gD8_OdRS5MQOJNSzY5Kg@mail.gmail.com>
References: <CABcZeBPs=znh-BUCRoVkPC1UuQt-xxf-COD+SGE59ASBzRZbJQ@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11342CB58@xmb-aln-x02.cisco.com> <CABcZeBN2R=dKYtoLEstNuT2K89k+Y_gD8_OdRS5MQOJNSzY5Kg@mail.gmail.com>
Date: Fri, 22 Mar 2013 10:10:36 -0700
Message-ID: <CABkgnnUXPqH9JLcH8o-oKdirb6H-iGtKJ752h9jL0+_8usD6ZA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] Notes on security for browser-based screen/application sharing
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2013 17:10:38 -0000

The other day Matthew suggested that his best solution for employee
motivation was to release a hungry lion into the office at random
times.  The more I think on the subject, the more this seems that this
is exactly what we are doing.

On 22 March 2013 07:17, Eric Rescorla <ekr@rtfm.com> wrote:
> This doesn't sound very implementable. First, if you're sharing primarily by
> pixel
> capturing out of the window, trying to figure out which pixels represent
> which
> origins is going to be a huge pain for the implementor. Second, many sites
> as a practical matter are composed of content from multiple origins
> (images out of a CDN, domain sharding, etc.) The result of what you propose
> is going to be that such sites will not render properly when shared. I
> suspect that sites will simply ask for "The browser".

The modern web reality is that any one page consists of content from
many different sources, so restricting to one source is impractical.
>From an implementation perspective, it might be possible to restrict
to untainted content (the content that the page origin can access),
but that would probably result in something that is virtually useless.
 Just like that interesting (redacted) document that contains
(redacted).

I suggested to EKR that perhaps we could devise an opt-out for truly
sensitive information using Frame-Options so that sensitive content
could be hidden, but even that seems a little weak.