Re: Proposed W3C Charter: Web Performance Working Group

2018-07-25 Thread Tom Ritter
On Wed, Jul 25, 2018 at 5:42 AM, Panos Astithas  wrote:

> On Wed, Jul 11, 2018 at 4:52 PM Tom Ritter  wrote:
>
>> Device Memory clearly has made an effort to make it 'less fingerprintable'
>> by only reporting possible values of 0.25, 0.5, 1, 2, 4, 8 - but there is
>> nothing in the spec about omitting it if desired to reduce fingerprinting.
>> This is a spec issue though, and not a rechartering one I don't think.
>>
>
> Would a privacy-conscious user prefer to get the full site experience or a
> reduced one? I assume they would rather get the full experience without
> divulging any additional information. In that case wouldn't it be better to
> just send the maximum allowed value (8) instead of adding another 7th
> possible value (like null)?
>

I would imagine the UA would either send the maximum value or just omit the
API entirely

-tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2018-07-25 Thread Panos Astithas
On Wed, Jul 11, 2018 at 4:52 PM Tom Ritter  wrote:

> Device Memory clearly has made an effort to make it 'less fingerprintable'
> by only reporting possible values of 0.25, 0.5, 1, 2, 4, 8 - but there is
> nothing in the spec about omitting it if desired to reduce fingerprinting.
> This is a spec issue though, and not a rechartering one I don't think.
>

Would a privacy-conscious user prefer to get the full site experience or a
reduced one? I assume they would rather get the full experience without
divulging any additional information. In that case wouldn't it be better to
just send the maximum allowed value (8) instead of adding another 7th
possible value (like null)?

Panos
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2018-07-23 Thread Peter Saint-Andre
Hi David, thanks for crafting this text. Would it make sense to also
mention countermeasures in the paragraph on privacy? (For instance:
disallowing use of this API for arbitrary origins or restricting access
to specific API methods.)

Given the significant privacy implications, I would lean toward a formal
objection, but other Mozillians have more experience with W3C charter
reviews than I do...

Peter

On 7/22/18 7:17 PM, L. David Baron wrote:
> Below is an attempt to write comments on the charter to consider the
> feedback so far in this thread.  It's not clear to me what the right
> charter changes to suggest for the privacy and fingerprinting issues
> are; I've made a proposal here, but I'm open to alternative
> suggestions.
> 
> There's also the question of whether these comments should
> constitute a formal objection to the charter.  I think I'm leaning
> against, but could also be persuaded otherwise.
> 
> -David
> 
> =
> 
> We're glad to see the plan to merge Navigation Timing into Resource
> Timing after level 2 is complete.  However, this only partially
> addresses our concerns about confusing cross-references and
> monkeypatching between a number of the specifications produced by this
> working group.  It would be good to also see User Timing and Performance
> Timeline merged into the same set of specifications in the next level.
> 
> A number of the group's specifications have significant privacy
> implications:  they might provide mechanisms for finding information
> about what other software is running on the user's computer, whether
> that's web content in other origins, or entirely separate software.
> This requires careful consideration of whether these features are safe.
> It would be good to see the Success Criteria section of the charter both 
> explicitly ask the group to consider these issues, and explicitly say
> that it is an acceptable result for the group to decide not to release a
> specification because an acceptable solution for user privacy cannot be
> found.
> 
> Likewise, some specifications in the group provide significant
> additional fingerprinting surface.  When they do this, they should
> explicitly point out that they are doing so, and explicitly allow
> implementations to take countermeasures.  We'd like to see the Success 
> Criteria section of the charter encourage the group to consider 
> fingerprinting explicitly.
> 
> 
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2018-07-22 Thread L. David Baron
Below is an attempt to write comments on the charter to consider the
feedback so far in this thread.  It's not clear to me what the right
charter changes to suggest for the privacy and fingerprinting issues
are; I've made a proposal here, but I'm open to alternative
suggestions.

There's also the question of whether these comments should
constitute a formal objection to the charter.  I think I'm leaning
against, but could also be persuaded otherwise.

-David

=

We're glad to see the plan to merge Navigation Timing into Resource
Timing after level 2 is complete.  However, this only partially
addresses our concerns about confusing cross-references and
monkeypatching between a number of the specifications produced by this
working group.  It would be good to also see User Timing and Performance
Timeline merged into the same set of specifications in the next level.

A number of the group's specifications have significant privacy
implications:  they might provide mechanisms for finding information
about what other software is running on the user's computer, whether
that's web content in other origins, or entirely separate software.
This requires careful consideration of whether these features are safe.
It would be good to see the Success Criteria section of the charter both 
explicitly ask the group to consider these issues, and explicitly say
that it is an acceptable result for the group to decide not to release a
specification because an acceptable solution for user privacy cannot be
found.

Likewise, some specifications in the group provide significant
additional fingerprinting surface.  When they do this, they should
explicitly point out that they are doing so, and explicitly allow
implementations to take countermeasures.  We'd like to see the Success 
Criteria section of the charter encourage the group to consider 
fingerprinting explicitly.

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2018-07-16 Thread Panos Astithas
Thanks everybody for the comments submitted so far on the WG rechartering
process, please keep them coming!

I would like to make two requests, if I may:
- feedback on specs and not on the recharter should be submitted to the
GitHub issue tracker for the spec (ping me if you can't find it)
- if you have any feedback that you would like me to voice in the WG calls,
please send me a note with the specifics.

Also, if anybody is interested in participating in the WG calls and
actively shaping the conversations, please let me know! I would very much
appreciate the help.

Thanks,
Panos


On Wed, Jul 11, 2018 at 11:30 PM Randell Jesup 
wrote:

> >Adding to what Tom said...
> >
> >1. "Web developers want the ability to observe the performance
> >characteristics of their applications" - they want to do so, but
> >*should* they be allowed to do so? The API would give access to deep
> >performance data that could be used for all sorts of nefarious purposes
> >(profiling, fingerprinting, probing for vulnerabilities, etc.).
>
> The extreme version of this is what Vlad and Benoit (Facebook) have
> proposed in WICG, which is an interface to profiling data for the page
> (origin): https://github.com/vdjeric/js-self-profiling
> Discussion (mozilla) here:
> https://github.com/mozilla/standards-positions/issues/92
>
> One can understand why they'd *want* to be able to profile their code
> in-the-field.
>
> Exposing this today would be have serious same-origin and Spectre
> impacts; in a Fission world these problematic impacts would be (more)
> limited though perhaps not "safe".  (Implied in the current Gecko
> Profiler impl is that other processes could affect how fast your
> origin's process runs, and thus how much progress is made between
> profiler 'ticks',leading to some leakage of information cross-orgin
> between processes.  How large an impact this is I'm not 100% sure at
> this point. If we changed sampling to be runtime-based instead of
> wallclock-based, this (mostly) hides the impact of other processes,
> though secondary effects still exist (cache impacts, etc).
>
> Making it runtime-based would be a largish change...
>
> --
> Randell Jesup, Mozilla Corp
> remove "news" for personal email
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2018-07-11 Thread Randell Jesup
>Adding to what Tom said...
>
>1. "Web developers want the ability to observe the performance
>characteristics of their applications" - they want to do so, but
>*should* they be allowed to do so? The API would give access to deep
>performance data that could be used for all sorts of nefarious purposes
>(profiling, fingerprinting, probing for vulnerabilities, etc.).

The extreme version of this is what Vlad and Benoit (Facebook) have
proposed in WICG, which is an interface to profiling data for the page
(origin): https://github.com/vdjeric/js-self-profiling
Discussion (mozilla) here:
https://github.com/mozilla/standards-positions/issues/92

One can understand why they'd *want* to be able to profile their code
in-the-field.

Exposing this today would be have serious same-origin and Spectre
impacts; in a Fission world these problematic impacts would be (more)
limited though perhaps not "safe".  (Implied in the current Gecko
Profiler impl is that other processes could affect how fast your
origin's process runs, and thus how much progress is made between
profiler 'ticks',leading to some leakage of information cross-orgin
between processes.  How large an impact this is I'm not 100% sure at
this point. If we changed sampling to be runtime-based instead of
wallclock-based, this (mostly) hides the impact of other processes,
though secondary effects still exist (cache impacts, etc).

Making it runtime-based would be a largish change...

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2018-07-11 Thread Boris Zbarsky

On 7/10/18 10:59 PM, L. David Baron wrote:

The changes relative to the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F07%2Fwebperf=https%3A%2F%2Fwww.w3.org%2F2018%2F07%2Fwebperf-charter


It looks like the new charter proposes to merge navigation timing and 
resource timing, but leave user timing and performance timeline 
separate.  That won't completely address my concerns about 
monkeypatching and unclear behavior, since the whole point is that the 
performance timeline exposes stuff from all those other specs but the 
way it's done is very monkeypatchy and unclear...  We should probably 
point out that we would prefer for all of these to be merged.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2018-07-11 Thread Peter Saint-Andre
Adding to what Tom said...

1. "Web developers want the ability to observe the performance
characteristics of their applications" - they want to do so, but
*should* they be allowed to do so? The API would give access to deep
performance data that could be used for all sorts of nefarious purposes
(profiling, fingerprinting, probing for vulnerabilities, etc.).

2. What is the permissions model for allowing access? If a browser
supports the API, must it grant access to any arbitrary web app?

3. What about user control over access to the API?

4. The privacy controls are weak. It's not enough to say that
"non-normative documents may be created such as Security and Privacy
considerations for Performance APIs" or that "Each specification should
contain a section detailing any known security or privacy implications
for implementers, Web authors, and end users." Privacy and security
simply MUST be top of mind here.

Peter

On 7/11/18 7:51 AM, Tom Ritter wrote:
> I have a few concerns.
> 
> The Long Task Specification is essentially a way for a website to know if
> you have other tabs open and if they are CPU intensive tasks. That seems in
> pretty fundamental opposition to the Same Origin Policy.
> 
> Device Memory clearly has made an effort to make it 'less fingerprintable'
> by only reporting possible values of 0.25, 0.5, 1, 2, 4, 8 - but there is
> nothing in the spec about omitting it if desired to reduce fingerprinting.
> This is a spec issue though, and not a rechartering one I don't think.
> 
> -tom
> 
> 
> On Wed, Jul 11, 2018 at 12:59 AM, L. David Baron  wrote:
> 
>> The W3C is proposing a revised charter for:
>>
>>   Web Performance Working Group
>>   https://www.w3.org/2018/07/webperf-charter
>>   https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0002.html
>>
>> Mozilla has the opportunity to send comments or objections through
>> Friday, August 3.
>>
>> The changes relative to the previous charter are:
>> https://services.w3.org/htmldiff?doc1=https%3A%2F%
>> 2Fwww.w3.org%2F2016%2F07%2Fwebperf=https%3A%2F%
>> 2Fwww.w3.org%2F2018%2F07%2Fwebperf-charter
>>
>> Please reply to this thread if you think there's something we should
>> say as part of this charter review, or if you think we should
>> support or oppose it.
>>
>> -David
>>
>> --
>> 턞   L. David Baron http://dbaron.org/   턂
>> 턢   Mozilla  https://www.mozilla.org/   턂
>>  Before I built a wall I'd ask to know
>>  What I was walling in or walling out,
>>  And to whom I was like to give offense.
>>- Robert Frost, Mending Wall (1914)
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2018-07-11 Thread Tom Ritter
I have a few concerns.

The Long Task Specification is essentially a way for a website to know if
you have other tabs open and if they are CPU intensive tasks. That seems in
pretty fundamental opposition to the Same Origin Policy.

Device Memory clearly has made an effort to make it 'less fingerprintable'
by only reporting possible values of 0.25, 0.5, 1, 2, 4, 8 - but there is
nothing in the spec about omitting it if desired to reduce fingerprinting.
This is a spec issue though, and not a rechartering one I don't think.

-tom


On Wed, Jul 11, 2018 at 12:59 AM, L. David Baron  wrote:

> The W3C is proposing a revised charter for:
>
>   Web Performance Working Group
>   https://www.w3.org/2018/07/webperf-charter
>   https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0002.html
>
> Mozilla has the opportunity to send comments or objections through
> Friday, August 3.
>
> The changes relative to the previous charter are:
> https://services.w3.org/htmldiff?doc1=https%3A%2F%
> 2Fwww.w3.org%2F2016%2F07%2Fwebperf=https%3A%2F%
> 2Fwww.w3.org%2F2018%2F07%2Fwebperf-charter
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2016-06-06 Thread Jack Moffitt
Many of the proposed output specifications for this seem quite useful
for the kinds of work we are doing in Servo. While this is aimed at
web developers, it seems very useful for browser vendors to be
measuring things the same way. Having standard ways of doing this
means we'll be able to get more accurate cross browser comparisons.

This seems like something we should support.

jack.

On Fri, Jun 3, 2016 at 5:57 PM, L. David Baron  wrote:
> The W3C is proposing a revised charter for:
>
>   Web Performance Working Group
>   https://w3c.github.io/charter-webperf/
>   https://lists.w3.org/Archives/Public/public-new-work/2016Jun/0001.html
>
> Mozilla has the opportunity to send comments or objections through
> Thursday, June 30.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2015-06-16 Thread Boris Zbarsky

On 6/12/15 3:08 PM, L. David Baron wrote:

   http://www.w3.org/2015/05/webperf-charter.html


So I have two main comments on the way this working group is operating. 
 Not sure how these can/should be reflected in the charter.


1)  The deliverables and their interrelationships are a bit of a mess. 
See the thread I started at 
https://lists.w3.org/Archives/Public/public-web-perf/2015Jun/0057.html. 
I would like the working group to explicitly pursue addressing those issues.


2)  The way the working group operates in discussion terms seems to 
largely be through telecons.  github issues are used some, but you have 
to know about them to pay attention to them, and they don't seem to be a 
common discussion venue anyway.  The mailing list seems to be a bit of 
an afterthought, and it's not uncommon for mails to the list to be 
completely ignored by the editors of the relevant specifications. 
They've gotten a bit better on this front, but this is one of my main 
problems with this working group.


Past that, I think there should be something explicit in the 
deliverables about extending the various APIs involved to workers and 
about making it possible to map timestamps between timelines in 
different globals.  This is already being worked on actively, so should 
not be controversial, but should be a bit more specific than just 
incremental revisions to a bunch of specs.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2015-06-13 Thread Anne van Kesteren
On Fri, Jun 12, 2015 at 9:08 PM, L. David Baron dba...@dbaron.org wrote:
 The W3C is proposing a revised charter for:

   Web Performance Working Group
   http://www.w3.org/2015/05/webperf-charter.html
   https://w3c.github.io/charter-webperf/
   https://lists.w3.org/Archives/Public/public-web-perf/2015Jun/0066.html

 Mozilla has the opportunity to send comments or objections through
 Wednesday, June 17.

 Please reply to this thread if you think there's something we should
 say as part of this charter review.  (Given that we implement some
 of the group's specs, it seems like we ought to have something to
 say.)

We gave feedback last time right that there were too many disjoint
deliverables without some coherent architecture they plug into? Is it
worth saying that again and that all this could easily be part of an
existing group that might do some review on the APIs, such as WebApps?


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2013-04-05 Thread Anne van Kesteren
On Thu, Apr 4, 2013 at 10:20 PM, L. David Baron dba...@dbaron.org wrote:
 W3C is proposing a revised charter for the Web Performance Working
 Group.  For more details, see:
 http://www.w3.org/2013/01/webperf.html
 http://lists.w3.org/Archives/Public/public-new-work/2013Mar/.html

 Mozilla has the opportunity to send comments or objections through
 Thursday, April 11.  Please reply to this thread if you think there's
 something we should say.

Some of this stuff seems really obscure. E.g. setImmediate is
basically an alias for setTimeout except it's less well defined, even
while having a whole document for it... Not really sure there's
anything meaningful we can say about that though, other than don't do
it.

I guess the other comment I have is that a lot of this seems to be
bolting stuff on rather than addressing the relevant concerns at the
core. E.g. Resource Priorities has been discussed in other contexts
and it had been decided to postpone it for now. Is it now going in via
some other group unless we pay attention? Performance is after all a
relevant concern just like accessibility, security, etc. is. I suppose
it makes sense to have a group ensure performance is addressed, but
bolting on special-purpose performance features seems like the wrong
strategy.


--
http://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Performance Working Group

2013-04-05 Thread Anne van Kesteren
On Fri, Apr 5, 2013 at 6:51 PM, L. David Baron dba...@dbaron.org wrote:
 So do you think our charter comments should push for merging the
 group into Web Apps?  Or some of the deliverables (e.g., leaving the
 navigation timing and performance timing work?).

 (The group is currently standardizing requestAnimationFrame, and
 heycam is involved in that; see
 http://www.w3.org/TR/animation-timing/ .)

Yeah, I think it would be better if they focused on guiding other
groups rather than adding features on their own.


--
http://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform