Safari and iOS users: Your browsing activity is being leaked in real time | Hacker News Reader

Safari and iOS users: Your browsing activity is being leaked in real time

arstechnica.com

48 pointspanarky19 comments

Dupe:

https://news.ycombinator.com/item?id=29947396

https://news.ycombinator.com/item?id=29951385

Safari has had lots of major issues recently https://twitter.com/jaffathecake/status/1389493762129375232 https://bugs.webkit.org/show_bug.cgi?id=226547

Luckily I'm using Firefox on iOS, oh wait... It's all WebKit anyway. Only workaround is disabling javascript, which is good enough for HN I guess.

It really amazes me that this is a thing that made it production, but it seems that browsers are just so complex now that something seemingly obvious like this can sneak by. What really shocks me is that Apple have known about this since at least October last year yet only appear to have started to do anything about it once it's in the public eye.

You only get control over your computer if you learn Linux.

Yes yes I'm aware of the hardware chips from Intel that let intelligence agencies take over computers but they are not used constantly, streaming data every day to Apple or Google. It's a huge difference.

I'm a former desktop linux user, and manage Linux servers at work. I've tried everything from Ubuntu to Arch to Gentoo; Linux on the desktop just is nowhere near the level of software polish that you get from Apple, let alone the excellent hardware that is my M1 MacBook. I understand that in theory there's a major difference in privacy, but honestly speaking, do you really think it makes a difference? I'm going to use the internet anyway, and if an idiot like me can think up a million ways to bypass tracking protection from my browser / ad blocker, do you really think using your fancy tracking-free distro makes any change besides giving you a more unique useragent?

Either way, I use a smartphone which is going to be Apple or Google which voids all of this anyway

At some point Linux will be usable on the Apple M1 devices:

https://asahilinux.org/

There are various privacy issues using Linux distros too, for eg Debian:

https://wiki.debian.org/PrivacyIssues

At some point Linux distros will be usable on mobile devices (like the PinePhone/Librem), but probably not the ones you own.

It’s fixed in the release candidates for iOS and MacOS. The release of those should come next week.

> Waiting to start game: 1 out of 6 players are ready to start.

why do I have to wait if I’ve selected vs bots?

does this mean every browser on iOS leaks because of requirement to use Safari as underlying engine?

ah yeah, I missed it says:

Attacks work on Macs running Safari 15 and on any browser running on iOS or iPadOS 15

Yes

Not Safari, WebKit. Safari is Apple’s web browser. WebKit is the rendering engine it uses. Third-party browsers use WebKit, not Safari. There’s a lot more to a web browser than just its rendering engine.

I don’t think third-party browsers have their hands tied here. They are able to subclass the data storage class and use the subclass for web views. They are able to provide different behaviour to Safari. But if they just use the default behaviour, they will be vulnerable too.

I'm not sure about that but based on the test site I can tell you that brave and firefox are affected

I think you meant Brave and Firebox iOS are affected. Because all browser on iOS must use the WebKit engine.

Check the parent comment which states that probably one can mitigate the bug even if webkit is always the engine used

> Not Safari, WebKit.

Not WebKit, WebCore.

WebCore's API client is broken and leaked IndexedDB transactions into the ObjectStore of the WebInspectorUI. This was kind of bound to happen, as WebCore's InjectedBundle [0] for cross-process communication exposes all kinds of APIs for debugging, which are all dependent on the JavaScriptCore VM's memory/heap and callstack.

Things like HitTestResult in order to be able to select an element in the DOM via the WebInspectorUI, for example. InspectorInstrumentations are littered all over the codebase, in the UI Process, Web Process and GPU process. WebGL and Media Codecs could probably result in a similar persistent state across the sandboxes if abused correctly.

Source: Forked WebKit into RetroKit, trying to get rid of everything security-relevant that a locally embedded WebView shouldn't need [1]. Still work in progress though.

[0] https://github.com/WebKit/WebKit/tree/main/Source/WebKit/Web...

[1] https://github.com/tholian-network/retrokit

> Not WebKit, WebCore.

No, WebKit. Browsers on iOS use WebKit. Here’s Firefox for iOS using WebKit, for example:

https://github.com/mozilla-mobile/firefox-ios/blob/main/Clie...

> Source: Forked WebKit into RetroKit

As far as I can see, RetroKit can’t be deployed to the App Store. So what relevance is it to what iOS browsers use?

> Not WebKit, WebCore.

^ I was literally pointing to the source code. WebKit consists of more than one project: JavaScriptCore, WebCore, WebKit, WebInspectorUI.

WebKit is also not a Browser, it's a Browser-building framework (or sth like that...) which allows writing platform-specific adapters for all platforms. For example, macOS and iOS are using the Common Framework to do network requests, whereas on Windows it uses libcurl, whereas on GTK it uses libsoup. All things, including UI interaction and how they're integrated with the OS, are platform-specific adapters; which makes the InjectedBundle kind of a dirty hack.

My point being that WebKit uses WebCore as an embedded library, and that the problem is in WebCore's concept of the InjectedBundle; which WebKit is using to do calls to the specific GPU/Web/UI Process sandbox.

This is because WebKit runs in the UI Process, not the Web process. It was split up back when WebKit2 introduced this as its new architecture (not to confuse with WebKit 2.x, because that is WebKitLegacy).

I think maybe you missed the point of the discussion?

Somebody said that third-party iOS browsers were forced to use Safari. I said no, because they aren’t. They use WebKit.

You then chimed in to correct me and say no, actually it’s WebCore. But you seem to be talking about something else. You seem to be talking about the most specific location of the vulnerability, not what third-party iOS browsers have to use. Third-party web browsers don’t use WebCore directly, they use WebKit like I said.

Reply on news.ycombinator.com