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

>
> 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).

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.

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? 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. 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. For
example, being able to opt-out of exposing status code cross origin might
be helpful to some sites and perhaps could pave the way for exposing more
information to sites which don't proactively allow x-origin timing
information.

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.


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.
>