Bug 201369 - [WebAuthn] Enable WebAuthn by default for MobileSafari and SafariViewService
Summary: [WebAuthn] Enable WebAuthn by default for MobileSafari and SafariViewService
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jiewen Tan
URL:
Keywords: InRadar
Depends on:
Blocks: 181943
  Show dependency treegraph
 
Reported: 2019-08-30 17:39 PDT by Jiewen Tan
Modified: 2019-09-03 16:58 PDT (History)
10 users (show)

See Also:


Attachments
Patch (6.95 KB, patch)
2019-08-30 17:51 PDT, Jiewen Tan
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jiewen Tan 2019-08-30 17:39:30 PDT
Enable WebAuthn by default for MobileSafari and SafariViewService.
Comment 1 Radar WebKit Bug Importer 2019-08-30 17:39:53 PDT
<rdar://problem/54903724>
Comment 2 Jiewen Tan 2019-08-30 17:51:44 PDT
Created attachment 377775 [details]
Patch
Comment 3 Brent Fulgham 2019-09-01 11:02:41 PDT
Comment on attachment 377775 [details]
Patch

r=me
Comment 4 WebKit Commit Bot 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>
Comment 5 WebKit Commit Bot 2019-09-03 11:56:18 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 mitz 2019-09-03 12:00:01 PDT
Why don’t those clients just call in to WebKit and enable WebAuthn?
Comment 7 Sam Weinig 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?
Comment 8 Jiewen Tan 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.
Comment 9 Sam Weinig 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.