Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

block referer based on eTLD+1 instead of full origin #13779

Closed
diracdeltas opened this issue Apr 9, 2018 · 7 comments · Fixed by #13820
Closed

block referer based on eTLD+1 instead of full origin #13779

diracdeltas opened this issue Apr 9, 2018 · 7 comments · Fixed by #13820
Assignees
@diracdeltas
Labels
privacy QA/checked-Linux QA/checked-macOS QA/checked-Win64 QA/test-plan-specified release-notes/include webcompat
Milestone
0.23.x (Release C...

Comments

@diracdeltas
Copy link
Member

diracdeltas commented Apr 9, 2018 •
edited by bsclifton
Loading

Test plan

See #13820

Original issue description

according to @bbondy, docs don't load in docs.google.com unless there is a referrer exception for *.google.com; similarly hangouts doesn't work in mail.google.com unless there is the same exception.

we should treat all these as first-party based on eTLD+1
@diracdeltas diracdeltas self-assigned this Apr 9, 2018
@diracdeltas
Copy link
Member Author

related: #11778

the same issue occurs on sheets.google.com

@diracdeltas diracdeltas added this to the 0.24.x (Nightly Channel) milestone Apr 12, 2018
diracdeltas added a commit that referenced this issue Apr 12, 2018
@diracdeltas
refactor isThirdPartyHost and block referer based on base domain
57b9b97 
fix #13779
fix #13779
also removes TODO for isThirdPartyHost to handle IP addresses and adds
tests

Test plan:
1. unit tests pass
2. open Brave, make sure cookie setting is block all or block 3rd party
3. go to docs.google.com and login
4. documents should appear
5. open devtools and go to 'network' tab
6. on a request to a non-google.com domain like gstatic.com, the referer
   header should be 'https://gstatic.com' or whatever the domain is, instead of
   'https://docs.google.com...'
7. turn cookie setting to 'allow all'
8. repeat step 6. now the referer header should be
   'https://docs.google.com...'
@diracdeltas diracdeltas mentioned this issue Apr 12, 2018
Merged
10 tasks
@diracdeltas diracdeltas mentioned this issue Apr 26, 2018
Closed
@bsclifton bsclifton modified the milestones: 0.24.x (Nightly Channel), 0.23.x (Developer Channel) May 2, 2018
@bsclifton
Copy link
Member

@diracdeltas can you add a test plan for this? Or are the steps in #11778 sufficient? (if so, let's tag this as no-qa-needed)

@diracdeltas
Copy link
Member Author

@bsclifton test plan is in #13820

@bsclifton
Copy link
Member

@diracdeltas when loading videos over photos.google.com, there appears to be an issue which causes videos to not load properly. Console displays (possibly unrelated):

Uncaught DOMException: Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported.
    at Image.img.onload (chrome-extension://mnojpmjdmbbfmejpflffifhffcmidifd/content/scripts/favicon.js:13:22)

Steps to reproduce:

  1. Visit https://photos.google.com/share/AF1QipPu6CS-eDZcwZ-keMebFwbl5guT2ebOB23Mg_SyMPz0-e10GFwM2jg0f33Bi5E3qw?key=V2d6NUs2Q0hHVDhUZWh0S0VLd19icmVJTFdBQTZ3
  2. Find one of the video posts (should have the play button on it, and also it'll preview the video when moused over)
  3. Click the video
  4. Notice the spinner - it never loads

I didn't see anything obvious in the network tab, just the above being logged to console ☹️

@diracdeltas
Copy link
Member Author

@bsclifton interesting - does that error occur without #13820 ?

@diracdeltas
Copy link
Member Author

i could repro in current release - when i clicked on the video, it didn't load until i allowed all cookies. seems like maybe a separate issue related to cookies/referer.

This was referenced Jun 11, 2018
Closed
Closed
Closed
This was referenced Jun 19, 2018
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
@srirambv
Copy link
Collaborator

srirambv commented Jun 21, 2018 •
edited by kjozwiak
Loading

Verified on Windows 10 x64 using

  • 0.23.12 - 88f6f07
  • Muon - 7.1.1
  • libchromiumcontent - 67.0.3396.87

Verified on Ubuntu 17.10 x64

  • 0.23.14 - f4da855
  • Muon - 7.1.1
  • libchromiumcontent - 67.0.3396.87

Verified on macOS 10.13.4 x64 using the following build:

  • 0.23.18 c101002
  • muon: 7.1.2
  • libchromiumcontent: 67.0.3396.87

@kjozwiak kjozwiak mentioned this issue Jun 25, 2018
Closed
@srirambv srirambv mentioned this issue Jun 25, 2018
Closed
@kjozwiak kjozwiak mentioned this issue Jun 27, 2018
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@diracdeltas diracdeltas

Labels
privacy QA/checked-Linux QA/checked-macOS QA/checked-Win64 QA/test-plan-specified release-notes/include webcompat
Projects
None yet
Milestone
0.23.x (Release Channel)
Development

Successfully merging a pull request may close this issue.

refactor isThirdPartyHost and block referer based on base domain brave/browser-laptop
5 participants
@diracdeltas @kjozwiak @bsclifton @srirambv @btlechowski