Bug 210772 – Set _STAttributionDisplayName to iOS WebContent Info plist

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Luming Yin]

<rdar://problem/62075201>

[Luming Yin]

Created attachment 397036 [details]
Patch

[Luming Yin]

Created attachment 397039 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 397039 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=397039&action=review

> Source/WebKit/ChangeLog:10
> +        Give the WebContent XPC service bundle a localizable CFBundleDisplayName to make it
> +        more easily identifiable.

WebContent sets its name dynamically, that's how it uses webpage domain name for Safari, or includes "Mail" in the name for Mail. 

Adding a static way to do the same appears confusing and thus undesirable.

[Luming Yin]

(In reply to Alexey Proskuryakov from comment #3)
> Comment on attachment 397039 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=397039&action=review
> 
> > Source/WebKit/ChangeLog:10
> > +        Give the WebContent XPC service bundle a localizable CFBundleDisplayName to make it
> > +        more easily identifiable.
> 
> WebContent sets its name dynamically, that's how it uses webpage domain name
> for Safari, or includes "Mail" in the name for Mail. 
> 
> Adding a static way to do the same appears confusing and thus undesirable.


Some frameworks are only able to read names statically declared in the Info.plist 
of an executable (or XPC binary in this case). Since these frameworks are unable 
to retrieve the dynamic name nonetheless, wouldn't it make sense to at least have 
a reasonable fallback attribution to avoid user confusion?

[Alexey Proskuryakov]

This depends on how the default is used. What seems like a reasonable fallback in one scenario can end up confusing users or being a security problem in another scenario. Obviously, not everything displayed by WebContent is a website.

On the technical level, I'm not sure about the implications:

1. How does CFBundleDisplayName interact with _kLSDisplayNameKey. Looks like we may get away for now with using one on macOS and another on iOS (but unsure what macCatalyst should do). But that seems fragile.

2. What else is CFBundleDisplayName used for. How bad is it to get "Website" as the name in those situations?

Documentation says "The user-visible name for the bundle, used by Siri and visible on the iOS Home screen", and "Use this key if you want a product name that's longer than CFBundleName."

[youenn fablet]

Created attachment 397446 [details]
Patch

[youenn fablet]

Created attachment 397447 [details]
Patch

[youenn fablet]

Created attachment 397448 [details]
Patch

[youenn fablet]

Created attachment 397451 [details]
Patch

[Geoffrey Garen]

Comment on attachment 397451 [details]
Patch

r=me

[EWS]

Committed r260650: <https://trac.webkit.org/changeset/260650>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 397451 [details].

[Per Arne Vollan]

Comment on attachment 397451 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=397451&action=review

> Source/WebKit/Scripts/process-entitlements.sh:155
> +    plistbuddy Add :com.apple.security.exception.mach-lookup.global-name array
> +    plistbuddy Add :com.apple.security.exception.mach-lookup.global-name:0 string com.apple.systemstatus.activityattribution

Is this also needed when issuing the extension?

[Geoffrey Garen]

(In reply to Per Arne Vollan from comment #12)
> Comment on attachment 397451 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=397451&action=review
> 
> > Source/WebKit/Scripts/process-entitlements.sh:155
> > +    plistbuddy Add :com.apple.security.exception.mach-lookup.global-name array
> > +    plistbuddy Add :com.apple.security.exception.mach-lookup.global-name:0 string com.apple.systemstatus.activityattribution
> 
> Is this also needed when issuing the extension?

Oh yeah, this looks like a mistake. The purpose of the extension is to avoid generally enabling access to this service in the WebContent process.

[WebKit Commit Bot]

Re-opened since this is blocked by bug 211172

[youenn fablet]

Created attachment 397946 [details]
Patch

[EWS]

Committed r260904: <https://trac.webkit.org/changeset/260904>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 397946 [details].