ActivityLogging

[Eric Seidel]

Could someone explain what ActivityLogging is?
https://codereview.chromium.org/55313003/

Is this an UMA feature?

The only mention of this I see on mailing lists is Nils Barth's
renaming of this property (from ActivityLog) and mention on
committers@ of felt@ involvement in such.

Searching on Google it looks like it's related to the "Activity Log
for Extensions" auditing feature?

Just curious what this means for Blink and what (if anything) the rest
of us Blinkers need to be aware of?

[Kentaro Hara]

+petr, ankur, ulfar

--
Kentaro Hara, Tokyo, Japan

[Adrienne Porter Felt]

The Activity Log is a private Chrome API (activityLogPrivate) that's being used to 

(1) get UMA stats on extension behavior in general (e.g., how many extensions use document.write?), and 

(2) expose information about extension behavior to the Watchdog app [not released yet].

Most of the Activity Log logic is in chrome/browser/extensions/activity_log/, but calls to the logger need to be added to various places. In terms of Blink's involvement, this means calls to the logger for certain DOM operations when an extension is running.

[Dimitri Glazkov]

FWIW, I am not excited about this. Maybe it's just an initial reaction to seeing ominous-sounding "ActivityLogger" in the IDL, or the fact that this functionality has a slight taste of being snuck in below the radar.

:DG<

[Adrienne Porter Felt]

The bulk of the Blink work took place 6 months ago: https://codereview.chromium.org/13799007/

However, most of the work for this feature was done on the Chrome side, where we went through the normal API review and launch process for M31.

Launch bug: https://code.google.com/p/chromium/issues/detail?id=241672

Privacy review: https://code.google.com/p/chromium/issues/detail?id=244841

In a few weeks, we'll be releasing the "Watchdog app" to people on the Chrome canary and dev channels. The app lets users see what their extensions are doing. It's also useful for developers when they are debugging the behavior of their extensions/apps.

[Ulfar Erlingsson]

For what it's worth, we started working on support for activity logging to WebKit in January, and iterated several times first with Adam, and then with the V8 team and the WebKit team inlcluding Kentaro (who was a big help) until finally adding the ActivityLogging IDL mechanism.

We roped in all the relevant stakeholders that we knew about, and made significant changes and compromises in the logging mechanisms to account for ongoing and future work by other teams.  At least from our perspective, nothing was snuck under the radar, nor was there any attempt to do so.

[Philip Jägenstedt]

On Sat, Nov 2, 2013 at 7:56 AM, Eric Seidel <ese...@chromium.org> wrote:
> Could someone explain what ActivityLogging is?
> https://codereview.chromium.org/55313003/

I'd also be interested to know why logging all URL property access
might be useful. Assuming the Watchdog app is supposed to catch
unwanted behavior, what makes URL properties more worthy of attention
than (most) other kinds?

Philip

[Dimitri Glazkov]

On Sat, Nov 2, 2013 at 2:13 PM, Ulfar Erlingsson <ul...@google.com> wrote:

For what it's worth, we started working on support for activity logging to WebKit in January, and iterated several times first with Adam, and then with the V8 team and the WebKit team inlcluding Kentaro (who was a big help) until finally adding the ActivityLogging IDL mechanism.

I see. It might have been difficult to discuss this on blink-dev, given that blink-dev didn't exist then. 

We roped in all the relevant stakeholders that we knew about, and made significant changes and compromises in the logging mechanisms to account for ongoing and future work by other teams.  At least from our perspective, nothing was snuck under the radar, nor was there any attempt to do so.

Apologies for sounding somewhat harsh. I haven't studied at the technical merit of the solution (or the problem) -- just seeing extensions terminology sprinkled over web platform IDLs got me a bit off balance.

:DG<

[Ulfar Erlingsson]

No apologies needed.  Just wanted to clarify where this came from.

[Joel Weinberger]

FWIW, felt@ is Chrome Security as well, so, needless to say, it's passed Chrome Security review as well, and we're actually quite excited about it :-) I can see why the name sounds rather ominous, though.

--Joel

[Eric Seidel]

Thank you for the context!

A log of all points at which execution exited a specific environment
(e.g. a JS in a specific isolate) sounds like a very reasonable
feature for an execution environment (e.g. Blink) to provide. It
sounds like that's largely what ActivityLogging is attempting to
emulate.

It's unfortunate that at this time you have to do this manually and
that core/ needs to know about the particular black-list of exit
points your specific tool might care about.

But perhaps we can come up with something more generic with which to
obsolete this hard-coded list in the future.

Best of luck with you experiment.

[Ulfar Erlingsson]

Totally agree that it's very reasonable for an execution environment to provide facilities to log the points where execution exits the environment.  That's exactly what we have a poor man's version of here.  Would be wonderful to have something better.

FWIW: Our initial implementation was generic, and not tied to the IDL in any way. See https://bugs.webkit.org/show_bug.cgi?id=107207 for the code and some of the discussion that led to the use of IDLs.

This initial mechanism used V8's support for "data" pointers on v8::Arguments and v8::AccessorInfo to create closures dynamically, in such a way that a policy-based decision could be made whether or not to log, based on the context.  These closures were then cached, using existing mechanisms, so performance wasn't much affected (even so, there was an extra function call on the path for simple DOM operations, such as firstChild, causing observable slowdown in microenchmarks).  

In particular, the policy decision happened in V8DOMConfiguration::batchConfigureAttributes, if you look at the code. However, some of those dynamic decision points may go away in the future (e.g., if bindings become more driven by static tables, which is one way of making V8 faster).  In case these decision points would have to move earlier (e.g., when an execution context is created, pick one of several pre-populated tables, based on policy), which might also avoid needing dynamically-allocated memory for closures in each process.