Why Arc Browser send large amount of user data to their server?

[warren_t]

I frequently noticed that when the Arc is opened, even without any webpage opened foreground or background, there could be a short period that the RAM usage of the browser bumps to 8GB. At the same time, the Arc is reading a lot of the data from local storage, and sending to their server. It ends up with more than 600MB upload. The high usage of RAM will drop back to normal after the browser stop sending the data. It seems that the company is collecting some data that they should not touch.

[tentacleuno]

That sounds like a binary was updated, or something similar.

There's no way they'd be collecting 600MB of data on each user; what would even be included in that? Plus, 600MB for each of their users would quickly become unprofitable, which would defeat the entire point of data-sharing.

Nevertheless, it may be worth inspecting the network I/O for the application to see what it's up to -- this could provide some hints as to what such a large payload is being used for.

[bluish29]

Doesn't update the binary means downloading data not uploading them?

[nsonha]

more like crash dump

[tentacleuno]

Ooh, good call. Yeah, crash dump seems likely.

Though I remember something about Facebook uploading phones' binaries to the server for inspection or soemthing. This was a few years back, so it's probably changed.

[warren_t]

I recorded the screen while the Arc was sending data. It ended up with 707 MB of uploads. https://youtu.be/m_Y7wuB5xk0

I'm confused that are they allowed to upload this huge amount of data without asking permission from the user?

[mangini]

Browser Company engineer here. Thanks for reporting! This is neither normal nor expected.

If you don’t mind, could you try the same test after temporarily disabling all extensions in arc://extensions? “Arc Helper” processes are used for both renderers and extensions. We have seen many cases where extensions behave unexpectedly.

The crash dump we upload for diagnose, when you first restart the browser after a crash happened, is a json file of about 100KB to 200KB similar to IPS files you see in the MacOS Console app, so they can’t be what is causing this.

If you need to send us any data you don’t want to share publicly for privacy reasons, feel free to create a bug report using Arc itself, and we can follow-up there.

Thank you!

[warren_t]

I just submitted a but report within the Arc with the steps to reproduce the bug and a link to my uploaded screen recording.

I found that the process used 6GB of RAM is "Arc Helper (Renderer)". This bug could potentially related with how the browser render the google docs.

I also noticed that if I have the Arc opened in the background, the bug shows up every 6 hours.

[1123581321]

Yes, that's just something buggy. The helper is pinned to a sandboxed tab that is making your CPU go crazy. The data isn't being uploaded to Arc. I'm guessing you know what the tab is.

[warren_t]

No, there was no tab in the background. I set the Arc to not restore any windows from previous session. After I opened the Arc, I only opened a google doc page and closed it before the recording. The same RAM increase and data upload can be observed without open and close a google doc page.

[satvikpendem]

I assume because it's a venture-backed company that needs to make its money somehow, so data tracking it is.

[1123581321]

Mine opens about 600 MB (300 core 300 render helpers) and sends about a meg of data on launch. Though I haven't watched closely, I think that's been typical. Perhaps you've got a buggy tab or some other state that's worth reporting.

[wryoak]

Like what? What are they touching they shouldn’t?

Also curious how to perform such an investigation myself, if you could describe your method