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

3rd party CSS, Font, XHR, IMG and JS reveals your browsing site by request header 'Origin' attribute #509

Open
crssi opened this Issue Sep 20, 2018 · 114 comments

Comments

Projects
None yet
@crssi
Copy link
Collaborator

crssi commented Sep 20, 2018

Most 3rd party CSS, Font and JS reveals you browsing site by request header Origin attribute.
I know that a lot of you block fonts by default and JS sometimes or most the times, but most of you do not block CSS.
So it might be of your interest to remove Origin attribute from request header for CSS and Font.
JS (and XHRs too) can be covered by good uBO blocklists.

You can use Header Editor web extension to remove those.
Rule type: Modify the request header
Match type: All
Execute type: Custom function
Code:

if (detail.type === 'font' || detail.type === 'stylesheet' || detail.type === 'image') {
	for (const header of val) {
		if (header.name.toLowerCase() === 'origin') {
			header.value = '';
			break;
		}
	}
}

We need an additional rule to work in pair with upper script:
Rule type: Modify the response header
Match type: All
Execute type: Custom function
Code:

if (detail.type == 'font' || detail.type == 'stylesheet' || detail.type === 'image') {
	for (const header of val) {
		if (header.name.toLowerCase() == 'access-control-allow-origin') {
			if (header.value == "null") { header.value = detail.originUrl.split('/', 3).join('/'); }
			return;
		}
	}
	val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});
}

What I don't know is, how much this action could add to unique fingerprint in a real world.

From logging traffic in a week of browsing, I could not find single case where Origin attribute would be used in XHR requests to the addresses of the different owner as the browsing site is.

This issue is a follow up of #506

@crssi crssi changed the title 3rd party CSS, Font and JS reveals you browsing site by request header 'Origin' attribute 3rd party CSS, Font and JS reveals your browsing site by request header 'Origin' attribute Sep 20, 2018

@claustromaniac

This comment was marked as outdated.

Copy link
Member

claustromaniac commented Sep 20, 2018

According to documentation (if I understand correctly) the Origin header should only be present in XHR (XMLHTTPRequests) anyway. If that's true, then for this to work I think you'd need to change the condition to:

if (detail.type === 'xmlhttprequest') {

The docs don't say that explicitly, though. I'm deducing it from the fact that it says it only applies to CORS and POST requests. CORS are always XHR as far as I know, and POST can supposedly only happen from XHR or HTML forms.

That being said, I'd expect a rule like this to cause some breakage, but I agree that the Origin header is a tracking vector, so I think this sure is worth investigating/testing more.

@earthlng

This comment has been minimized.

Copy link
Member

earthlng commented Sep 23, 2018

but most of you do not block CSS.

that's because the number of sites that use someone else's CSS is slim to none (except for google fonts and as you already noticed in most or all cases those don't leak origin). So in that sense origin doesn't leak anything that the CDN doesn't already know anyway, namely that a certain CSS belongs to a certain site. But regardless of that I personally only allow 1st party css by default anyway.

CORS are always XHR as far as I know

github uses <link crossorigin="anonymous" media="all" integrity="sha512..." rel="stylesheet" href="https://....css"> and AFAIK that's CORS as well so it's not just XHR.

That being said, I'd expect a rule like this to cause some breakage, but I agree that the Origin header is a tracking vector, so I think this sure is worth investigating/testing more.

👍

@KOLANICH

This comment has been minimized.

Copy link

KOLANICH commented Sep 23, 2018

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

What requests use CORS?
This cross-origin sharing standard is used to enable cross-site HTTP requests for:
Invocations of the XMLHttpRequest or Fetch APIs in a cross-site manner, as discussed above.
Web Fonts (for cross-domain font usage in @font-face within CSS), so that servers can deploy TrueType fonts that can only be cross-site loaded and used by web sites that are permitted to do so.
WebGL textures.
Images/video frames drawn to a canvas using drawImage().

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Sep 23, 2018

that's because the number of sites that use someone else's CSS is slim to none

Sadly far from what I see. Maybe you see it that way as you block most 3rd party's. For someone who does not, the reality is different.

Origin header should only be present in XHR (XMLHTTPRequests) anyway

As we see, its not in the real world. Even github is using Origin in a websocket requests.

@earthlng

This comment has been minimized.

Copy link
Member

earthlng commented Sep 23, 2018

but it's not really someone else's CSS, is it? It may be hosted on some CDN but it's only used by that site, no? I mean who would use someone else's CSS for his/her own site? that's just silly. The 3rd party changes something and all of a sudden your page looks different? really?

@Atavic

This comment has been minimized.

Copy link

Atavic commented Sep 23, 2018

CMS Templates are shared by many different sites.

@earthlng

This comment has been minimized.

Copy link
Member

earthlng commented Sep 23, 2018

I guess that's possible but arent' templates usually installed into the CMS and then hosted and served by the domain using the CMS?

btw according to https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes even <img>s can leak the origin

@Atavic

This comment has been minimized.

Copy link

Atavic commented Sep 24, 2018

It may be hosted on some CDN but it's only used by that site, no?

Wordpress Themes are used by many, as Joomla, Blogger, even Jekyll on GH Pages.

@claustromaniac

This comment was marked as outdated.

Copy link
Member

claustromaniac commented Sep 24, 2018

@earthlng, @crssi

You're right. This deserves even more attention than I initially thought, then. Thanks for bringing this up, @crssi !

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Sep 25, 2018

We need additional rule for CORS... see #506 (comment)
Rule type: Modify the response header
Match type: All
Execute type: Custom function
Code:

if (detail.type === 'font' || detail.type === 'script' || detail.type === 'stylesheet') {
   for (let a in val) {
      if (val[a].name.toLowerCase() === 'access-control-allow-origin') { return; }
   }
   val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});
}

What we do here is to check if CORS is set, in that case we do not alter anything.
If is is not set, then we add it and set to the schema+domain of the response server for CORS.

We might get some better performance with regex for the line (@claustromaniac help 😄)

   val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});

Test page (note the icons with or without this additional rule): https://gitlab.com/labwrat/Firefox-user.js/tree/master

OT: @earthlng... for better performance add break; for eTag rule, after clearing eTag 😉, I don't think there is a need to roll over all headers when after a hit is found.

Still in ToDo: XHR, WebSocket, IMG.

Cheers

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Sep 26, 2018

We might get some better performance with regex for the line (@claustromaniac help 😄)

It seems the pattern is too simple for a regex to give a significant performance benefit here, at least on my end (YMMV). You can test here if you want:

Another alternative (didn't test this one):

val.push({'name': 'Access-Control-Allow-Origin', 'value': (new URL(detail.originUrl)).origin});

Hm.. I'm wondering, though. Isn't detail.originUrl always meant to be only the protocol + domain (+ port)? Gotta check that. If that's the case we just need to do:

val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl});

EDIT: NVM, it's not. I just tested it.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Sep 26, 2018

OT: @earthlng... for better performance add break; for eTag rule, after clearing eTag 😉, I don't think there is a need to roll over all headers when after a hit is found.

If performance is not a concern, not breaking out of the loop is safer because servers can include multiple ETag headers in the responses if they want. It's not common practice, but it is technically doable.

The same goes for Access-Control-Allow-Origin and all other response headers, AFAIK.

In the case of the Origin header, breaking out of the loop like you did in your rule is perfectly safe because it is a request header (the browser will not send multiple Origin headers in the same request).

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Sep 26, 2018

BTW, you shold probably check that the value of the ACAO header is not "null" if found, just in case. It is a bad practice but some servers do that, and Firefox will not fetch the resource in that scenario.

Another tip: you can use a for...of loop since val is an iterable object and you don't need the array index for anything else (makes code shorter and nicer).

Like this:

if (detail.type == 'font' || detail.type == 'script' || detail.type == 'stylesheet') {
   for (const a of val) {
      if (a.name.toLowerCase() == 'access-control-allow-origin') {
		  if (a.value == "null") {a.value = detail.originUrl.split('/', 3).join('/');}
		  return;
	  }
   }
   val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});
}
@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Sep 26, 2018

^^ @claustromaniac thank you for the upper tip and rework (and help overall). 👍 Could you just edit upper script and replace a with header, or am I complicating? Edit; never mind, I have updated the first post 😄

From what I see now, we have a working solution for Fonts, CSSs and JSs.., see updated first post.
We need a pair of request header and response header rules.
For now the request header script is #509 (comment) (I have edit it now with const method) and respond header script is #509 (comment)
Edit: updated the first post.

OT:

If performance is not a concern, not breaking out of the loop is safer because servers can include multiple ETag headers in the responses if they want. It's not common practice, but it is technically doable.

I am aware of that, but didn't found a single case now browsing around, but of course it doesn't mean its not there somewhere or will be in the future. The same goes for using Origin on IMG,
Maybe the eTag script should be updated with your const trickery.

I am using fiddler where I am tagging all Origins to see what is happening in the last couple of weeks.

For now, there are XHRs and WebSockets left to investigate and, oh man, the XHRs are really bad, broadcastings Origins all around the globe.
More and more I look into XHRs... crap, a Gordian knot to solve.

EDIT: I have reedited this whole post.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Sep 26, 2018

broadcastings Origins all around the globe.

Yeah, that's a good way to put it. 😆

Reading through https://w3c.github.io/webappsec-cors-for-developers/ more carefully, I think it is worth noting that these rules can involve some serious risks. Summarizing, we are trading off security for privacy.

If I understand correctly, this is how CORS works, in a nutshell:

spoiler

Typical situation:

  • [1] client (Firefox) visits site A.
  • [2] a script from site A running in the client attemps to fetch a resource from site B. Firefox adds the Origin header to this request, with site A as its value.
  • [3] site B checks its policies to see if it allows clients visiting site A to fetch this resource.
  • [4a] site B allows this, so it sends back the resource with an ACAO header saying either * or site A
  • [5a] client reads the response headers, finds the ACAO header and allows the script from site A to read the body of the response for the resource in site B.
  • [4b] (alternative path) site B does not allow this, so it doesn't add an ACAO header to the response.
  • [5b] client reads the response headers, and since it doesn't find the ACAO header, the script from site A is not allowed to read that resource.

What happens when we use these rules:

  • [1] same as above.
  • [2] same as above, except the HE rule strips the Origin header.
  • [3] server receives a request for a resource without an Origin header, therefore, it will most likely not add an ACAO header. If the resource is meant to be public, it may add an ACAO: * to the response anyway.
  • [4] the HE rule ensures the final response headers include an ACAO header. In practice, the value will almost always be either ACAO: * or ACAO: site A.
  • [5] same as 5a above.


The problem is that, in practice, we are giving up the same-origin policy for this, which is risky. Here is why:

spoiler

  • [1] client visits www.malicious.net.
  • [2] malicious script in www.malicious.net requests a resource from www.yourbank.com that requires authentication (like your bank account details). Let us say you visited your bank's site a while back and your session still has the auth cookies. The HE rule strips the Origin header from the request, but not the Cookie headers.
  • [3] www.yourbank.com responds without an ACAO header, because the request did not include an Origin header, but the request did include the Cookie header, so the body of the response is your personal data.
  • [4] the HE rule adds an ACAO: www.malicious.net header to the response.
  • [5] client reads the response headers, finds the ACAO header and fetches the resource, and malicious script from www.malicious.net just got ahold of your bank account's details.



I believe we are safe so as long as we use FPI and/or containers, and there are other obvious ways to mitigate this.

Alternatively, this could be solved by a simple dedicated extension. Said extension would have to check whether the Cookie header is present in the request headers, and only remove the Origin header if it is not. Then, if it did remove the Origin header, it would have to check the response headers for that specific request and add/modify the ACAO header so it says Access-Control-Allow-Origin: *. That's the best compromise I can think of between privacy and security. It would be trivial to implement, but I personally don't like the fact that it would conflict with other extensions that use the OnHeadersReceived event...

Anyway, I think people should be warned of this. There is a good reason for these headers to exist, and that reason is not something that many would easily give up (such as performance).

@Maryse47

This comment has been minimized.

Copy link

Maryse47 commented Sep 26, 2018

Summarizing, we are trading off security for privacy.

Even with whitelisting CORS as in #509 (comment) ?

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Sep 26, 2018

Even with whitelisting CORS as in #509 (comment) ?

We are trading off security for privacy by whitelisting CORS. BTW what that rule does is not really whitelisting, it's more like enforcing CORS 😛.

I'm sorry to say I don't think I can explain it any better than I already did. The same-origin policy and CORS are messy concepts that take a while to comprehend. I don't fully comprehend them myself, TBH.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Sep 26, 2018

Its prematurely to say, but IMHO, what we are doing here should be safe for Fonts and CSSs.
JSs needs to be investigated further. At least I am using separate browser for banking/paying only, also to avoid possible breakages at the critical moments.
XHRs (same goes for WebSockets) would be best to have separated topic when time... this can lead to a lot of breakages.

@Maryse47

This comment has been minimized.

Copy link

Maryse47 commented Sep 26, 2018

Maybe drop detail.type === 'script' from the rules for now?

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Sep 27, 2018

IMHO, what we are doing here should be safe for Fonts and CSSs.

Yes, probably. Besides, if I understand correctly, there are various ways to mitigate the bad side effects of that rule. I believe that even without taking any special precautions the risk is likely low, but I thought it was worth pointing it out anyway.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Sep 30, 2018

Maybe drop detail.type === 'script' from the rules for now?

IMHO no. All it can do bad, is to lead to unforeseen breakages, but I haven't found any till now.

@Maryse47

This comment has been minimized.

Copy link

Maryse47 commented Sep 30, 2018

Breaking same-origin policy isn't matter of breakage but security #509 (comment) and using separate browser isn't a fix.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Oct 1, 2018

@claustromaniac
See #509 (comment) at step 4...

[4] the HE rule adds an ACAO: site A header to the response.

Its wrong, it should be:
[4] the HE rule adds an ACAO: site B header to the response.

The response rule actually doesn't know the site A.
In that case I don't see how this could weaken the security, except there might be a breakages (which I haven't found yet any),
It might also raise security awareness. If a "bank" is using a 3rd party public site for their scripting repository (which could lead in a breakage in our case), that would be a very very good sign to change the bank.

@Maryse47 Using a separate browser for banking/paying was never meant as a fix, but as a best practice.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Oct 1, 2018

The response rule actually doesn't know the site A.

It does. detail.originUrl is the URL of the resource which triggered the request. See originUrl in the docs for onHeadersReceived.

If you want to confirm, you can use a rule like this in HE:

if (detail.type == 'font' || detail.type == 'script' || detail.type == 'stylesheet') {
	console.log(
`-----------------------------------
Resource at
	${detail.url}
has this originUrl:
	${detail.originUrl}`);
}

Save it as a rule to modify response headers and check the browser console (with CTRL+SHIFT+J) while you browse.

If a "bank" is using a 3rd party public site for their scripting

My bad. I should've made that part clearer. My example implied that site B was the banking site. In that example, site A would be a random malicious site, and a resource from site A would request your private data to your banking site (site B). So, it wouldn't be your bank making requests to a third party, it would be another site making requests to your bank (your bank would be the third party).

I should probably edit that comment, just in case. Even then, it is pretty hard to explain... for me, at least.

EDIT: OK, I edited that part of the comment. I hope it is easier to understand now.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Oct 1, 2018

Now that I think about it, some sites may also rely on the same-origin policy for practical reasons, not just for security. Since web developers wouldn't expect common users to tamper with headers, in some scenarios it could be reasonable for them to attempt to make several requests for different resources and let the same-origin policy filter out the unnecesary ones, instead of doing that filtering by other means. This is just theoretical, though.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Oct 1, 2018

Thx @claustromaniac ... I will get back to the drawing board as soon I have time.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Oct 4, 2018

From what I have browsed and monitored in the last days, the detail.type === 'script' is not really needed if someone is using a good block lists sources for uBO.
Most of destinations that are using this feature I have stumbled on were covered by block lists I am using.
Same goes for XHR.
Without good block lists there is a madness.

First post updated.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Oct 5, 2018

Note to myself:

Libraries at code.jquery.com are using origin and are not sanitized, origin-wise, by Decentraleyes WE. I didn't noticed origin usage on other libraries that are covered by Decentraleyes WE.
I am thinking to add JS to the code and being active only for code.jquery.com ATM, will do so and test further.

Also, @earthlng mentioned possible abusements over IMG and I have finally found one page doing so at http://rpresa.**/ . I cannot reproduce, but I think it starts to happen when the page is left open longer time. Will test more and maybe add IMG also into account. and its interacting with street maps leaking Origin over IMG to destination url ggpht.com

There are abusements over referers, but this is covered by ghacks-user.js out-of-the-box.

I am currently logging possible discrepancies over console with header request code and ORIGIN_ALERT: as a filter:

if (detail.type === 'font' || detail.type === 'stylesheet' || detail.type === 'image') { return; }

for (const header of val) {
	if (header.name.toLowerCase() === 'origin') {
		var headerOrigin = header.value;
		break;
	}
}

if (headerOrigin === 'undefined') { return; }

// testing if different domain and filtering out same domain
if (!(detail.url.split('/', 3)[2].endsWith(headerOrigin.split('//')[1].replace('www.','')))) {
	console.log(`ORIGIN_ALERT: ${detail.type}
S: ${detail.originUrl}
D: ${detail.url}
O: ${headerOrigin}`
	);
}

Log output:

ORIGIN_ALERT: <call type>
S: source url
D: destination url
O: origin header

There will be also false positives in the output (but it can be identified as such by naked eye).
Could be done better, to avoid false positives, but not without knowing TLDs.
Mozilla should integrate API into to easier getting the domain and subdomain parts out of URLs with TLDs taking info account.
@sblask did a very good job resolving TLD problem in Skip Redirect WE: https://github.com/sblask/webextension-skip-redirect/blob/master/pslrules.js and https://publicsuffix.org/list/public_suffix_list.dat
More here https://github.com/sblask/webextension-skip-redirect/issues/29 and here https://github.com/sblask/webextension-skip-redirect/issues/30.

EDIT: Added image to upper script and to sripts at first post in this topic.

@claustromaniac

This comment was marked as outdated.

Copy link
Member

claustromaniac commented Dec 14, 2018

done 1.0.0b4

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 14, 2018

that was fast 😄 and look quite good.

Settings (additional to default):
Type: XHR
Other: exclude root domain matches

Open https://www.techradar.com/reviews/logitech-g513
Font GET requests to fonts.gstatic.com are not cleaned.

The folowing XHR get requests are not cleaned:
to https://api.vanilla.futurecdn.net/...
to https://search-api.fie.future.net.uk/...
to https://vendorlist.consensu.org/vendorlist.json
to https://service.cmp.oath.com/...
to https://r.skimresources.com/api/

At the first glance the exclude root domain matches works perfeclty. 👍 ❤️

Thank you and cheers

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Dec 14, 2018

I couldn't reproduce your issue with fonts.gstatic.com, but I admit I haven't tested very well yet. However, I did find some other issues that could cause that. I'll see if I can do some decent tests later, but for now I made a few more pre-releases to fix the few fuck-ups that I noticed in 1.0.0b3.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 15, 2018

The cache must be cleared, otherwise it would not show.
But, never mind, you obviously nailed it at 1.0.0b6 and also I don't see XHR leakages. 😄

You are fantastic.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 16, 2018

Is it possible to whitelist per destination?
If I do XHR with Exclude root domain matches then everything is almost perfect.
The exceprtion is that in that case the only breakage I have found is youtube video, but since it can also run on other web pages as embedded, then whitelisting www.youtube.com works only on youtube main page.
To make it work everywhere, I would need to whitelist by destination as *.googlevideo.com or even more complex like source->destination combination, in that case like www.youtube.com -> *.googlevideo.com, since for every embedded YT video the source is always www.youtube.com.

I have tried several video sources, like: youtube, twitch, twitter, imdb... with an exception where I haven't tried FB.
The youtube is the only one that is doing GET type of XHR requests. So this is ATM the only breakage I have found and cannot work around.

removed non-relevant confusement

I am just thinking out loud... but in that case you would avoid requests (issues) to add additional parameters or the query part of URL for whitelistings and the end user would have more control.
In that case I would also volunteer to take a part of resolving issues for users with such requests on your GIT issues page.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 16, 2018

^^ To simplify the upper shitload, could you just add a whitelist for XHR destination to *.googlevideo.com (if simply possible then only when source is www.youtube.com) and leave upper comment aside for now. 🤗

Cheers

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Dec 18, 2018

It is not currently possible to whitelist individual resources, but I considered the idea last week. I kinda wanted to avoid implementing that, but I think that will be the best way to go about this, because it will require almost no maintenance in the long term. It is also more flexible and everything.

I think I'll use a syntax like the one you proposed. Something like origin -> target, but in a separate section of the options, to make things easier (for me) and tidier for the end user too.

I'll try to do it in the next few days. With that the extension will be feature-complete at last 😅 Then I'll have to write the documentation and all that, which is the boring part.

@claustromaniac

This comment was marked as resolved.

Copy link
Member

claustromaniac commented Dec 18, 2018

You have also mentioned that you skip altering when parameters like username or password are preset in the URL (https://github.com/claustromaniac/poop/blob/b251d7360003e18d4a05a76c02f31b80f865c78f/src/bg/webRequest.js#L34)... it is possible that there would be option to also make a whitelist by those in the settings?

That is part of the relaxed mode. I'm not sure I understand what you mean.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 18, 2018

ˇˇ Don't worry, nothing to understand... I must have been eaten something "strong" that day, since you have already implemented that.

I will update that post and remove the confusing and embarrassment part.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 20, 2018

@claustromaniac
I am testing now 1.0.0b7 from the moment of release.
Haven't found any culprit, having default+XHR+exclude root domain match+www.youtube.com *.googlevideo.com.

Its working perfect. Thank you.
Do you have ETA for release?

Cheers

OT:
What I learned in the process is that near 100% of XHR Post requests to different domains are trackers, FP sites... so in short bad ones.
Obviously I have really good uBO filtering config, since I can't see almost none (actually don't remember to see any) of those in the moment (except when I turn off uBO, then there are tons of it).
But it occurred me that it would be good way to detect rough domains as a source to build uBO block list.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 20, 2018

OK... a small bug there is.
Current setting are same as on ^^previous post.
Visit https://hexxiumcreations.github.io/threat-list/, observe connection with Origin leak to https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js.

Now add 2: *.bootstrapcdn.com to Overrides.
Clear cache and reload https://hexxiumcreations.github.io/threat-list/... the leak is still there.
But if I use 2 in Overrides it should be aggressive or I understood this wrong?

Cheers

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Dec 20, 2018

I couldn't reproduce that one. I tested on a clean profile with only this extension. I'm guessing there must be some kind of conflict on your end, but I wonder what that could be 😕 or maybe it is working inconsistently somehow? I'll try to see if the logic is missing something.

I meant to do a release today; it's been over two weeks already. I only have to do some final retouches and finish the documentation.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 20, 2018

I have tried now with a clean profile with only this extension and can reproduce every time.
So now I am confused a bit. 😿

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Dec 20, 2018

I misread this part:

Now add 2: *.bootstrapcdn.com to Overrides.

That is not how overrides work. Overrides rely on the document URL (the URL in your URL bar). To accomplish what you tried to do I would have to implement a sort of blacklist (similar to the exclusions that I released yesterday, but for blacklisting).

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 20, 2018

Oh... I see.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Dec 20, 2018

The problem is I don't see any efficient way to do that, because I'd have to parse headers in all requests to achieve that... I'd have to rewrite the whole webRequest.js to implement something like that. I'll have to analyze this more..

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Dec 20, 2018

I mean, I can do it, but I will be throwing out all the efficience-driven logic. Right now it's using fail-fast patterns to save CPU cycles, but I'll have to rewrite all that... hm... or maybe I can use an alternative callback for when there are items in the blacklist, and the extension will only be inefficient then, but that's like doubling the lines of code in webRequest.js and radically changing the whole logic everywhere.

It would take some time. I think I'd prefer to do the 1.0.0 release before implementing that (if I implement it). It's not like what you're trying to achieve is not doable in practice already (with global aggressive mode + overrides + exclusions). It's mostly a matter of preference.

EDIT: NVM, I think I overestimated the problem. I think I know what I'll do.
EDIT2 I take that back. I really can't add this without making a pretty extreme rework.

@Woofy-Wolf

This comment has been minimized.

Copy link

Woofy-Wolf commented Dec 23, 2018

Thank you @crssi for your early work to block this tracking method and for helping @claustromaniac as s/he developed POOP. I finally replaced CorsE and your Header Editor rule with POOP ver. 1.1.0. @claustromaniac, your knowledge and generosity impress me. Thank you for creating and offering this extension. It should be adopted by everyone, right alongside their favorite adblockers.

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Dec 23, 2018

Thank you, but the heavy lifting was done by the @claustromaniac.
If you are using HE solely for removing ETag header, then you can replace it with ETag Stoppa (also made by @claustromaniac).

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented Dec 23, 2018

@Woofy-Wolf, glad to help!

@crssi

This comment has been minimized.

Copy link
Collaborator Author

crssi commented Jan 10, 2019

We have found Jesus. It disguises as @claustromaniac .
@Thorin-Oakenpants I will close this issue now to remove clutter in open issues, but if you need to reopen, then be my guest. 😸 ❤️

@crssi crssi closed this Jan 10, 2019

@StanGets

This comment has been minimized.

Copy link

StanGets commented Jan 10, 2019

We have found Jesus. It disguises as @claustromaniac .

Is he Portuguese?!

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

Thorin-Oakenpants commented Jan 10, 2019

I want to leave it open, because I think we should do something more about it (learn more about it myself, maybe add it to the wiki, etc ) - open issues are my personal todo checklist - just like we still have the EvilCorp AMP issue open

@tartpvule

This comment has been minimized.

Copy link

tartpvule commented Feb 16, 2019

I have created an experimental extension aiming to provide complete user control over CORS, including plugging this Origin header leak. Might anyone be interested? Feedbacks needed.
https://github.com/tartpvule/custom-cors-control

Thank you

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

Thorin-Oakenpants commented Feb 16, 2019

Thanks @tartpvule ... I'll keep out of this conversation (as I have up til now) as I'm not up to date or even qualified about all of this. I'm not sure where @claustromaniac - he's been missing for about 3 or 4 weeks - maybe he went on holiday or got locked in the neighbor's garage or something. Cats are pretty amazing creatures, so I expect he'll show up soon 🐈

@slowfar

This comment has been minimized.

Copy link

slowfar commented Mar 1, 2019

I keyed into the bold request of the first item wrongly selecting the first request option 'cancel'. It was entertaining having no functional web. Oops.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.