Bug 213510

<rdar://problem/64645720>

Hi Niklas! Thanks for filing. We have yet to publish the WWDC video session on what's new in WKWebViews. The title is "Discover WKWebView enhancements" and it'll go live on Thursday June 25th: https://developer.apple.com/videos/play/wwdc2020/10188/ You should find it useful. Meanwhile, could you explain to us what your app is doing, how it makes use of cookies in cross-site requests, how many different domains are involved in these requests, and whether those domains are part of the same organization or spread across multiple orgs? Thanks!

Hi John. Thanks for the suggestion, looking forward to this session. I noticed some changes to Safari briefly in the keynote. Our app is an hybrid app using the Apache Cordova framework. Because it is built with this approach basically every external connection is a cross-site request. When the app launches it loads a web app in WKWebView running on a custom scheme handler with an origin like "ionic://localhost". If you want more information how Cordova works and why some things are like they are contact me. I am happy to discuss this and I have done quite a bit of troubleshooting especially with CORS issues for Cordova apps. Users of our app now enter their credentials for their on-premise installation of our server side product into the app that is the second origin. The app running in the main webview on our apps internal origin should now use cookies to connect to the configured external origin to load resources like images with the uesers session. Basically there are just those two origins involved but not always the same two. Each enterprise customer uses its own origin (server) and one origin is just the internal origin the app is running on. We need this flexibility to run the app on one origin and connect to a server the users configures in the app at runtime. Cross-origin cookies are important for the connection to the server the user set in the app to make use of the user session the server solution provides. We had this exact problem with iOS 13.3 and fortunately we got a fix from you really quickly in one of the betas.

Thanks for the clarifications, Niklas. Could you provide us with info on what app this is and perhaps with a test account? You can email the details to me. Thanks!

(In reply to John Wilander from comment #4) > Thanks for the clarifications, Niklas. Could you provide us with info on > what app this is and perhaps with a test account? You can email the details > to me. Thanks! I hope you got my email earlier this week with details about the app I am talking about. I thought about mitigations for this issue in this particular app. Using WKURLSchemeHandler is presumably the best way to handle that. Probably we will discuss this more with the Cordova project https://github.com/apache/cordova-ios/issues/922 I started a poll targeted to Cordova developers on Twitter to ask how many use cookies in their app. Not that many people participated but 30% for yes on the first day turned to 50.7% for yes until today https://twitter.com/NiklasMaerz/status/1276417185204916225. That means to me that possibly some Cordova developers may notice issues when they test iOS 14. Using WKWebView (in Cordova) with this use case where the app runs on one origin and needs to talk to unknown servers on another origin has been very troublesome for me in the recent versions of iOS. iOS 13 had some challenges and we face very similar problems again with iOS 14. Living in fear of a breaking app with every iOS update is not a great developer experience. The "Discover WKWebView enhancements" session from WWDC 2020 was about the ever expanding API of WKWebView and I strongly believe an open discussion with the WebKit and Cordova communities would improve developing apps on the Cordova and iOS platform for many Cordova app developers out there. You can reach out to Cordova via email, Slack: https://cordova.apache.org/contribute/. I am happy to provide some insights around CORS and Cordova from my experience the last year or so.

(In reply to Niklas Merz from comment #5) > (In reply to John Wilander from comment #4) > > Thanks for the clarifications, Niklas. Could you provide us with info on > > what app this is and perhaps with a test account? You can email the details > > to me. Thanks! > > I hope you got my email earlier this week with details about the app I am > talking about. Yes, and thank you for that! I've shared the information with the team.

We just found this change: https://bugs.webkit.org/show_bug.cgi?id=213889 How does it affect this issue? As explained the app is running on a custom scheme but needs to connect to a server that is selected by the user at runtime. So it won't be possible to enter all servers at build time in Info.plist.

(In reply to Niklas Merz from comment #7) > We just found this change: https://bugs.webkit.org/show_bug.cgi?id=213889 > > How does it affect this issue? > > As explained the app is running on a custom scheme but needs to connect to a > server that is selected by the user at runtime. So it won't be possible to > enter all servers at build time in Info.plist. I don’t think that change affects you. It’s making sure custom schemes can be included in what we refer to as app-bound domains. You can read about app-bound domains here: https://webkit.org/blog/10882/app-bound-domains/

(In reply to John Wilander from comment #8) > (In reply to Niklas Merz from comment #7) > > We just found this change: https://bugs.webkit.org/show_bug.cgi?id=213889 > > > > How does it affect this issue? > > > > As explained the app is running on a custom scheme but needs to connect to a > > server that is selected by the user at runtime. So it won't be possible to > > enter all servers at build time in Info.plist. > > I don’t think that change affects you. It’s making sure custom schemes can > be included in what we refer to as app-bound domains. You can read about > app-bound domains here: https://webkit.org/blog/10882/app-bound-domains/ Or, I should say that change doesn’t affect how you use cookies.

That's what I thought. App-bound domains are not a solution from this problem. You commented in the other bug: > If possible, it would be nice to test that this'll work with the ITP relaxation for app-bound domains too. Why not relax ITP for custom schemes or webcontet from the apps bundle in WKWebView in some way? I am thinking about this for some time now. Cordova implemented a custom scheme to serve web content from the apps bundle. (The scheme and hostname is configurable now). So ITP does not protect users from malicious websites because the website is part of the app code. The webcontent in this case is just like a native app that want's to talk to external servers with cookie sessions. Why not introduce a custom scheme for serving local content (like localhost) and relax ITP for that scenario? Using file: has other problems with web content and CORS. Just thinking out loud. I am not sure about further implications and other problems.

I just noticed that the new behavior with ITP enabled only happens if the app is built with Xcode 12. The same app built with the release version of Xcode and installed through Testflight or the App Store works just fine. I was a bit confused at first so sharing this for others here. Any news APIs/options for hybrid apps?. We can use WKURLSchemeHandler to solve many CORS/ITP related issues but these solutions always feel very fragile and not future proof. As a Cordova developer I don't think it's good to have user apps break every major iOS version and us as framework and app developers needing to find a workaround for these breaking issues. WKWebView should be a solid foundation for hybrid apps. General web content requires other security considerations than web content that is bundled with the native app. Hybrid apps would just a need a good way to server content from the apps bundle and make requests to the internet without these security measures (CORS, ITP etc.) that are critical for the general web content. WKWURLSchemeHandler is a good start but it could be better.

Just wanted to add my two cents that this is a really big deal. All cookies not working in Cordova is a serious regression, and even though some solutions help, none of them fix all of the problems. We need help from Apple's end and it seems very discouraging that discussion stopped here nearly three months ago.

(In reply to Todd from comment #12) > Just wanted to add my two cents that this is a really big deal. All cookies > not working in Cordova is a serious regression, and even though some > solutions help, none of them fix all of the problems. We need help from > Apple's end and it seems very discouraging that discussion stopped here > nearly three months ago. Thanks for commenting. As far as I know, we have received very few developer reports of this being an issue. That may be because developers aren't testing with betas or something else. I could also have missed them but I hope that's not the case. Niklas Merz tested right away and has communicated plenty with us on this change, as can be seen above. However, it would be good to hear from more developers both at WWDC sessions and during the long beta period after. There are a lot of changes that go into major releases and bugs that need to be screened, fixed, and put to test in subsequent betas. In this case, the change is deliberate and we'd have to understand more user cases to be able to consider any adjustments. The questions I asked Niklas Merz back in June are still valid: Could you explain to us what your app is doing, how it makes use of cookies in cross-site requests, how many different domains are involved in these requests, and whether those domains are part of the same organization or spread across multiple orgs?

Generally(In reply to John Wilander from comment #13) > (In reply to Todd from comment #12) > > Just wanted to add my two cents that this is a really big deal. All cookies > > not working in Cordova is a serious regression, and even though some > > solutions help, none of them fix all of the problems. We need help from > > Apple's end and it seems very discouraging that discussion stopped here > > nearly three months ago. > > Thanks for commenting. As far as I know, we have received very few developer > reports of this being an issue. That may be because developers aren't > testing with betas or something else. I could also have missed them but I > hope that's not the case. Shoot, I wish I could get feedback like this every time I complained lol. > Niklas Merz tested right away and has communicated plenty with us on this > change, as can be seen above. However, it would be good to hear from more > developers both at WWDC sessions and during the long beta period after. > There are a lot of changes that go into major releases and bugs that need to > be screened, fixed, and put to test in subsequent betas. In this case, the > change is deliberate and we'd have to understand more user cases to be able > to consider any adjustments. I'll try to be better about testing the betas in the future. It can be tricky because I work on one mac, and doing the iOS betas sometimes necessitates the XCode betas and the Safari beta and all of that. It can be tough to check > The questions I asked Niklas Merz back in June are still valid: > Could you explain to us what your app is doing, how it makes use of cookies > in cross-site requests, how many different domains are involved in these > requests, and whether those domains are part of the same organization or > spread across multiple orgs? So it's mainly one organization. Our organization's staging app is using the domain of https://staging.silverstreet.io for all of its networking, but with how Cordova works, our requesting URL is ionic://localhost. Maybe I'm able to match up the domains somehow using the custom schemes in Cordova, but I haven't figured it out yet. We also feed some data to google tag manager (analytics) and Twilio (messaging), but these aren't crucial to all requests after login like the onsite cookies are. We don't do anything fancy or non-standard I believe. We have an onsite log in flow that uses secure httpOnly cookies to authenticate the user. These cookies are used on subsequent network requests as well as websocket upgrade requests to subscribe to real-time updates.

Huge thank you to Niklas Merz for leading the discussions on these issues. I am also a Cordova (hybrid app) developer. I'd imagine there are a lot of developers that are just now seeing their employers prioritize the transition from UIWebView to WKWebView and will be facing this issue soon if not already. Our static content is packaged into the app and could be served from a custom schema (eg. foo://mydomain.com), but every XHR request will be over https, (eg. https://mydomain.com). A login request works fine, but the cookies in the header of the response are NOT set, and therefore subsequent API requests (which require authentication cookies) fail. I have NOT tried XCode 12 yet, but in light of the "very few developer reports of this being an issue" comment, I decided to make an account and chime in here. Cross origin cookies are critical to our app, and the track record of this issue makes me extremely nervous that it could break at any time: * broken in iOS13: https://bugs.webkit.org/show_bug.cgi?id=140205 * fixed in 13.2: https://bugs.webkit.org/show_bug.cgi?id=200857#c39 * broken again in 13.3: https://bugs.webkit.org/show_bug.cgi?id=204109 * fixed in 13.3 beta 4: https://bugs.webkit.org/show_bug.cgi?id=204109#c25 * broken again on ios14: (this issue) If you're looking for more developers to say "this is an issue" I'd be happy to start posting a link to this issue from the github and stackoverflow questions about it. Thanks all for sharing your experiences/ideas.

(In reply to Adam Davenport from comment #15) > Huge thank you to Niklas Merz for leading the discussions on these issues. > > I am also a Cordova (hybrid app) developer. I'd imagine there are a lot of > developers that are just now seeing their employers prioritize the > transition from UIWebView to WKWebView and will be facing this issue soon if > not already. Our static content is packaged into the app and could be served > from a custom schema (eg. foo://mydomain.com), but every XHR request will be > over https, (eg. https://mydomain.com). A login request works fine, but the > cookies in the header of the response are NOT set, and therefore subsequent > API requests (which require authentication cookies) fail. I have NOT tried > XCode 12 yet, but in light of the "very few developer reports of this being > an issue" comment, I decided to make an account and chime in here. Cross > origin cookies are critical to our app, and the track record of this issue > makes me extremely nervous that it could break at any time: > > * broken in iOS13: https://bugs.webkit.org/show_bug.cgi?id=140205 > * fixed in 13.2: https://bugs.webkit.org/show_bug.cgi?id=200857#c39 > * broken again in 13.3: https://bugs.webkit.org/show_bug.cgi?id=204109 > * fixed in 13.3 beta 4: https://bugs.webkit.org/show_bug.cgi?id=204109#c25 > * broken again on ios14: (this issue) > > If you're looking for more developers to say "this is an issue" I'd be happy > to start posting a link to this issue from the github and stackoverflow > questions about it. Thanks all for sharing your experiences/ideas. Hi, Adam, and thanks for commenting! “Broken” is not an accurate description of how this works in iOS 14. It’s an announced, deliberate change. WKWebView now has tracking prevention enabled by default. The same questions are still valid: Could you explain to us what your app is doing, how it makes use of cookies in cross-site requests, how many different domains are involved in these requests, and whether those domains are part of the same organization or spread across multiple orgs?

Thanks Adam Davenport for putting together the track record. That's the timeline how it changed in the last year.

I tried to change the title of this bugzilla entry since it's indeed not really a bug. I am currently working on a built-in Cordova feature to get around these tighter limitations. But it does not feel right. Let's see if it becomes part of Cordova. Like said previously it would be awesome if hybrid frameworks like Cordova would have a way in WebKit to serve their bundled web code with a kind of special origin with the same freedoms like other native apps. WKUrlSchemeHandler is very powerfull and serves us kind of ok for this purpose but if WebKit could smooth out some rough edges it could have a big impact on many apps.

John Wilander by "broken" I meant *my app* is broken, sorry for the miscommunication. What worked with UiWebView now no longer works in WkWebView. > Could you explain to us what your app is doing I'd imagine all Cordova apps are roughly the same; I have a static website that makes XHR requests to a remote server, and Cordova packages it up into an app that I can deliver to customers. > how it makes use of cookies in cross-site requests Users make an XHR request with credentials. The response has authentication cookies which are required to be sent with every subsequent request. This isn't happening. > how many different domains are involved in these requests 2ish, the "fake" domain defined by my app scheme, eg. foo://mydomain.com this can be anything I want afaik, except http or https), and my remote API hosted under https://mydomain.com. > and whether those domains are part of the same organization or spread across multiple orgs Same organization. As I'm just a consumer of Cordova, I defer to Niklas regarding what Cordova is doing under the hood. I'm not done with my investigation, but in response to "it would be good to hear from more developers" I just felt obliged to say "I too am struggling with this"

(In reply to Adam Davenport from comment #19) > John Wilander by "broken" I meant *my app* is broken, sorry for the > miscommunication. What worked with UiWebView now no longer works in > WkWebView. > > > Could you explain to us what your app is doing > > I'd imagine all Cordova apps are roughly the same; I have a static website > that makes XHR requests to a remote server, and Cordova packages it up into > an app that I can deliver to customers. > > > how it makes use of cookies in cross-site requests > > Users make an XHR request with credentials. The response has authentication > cookies which are required to be sent with every subsequent request. This > isn't happening. > > > how many different domains are involved in these requests > > 2ish, the "fake" domain defined by my app scheme, eg. foo://mydomain.com > this can be anything I want afaik, except http or https), and my remote API > hosted under https://mydomain.com. > > > and whether those domains are part of the same organization or spread across multiple orgs > > Same organization. Thank you! This is useful information. > As I'm just a consumer of Cordova, I defer to Niklas regarding what Cordova > is doing under the hood. I'm not done with my investigation, but in response > to "it would be good to hear from more developers" I just felt obliged to > say "I too am struggling with this" Sure. You're not on the hook to explain Cordova to me. :) However, we always try to understand what the needs and requirements are before considering solutions. "Allow all cookies" is an obvious solution but it has downsides that we are deliberately trying to remove. What it comes down to is how to provide just enough functionality for apps while not re-creating, in this case, cross-site tracking. As for hearing from multiple developers, it's very important for us to get details from a diverse set of sources. Sometimes you have a single developer who is very vocal about a use case that turns out to be very specific to their app or website. With a more complete picture, we are able to create solutions that serve many more developers and is much more stable. Hunting piecemeal use cases can get you to a messy place in the end.

For the case described by Adam where an app needs to communicate with one domain (or a small of domains), would listing those specific domains in WKAppBoundDomains allow those cookies to work as expected? (Guessing based on bug 210674)

My app is broken too. I am using cordova-plugin-ionic-webview (which uses WkWebView under the hood) I am sending xhr requests for the user to log in: (from ionic://app/**) and even though it receives those cookies (I use one as session and other as a way to know if the user has previously logged in with the device and if not, send them a mail whenever they login). As a hack for this, I am using Niklas proxy to do native HTTP requests, but it's not ideal.

Would any developers running into this problem be willing to share the following? 1. How many different domains do you need to share cookies with? (It sounds like maybe two or three in many cases?) 2. Does your application need to interact with the general web using script or style sheet injection? 3. Could you share the name of your iOS App? If you are not comfortable posting that here, feel free to e-mail me at bfulgham@apple.com.

(In reply to Darryl Pogue from comment #21) > For the case described by Adam where an app needs to communicate with one > domain (or a small of domains), would listing those specific domains in > WKAppBoundDomains allow those cookies to work as expected? (Guessing based > on bug 210674) That's an off-by-default experimental thing that isn't available in normal use. To clarify: When App-Bound domains are in use you have this behavior: (1) WKWebView would only have script injection and style injection capabilities on the sites listed in the set of app bound domains. (2) WKWebView marked as 'app bound' would be unable to navigate to domains outside of that set. I.e., if you wanted to support general web browsing, you would need to create a separate WebView for that use. This flag would have the following effect: (3) Cross-site cookie access between domains in the App-bound domain list would be permitted, and they would be protected from deletion. Is that behavior sufficient to meet your needs? Or would you still have problems with that mode?

(In reply to Brent Fulgham from comment #24) > > (3) Cross-site cookie access between domains in the App-bound domain list > would be permitted, and they would be protected from deletion. > > Is that behavior sufficient to meet your needs? Or would you still have > problems with that mode? I think that would be sufficient for the common use case with Cordova (assuming a local scheme like app://localhost is counted as permitted). We already have a Cordova-enforced list of "allowed navigation" domains, so we'd likely want to encourage opting-in to the App-Bound WebView behaviour too.

Hi all, I've submitted my fe(In reply to Brent Fulgham from comment #23) > Would any developers running into this problem be willing to share the > following? > > 1. How many different domains do you need to share cookies with? (It sounds > like maybe two or three in many cases?) > > 2. Does your application need to interact with the general web using script > or style sheet injection? > > 3. Could you share the name of your iOS App? > > If you are not comfortable posting that here, feel free to e-mail me at > bfulgham@apple.com. Hi, emailed this, thanks! Did we have a status update on this?

(In reply to Brent Fulgham from comment #23) > Would any developers running into this problem be willing to share the > following? > > 1. How many different domains do you need to share cookies with? (It sounds > like maybe two or three in many cases?) > > 2. Does your application need to interact with the general web using script > or style sheet injection? > > 3. Could you share the name of your iOS App? > > If you are not comfortable posting that here, feel free to e-mail me at > bfulgham@apple.com. I emailed also my feedback to you. Any status update highly appreciated. Thank you very much. Daniel

Thought I would chip in here also but seems Niklas has done a good job in outlining the problem. For my apps and we have 4 or so in the app store we need to have access to a list of max 3 domains per app. Again and like all the others it appears to only occur on latest xCode 12 and using xhr requests with cookie stripping (ITP). I believe you have all the information needed but if there is anything I can add please ask otherwise I am awaiting a solution. I am in a critical release window right now for a major update and thinking of compiling on XCode 11 as I am reluctant to implement a whole heap of bespoke work arounds.

Hi All, Are there any news on this? Is the behaviour you described: "(3) Cross-site cookie access between domains in the App-bound domain list would be permitted, and they would be protected from deletion." testable? Sorry if this was announced somewhere else, but I could not find anything. Thanks Daniel

Are there any updates? With iOS 14 and XCode 12, even if I request Tracking permission from users, and if I specify `WKAppBoundDomains` in my Info.plist and `limitsNavigationsToAppBoundDomains` the Cookies are not sent with XHR requests to those third-party domains. Is this expected?

Did anyone got this working with by adding NSCrossWebsiteTrackingUsageDescription as suggested in the last part of the below documentation? Intelligent Tracking Prevention in WKWebView: https://webkit.org/blog/10882/app-bound-domains/ Best Regards, Sami

I managed to get it to work only after adding NSCrossWebsiteTrackingUsageDescription and going in Settings and enabling 'Allow Cross-Website Tracking'. But since this requires user intervention is not desirable so are there any updates / plans on this?

I just checked the issue in Cordovas bug tracker again and just looking at the thumbs up count I suspect there are quite a few developers affected by this issue. https://github.com/apache/cordova-ios/issues/922

Our app too was affected by this change. Our use case is very similar to the one described by Niklas. We have a hybrid app using the Apache Cordova framework. As Niklas already said, when the app launches it loads a web app in WKWebView running on a custom scheme handler with an origin like "ionic://localhost". Using that approach, almost all external connections are considered cross-site requests. In our use case, the user provide a server URL (every client has their own backend server). The app then proceeds to load content from that external URL (such as full pages and images) with the user session. The content only loads if I set the 'NSCrossWebsiteTrackingUsageDescription' and go to the settings and enable 'Allow Cross-Website Tracking'. For the rest, I can fully quote Niklas: "We need this flexibility to run the app on one origin and connect to a server the users configures in the app at runtime. Cross-origin cookies are important for the connection to the server the user set in the app to make use of the user session the server solution provides."

My company also has an app that has been affected by this change. It is very similar to the apps described in previous comments. It is Apache Cordova with web content bundled locally. The local content interacts with remote content in our hosting domain in the following manner: 1. The local HTML includes an IFrame to load HTML/JS content from the remote hosting domain. 2. The IFramed pages makes XHR requests to the hosting domain, which is the same domain from which the IFrame content was served. Authentication with the hosting domain uses cookies. Our server is emitting the cookies, and has taken the necessary steps to support CORS (Access-Control headers and same-site:none attribute on cookies). We run our app on multiple mobile platforms. Only on iOS are the cookies blocked. To clarify, by "blocked" I mean that the cookies are returned to the iOS app, but they are neither persisted nor included in subsequent HTTP requests.

WTF? No really, WTF? Why on earth app-bound domains (in fact all of them are: primary domain + subdomains) are not sharing cookies? This is do dumb. You guys haven't heard and not aware of session cookie commonly shared across all subdomains (ie. *.myapp.com)? I understand the point of ITP and apperciate Apple for taking care of my privacy by blocking annoying tracking bloatware, but why you didn't think about legit stuff? There are a lot of discussions going on on github, SO and other sites regarding this breaking change with no way to easily work around the constraint without dirty hacks or regressions in UX ("Allow Cross-Website Tracking" is confusing and misleading, because user session is not "Tracking"). What we should do given that WKWebView provides an essential part of our app hosted on dozen of subdomains (apps, resources, cdn, content, api) and we are a team of web developers and have no iOS developer in house? Now most of our team (Engineering, Management, QA) struggles in trying to find a workaround ASAP because otherwise our app would be broken for thousands of our users. Shame on you.

(In reply to Mad from comment #36) > WTF? No really, WTF? > > Why on earth app-bound domains (in fact all of them are: primary domain + > subdomains) are not sharing cookies? This is do dumb. Cookies matching the top frame registrable domain (eTLD+1) are available according to the regular cookie scoping rules (domain attribute etc). No blocking of those. > You guys haven't heard and not aware of session cookie commonly shared > across all subdomains (ie. *.myapp.com)? Session cookies typically mean non-persistent cookies. What you refer to are same-site cookies or perhaps same-party cookies. Regardless, the cookies you refer to are available and not blocked if their domain indeed matches the top frame registrable domain. > I understand the point of ITP and apperciate Apple for taking care of my > privacy by blocking annoying tracking bloatware, but why you didn't think > about legit stuff? > > There are a lot of discussions going on on github, SO and other sites > regarding this breaking change with no way to easily work around the > constraint without dirty hacks or regressions in UX ("Allow Cross-Website > Tracking" is confusing and misleading, because user session is not > "Tracking"). As mentioned, the "session cookies" you refer to are available. > What we should do given that WKWebView provides an essential part of our app > hosted on dozen of subdomains (apps, resources, cdn, content, api) and we > are a team of web developers and have no iOS developer in house? > > Now most of our team (Engineering, Management, QA) struggles in trying to > find a workaround ASAP because otherwise our app would be broken for > thousands of our users. > > Shame on you. We try to use a respectful tone in these bug comments. I hope you are willing to do so too.

(In reply to John Wilander from comment #37) > As mentioned, the "session cookies" you refer to are available. We use a similar approach (Cordova) described in the comments above and having the same issues. The only way to work around this is to manually enable "Allow Cross-Website Tracking" toggle, albeit there is nothing related to "Tracking". Session cookie is a valid example. Typically web apps have more shared data required across app-bound subdomains, including all sort of cookies (not only non-persistent), non-stripped header values ("Referrer", "Origin") and custom headers (CORS). Everything worked perfectly until this breaking change introduced along with ITP. It has been 7 months since the bug was reported here and still no good solution available for all cases.

(In reply to Mad from comment #38) > (In reply to John Wilander from comment #37) > > > As mentioned, the "session cookies" you refer to are available. > > We use a similar approach (Cordova) described in the comments above and > having the same issues. The only way to work around this is to manually > enable "Allow Cross-Website Tracking" toggle, albeit there is nothing > related to "Tracking". > > Session cookie is a valid example. Typically web apps have more shared data > required across app-bound subdomains, including all sort of cookies (not > only non-persistent), non-stripped header values ("Referrer", "Origin") and > custom headers (CORS). Then the domains you refer to do not match the top frame, they are third-party cookies, and subdomains or no subdomains doesn't matter. If the resource domain doesn't match the top frame's registrable domain, it is considered a third-party request. I just wanted to make that clear so that you don't think this has anything to do with subdomains. > Everything worked perfectly until this breaking change introduced along with > ITP. > > It has been 7 months since the bug was reported here and still no good > solution available for all cases.

Hello there Need to say that lots of us share Mad's frustration in regards to this issue, and even if there are workarounds they are time consuming and hard to implement. Here is our situation, we have a cordova application packed and working perfectly on ios. The app is upgraded to latest cordova platform, hence running under app://localhost and is connecting to 2 different APIS, one https://db.domain.com:1234 (that is used for authentication and data) and https://db.domain.com:4567 (for other functionality). The problem is that even if the first call to https://db.domain.com:1234/_session returns correctly with the header Set-Cookie: AuthSession=yyyy; Version=1; Expires=Sat, 13-Mar-2021 11:23:42 GMT; Max-Age=2600000; Secure; Domain=domain.com; Path=/; HttpOnly; SameSite=None The next call to https://db.domain.com:1234/ doesn't have the cookie anymore and any subsequent calls fail (and ofc any calls to https://db.domain.com:4567 as well) So, just to get things a little clearer the problem is the fact we are running the app under app://localhost (top frame registrable domain (eTLD+1)) but consuming an API from https://db.domain.com hence (which is not matching the same site rule). Since we cannot control that the only option would be to list these accepted domains in a setting. So the questions is, is there any chance of getting this fixed by the Apple team, or is actually someone working on it, are any estimations on when will this be shipped? Or should we just try to find alternatives (again, quite hard to implement) Thanks

To respond to the "has anyone got this working" posts, I finally got my Cordova app working! The authentication cookie set by the login response from my remote server now persists for subsequent requests, and even seems to persist in IFrames and the InAppBrowser plugin! > The App-Bound Domains feature takes steps to preserve user privacy by limiting the domains on which an app can utilize powerful APIs to track users during in-app browsing. Applications that opt-in to this new feature can specify up to 10 “app-bound” domains using a new Info.plist key — WKAppBoundDomains If you're like me and your app needs to talk to 10 or fewer remotes, you can add your remote domain to your plist file and opt in using limitsNavigationsToAppBoundDomains. https://webkit.org/blog/10882/app-bound-domains/ AppBoundDomains only affect iOS14, and don't exist prior, seems to work fine in iOS 13 without them. You'll also need to configure your remote to enable CORS, including adding the origin defined by the scheme/hostname (eg. app://localhost or foo://mydomain.com) in the cordova config. This approach won't work for OP (Niklas) since his app doesn't know the domain of the remote at build time. For most of us, however, I think the issue with authentication cookies not persisting can be resolved by setting up AppBoundDomains and CORS. This does NOT work out of the box, however, and I've created a github issue for Cordova-ios to support AppBoundDomains, since I currently need to both modify my plist and opt in to AppBoundDomains after building cordova. That issue can be tracked here: https://github.com/apache/cordova-ios/issues/1088. In addition, you'll need to set withCredentials: true on your XHR requests to enable cookies to be set/sent cross origin! https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials Kinda frustrating that this isn't all documented somewhere (cordova docs), but hopefully I've done that here. I hope you guys find this helpful, feel free to share successes/failures/questions to help others. Thanks all.

I tried changing my app's scheme/hostname to "foo://bar.baz" instead of "foo://localhost" and I'm no longer able to persist cookies on XHR requests to http://localhost. Both "localhost" and "bar.baz" are listed in WKAppBoundDomains and I added foo:bar.baz as an allowed origin on localhost. So it looks like in its current state, hybrid apps will only be able to persist cookies on calls to one domain?

I want to throw my hat in the ring here. I have a similar app setup to Ricardo Sohn. We don't know what server will be connected to until runtime as they are customer hosted and often times there is a load balancer in front of that back-end the app may be connecting to which will also be inserting its own cookie. I am currently using Niklas's proxy similar to others in this thread but there has to be a better way.

i face the same issue on the roblox ids application get from this website https://robloxidshub.com/. Still looking for the solution anyone here guide me?

Hi all, Let's consider the following situation (that I am struggling currently with): - I have IoS app A - IdP SSO Proxy - 2 federated IdP's -> IdP1 and IdP2 1. The user choose IdP1 to register with 2. He gets the confirmation email 3. Open email app and click on the confirmation 4. The IdP1 process all the data and perform a post back to IdP proxy 5. The IdP proxy cannot find his cookies, because is no shared cookie storage between apps developed by different developers and even if the use is authenticated, throws a 400 because can't match the correlation id None of the cookies are cross-domain, the only problem it is with the cookie storage, and basically it is very, very difficult to use federated SSO with native apps, or at least in this moment I am running out of ideas. Regards, Aurel

Has anyone found a resolution to this issue? Now that building with Xcode 12 is required, we can no longer get our cookies to persist between ionic://localhost and our iframes without setting "NSCrossWebsiteTrackingUsageDescription" in our plist. We have tried using App Bound Domains with the few domains that we need to support and have been unsuccessful in restoring cookie functionality. Setting "NSCrossWebsiteTrackingUsageDescription" is confusing for our users because we aren't using cookies beyond domains that we own. We have also seen that the opt in rate for this setting is around 4%. https://www.engadget.com/ios-14-5-users-reject-app-tracking-165309407.html This doesn't work for us because without this setting the app will not work as expected and we can't have 96% of our users reaching out for support.

We found a work-around for Cordova mobile apps, so not sure if this applies to your case or not. In the config.xml file for your Cordova app, you can set the "HostName" preference to the domain name of your app, like this: <preference name="HostName" value="domain.example.com"/> Where the domain name is that of the content you are loading into the WebView. After doing this, iOS stopped blocking cookies from that domain.

cookies is the main pain point of WKWebView users, if you don't receive a lot of reports is probably because users are not aware of this bug tracker and they report in the regular Apple issue tracker, which is a black box. I have reported a few issues there in the past and as far as I know, they have not been fixed not received any response. Also, most WKWebView users use it through Apache Cordova or Ionic Capacitor, so they report the issues to them instead of reporting to you. I try to point them to this direction when they do. In example, you can see this Capacitor issue about document.cookie not working when using a custom scheme with 60 comments. https://github.com/ionic-team/capacitor/issues/1373 there are others about XHR cookies too

(In reply to jcesarmobile from comment #48) > cookies is the main pain point of WKWebView users, if you don't receive a > lot of reports is probably because users are not aware of this bug tracker > and they report in the regular Apple issue tracker, which is a black box. I > have reported a few issues there in the past and as far as I know, they have > not been fixed not received any response. > > Also, most WKWebView users use it through Apache Cordova or Ionic Capacitor, > so they report the issues to them instead of reporting to you. I try to > point them to this direction when they do. > > In example, you can see this Capacitor issue about document.cookie not > working when using a custom scheme with 60 comments. > https://github.com/ionic-team/capacitor/issues/1373 > > there are others about XHR cookies too I'm not aware of any cookie bugs for WKWebView. There is cookie blocking according to the rules of Intelligent Tracking Prevention on by default, but that is intended behavior. Do you have any bugs to report that you believe is not intended behavior? Or do you have enhancement requests? If so, please file separately. Thanks! The originator of this bug, Niklas, has reported actual cookie bugs to us a few times and all of those should be resolved already.

yeah, sorry just wanted to chime in to give you some insights about your "very few developer reports of this being an issue" comment.

(In reply to jcesarmobile from comment #50) > yeah, sorry just wanted to chime in to give you some insights about your > "very few developer reports of this being an issue" comment. No worries. It's helpful to know, especially if we can get a clear explanation of the use cases. You can see that in the conversation above "Could you explain to us what your app is doing, how it makes use of cookies in cross-site requests, how many different domains are involved in these requests, and whether those domains are part of the same organization or spread across multiple orgs?"

Some time has passed and I can share the sentiment that cookies are the main pain point of WKWebView. I have been watching a few Cordova issues where some people try to figure out solutions for cookie problems. Aside from some weird behaviors of NSHTTPCookieStorage, I never really fully understood, there are no actual bugs right now AFAIK, but ITP brings some app devs in trouble. Probably many don't identify it right away as the cause of their issues. Maybe that's the reason we don't get many reports. What could help here would be a way to debug ITP in WKWebView, like a special indication for blocked tracking in Safari Web Inspector? A handful of Cordova developers got directly in touch with me because of my bug reports and blog posts. With some of them I talked extensively about their use cases of CORS cookies and possible alternatives. The biggest use case is similar to mine: Their app connects to a backend that's either not in their control or does not support an authentication without cookies. Often it's just one or two domains I think. Cordova/Capacitor apps are almost never a general web browser, but load web content from the app bundle. ITP does not really make sense in this context as WKWebView is just used to built a "native app with web technology". If Cordova apps browse web pages most of the time the InAppBrowser plugin is used which opens another WKWebView where ITP would make sense again. Is it unthinkable to have an option to disable for WKWebView instances? Maybe having ITP disabled when a WKWebView uses WKURLSchemeHandler to serve content from a custom scheme would be a good compromise. WKWebViews used for web browsing where ITP is good won't be using custom schemes but Cordova/Capacitor apps often do to serve their content.

Hi John Wilander We are using an app with SSO feature where our enterprise customer can you use different domains to login. This is working fine since we are not using App Bound Domains yet. Now we wanted to survey our users for NPS using Delighted(https://delighted.com) which uses cookies to survey user once in the throttle period and this don't seems to work as third party cookies are blocked. We can't use App Bound Domain as this feature would restrict us to 10 domains only and would impact our customers who use SSO for login. Can you share a workaround for this. Thanks and Regards Pradeep Gupta

We've now hit up against this issue as well. We have a Capacitor app which makes requests to a backend service that we own. It employs token-based authentication with a refresh token. The auth token doesn't need to be secured, but the refresh (long-living) token does. We intended to use secure, httponly cookies for this refresh token, but that is now not possible due to ITP. Presenting the ITP modal to users is unacceptable UX, and there is a high likelihood of "tracking" being rejected, which means we would have to compromise on security anyway. This puts us in a corner whereby we'll have to implement the authentication mechanism natively.