Bug 201369

Summary:

[WebAuthn] Enable WebAuthn by default for MobileSafari and SafariViewService

Product:

WebKit

Reporter:

Jiewen Tan <jiewen_tan>

Component:

WebKit Misc.

Assignee:

Jiewen Tan <jiewen_tan>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

alex.gaynor, bfulgham, commit-queue, james, jiewen_tan, kieun.shin, mitz, sam, simon.fraser, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

See Also:

https://bugs.webkit.org/show_bug.cgi?id=201439

Bug Depends on:

Bug Blocks:

181943

Attachments:

Description	Flags
Patch	none

Jiewen Tan

Reported 2019-08-30 17:39:30 PDT

Enable WebAuthn by default for MobileSafari and SafariViewService.

Attachments
Patch (6.95 KB, patch) 2019-08-30 17:51 PDT, Jiewen Tan	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Radar WebKit Bug Importer

Comment 1 2019-08-30 17:39:53 PDT

<rdar://problem/54903724>

Jiewen Tan

Comment 2 2019-08-30 17:51:44 PDT

Created attachment 377775 [details] Patch

Brent Fulgham

Comment 3 2019-09-01 11:02:41 PDT

Comment on attachment 377775 [details] Patch r=me

WebKit Commit Bot

Comment 4 2019-09-03 11:56:16 PDT

Comment on attachment 377775 [details] Patch Clearing flags on attachment: 377775 Committed r249436: <https://trac.webkit.org/changeset/249436>

WebKit Commit Bot

Comment 5 2019-09-03 11:56:18 PDT

All reviewed patches have been landed. Closing bug.

mitz

Comment 6 2019-09-03 12:00:01 PDT

Why don’t those clients just call in to WebKit and enable WebAuthn?

Sam Weinig

Comment 7 2019-09-03 12:03:44 PDT

(In reply to mitz from comment #6) > Why don’t those clients just call in to WebKit and enable WebAuthn? I agree, this is a very unorthodox way of enabling a feature. We tend to keep bundle checks to the absolute minimum. What is preventing MobileSafari and SafariViewServices from enabling this themselves? Why is this only an issue on iOS?

Jiewen Tan

Comment 8 2019-09-03 12:15:34 PDT

(In reply to Sam Weinig from comment #7) > (In reply to mitz from comment #6) > > Why don’t those clients just call in to WebKit and enable WebAuthn? > > I agree, this is a very unorthodox way of enabling a feature. We tend to > keep bundle checks to the absolute minimum. What is preventing MobileSafari > and SafariViewServices from enabling this themselves? Why is this only an > issue on iOS? Right, that's a good idea. I should do that instead. Will follow up with patches on Internal. In macOS, applications are not required to be sandboxed. If they are not, they don't need any entitlements to enable the feature. Also, we don't have that many browser like clients in macOS. They probably never hit this path. In iOS, however, the story is the opposite way. I was not quite sure if I should do it for macOS as well. Now, I think I should.

Sam Weinig

Comment 9 2019-09-03 16:01:21 PDT

(In reply to Jiewen Tan from comment #8) > (In reply to Sam Weinig from comment #7) > > (In reply to mitz from comment #6) > > > Why don’t those clients just call in to WebKit and enable WebAuthn? > > > > I agree, this is a very unorthodox way of enabling a feature. We tend to > > keep bundle checks to the absolute minimum. What is preventing MobileSafari > > and SafariViewServices from enabling this themselves? Why is this only an > > issue on iOS? > > Right, that's a good idea. I should do that instead. Will follow up with > patches on Internal. > > In macOS, applications are not required to be sandboxed. If they are not, > they don't need any entitlements to enable the feature. Also, we don't have > that many browser like clients in macOS. They probably never hit this path. > In iOS, however, the story is the opposite way. > > I was not quite sure if I should do it for macOS as well. Now, I think I > should. Matching iOS and macOS should generally be preferred, unless there is a really compelling reason not to.

Note You need to log in before you can comment on or make changes to this bug.