[webkit-dev] WPT first test policy proposal

[Tim Nguyen via webkit-dev]

Hello everyone,

I would like to start a discussion on a policy to enforce WPT usage as a first 
choice, that would be enforced via check-webkit-style on Changelog files.

Why use WPT?

Contributing to WPT has many benefits:
interoperability/compatibility issues with WPT we write may be detected by 
other browser vendors and we would get faster feedback and turnaround to fix 
them
creates/encourages discussion in case of disagreement with other browser vendors
WebKit greatly benefits from WPT coverage, it is time to provide our own 
coverage to other browsers
Improves WebKit’s score generally for WPT (which has tests mostly contributed 
by Chromium, Firefox at the moment)

Are there reasons to not use WPT?

Common reasons for not writing WPT that have been mentioned are:
"WPTs are less pleasant to write.”
This is not true imo, the WPT harness is documented 
(https://web-platform-tests.org/writing-tests/index.html 
), unlike WebKit 
internals, making it easier for new contributors to figure out things.

“When you actually move a regression test to WPT proper, commit history is 
lost, and you don't know what kind of user facing problem it's preventing any 
more.”
Use `` with a reference to the webkit bug. Ensure you 
actually export the WPT and merge the WPT PR as well!

There are things WPT can’t test
True (e.g. tree dumps). My proposal below covers that.

Here is my current proposal:

Every LayoutTests/ changelog adding new test files would contain:

WPT-exemption-reason:  NONE (OOPS!)

If that line is removed or no valid reason is provided, webkit-style would 
throw out an error. Valid reasons could be:

WPT-exemption-reason: urgency (webkit.org/b/XXX )
I’m personally not in favour of this reason existing, but some have expressed 
interest in it, this may be used in case of urgency (security fixes etc.), 
where a bug must be filed to port it to WPT (alternatively the test path could 
be added to a new allowlist file). Eventually this reason would be removed if 
two way sync with the WPT repo is available.

WPT-exemption-reason: test-harness-deficiency (webkit.org/b/XXX 
)
If the WebKit implementation of the WPT harness lacks a certain feature that 
should be implemented in the WPT harness, a new bug may be filed, or an 
existing bug may be referenced.
Maintainers of the WPT harness may watch this reason to prioritize work needed 
on the harness.

WPT-exemption-reason: requires-internals: NONE (OOPS!)
requires-internals should have a valid explanation of which internals are 
needed. (Tree dumps would be a valid reason, although usually reftests can 
cover those)

In addition: 

WPT-PR: https://github.com/web-platform-tests/wpt/pulls/XX 
 must be present in 
LayoutTests/imported/w3c/Changelog, this is to ensure tests are not lost at the 
next import.

This would also be enforced in webkit-style, although eventually this might be 
replaced by a fully automated process in the future similar to Chrome/Firefox.

Any feedback is absolutely welcome!

Cheers,
Tim___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: new window.open() behavior

[Mason Freed via webkit-dev]

Hi WebKit,

I'd like to get WebKit's position on some changes that were recently made
to the spec  for window.open().
Chromium is planning to ship

these
new behaviors soon. The chromestatus entry
 has the full details,
but in essence, this makes two changes to the spec. First is that a new
windowFeature value, 'popup', can be used to explicitly trigger a popup
(popup=1) vs. a window/tab (popup=0). The other change is that the
BarProp.visible properties will all return the same values, true for
tab/window, false for popup. We do not believe either of these changes
should cause compat problems, but we'll monitor for bugs as we roll it out.

These changes simplify the usage of window.open() and work toward better
interop in this area. We're hopeful that you're supportive of this change.

Thanks,
Mason
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: WebAuthn minPinLength

[Adam Langley via webkit-dev]

Dear WebKit,

As part of the Blink process we're seeking any input that WebKit may have
on the minPinLength extension in WebAuthn. What follows is the explainer
 for this
change:


Security keys are physical devices, often USB-connected, that can create
public–private key pairs and sign with the private keys to authenticate a
user. Websites can use them via the WebAuthn API
. Several major sites allow users to
register security keys for better account security, for example, Microsoft,
Dropbox, GitHub, Google, and Facebook, to name a few.

Expert / high-sensitivity accounts are one user cohort, but security keys
are also used by enterprises and governments. In the latter contexts, they
can form part of a compliance system, for example for both public and
private sectors SP800-63-3
 requires
user-selected memorized secrets (e.g. PINs) be a minimum of 8 characters.
In order to meet SP800-63-3, enterprises can use the user verification
 feature of WebAuthn,
which involves local entry of a PIN or use of a fingerprint reader on the
security key. However, such compliance regimes often have requirements for
minimum PIN lengths greater than the default minimum

of
4 characters.

In order to help organizations with meeting such regulatory requirements,
the current standard for security keys (CTAP 2.1
)
defines an extension called minPinLength
.
This allows the authenticator to report, when a credential is created, the
authenticator's current configured minimum PIN length. Since the minimum
can only be decreased by resetting the security key, which erases all
credentials, an enterprise that uses this extension knows that the minimum
was enforced whenever that credential is used.

In order to prevent just any site from requesting this information, the
security key will only report the current minimum PIN length for sites that
have been explicitly preconfigured. This configuration has to be done
directly, by sending special CTAP messages

to
the security key. This API is not exposed over the internet. The envisioned
process is that an enterprise will enable minimum PIN length reporting for
its sign-in domain manually, on each security key, before distributing them
to employees.

The CTAP 2.1 minPinLength extension can be exposed to the Web via
WebAuthn's existing extensions mechansim
.
This request is being submitted as part of the Blink process because Blink
proposes to so expose it.


Cheers

AGL
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev