W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2011

Re: [Page Visibility] Spec -- privacy concern

From: Bryan McQuade <bmcquade@google.com>
Date: Fri, 13 May 2011 21:10:02 -0400
Message-ID: <BANLkTinBcg2Gp2S0oawHMSROH0AwQ7Vgvg@mail.gmail.com>
To: Arvind Jain <arvind@google.com>
Cc: Kyle Simpson <getify@gmail.com>, Sreeram Ramachandran <sreeram@google.com>, public-web-perf@w3.org
I agree with Arvind that this is a minor addition to existing
information that is already available. For instance it is already
possible to infer whether you are in the background/foreground in
Chrome by monitoring the frequency with which a timer fires. Chrome
recently added timer throttling for background tabs to reduce
CPU/power consumption of backgrounded tabs:

http://blog.chromium.org/2011/03/getting-smoother-animated-web-content.html

"In the forthcoming Chrome 11 release, we plan to reduce CPU
consumption even for pages that are using setTimeout and setInterval.
For background tabs, we intend to run each independent timer no more
than once per second."


On Fri, May 13, 2011 at 8:59 PM, Arvind Jain <arvind@google.com> wrote:
> Yes there is additional information being exposed (the case where a window
> loses focus but is still visible). But it seems like a minor addition to the
> existing information available via onfocus/onblur/onload/onunload.
> Limiting it to same domain would render the API ineffective. One of the
> goals was for Analytics software to track time spent on a page with higher
> fidelity, which would not get served. Another goal was for advertisers to
> know whether their ad was ever shown (or to not play an ads video when the
> window is not visible). These are both third party content examples.
>
> Arvind
>
> On Fri, May 13, 2011 at 5:44 PM, Kyle Simpson <getify@gmail.com> wrote:
>>
>> I'm not entirely certain the answer to your question... but I'd submit
>> that if such functionality exists and is truly reliable and represents the
>> same visible/hidden states we're discussion, then on principle why are we
>> creating a new event/state property for something that already exists?
>>
>> If they aren't the same thing, then `blur`/etc must necessarily be a
>> subset of the proposed new functionality, so it by definition introduces new
>> potential privacy leaks.
>>
>> --Kyle
>>
>>
>>
>>
>> --------------------------------------------------
>> From: "Sreeram Ramachandran" <sreeram@google.com>
>> Sent: Saturday, May 14, 2011 2:06 AM
>> To: "Kyle Simpson" <getify@gmail.com>
>> Cc: <public-web-perf@w3.org>
>> Subject: Re: [Page Visibility] Spec -- privacy concern
>>
>>> On Fri, May 13, 2011 at 16:50, Kyle Simpson <getify@gmail.com> wrote:
>>>>
>>>> One major privacy concern I (and others I chatted with on Mozilla's
>>>> #developers IRC) have is that third-party scripts (like ad providers,
>>>> etc)
>>>> would be able to monitor this type of data (page visibility) and gain
>>>> valuable (to them!) information which a user might not want them to
>>>> have,
>>>> such as how long I stay viewing a page, etc.
>>>
>>> Doesn't this privacy concern also apply to other existing mechanisms,
>>> such as window.onblur/onfocus/onpageshow/onpagehide? It's not clear to
>>> me that the visibility API introduces additional privacy-violating
>>> capabilities on top of those.
>>>
>>
>
>
Received on Saturday, 14 May 2011 01:10:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 14 May 2011 01:10:28 GMT