Bug 208461 – Add flag to indicate that ITP state was explicitly set

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Brent Fulgham]

Test code sets ITP state explicitly through Internals SPI calls. Revise the ITP logic to recognize this condition by threading this state through the UIProcess and NetworkProcess so that we have less chance of getting confused about state.

[Brent Fulgham]

<rdar://problem/59960829>

[Brent Fulgham]

Created attachment 392172 [details]
Patch

[John Wilander]

Comment on attachment 392172 [details]
Patch

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

r=me with comments and fixes for the non-Cocoa builds.

> Source/WebKit/ChangeLog:10
> +        This patch takes the first step by adding a flag to the NetworkSessionCreationParameters

I try to always provide the namespace when reasoning about classes in text, in this case WebKit::NetworkSessionCreationParameters.

> Source/WebKit/ChangeLog:14
> +        Subsequent patches will enable ITP in Ephmeral sessions, allowing us to decouple

Landed in https://trac.webkit.org/changeset/257726.

> Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.cpp:183
> +    Optional<bool> itpStateWasExplicitlySet;

Since it's a boolean, I think we should go with present tense and lead with it, like isITPStateExplicitlySet.

> Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.h:85
> +    bool itpStateWasExplicitlySet { false };

Ditto.

> Source/WebKit/NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in:443
> +;; Needed for TCC

Missing period.

> Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb:678
> +;; Needed for TCC

Ditto.

> Source/WebKit/Scripts/process-entitlements.sh:48
> +        if (( "${TARGET_MAC_OS_X_VERSION_MAJOR}" >= 101600 ))

I assume nothing similar is needed for other platforms.

> Source/WebKit/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:165
> +        itpStateWasExplicitlySet(),

isITPStateExplicitlySet()

> Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h:198
> +    bool itpStateWasExplicitlySet() const { return m_itpStateWasExplicitlySet; }

isITPStateExplicitlySet()

> Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h:341
> +    bool m_itpStateWasExplicitlySet { false };

m_isITPStateExplicitlySet

Since we're capturing something explicit, is there a possible enum here? Like { implicitlyOff, implicitlyOn, explicitlyOff, explicitlyOn } ? I'm thinking if there's a way to capture the ITP on/off and explicitlySet Yes/No in one, self-documenting flag.

[Sam Weinig]

Comment on attachment 392172 [details]
Patch

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

> Source/WebKit/ChangeLog:9
> +        We would like to move to a more global concept of ITP being on or off.

Global in what sense? Why is this desirable?

> Source/WebKit/ChangeLog:15
> +        Subsequent patches will enable ITP in Ephmeral sessions, allowing us to decouple
> +        the ITP state from the WebsiteDataStore.

Why is this desirable? As ITP state is website data, it seems like coupling it with WebsiteDataStore is the right design.

> Source/WebKit/ChangeLog:18
> +        This patch also lays some groundwork for communicating with TCC for the purpose of
> +        checking if ITP is on or off, though it does not actually use this knowledge yet.

This seems unrelated to the change indicated in the title, and should be done in a different patch.

> Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm:1165
> +    if (!parameters.itpStateWasExplicitlySet)
> +        activateSessionCleanup(*this);

I think this deserves a comment explaining why cleanup doesn't happen when this flag is set. 

That said, how is this call to activateSessionCleanup() being tested now that it's not being called when itpStateWasExplicitlySet is called?

> Source/WebKit/UIProcess/API/C/WKWebsiteDataStoreRef.cpp:72
> +    websiteDataStore->useExplicitITPState();

From the name, it seems like "useExplicitITPState" would come along with some explicit state being used. But instead, it seems to be indicating that ITP is enabled. I think the terminology needs to be clearer here.

[Brent Fulgham]

Comment on attachment 392172 [details]
Patch

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

>> Source/WebKit/ChangeLog:9
>> +        We would like to move to a more global concept of ITP being on or off.
> 
> Global in what sense? Why is this desirable?

We no longer want a model where ITP is on for some WKWebViews, but not others. It no longer necessary to track this on a WebsiteDataStore level since this setting should be honored across all web views in the process.

>> Source/WebKit/ChangeLog:10
>> +        This patch takes the first step by adding a flag to the NetworkSessionCreationParameters
> 
> I try to always provide the namespace when reasoning about classes in text, in this case WebKit::NetworkSessionCreationParameters.

Will do!

>> Source/WebKit/ChangeLog:14
>> +        Subsequent patches will enable ITP in Ephmeral sessions, allowing us to decouple
> 
> Landed in https://trac.webkit.org/changeset/257726.

Oh, great!

>> Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.cpp:183
>> +    Optional<bool> itpStateWasExplicitlySet;
> 
> Since it's a boolean, I think we should go with present tense and lead with it, like isITPStateExplicitlySet.

Will do.

>> Source/WebKit/NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in:443
>> +;; Needed for TCC
> 
> Missing period.

Will do.

>> Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb:678
>> +;; Needed for TCC
> 
> Ditto.

Will do.

>> Source/WebKit/Scripts/process-entitlements.sh:48
>> +        if (( "${TARGET_MAC_OS_X_VERSION_MAJOR}" >= 101600 ))
> 
> I assume nothing similar is needed for other platforms.

Correct. They don't build down-level versions, so we don't need this check.

>> Source/WebKit/UIProcess/API/C/WKWebsiteDataStoreRef.cpp:72
>> +    websiteDataStore->useExplicitITPState();
> 
> From the name, it seems like "useExplicitITPState" would come along with some explicit state being used. But instead, it seems to be indicating that ITP is enabled. I think the terminology needs to be clearer here.

ITP could be enabled or disabled through this call. This flag notes that WebsiteDataStore's ITP value is the result of an explicit SPI call being made.

>> Source/WebKit/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:165
>> +        itpStateWasExplicitlySet(),
> 
> isITPStateExplicitlySet()

Will do.

[Brent Fulgham]

Created attachment 392213 [details]
Patch

[Brent Fulgham]

Created attachment 392227 [details]
Patch

[John Wilander]

Comment on attachment 392227 [details]
Patch

LGTM. Leaving the cq? in wait for a green light on the wpe and api-gtk bots.

[Brent Fulgham]

(In reply to John Wilander from comment #8)
> Comment on attachment 392227 [details]
> Patch
> 
> LGTM. Leaving the cq? in wait for a green light on the wpe and api-gtk bots.

wpe is now green.... just waiting for api-gtk now.

[Myles C. Maxfield]

I believe the absence of this patch is breaking the internal Apple bots

[WebKit Commit Bot]

Comment on attachment 392227 [details]
Patch

Clearing flags on attachment: 392227

Committed r257758: <https://trac.webkit.org/changeset/257758>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.