3 ms·
This appears to be caused by a bug in the Shared Web Credentials Daemon, which shares website credentials between apps and Safari. Once particular data is put i
by misterdata 11y ago
This appears to be caused by a bug in the Shared Web Credentials Daemon, which shares website credentials between apps and Safari. Once particular data is put in its database, it keeps crashing.
https://twitter.com/aveapps/status/714215571894747136 https://twitter.com/aveapps/status/714215571894747136
- tvmalsv 11y agoSafari kept crashing for me (and occasionally other apps, but don't know if related, just thought they were buggy apps) on my iPhone 5. I originally thought it was a problem with some sites being horribly broken, but it was also happening on mainstream sites such as wsj.com. After I installed the 9.3 update, the crashes stopped. Maybe the firmware update and device reset clears that database. Or it could be completely unrelated. Whichever, that's my anecdote.
- cristianbica 11y agoShared Web Credentials and App Links are set in the same file: you have an .entitlements where you set on what domains you want to have applinks, webcredentials. Then the iOS downloads from those domains a signed json file where you specify what apps can do applinks or webcredentials and you can limit those actions on some paths. What booking.com did is populated the paths section will 2.4M of urls instead of using wildcards (like "hotels/*"). The effect on the iOS is the Shared Web Credentials Daemon (the file is swcd) has a bug and with high amount of data it corrupts it's own database and fails. When opening absolute urls (schema://, ex: http:// http://) the iOS wants to pull some data from swcd which isn't running because of the corrupt database so it freezes the app opening the absolute url. From my point of view Apple is the only to be blamed (of course booking.com has been sloppy). They shipped a buggy core component (swcd) and they failed on the booking.com app approval process to detect this behavior.