Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workers not farbling user agent properly - follow up to 12097 #12392

Closed
LaurenWags opened this issue Oct 29, 2020 · 9 comments · Fixed by brave/brave-core#7596
Closed

Workers not farbling user agent properly - follow up to 12097 #12392

LaurenWags opened this issue Oct 29, 2020 · 9 comments · Fixed by brave/brave-core#7596
Labels
feature/shields/fingerprint The fingerprinting (aka: "device recognition") protection provided in Shields OS/Android Fixes related to Android browser functionality OS/Desktop privacy privacy-pod Feature work for the Privacy & Web Compatibility pod QA Pass - Android ARM QA Pass - Android Tab QA Pass-Linux QA Pass-macOS QA Pass-Win64 QA/Yes release-notes/include
Projects

Comments

@LaurenWags
Copy link
Member

Description

When Fingerprinting = strict, the "Worker" column value should match the other values in the row for User Agent on the QA pages. This is not occurring.

Steps to Reproduce

  1. Clean profile 1.17.x
  2. Visit https://dev-pages.brave.software/farbling.html and https://dev-pages.bravesoftware.com/farbling.html
  3. With FP = standard (default), click Generate fingerprints on both pages.
  4. See FP values are the same across the User Agent row (expected, since "Mode" column says strict.
  5. Change FP = strict for both pages.
  6. Click Generate fingerprints on both pages.

Actual result:

Worker column value for the User Agent row is different than other values in that row. It is the same value from when FP = standard and it is the same between both pages:
strict 1 copy

Expected result:

all values in User Agent row should be the same when FP = strict

Reproduces how often:

easily

Brave version (brave://version info)

Brave 1.17.55 Chromium: 86.0.4240.111 (Official Build) dev (x86_64)
Revision b8c36128a06ebad76af51591bfec980224db5522-refs/branch-heads/4240@{#1290}
OS macOS Version 10.14.6 (Build 18G6032)
Brave 1.18.17 Chromium: 87.0.4280.27 (Official Build) nightly (x86_64)
Revision d8c1fe98de8d9c6bd46ebe8b0cc9d2b6bdccca1e-refs/branch-heads/4280@{#556}
OS macOS Version 10.14.6 (Build 18G6032)

Version/Channel Information:

  • Can you reproduce this issue with the current release? n/a for 1.16.x, this should be fully implemented with 1.17.x per Fingerprinting 2.0: User Agent #9190 (comment)
  • Can you reproduce this issue with the beta channel? yes 1.17.x
  • Can you reproduce this issue with the nightly channel? yes 1.18.x

Other Additional Information:

  • Does the issue resolve itself when disabling Brave Shields? n/a
  • Does the issue resolve itself when disabling Brave Rewards? n/a
  • Is the issue reproducible on the latest version of Chrome? n/a

Miscellaneous Information:

cc @pes10k @pilgrim-brave

@LaurenWags LaurenWags added privacy feature/shields/fingerprint The fingerprinting (aka: "device recognition") protection provided in Shields QA/Yes OS/Android Fixes related to Android browser functionality privacy-pod Feature work for the Privacy & Web Compatibility pod OS/Desktop labels Oct 29, 2020
@LaurenWags LaurenWags added this to Untriaged / Incoming in Shields via automation Oct 29, 2020
@pes10k
Copy link
Contributor

pes10k commented Oct 29, 2020

thanks @LaurenWags ! Was just wondering, do you see the issue in nightly? Im not able to reproduce there at least, so hopefully this just means something needs to be uplifted or retagged 🤞

@pes10k
Copy link
Contributor

pes10k commented Oct 29, 2020

Specifically it looks like it might be solved by brave/brave-core#6906

@LaurenWags
Copy link
Member Author

@pes10k yes I can reproduce on nightly 1.18.17 with a clean profile:

Screen Shot 2020-10-29 at 1 42 38 PM

Brave | 1.18.17 Chromium: 87.0.4280.27 (Official Build) nightly (x86_64)
-- | --
Revision | d8c1fe98de8d9c6bd46ebe8b0cc9d2b6bdccca1e-refs/branch-heads/4280@{#556}
OS | macOS Version 10.14.6 (Build 18G6032)

@LaurenWags
Copy link
Member Author

ah, ok that one didn't make it into 1.18.17. let me try 1.18.18.

@LaurenWags
Copy link
Member Author

Does not reproduce with 1.18.18

Screen Shot 2020-10-29 at 2 00 30 PM

Brave 1.18.18 Chromium: 87.0.4280.27 (Official Build) nightly (x86_64)
Revision d8c1fe98de8d9c6bd46ebe8b0cc9d2b6bdccca1e-refs/branch-heads/4280@{#556}
OS macOS Version 10.14.6 (Build 18G6032)

@bsclifton
Copy link
Member

Closing as this should be fixed in later versions - cc: @pes10k in case I have that wrong

Shields automation moved this from Untriaged / Incoming to Completed Jan 26, 2021
@bsclifton bsclifton added the closed/stale Issue is no longer relevant, perhaps because the feature it refers to has been deprecated. label Jan 26, 2021
@pes10k pes10k reopened this Jan 26, 2021
Shields automation moved this from Completed to Untriaged / Incoming Jan 26, 2021
@pes10k
Copy link
Contributor

pes10k commented Jan 26, 2021

@bsclifton this is not ready to be closed yet, its waiting on a fix @pilgrim-brave is working on to land (see brave/brave-core#7596)

@pes10k pes10k removed the closed/stale Issue is no longer relevant, perhaps because the feature it refers to has been deprecated. label Jan 26, 2021
Shields automation moved this from Untriaged / Incoming to Completed Jan 28, 2021
@pilgrim-brave pilgrim-brave added this to the 1.21.x - Beta milestone Feb 5, 2021
@stephendonner
Copy link

stephendonner commented Feb 10, 2021

Verified FIXED using the inline testcase, with

Brave 1.21.50 Chromium: 88.0.4324.152 (Official Build) beta (x86_64)
Revision 6579930fc53b4dc589c042bec9d0a3778326974d-refs/branch-heads/4324@{#2106}
OS macOS Version 11.2.1 (Build 20D74)

Screen Shot 2021-02-10 at 11 30 41 AM


Verification passed on

Brave 1.21.56 Chromium: 88.0.4324.152 (Official Build) dev (64-bit)
Revision 6579930fc53b4dc589c042bec9d0a3778326974d-refs/branch-heads/4324@{#2106}
OS Ubuntu 18.04 LTS

Verified test plan from the description

image


Verification passed on


Brave | 1.21.63 Chromium: 88.0.4324.182 (Official Build) dev (64-bit)
-- | --
Revision | 73ee5087001dcef33047c4ed650471b225dd8caf-refs/branch-heads/4324@{#2202}
OS | Windows 10 OS Version 2004 (Build 19041.804)


Verified test plan from the description

When FB is default (standard) values are the same across the User Agent row

https://dev-pages.brave.software/farbling.html https://dev-pages.bravesoftware.com/farbling.html
image image

When FB is strict values are the same across the User Agent row

https://dev-pages.brave.software/farbling.html https://dev-pages.bravesoftware.com/farbling.html
image image

@rebron rebron changed the title workers not farbling user agent properly - follow up to 12097 Workers not farbling user agent properly - follow up to 12097 Mar 1, 2021
@srirambv
Copy link
Contributor

srirambv commented Mar 2, 2021

Verification passed on OnePlus 6T with Android 10 running 1.21.70 x64 build

  • Verified worker column has the same values as others for UA

FP=Standard

image image

FP=Strict

image image

Verification passed on Samsung Tab A with Android 10 running 1.21.70 x64 build

  • Verified worker column has the same values as others for UA

FP=Standard

image image

FP=Strict

image image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature/shields/fingerprint The fingerprinting (aka: "device recognition") protection provided in Shields OS/Android Fixes related to Android browser functionality OS/Desktop privacy privacy-pod Feature work for the Privacy & Web Compatibility pod QA Pass - Android ARM QA Pass - Android Tab QA Pass-Linux QA Pass-macOS QA Pass-Win64 QA/Yes release-notes/include
Projects
Shields
  
Completed
Development

Successfully merging a pull request may close this issue.

8 participants