Intent to Merge: Google Analytics on perf-html.io

Harald Kirschner harald at mozilla.com
Mon Nov 20 04:00:27 UTC 2017


(from PTO, will be slow to respond)

Thanks Julien for jumping in. The his point that security wasn’t lowered
but raised when we prepared perf.html for adding GA: bugzilla and
crash-stats have GA for tracking product analytics; as these teams, just as
ours, want to make data-driven decisions on where to focus their efforts.
Just as perf.html, these sites tightly control how GA gets embedded and
what is tracked.

Thank you everybody else to raise the general concern of using a hosted web
app. For the future we might look at other ways to deliver the web app that
provides more control, ideas welcome. A first step would be for now to
review how to replace 3rd party libraries included, as both GA and bitly
provide HTTP APIs.

Thanks again. If you have feedback on perf.html outside of the scope of
this discussion please don’t hesitate to file them at
https://github.com/devtools-html/perf.html/

/Harald
On Sun, Nov 19, 2017 at 3:46 PM Julien Wajsberg <jwajsberg at mozilla.com>
wrote:

> Hi,
>
> I'm part of the perf.html dev team.
>
> Let me try to rephrase what the possible threat is:
>
>    1. You are privacy-conscious so you have DNT enabled. You capture a
>    profile with the Gecko Profiler, and share it through perf-html.io.
>    Locally GA is _not_ loaded because DNT is enabled.
>    2. You then hand over the link to another person.
>    3. This person is not as privacy-conscious, and didn't enable DNT. As
>    a result, loading the URL through perf-html.io _will_ load GA.
>    4. Loading GA involves loading a 3rd-party script we don't control,
>    and so this can be a malicious script.
>
> If that's the threat, I'd like to share some other bits of information
> about perf-html, from _before_ we integrate GA:
>
>    - we already do load a 3rd-party script to shorten URL: we use the
>    JSONP-based bit.ly API and therefore it involves loading a <script>.
>    Looking at it closer it seems they now support CORS so we should switch to
>    that instead.
>    - when sharing profiles we already send the profiles to google cloud
>    storage, plain and uncrypted.
>    - before implementing GA we implemented CSP [1]
>
> This means we already had some threats even before we implemented GA. I'm
> not saying "ok, now we can continue to do bad things" :) You made me look
> at it closer and I do think we should address them.
>
>    1. We should encrypt the data *à la* Firefox Send.
>    2. We should switch to the CORS version of the big.ly API
>    3. Maybe we should have a flag in the URL that would enable DNT as
>    well, so that it's easy to share a non-tracking URL to perf-html.io.
>    When a user with DNT enabled shares a profile, he could check a checkbox to
>    get this flag in the URL.
>
> Thoughts ?
>
> [1]
> https://github.com/devtools-html/perf.html/blob/5382311a5a86ca2e40f534d0986b875dddf85da5/res/.htaccess#L49
>
> Le 18/11/2017 à 07:06, Boris Zbarsky a écrit :
>
> On 11/17/17 7:50 PM, Harald Kirschner wrote:
>
> nothing private about the profile itself is collected in GA.
>
>
> Assuming GA itself is not buggy or malicious, right?
>
> As alternative to uploading you can also download the profiles locally and
> attach them to private bugs; so you stay in control over them and can
> remove them as needed.
>
>
> I don't see how that's possible in a sane way.  Capturing a profile
> automatically hands the data to scripts running on perf-html.io, no?  It
> may not be uploaded in the sense of being stored on the server, but it's in
> the global the GA scripts are running in.
>
> I have to admit that this change makes me a lot less comfortable using the
> Gecko profiler at all.  :(
>
> Would it be helpful to have anonymization as an option; to have a
> best-effort approach on removing PII like URLs from profiles?
>
>
> If it were done in the profiler itself (i.e. in code we control), not in
> perf-html.io (which we don't fully control if we load third-party scripts
> into it), it would help with the privacy issue.  Of course it would make
> the profiles a lot less useful (e.g. make it harder to figure out which
> site of the several I have open is causing the performance problem).
>
> -Boris
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20171120/1ae814bb/attachment.html>


More information about the firefox-dev mailing list