Hello everyone, I am Ralph Swick.

In this presentation Sam Weiler and I will be talking about further progress we are making in supporting horizontal reviews of W3C's work.

First, I'd like to remind us all of one of our motivations for requiring horizontal reviews.

Namely, that the benefits of the web are available to all people regardless of the device they use, their network infrastructure, their language, their culture, their geographic location, or their physical or mental ability.

And our focus for horizontal reviews therefore covers five primary areas.

Internationalization, to assure that web technologies support different languages, scripts and cultures.

Privacy, to assure that individuals can access materials on the web without unknowingly or unwillingly exposing their private personal information.

Security, to assure that web technologies provide and preserve expectations over reliable and secure communication.

Accessibility, to assure that the web is accessible to people with disabilities.

And architecture, to guide specification developers in creating technologies that respects some general design principles for the web.

We want to consider these five areas in all of the work that we do.

In addition, there are two areas that we consider when a particular activity might have specific needs or requirements.

Device independence, web technologies that support mobile devices, devices with both very small or very large screens, and use of web technologies in other consumer devices, such as interactive television, automobiles, web of things, and others.

Mobile Web, special considerations for highly mobile devices with unique native app and connectivity characteristics.

Which of our W3C activities should we review?

Well, everything.

But specifically all Working Drafts of specifications that are expected to become W3C Recommendations.

I'll say more about this on the next slide.

That's obvious, but also early drafts of ideas that are in incubation.

Reviews of ideas in this stage might not be as detailed as reviews of Working Drafts, but the earlier that a potential issue such as a security or privacy issue, the earlier such an issue can be identified, the easier it generally is to plan ways to address it.

Workshop proposals, this might be less obvious.

Often, and especially in W3C, workshops precede incubation.

When we envision that the subject matter of a workshop could benefit from some insight from practitioners in one or more of these five or seven areas, we want to encourage participation from these practitioners.

Working Group charter proposals.

Here our aim is both to document expectations we have of the Working Group participants as they proceed with their deliverables and provide the opportunity for the horizontal reviewers to anticipate and be on the watch for points at which the Working Group might need advice or assistance.

We have a section of our W3C Guidebook currently titled, “How To Do Wide Review.” I provided a pointer in this slide as well as in a resource list at the end of my section.

A frequent question is, when should we review?

A short but not very practical answer is, as often as possible.

We use these guidelines at a minimum.

First Public Working Draft should always trigger a request for review.

This is often the point at which ideas are sufficiently fleshed out for the reviewers to understand the likely scope of the future specification.

The reviewers may not be able yet to point to specific issues, but they can alert the Working Group to potential areas of concern and plan to schedule further review and discussion.

Before advancing to Candidate Recommendation.

This is a Process requirement.

The Director will look for any issues the horizontal review groups have identified as requiring resolution before advancing to Candidate Recommendation.

Then there's the in between, characterized in our guidebook as, “When a document is both reasonably stable and still flexible enough to allow changes.” This is a judgment call and we rely on the Working Groups to make this judgment.

But to help in that judgment, whenever a Working Draft is updated with new features after the previous draft has been widely reviewed.

This review request might be limited to just those new features.

Though the Working Group should not be surprised if a reviewer finds interactions between the new features and features that were in the previous draft, or realizes other issues with those previous issues based on new understandings.

Who conducts these reviews?

Those who are working on the design of the idea should use the various self-review tools that the horizontal groups and the Technical Architecture Group, the TAG, have provided.

The team will help out as often as we can, but the groups who are specifically chartered to provide horizontal review, will need to be engaged on REC track work.

These charter groups include Working Groups and an Interest Group, and as Sam Weiler will talk about next, we also engage other volunteers for some of these reviews.

In the year since I last spoke with you about horizontal review our Project Management team has made substantial progress to support horizontal review.

This tooling leverages our use of GitHub across our Recommendation Track work.

The Project Management team, lead by Philippe Le Hegaret, has documented a collection of GitHub mechanisms for use both by those performing horizontal review as well as those requesting horizontal review.

And when a Transition Request comes to the Director to advance a Rec-Track document, the Director uses those markers to confirm both that reviews have been done and that no blocking issues remain.

We strongly encourage Working Groups who are not yet using this new tooling to become familiar with it and start using it.

To discuss the details of use of this tooling, Philippe has scheduled a dedicated session during the TPAC breakout week.

I hope you are viewing this presentation in time to take advantage of that breakout.

You can help in our mission to assure our work respects these five areas of horizontal effort by reminding your Working Group representatives that these are important.

Remind them to seek advice from others.

You can make representatives from your organization with expertise in these areas available to advise Working Groups on an occasional basis or appoint them to participate on a regular basis.

I will turn it over to Sam Weiler now, to share more specifics about security and privacy review.

And I'll leave you on this slide 10, with pointers to the four resources I mentioned previously: What we expect when we write a Working Group or Interest Group charter, our new Guidebook section on wide review and horizontal review, and the horizontal review comment trackers using GitHub.

Over to Sam.

W3C reviews documents for accessibility, internationalization, privacy, security, and overall architecture.

I'm going to talk about two of those areas, sharing details about how both privacy reviews and security reviews are done, as well as suggestions on how Working Groups can get the most out of those reviews.

First, know that privacy reviews and security reviews are done separately by different groups of people.

Privacy reviews are done by the Privacy Interest Group, commonly called PING.

Security reviews are done by a pool of volunteer reviewers, many of whom have experience in the IETF and other standards organizations.

Those reviews are coordinated by Team, specifically me.

W3C has had some problems in past years with getting timely security reviews, and we have made some progress systematizing that in recent months.

We have also had a problem with groups not asking for security review, and we have been updating the published instructions to make sure the process is clear.

While these reviewers have deep expertise in privacy, or security, or sometimes both, they usually will not have deep expertise in the specifications they're being asked to review.

So while they may identify additional issues, it's important for Working Groups to do their homework before asking for a review.

Specifically, I want Working Groups to have already considered both privacy and security issues in some depth and documented their analysis of those in separate privacy considerations and security considerations sections inline in their specifications.

I said separate sections, because usually the concerns are quite different, though they may interrelate.

Those sections should be written for the general reader of the specification; they should be useful beyond just the moment of review.

The horizontal reviewers will then help identify additional issues and help a Working Group evaluate how complete its own analysis is.

They can help guide that Working Group to where more attention might be needed, and they can be useful sounding boards as Working Groups work to mitigate issues.

A wonderful example arose with the Web Audio specification earlier this year.

A reviewer observed that the sample rates of audio hardware provided a few extra bits of fingerprinting surface, particularly for users with custom audio hardware.

The Working Group agreed to hide all but two default rates behind some sort of configuration switch, even though that will require re-sampling on some devices.

But the real win was when the Working Group inspired by that discussion found another variable in their API that could and should be constrained to prevent it from becoming fingerprinting surface.

So again, the reviewer didn't catch everything, but they helped the Working Group look at their own spec with a more critical eye.

This example highlights something that's common in other specs, namely that many, if not most, API's will add some fingerprinting surface.

And just as we expect specs to mitigate other privacy and security issues they create, it is important for specs to identify the fingerprinting surface they are adding and make reasonable efforts to minimize that surface.

We have several resources to help them guide that analysis and the writing of privacy and security considerations sections.

PING and the TAG publish a self-review questionnaire for security and privacy.

PING publishes a separate document on mitigating browser fingerprinting, and the IETF's RFC about privacy considerations, RFC 6973, is a wonderful resource.

I recommended that all spec authors read section seven of RFC 6973.

For the first two documents, I urge you to use the editors drafts, the self-review questionnaire in particular has had some notable changes recently.

Be aware that the TAG asks specification authors to literally complete the self-review questionnaire prior to a TAG design review.

That helps them see how much attention has been paid to privacy and security issues, which is particularly relevant given the early review requests they have been getting.

Specification readers though, need a more narrative discussion that has been crafted to the specific specification and goes in depth into the vulnerabilities introduced by that spec.

I and our privacy and security reviewers want to see those narrative analysis of privacy issues and security issues inline when we do our reviews, just as though we were regular readers of the spec.

While the self-review questionnaire will inform writing those narrative analyses and the TAG once those answers for its own reviews, I don't want to see the self-review questionnaire imported verbatim into documents in lieu of the narratives.

After those analysis sections are written Working Groups may request review by sending emails to the PING list for privacy reviews, and to the public-web-security@w3.org list for security reviews, the former are coordinated by PING, the latter are coordinated by Team.

Using email requests is likely to change in the future, possibly in the near future.

As we introduce new tooling; check the Guide for up to date instructions.

One of the questions I often hear is, when should we ask for review?

This can be a balancing act because the real answer is when a spec is both reasonably stable, and still flexible enough to allow changes.

As a rule of thumb, that should be at least 90 days before publication of CR or Candidate Recommendation.

And again when new features are added or major changes are made.

Is perfectly reasonable to ask earlier so long as the basic spec is pretty stable, and you have both done and documented your analysis.

Again, since security reviews and privacy reviews are done separately, you can ask for those at different times, and you must ask separately for each of them.

Perhaps you have a spec that you think has no security issues, but you're still working on mitigating some fingerprinting surface that you're introducing.

It might be reasonable to write your security consideration section and request security review, even though you're not ready for privacy review yet.

I will close with a few words about why we are doing these reviews and a pair of requests for you.

We're trying to get more eyes on specifications in the interest of protecting the people who use the web.

I think we're having a positive impact.

It's also the case that many hands make for light work, we would benefit from having more people to share the work.

I specifically want more security reviewers.

We have about 10 security reviewers in the pool right now.

Mostly people with experience in other standards organizations.

My goal is to ask each reviewer for a review about three times a year.

I need several more reviewers to get the workload down to that level.

If you have someone in your organization who would enjoy and benefit from looking at W3C specs with an eye toward security issues, please have them get in touch with me.

PING would also benefit from having more people involved.

Ideally, people who have a critical eye for browser fingerprinting and other privacy risks.

AC members can nominate people to PING in the usual way and those who aren't W3C members can join PING as Invited Experts.

The PING chairs maintain a list of volunteers to take point on individual reviews.

Lastly, I invite your questions and feedback on this talk.

You can reach me at weiler@w3.org