Re: Proposed W3C Charter: Web Performance Working Group
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
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
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
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
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
>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
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
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
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
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 Baronwrote: > 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
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
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
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
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