1. 37
  1.  

  2. 19

    I added the workaround for Lobsters. A better workaround would probably be to detect the <script> they MITM and replace the page contents with an explanation of the attack. Lobsters doesn’t serve js to logged-out users and I don’t want to start for this; it seems real likely they’ll be forced to stop by the platform or regulators within a few weeks.

    The author doesn’t say how they detected the attack. I wonder if it was CSP.

    1. 1

      The author doesn’t say how they detected the attack. I wonder if it was CSP.

      I wonder if a strict CSP could be effective against this, since they control the webview. If that is the case, it is just another good reason for any website owner to dedicate some time to write a proper policy.

    2. 5

      I’m of two minds about this. The way this feature is being used by apps like IG is awful, and I hope something will be done about it.

      But the underlying API — the native/JS bridging stuff in WKWebView — is very useful. You don’t get native access to the DOM, but you can get JS in the page and native app code to interact, which is important for hybrid technologies like React or PhoneGap. I’m doing this kind of thing myself.

      Also, I like in-app browsers because they’re better UX for one-off page views from an app. I can click a link in the app, read/navigate a bit, then hit the close button and I’m right back where I was in the app. Without this I’d be in my browser and I’d have to close the tab then switch back to the original app. (Android might have better navigation here, IIRC.)

      What I think Apple could easily do is apply cross-domain rules to WKWebView, so if the page origin isn’t one of your (app developer’s) domains, the app can’t inject scripts into it. That would give pretty good isolation: the renderer is actually in another process so the only way an app can inspect/access it at all is to go through the public API.

      1. 3

        Or they can just enforce the usage of SFSafariViewController for this purpose, which apps like Twitter use.

        1. 2

          If I understood the article correctly, there is no need for two minds. You can use webview for one-off views no problem, but if you’re injecting tracking code, and not for your app/website, then it’s kinda clear what’s going on. What you suggest is already possible, and as the article mentions, there are app-bound domains for that. What Meta is doing is exactly the opposite: sneaking into the sites that do not have Facebook code already.

          1. 4

            It’s unclear to me why this isn’t a straight case of copyright infringement. By injecting their JS into your copyrighted content, they are creating and distributing a derived work without your consent. There are statutory penalties in the US of $750-$30,000 per infringement ($300,000 for wilful infringement, which could probably be argued here) and case law to indicate that one copyrighted work counts as one infringement, so there should be sufficient cases here to bankrupt Meta.

            1. 1

              Yep. But how can I enforce it? I have 0 legal budget, Meta has practical infinity. How can I ensure their infringement is punished?

              1. 1

                You personally probably don’t, but you can probably persuade some lawyers to file a class-action lawsuit against Meta for this. They could easily start with damages more than 100 times larger than the total Meta market cap and negotiate from there.

            2. 4

              I wasn’t aware of App-Bound Domains, but my suggestion was effectively that they be automatically enforced unless the app adds an entitlement to opt out, which would flag some attention from Apple’s reviewers.

          2. 3

            $10B a year goes missing - it’s going to be all hands to the pumps to get it back.

            1. 2

              I don’t mean to denigrate this research, nor to minimize the significance of this finding. It really all makes me think that I am missing something…

              When I am browsing the web, I assume that my browser can track anything I do on any website, should it so choose. In order to serve its basic function, it must have that ability. As a consequence, I tend to carefully consider which browser I choose to use.

              I have never learned anything different about the in-app browsers that various applications provide. As far as I know, they are just browsers, and in order to function, they have access to the things I browse. As a consequence, I don’t like to use those in-app browsers for much of anything at all, and I always use the ability they provide to escape to my platform’s browser if I’m doing more than just reading a thing that’s available to the general public anyway.

              Is there some new thing they’re doing that’s worse than just “being a browser supplied by a party I don’t trust”? The attention this is getting makes me suspect so, but I don’t see it yet. And that worries me a little.

              1. 8

                The point is that they went out of their way to not just use a typical webview but modify and render the pages “themselves”

                1. 2

                  It is still a WKWebView, isn’t it? Is the script they’re injecting giving them more/nastier abilities than the DOM inspection they could do against whatever is loaded into the view, given that their app can talk to their own server at any time?

                  I find it very interesting that they’ve been caught at the kind of thing I (and clearly others) suspected they’d be doing.

                  I also wonder what countermeasures are available to Apple. Too many apps need to be able to interact with the DOM on pages they load this way for them to get rid of that completely. Maybe they could only allow that for markup that’s shipped with the app, and require SFSafariViewController for remote content?

                  Or for content hosted outside the domains the authors declare in advance?

                  I’m sure that would still break a great many apps.

                  1. 1

                    I don’t have any answers except yes, it needs to be some kind of webkit-webview (I think there were two kinda kf classes. Dunno if they both still exist). Apple does not allow any web rendering engine except its own.

                2. 3

                  Apparently they inject some tracking js into the pages you’re viewing, if I understood it correctly.

                  1. 3

                    (I’m still digging around and reading stuff as I comment…) That matches my understanding, but my question is more about whether/why that’s different than what you’d assume to be the situation prior to the publication of this research. It’s certainly interesting that they’ve been caught using this mechanism, but can’t they inspect the DOM of anything at all they load into their embedded browser anyway? Without this easy(ish)-to-detect injection? It’s been a while since I played with these controls on iOS, but whole classes of apps do or did depend on doing just that.

                    I think I’m still missing something.

                    1. 2

                      I’m sure they could be doing it more covertly, but I suppose it was easier for them to just inject the code they already had working.

                      Considering that Meta is Meta I already assumed that they’d be doing something like this (which is a reason I prefer the “Open in Safari” route where possible), but this is proof that they actually are. So it’s not a surprise, just confirmation of suspicion.

                      It’ll be interesting to see how they handle this when Apple comes asking questions; will they remove it, make it covert, and/or lawyer about it in court?

                      1. 1

                        I’m also a bit confused here. If you’re using someone’s program, they can phone home with whatever information they please. If you’re browsing the web from their program, they can quite obviously snitch on what you’re doing on the web.

                        Perhaps the issue here is that they can’t really ship their own browser engine (which would trivially allow the above) because Apple won’t allow it. So, they have to use Apple’s shipped browser engine, which would perhaps make this kind of spying harder. So maybe the actual news here is that they’ve found a way to still extract information from it by injecting JS code into web pages?

                        1. 2

                          No, that’s the point. On iOS you should be using the system provided browser inside your app to present web views or render HTML, the OS then limits what the host program can do with that view. Facetagram has built/packaged/shipped its own render to avoid this limitation and circumvent the OSS strict enforcement of User privacy.

                          1. 5

                            Nope. No one uses a custom browser engine on iOS, it’s effectively disallowed. They are using a regular WKWebView and using its API to inject a JS script that messes with the DOM.

                            1. 3

                              But apps are basically allowed at Apple’s discretion, so if they really wanted they could take a stand and flat out reject the app from their store. Now that would set a precedent!

                              1. 1

                                That was my understanding before this article. I should read it when less sleep deprived. Thanks for the correction

                          2. 1

                            I believe WKWebView renders out of process (that’s why it can JIT JS). Grabbing DOM from WKWebView without injecting JS is not straightforward (you probably can do by grabbing the data with one of the “snapshot” APIs, but need to reparse again). Many things to do with WKWebView probably is not straightforward due to this out of process and sandboxed nature.

                            1. 1

                              WKWebView does not support native-code access to the DOM the way the old WebView did (if only on MacOS.) What it does have is methods to run a JS script in the loaded window context, and to define JS hook functions that invoke native callbacks.

                              There are a lot of legit uses for this — HTML-based app packaging systems like PhoneGap/Cordova use it extensively, and I’m sure app-packaged React does too.

                              1. 1

                                There are a lot of legit uses for this — HTML-based app packaging systems like PhoneGap/Cordova use it extensively, and I’m sure app-packaged React does too.

                                I agree. I think what I was speculating could be a countermeasure would be tying the injection to the “app bound domains” that another poster pointed out and scrutinizing anything that needs that kind of feature for a non-bound domain.

                              2. 1

                                If it’s a WKWebView, the app can fully interact with the page by injecting JS.

                                If it’s a SFSafariViewController, the app can do very little: change the accent color of the Safari controls, choose from a few dismiss button options, adjust how the user can use the share sheet, and a few others.

                                Most apps that don’t open the user’s default browser opt to use the SFSafariViewController. As a user, I think the only way you could tell the difference is that if it doesn’t look like a SFSafariViewController, then it’s definitely WKWebView. I don’t think there’s a way to tell that an app definitely is using a SFSafariViewController (as a user).