Closed Ghxst closed 2 months ago
Using https://abrahamjuliot.github.io/creepjs/ I have started noticing in headless mode that it is able to track me across browser profiles as well, could anyone explain why? I confirmed it's still using some farbling as the reported memory size and such changes from default.
cc: @arthuredelstein
Seems something even more weird is going on, https://abrahamjuliot.github.io/creepjs/ is now able to track me across browser profiles just running vanilla brave on my personal machine.
Another one that will be fixed by https://github.com/brave/brave-browser/issues/28904
@ShivanKaul Could you please let me know if you or anyone else on the team(Since there is similar issue with different assignees) is working on this?
Also, if you have any recommendations for this feature, please let me know.
This was on @goodov 's queue to fix the way we generate the farbling seed. @goodov have you already started this/have a strategy? This would be a fairly fundamental and powerful change to our fingerprinting protections.
This was on @goodov 's queue to fix the way we generate the farbling seed. @goodov have you already started this/have a strategy? This would be a fairly fundamental and powerful change to our fingerprinting protections.
Yes, I understand that this will change the fundamental of existing farbling seed.
At first glance, I thought of moving the |BraveFarblingService| from the BrowserProcessImpl
to BrowserContextKeyedService
(But still need to figure out edge cases for current implementations)
This was on @goodov 's queue to fix the way we generate the farbling seed. @goodov have you already started this/have a strategy? This would be a fairly fundamental and powerful change to our fingerprinting protections.
The farbling seed will be bound to the ephemeral storage area lifetime. I'm figuring out the right way of passing it and whether we can re-use upstream's StorageKey
for this.
At first glance, I thought of moving the |BraveFarblingService| from the
BrowserProcessImpl
toBrowserContextKeyedService
(But still need to figure out edge cases for current implementations)
That might work just fine, because we pass the farbling seed (brave_session_token
) via the command line to renderer right now. Feel free to work on this for now if you'd like.
That might work just fine, because we pass the farbling seed (
brave_session_token
) via the command line to renderer right now. Feel free to work on this for now if you'd like.
Okay, Will look into this. Thanks!
@jagadeshjai is this issue still open? I saw the note about https://github.com/brave/brave-core/pull/24590 partially solving
@jagadeshjai is this issue still open? I saw the note about brave/brave-core#24590 partially solving
Actually this PR will address the reported initial issue, but won't reslove browser getting tracked from different profiles and/or sessions which is mentioned here at https://github.com/brave/brave-browser/issues/39182#issuecomment-2183555038.
I think we can create a separate issue for it, as implementing farbling in more APIs might be necessary to slove that. @bsclifton
@ShivanKaul does this need QA? Can you please help add label (QA/Yes or QA/No) and then share a test plan if needed? Thanks! 😄
No, the QA plan specified in https://github.com/brave/brave-browser/issues/38067 should suffice (basically check that the fingerprint is now different). Some of the APIs mentioned here we don't/can't farble (e.g. User Agent). I've marked this one as a dupe and removed the release-notes label @bsclifton. creep.js should be its own issue, which we're actually discussing on Slack.
per @ShivanKaul notes above, I'm going to add QA/No
and release-notes-exclude
as this seems to be covered by https://github.com/brave/brave-browser/issues/38067. If this is incorrect please adjust.
Platforms
Windows
Description
When using the dev-tools protocol and creating multiple browser contexts, fingerprints are shared between contexts, is this a use case that brave can support?
context a: context b: