Threads for jnye131

  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).

                1. 3

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

                  1. 1

                    Having bought a Psion 5 and the programming for EPOC book, I’m trying to decide where / how to get an XP box up and running for some hacking. Getting CF cards formatted correctly is proving to be difficult. Possibly because I’m using an SD to CF card adapter. I’ll try from a Linux box as per https://www.kianryan.co.uk/2021-07-14-psion-5mx/.

                    1. 1

                      Working with swift & swift UI it’s easy to bump into its limitations and be continually frustrated by them.

                      Nice to read about someone who is impressed with swift, makes me reconsider my stance on it.