'Top Browser Domains' not working on Brave

[oliviodare]

• I am on the latest ActivityWatch version.
• I have searched the issues of this repo and believe that this is not a duplicate.

• OS version and name: MacOS: Catalina 10.15.5, Brave: 1.11.97 Chromium: 84.0.4147.89 (Build oficial) (64 bits)
• ActivityWatch version: v0.9.2

Describe the bug

There is no information on 'Top Browser Domains'. It is just empty (see attached screenshot).

I am new to both Brave and ActivityWatch. I am not sure whether logs are of any use in this case, but I can provide them if needed.

Documentation

[ErikBjare]

Did you install the web extension?

[oliviodare]

Yes, installed and active.

[ErikBjare]

I think I know what the issue is. We just need to add "Brave Browser" here: https://github.com/ActivityWatch/aw-webui/blob/0036b4860fb52f428e7e14fdba1fe22950e17db8/src/queries.ts#L124

@bawasi Can you confirm if the bucket name (on the "Raw Data" page) is aw-watcher-web-chrome or aw-watcher-web-brave?

[robinbijlani]

I am having the same issue with seeing no browser data from Brave. My bucket id is aw-watcher-web-chrome.

[oliviodare]

Yes, bucket id is also for me aw-watcher-web-chrome

[johan-bjareholt]

@ErikBjare It should not be added to the "brave" dict, older versions of brave for a short while had that but removed it because they had incompatibilities with some sites. The developers instead made their own exotic API for others to detect if the user is running or brave or not instead of following internet standards.

brave/brave-browser#1052 (comment)

So the only possible solution to this is to add it to the "chrome" section, but if any user has both chrome and brave running at the same time your activity will be completely wrong because now two watchers will write to the same bucket at the same time creating invalid data.

So brave developers has essentially shot themselves in the foot by tricking every website that they are chrome even if they are not. For most sites that fixes issues, but in our case that's exactly what breaks our use-case. The responsible thing for Brave would have been to be honest that it's in fact brave and if some site works fine on brave but lies that it's incompatible it could have had a "whitelist" for those sites so it only fakes it on those specific sites. But they have gone the easy route and trick everyone instead of just the bad actors.

I am considering if we should just remove Brave support completely and refer to that GitHub issue upstream (others have reported that it has worked on Linux, but also complained about the bug when running both brave and chrome).

[ErikBjare]

@johan-bjareholt That's pretty crazy.

If you want to deal with upstream that's all good but I think we're good with just saying "because Brave doesn't want anyone to know that their users are using Brave, watching both Chrome and Brave at the same time leads to undefined behavior", and then go ahead and keep putting Brave in the "chrome" field anyway.

Does this mean we should move the existing Brave entry into the chrome field? I guess it's useless right now?

Flooding might partially fix it for those few cases that watch Chrome and Brave simultaneously, so it wouldn't be worthless, just kinda corrupted/inaccurate.

Edit: After reading that issue, aren't there more reliable ways to figure out the browser name than checking the User-Agent?

[johan-bjareholt]

Does this mean we should move the existing Brave entry into the chrome field? I guess it's useless right now?

Yes

Flooding might partially fix it for those few cases that watch Chrome and Brave simultaneously, so it wouldn't be worthless, just kinda corrupted/inaccurate.

The URLs and titles would be correct, but "kinda corrupted/inaccurate" is an understatement as the durations would be completely wrong.
If both watchers heartbeat at the same time all the time (which will be the case because aw-watcher-web is not aware if the user is afk or not) they will take turns on sending heartbeats making most heartbeats a new unique event instead of actually merging them resulting in a bucket getting filled rather quickly. The durations will be completely random as both write at the same time but will most likely average out to be 50% brave and 50% chrome even though you might be using brave 95% of the time.

Edit: After reading that issue, aren't there more reliable ways to figure out the browser name than checking the User-Agent?

Not that is compatible with all browsers. User-Agents are already complicated as is, which is why we use the ua-parse library in aw-watcher-web. We could use braves unique API to find out whether it's brave or not, but I'd prefer to avoid having brave specific code.

function isBraveUA () {
  if (!window.Promise) {
    return false;
  }
  if (typeof navigator.brave == "undefined" ||
      typeof navigator.brave.isBrave != "function")
  {
    return new Promise(function (resolve) {
      resolve(false);
    });
  }
  return navigator.brave.isBrave()
    .then((response) => {
      return response;
    })
    .catch((error) => {
      return false;
    });
}

[MitPitt]

Any updates on this? For some reason URLs show up correctly in 'aw-watcher-web-chrome' in Timeline tab, but not in Activity tab, just like OP's screenshot

[tihomir-kit]

Perhaps the temporary hard-coded solution could be used until ua-parse supports brave?

[johan-bjareholt]

I assume ua-parse will never be fixed because it's not broken, brave wants itself to be disguised as chrome in the user agent and that's what ua-parse parses.

It would certainly be possible to use the brave specific code, but then we should also ask if we should add the vivaldi specific code too. Then maybe in the future there's yet another browser disguising itself at chrome (maybe Opera?) which needs a specific fix and then suddenly we have a lot more to handle than just brave.

If there's some actively maintained library that handle these I'd be happy to take in a change which uses that instead. I haven't looked at that though.

[tihomir-kit]

I see your point, but besides the philosophical question and code purity, you have an actual situation, which is not difficult to fix technically. You have actual users, having a very real-world issue. That is, part of the ActivityWatch doesn't work correctly because it doesn't recognize a browser. Is it realistic to expect people to ditch Brave just so ActivityWatch would work for them? Isn't software supposed to hide these issues away from us? In my view, the code itself is not the point of software, solving real-world problems is. :) Often, if the library doesn't do it for us, we get around that by writing custom code.

[ErikBjare]

I see your point, but besides the philosophical question and code purity, you have an actual situation, which is not difficult to fix technically.

@tihomir-kit This is not a philosophical question or about 'code purity', it's about the very practical matter of us not having the time (nor the personal motivation) to maintain hacky workarounds which are doomed to break every once in a while.

Me and @johan-bjareholt simply don't want to maintain a browser identification library, especially when certain browser vendors have their own reasons to make it hard to identify a browser (to avoid fingerprinting, and websites blocking "unsupported" browsers). Frankly, our time is better spent elsewhere.

Is it realistic to expect people to ditch Brave just so ActivityWatch would work for them?

No, but it is expected that people who use these browsers (which don't follow standards) to themselves contribute and maintain fixes for them. The source is open. So if you need a fix, fix it and make a PR 🙂

[tihomir-kit]

Ok, I thought the issue was more of you not wanting to have that workaround code inside the application at all. But what you're saying is if someone implements a workaround / custom agent identification in a form of PR, you will accept it?