Re: "local" vs "remote" performance API's: privacy, security, best practices

Ben, thanks for the comments. Inline..

On Sat, Apr 30, 2016 at 2:27 PM, Ben Maurer <ben.maurer@gmail.com> wrote:

> For example, application developers may want to know precise information
>> about renderer-related activities: if and when layout or style-recalc
>> occurs, how long each frame took to render, when the paint happens, and so
>> on. However, access to such high-resolution data can be (ab)used by an
>> attacker to launch a number of high-resolution attacks:
>
>
> You give examples of security issues with informing the user about the
> timing of paints (specifically the :visited issue). Do you have an example
> of issues that occur because of high-res information about layout and
> style-recalc? Can't a developer already manually trigger stylesheet recalc
> or layout for the document (eg, by querying stylesheet / layout information
> in JS and forcing a reload).
>

They can, but that's not the issue. Rather, it's the explicit feedback that
the operation occurred and, optionally, the time taken by it - i.e. a huge
step up in accuracy and precision. In general, I think the main point of
caution here is about guarding from exposing higher-speed and
higher-accuracy forms attacks (existing and new).


> Are there other examples of sensitive information about paint timing other
> than :visited? If :visited is the primary issue around painting, maybe it'd
> be worth exploring allowing a site to turn off the feature for the sake of
> allowing more detailed profiling.
>

This topic has come up numerous times and I'd *love* to see such mechanism.
I believe Alex (cc'ed) drafted some docs exploring various options on
this.. I'll defer to him on latest and greatest.


> e.g. an attacker can figure out if the user is authenticated by comparing
>> the memory footprint of the loaded iframe
>
>
> Arguably any site with authenticated content that can be iframed has a
> more serious problem -- clickjacking. A developer could also run setTimeout
> on a short interval to figure out how much time the iframed site used on
> the main event loop. Is there any list of expectations around exposing
> information to other origins?
>

I'm not aware of any comprehensive list. Given the surface area...


> For example, it is possible to make a GET request to a cross-origin
> resource and figure out the status code of that request (
> https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information
> ).
> I also wonder if the example of click-jacking suggests another potential
> best practice: cross-origin opt-out. The X-Frame-Options is an example of
> cross-origin opt-out.
>

Yep, and sites should definitely make use of it, if possible.


> An opt-out seems appropriate when:
>
> 1) An existing feature exists that can not be easily removed has a
> security issue. Origins that are sensitive to those issues can proactively
> opt out of the feature when they know it will not break their use case.
>

FWIW, this is exactly what we're exploring here:
https://discourse.wicg.io/t/proposal-sandbox-policy/1414


> 2) We want to add a feature that is likely to be harmless, or at least no
> worse than the current state of affairs, but might have security
> implications to a small number of highly security aware users. The memory
> footprint example might be a good one here. If we believe that exposing
> memory information is relatively low risk we could allow an iframe to opt
> the entire page out of the information.
>

Hmm, interesting.. Re, memory: it's not clear to me if its low risk or not.
Also, I'm not sure how realistic it is to expose such data across all the
various platforms. That said, as a minimum, I do think we could expose a
"under memory pressure" signal to apps.

ig



> On Thu, Apr 28, 2016 at 3:11 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>> Hey all.
>>
>> I'm often approached with "DevTools / tracing / <insert favorite tool
>> here> gives me this really useful performance metric and I'd love to (no, *need
>> to*) have it available via RUM. Can we spec and ship a new API to expose
>> it via Performance Timeline?"
>>
>> The above inevitably prompts a series of discussions on the differences
>> between "local" vs "remote" profiling, privacy and security limitations of
>> each, best practices for mitigating various concerns, and so on. After
>> having this discussion a few too many times with different people, I've
>> tried to put together a braindump that captures the highlights:
>>
>> https://docs.google.com/document/d/1V-p7DNpBx8j-
>> fzXuN8poy8rs4xMYSDN5hgYPaFXMRMY/edit
>>
>> *"... just because something is possible to measure, and perhaps is even
>> highly desirable and useful to many developers, does not mean that it can
>> be exposed as a RUM API. The goal of this document is to explain why that
>> is the case, and to provide guidance for what needs to be considered when
>> making or evaluating a proposal for such API’s. "*
>>
>> I don't claim that it is complete and covers every corner case, but
>> hopefully it lays out a basic framework for how to think about this space.
>>
>> Would love to hear any comments or feedback. Anything that's you disagree
>> with, is missing, etc?
>>
>> ig
>>
>> p.s. big thanks to Todd Reifsteck, Yoav Weiss, and Nat Duca for feedback
>> on early drafts.
>>
>
>