{"id":293102,"date":"2019-07-23T07:39:42","date_gmt":"2019-07-23T14:39:42","guid":{"rendered":"https:\/\/css-tricks.com\/?p=293102"},"modified":"2019-07-23T07:39:42","modified_gmt":"2019-07-23T14:39:42","slug":"zoom-cors-and-the-web","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/zoom-cors-and-the-web\/","title":{"rendered":"Zoom, CORS, and the Web"},"content":{"rendered":"

It’s sorta sad by funny that that big Zoom vulnerability thing<\/a> was ultimately related to web technology and not really the app itself. <\/p>\n

There is this idea of custom protocols or “URL<\/abbr> schemes.”<\/a> So, like gittower:\/\/<\/code> or dropbox:\/\/<\/code> or whatever. A native app can register them, then URL<\/abbr>s that hit them get passed to the native app. iOS<\/abbr> has “universal links”<\/a> which are coming to the web<\/a> apparently. (Atishay Jain has an excellent write-up on them<\/a>.) But links like that don’t leave much choice — they will<\/em> open in the app. If your app has both web and native components, you might want to offer the user a choice. So, you use a regular URL<\/abbr> instead.<\/p>\n

<\/p>\n

\"\"<\/figure>\n

In order for that web page to open up a native app, apparently, the tactic used by many is to have it communicate with a server running on localhost on your own computer which uses a URL<\/abbr> scheme to open the native app. Clever, but I’ve heard sentiment from folks like:<\/p>\n