User.js: 3rd party CSS, Font, XHR, IMG and JS reveals your browsing site by request header 'Origin' attribute

[crssi]

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 https://github.com/ghacksuserjs/ghacks-user.js/issues/506

[claustromaniac]

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]

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.

:+1:

[KOLANICH]

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]

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]

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]

CMS Templates are shared by many different sites.

[earthlng]

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]

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]

@earthlng, @crssi

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

[crssi]

We need additional rule for CORS... see https://github.com/ghacksuserjs/ghacks-user.js/issues/506#issuecomment-423833554
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 :smile:)

   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 :wink:, 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]

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

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:

• benchmark very close to reality
• simpler benchmark

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]

OT: @earthlng... for better performance add break; for eTag rule, after clearing eTag :wink:, 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]

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]

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

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 https://github.com/ghacksuserjs/ghacks-user.js/issues/509#issue-362331158 (I have edit it now with const method) and respond header script is https://github.com/ghacksuserjs/ghacks-user.js/issues/509#issuecomment-424583577 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]

broadcastings Origins all around the globe.

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

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]

Summarizing, we are trading off security for privacy.

Even with whitelisting CORS as in https://github.com/ghacksuserjs/ghacks-user.js/issues/509#issuecomment-424347655 ?

[claustromaniac]

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 :stuck_out_tongue:.

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]

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]

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

[claustromaniac]

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]

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]

Breaking same-origin policy isn't matter of breakage but security https://github.com/ghacksuserjs/ghacks-user.js/issues/509#issuecomment-424667721 and using separate browser isn't a fix.

[crssi]

@claustromaniac
See https://github.com/ghacksuserjs/ghacks-user.js/issues/509#issuecomment-424667721 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]

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]

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]

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

[crssi]

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]

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.

[crssi]

EvilCorps StreetMap leaks Origin over IMG.

[claustromaniac]

I still think what these rules do would be better achieved by a dedicated extension. Here is another reason for that: preflight requests. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS (scroll down). It would take some serious analysis, though, and I still wouldn't want to add more extensions that listen to onHeadersReceived. Bummer.

[crssi]

Sure, but we don't have better ATM. :cry:
I know about preflight requests, but haven't seen any for Fonts, CSSs and IMGs... yet.

[crssi]

I don't care about CORS, using FPI and TC.

ATM, I am using the following...

Request:

for (const header of val) {
    if (header.name.toLowerCase() === 'origin') {
        if (detail.url.split('/', 3)[2].endsWith(header.value.split('//')[1].replace(/(^www\.)/,''))) { return; }
        if (header.value == 'https://www.youtube.com' && detail.url.split('/', 3)[2].endsWith('.googlevideo.com')) { return; }
        header.value = detail.url.split('/', 3).join('/');
        return;
    }
}

Response:

for (const header of val) {
    if (header.name.toLowerCase() == 'access-control-allow-origin') {
        if (header.value == 'https://www.youtube.com' || header.value == 'https://twitter.com') { return; }
        header.value = '*';
        return;
    }
}
val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});

[crssi]

Any audience interested, I have opened an issue at https://gitlab.com/smart-referer/smart-referer/issues/118.
Please make a suggestions/brainstorming there, if applicable.

Cheers

[crssi]

For the last 10 days I have the following:

Request:

for (const header of val) {
    if (header.name.toLowerCase() === 'origin') {
        if (detail.url.split('/', 3)[2].endsWith(header.value.split('//')[1].replace(/(^www\.)/,''))) { return; }
        header.value = detail.url.split('/', 3).join('/');
        return;
    }
}

Response: none

And web extension CORS Everywhere with (which also deals with responses):
Enabled at startup = Checked
Force value of access-control-allow-origin = empty
Activation whitelist = empty

All together with TC and FPI.
I haven't got any breakages yet.

EDIT: Added line in script to skip removal when same domain, which was removed due to copy/paste mistake into this post

[Woofy-Wolf]

Hi. I followed the conversation as well as I can, but I don't speak regex or javascript. Should I add three rules to Header Editor? Two rules from the first post and a third rule from the previous post? (plus CORS Everywhere.)

I use TC and FPI, which (if I understand correctly) minimizes the security issue that claustromaniac described.

[crssi]

@Woofy-Wolf
Just the last post, but don't do anything ATM.
I have something very similar in the cooking now, but way better.
"Prototype" is working but needing a optimization to avoid CPU overwhelming.
I need a few days more,

Cheers

[Woofy-Wolf]

Thanks, crssi. I'll hold off.

[crssi]

@Woofy-Wolf

Try this and let me know. In a few days I might close this topic and open a new one, to avoid clutter.

Drop all rules you have regarding this and create request rule:

const requests = ["font","script","stylesheet","xmlhttprequest","websocket"]
// "image" ATM seen only at ebay and streetview, but always points to same origin

if (!(requests.includes(detail.type))) { return; }

for (const header of val) {
    if (header.name.toLowerCase() === 'origin') {

        const getDomain = (u) => { return /.*?:\/*([^\/:]+)/.exec(u)[1]; }

        const domain = getDomain(detail.url);
        const origin = getDomain(header.value);

        // domain match
        if (domain.endsWith(origin)) { return; }

        // domain does NOT match, so we check SLD (second level domain to avoid breakages)
        const getSLD = (d) => {
            // https://github.com/wrangr/psl/  (https://raw.githubusercontent.com/wrangr/psl/master/data/rules.json)
            const rules = ["ae","co.ae","net.ae","org.ae","sch.ae","ac.ae","gov.ae","mil.ae","ar","com.ar","edu.ar","gob.ar","gov.ar","int.ar","mil.ar","musica.ar","net.ar","org.ar","tur.ar","at","ac.at","co.at","gv.at","or.at","au","com.au","net.au","org.au","edu.au","gov.au","asn.au","id.au","info.au","conf.au","oz.au","act.au","nsw.au","nt.au","qld.au","sa.au","tas.au","vic.au","wa.au","act.edu.au","nsw.edu.au","nt.edu.au","qld.edu.au","sa.edu.au","tas.edu.au","vic.edu.au","wa.edu.au","qld.gov.au","sa.gov.au","tas.gov.au","vic.gov.au","wa.gov.au","az","com.az","net.az","int.az","gov.az","org.az","edu.az","info.az","pp.az","mil.az","name.az","pro.az","biz.az","be","ac.be","bg","a.bg","b.bg","c.bg","d.bg","e.bg","f.bg","g.bg","h.bg","i.bg","j.bg","k.bg","l.bg","m.bg","n.bg","o.bg","p.bg","q.bg","r.bg","s.bg","t.bg","u.bg","v.bg","w.bg","x.bg","y.bg","z.bg","0.bg","1.bg","2.bg","3.bg","4.bg","5.bg","6.bg","7.bg","8.bg","9.bg","biz","br","9guacu.br","abc.br","adm.br","adv.br","agr.br","aju.br","am.br","anani.br","aparecida.br","arq.br","art.br","ato.br","b.br","barueri.br","belem.br","bhz.br","bio.br","blog.br","bmd.br","boavista.br","bsb.br","campinagrande.br","campinas.br","caxias.br","cim.br","cng.br","cnt.br","com.br","contagem.br","coop.br","cri.br","cuiaba.br","curitiba.br","def.br","ecn.br","eco.br","edu.br","emp.br","eng.br","esp.br","etc.br","eti.br","far.br","feira.br","flog.br","floripa.br","fm.br","fnd.br","fortal.br","fot.br","foz.br","fst.br","g12.br","ggf.br","goiania.br","gov.br","ac.gov.br","al.gov.br","am.gov.br","ap.gov.br","ba.gov.br","ce.gov.br","df.gov.br","es.gov.br","go.gov.br","ma.gov.br","mg.gov.br","ms.gov.br","mt.gov.br","pa.gov.br","pb.gov.br","pe.gov.br","pi.gov.br","pr.gov.br","rj.gov.br","rn.gov.br","ro.gov.br","rr.gov.br","rs.gov.br","sc.gov.br","se.gov.br","sp.gov.br","to.gov.br","gru.br","imb.br","ind.br","inf.br","jab.br","jampa.br","jdf.br","joinville.br","jor.br","jus.br","leg.br","lel.br","londrina.br","macapa.br","maceio.br","manaus.br","maringa.br","mat.br","med.br","mil.br","morena.br","mp.br","mus.br","natal.br","net.br","niteroi.br","*.nom.br","not.br","ntr.br","odo.br","org.br","osasco.br","palmas.br","poa.br","ppg.br","pro.br","psc.br","psi.br","pvh.br","qsl.br","radio.br","rec.br","recife.br","ribeirao.br","rio.br","riobranco.br","riopreto.br","salvador.br","sampa.br","santamaria.br","santoandre.br","saobernardo.br","saogonca.br","sjc.br","slg.br","slz.br","sorocaba.br","srv.br","taxi.br","teo.br","the.br","tmp.br","trd.br","tur.br","tv.br","udi.br","vet.br","vix.br","vlog.br","wiki.br","zlg.br","by","gov.by","mil.by","com.by","of.by","ca","ab.ca","bc.ca","mb.ca","nb.ca","nf.ca","nl.ca","ns.ca","nt.ca","nu.ca","on.ca","pe.ca","qc.ca","sk.ca","yk.ca","gc.ca","cat","cc","ch","cl","gov.cl","gob.cl","co.cl","mil.cl","club","cn","ac.cn","com.cn","edu.cn","gov.cn","net.cn","org.cn","mil.cn","公司.cn","网络.cn","網絡.cn","ah.cn","bj.cn","cq.cn","fj.cn","gd.cn","gs.cn","gz.cn","gx.cn","ha.cn","hb.cn","he.cn","hi.cn","hl.cn","hn.cn","jl.cn","js.cn","jx.cn","ln.cn","nm.cn","nx.cn","qh.cn","sc.cn","sd.cn","sh.cn","sn.cn","sx.cn","tj.cn","xj.cn","xz.cn","yn.cn","zj.cn","hk.cn","mo.cn","tw.cn","co","arts.co","com.co","edu.co","firm.co","gov.co","info.co","int.co","mil.co","net.co","nom.co","org.co","rec.co","web.co","com","cz","de","dk","edu","ee","edu.ee","gov.ee","riik.ee","lib.ee","med.ee","com.ee","pri.ee","aip.ee","org.ee","fie.ee","es","com.es","nom.es","org.es","gob.es","edu.es","eu","fi","aland.fi","fr","com.fr","asso.fr","nom.fr","prd.fr","presse.fr","tm.fr","aeroport.fr","assedic.fr","avocat.fr","avoues.fr","cci.fr","chambagri.fr","chirurgiens-dentistes.fr","experts-comptables.fr","geometre-expert.fr","gouv.fr","greta.fr","huissier-justice.fr","medecin.fr","notaires.fr","pharmacien.fr","port.fr","veterinaire.fr","gr","com.gr","edu.gr","net.gr","org.gr","gov.gr","hk","com.hk","edu.hk","gov.hk","idv.hk","net.hk","org.hk","公司.hk","教育.hk","敎育.hk","政府.hk","個人.hk","个人.hk","箇人.hk","網络.hk","网络.hk","组織.hk","網絡.hk","网絡.hk","组织.hk","組織.hk","組织.hk","hr","iz.hr","from.hr","name.hr","com.hr","hu","co.hu","info.hu","org.hu","priv.hu","sport.hu","tm.hu","2000.hu","agrar.hu","bolt.hu","casino.hu","city.hu","erotica.hu","erotika.hu","film.hu","forum.hu","games.hu","hotel.hu","ingatlan.hu","jogasz.hu","konyvelo.hu","lakas.hu","media.hu","news.hu","reklam.hu","sex.hu","shop.hu","suli.hu","szex.hu","tozsde.hu","utazas.hu","video.hu","id","ac.id","biz.id","co.id","desa.id","go.id","mil.id","my.id","net.id","or.id","sch.id","web.id","ie","gov.ie","il","ac.il","co.il","gov.il","idf.il","k12.il","muni.il","net.il","org.il","in","co.in","firm.in","net.in","org.in","gen.in","ind.in","nic.in","ac.in","edu.in","res.in","gov.in","mil.in","info","io","com.io","ir","ac.ir","co.ir","gov.ir","id.ir","net.ir","org.ir","sch.ir","ایران.ir","ايران.ir","kr","ac.kr","co.kr","es.kr","go.kr","hs.kr","kg.kr","mil.kr","ms.kr","ne.kr","or.kr","pe.kr","re.kr","sc.kr","busan.kr","chungbuk.kr","chungnam.kr","daegu.kr","daejeon.kr","gangwon.kr","gwangju.kr","gyeongbuk.kr","gyeonggi.kr","gyeongnam.kr","incheon.kr","jeju.kr","jeonbuk.kr","jeonnam.kr","seoul.kr","ulsan.kr","kz","org.kz","edu.kz","net.kz","gov.kz","mil.kz","com.kz","lt","gov.lt","lv","com.lv","edu.lv","gov.lv","org.lv","mil.lv","id.lv","net.lv","asn.lv","conf.lv","me","co.me","net.me","org.me","edu.me","ac.me","gov.me","its.me","priv.me","mx","com.mx","org.mx","gob.mx","edu.mx","net.mx","my","com.my","net.my","org.my","gov.my","edu.my","mil.my","name.my","net","ng","com.ng","edu.ng","gov.ng","i.ng","mil.ng","mobi.ng","name.ng","net.ng","org.ng","sch.ng","nl","bv.nl","nz","ac.nz","co.nz","cri.nz","geek.nz","gen.nz","govt.nz","health.nz","iwi.nz","kiwi.nz","maori.nz","mil.nz","māori.nz","net.nz","org.nz","parliament.nz","school.nz","online","org","pe","edu.pe","gob.pe","nom.pe","mil.pe","org.pe","com.pe","net.pe","ph","com.ph","net.ph","org.ph","gov.ph","edu.ph","ngo.ph","mil.ph","i.ph","pk","com.pk","net.pk","edu.pk","org.pk","fam.pk","biz.pk","web.pk","gov.pk","gob.pk","gok.pk","gon.pk","gop.pk","gos.pk","info.pk","pro","aaa.pro","aca.pro","acct.pro","avocat.pro","bar.pro","cpa.pro","eng.pro","jur.pro","law.pro","med.pro","recht.pro","pt","net.pt","gov.pt","org.pt","edu.pt","int.pt","publ.pt","com.pt","nome.pt","ro","arts.ro","com.ro","firm.ro","info.ro","nom.ro","nt.ro","org.ro","rec.ro","store.ro","tm.ro","www.ro","rs","ac.rs","co.rs","edu.rs","gov.rs","in.rs","org.rs","ru","ac.ru","edu.ru","gov.ru","int.ru","mil.ru","test.ru","se","a.se","ac.se","b.se","bd.se","brand.se","c.se","d.se","e.se","f.se","fh.se","fhsk.se","fhv.se","g.se","h.se","i.se","k.se","komforb.se","kommunalforbund.se","komvux.se","l.se","lanbib.se","m.se","n.se","naturbruksgymn.se","o.se","org.se","p.se","parti.se","pp.se","press.se","r.se","s.se","t.se","tm.se","u.se","w.se","x.se","y.se","z.se","sg","com.sg","net.sg","org.sg","gov.sg","edu.sg","per.sg","si","site","sk","su","th","tk","top","tr","com.tr","info.tr","biz.tr","net.tr","org.tr","web.tr","gen.tr","tv.tr","av.tr","dr.tr","bbs.tr","name.tr","tel.tr","gov.tr","bel.tr","pol.tr","mil.tr","k12.tr","edu.tr","kep.tr","nc.tr","gov.nc.tr","tv","tw","edu.tw","gov.tw","mil.tw","com.tw","net.tw","org.tw","idv.tw","game.tw","ebiz.tw","club.tw","網路.tw","組織.tw","商業.tw","ua","com.ua","edu.ua","gov.ua","in.ua","net.ua","org.ua","cherkassy.ua","cherkasy.ua","chernigov.ua","chernihiv.ua","chernivtsi.ua","chernovtsy.ua","ck.ua","cn.ua","cr.ua","crimea.ua","cv.ua","dn.ua","dnepropetrovsk.ua","dnipropetrovsk.ua","dominic.ua","donetsk.ua","dp.ua","if.ua","ivano-frankivsk.ua","kh.ua","kharkiv.ua","kharkov.ua","kherson.ua","khmelnitskiy.ua","khmelnytskyi.ua","kiev.ua","kirovograd.ua","km.ua","kr.ua","krym.ua","ks.ua","kv.ua","kyiv.ua","lg.ua","lt.ua","lugansk.ua","lutsk.ua","lv.ua","lviv.ua","mk.ua","mykolaiv.ua","nikolaev.ua","od.ua","odesa.ua","odessa.ua","pl.ua","poltava.ua","rivne.ua","rovno.ua","rv.ua","sb.ua","sebastopol.ua","sevastopol.ua","sm.ua","sumy.ua","te.ua","ternopil.ua","uz.ua","uzhgorod.ua","vinnica.ua","vinnytsia.ua","vn.ua","volyn.ua","yalta.ua","zaporizhzhe.ua","zaporizhzhia.ua","zhitomir.ua","zhytomyr.ua","zp.ua","zt.ua","uk","ac.uk","co.uk","gov.uk","ltd.uk","me.uk","net.uk","nhs.uk","org.uk","plc.uk","police.uk","*.sch.uk","us","dni.us","fed.us","isa.us","kids.us","nsn.us","ak.us","al.us","ar.us","as.us","az.us","ca.us","co.us","ct.us","dc.us","de.us","fl.us","ga.us","gu.us","hi.us","ia.us","id.us","il.us","in.us","ks.us","ky.us","la.us","ma.us","md.us","me.us","mi.us","mn.us","mo.us","ms.us","mt.us","nc.us","nd.us","ne.us","nh.us","nj.us","nm.us","nv.us","ny.us","oh.us","ok.us","or.us","pa.us","pr.us","ri.us","sc.us","sd.us","tn.us","tx.us","ut.us","vi.us","vt.us","va.us","wa.us","wi.us","wv.us","wy.us","k12.ak.us","k12.al.us","k12.ar.us","k12.as.us","k12.az.us","k12.ca.us","k12.co.us","k12.ct.us","k12.dc.us","k12.de.us","k12.fl.us","k12.ga.us","k12.gu.us","k12.ia.us","k12.id.us","k12.il.us","k12.in.us","k12.ks.us","k12.ky.us","k12.la.us","k12.ma.us","k12.md.us","k12.me.us","k12.mi.us","k12.mn.us","k12.mo.us","k12.ms.us","k12.mt.us","k12.nc.us","k12.ne.us","k12.nh.us","k12.nj.us","k12.nm.us","k12.nv.us","k12.ny.us","k12.oh.us","k12.ok.us","k12.or.us","k12.pa.us","k12.pr.us","k12.ri.us","k12.sc.us","k12.tn.us","k12.tx.us","k12.ut.us","k12.vi.us","k12.vt.us","k12.va.us","k12.wa.us","k12.wi.us","k12.wy.us","cc.ak.us","cc.al.us","cc.ar.us","cc.as.us","cc.az.us","cc.ca.us","cc.co.us","cc.ct.us","cc.dc.us","cc.de.us","cc.fl.us","cc.ga.us","cc.gu.us","cc.hi.us","cc.ia.us","cc.id.us","cc.il.us","cc.in.us","cc.ks.us","cc.ky.us","cc.la.us","cc.ma.us","cc.md.us","cc.me.us","cc.mi.us","cc.mn.us","cc.mo.us","cc.ms.us","cc.mt.us","cc.nc.us","cc.nd.us","cc.ne.us","cc.nh.us","cc.nj.us","cc.nm.us","cc.nv.us","cc.ny.us","cc.oh.us","cc.ok.us","cc.or.us","cc.pa.us","cc.pr.us","cc.ri.us","cc.sc.us","cc.sd.us","cc.tn.us","cc.tx.us","cc.ut.us","cc.vi.us","cc.vt.us","cc.va.us","cc.wa.us","cc.wi.us","cc.wv.us","cc.wy.us","lib.ak.us","lib.al.us","lib.ar.us","lib.as.us","lib.az.us","lib.ca.us","lib.co.us","lib.ct.us","lib.dc.us","lib.fl.us","lib.ga.us","lib.gu.us","lib.hi.us","lib.ia.us","lib.id.us","lib.il.us","lib.in.us","lib.ks.us","lib.ky.us","lib.la.us","lib.ma.us","lib.md.us","lib.me.us","lib.mi.us","lib.mn.us","lib.mo.us","lib.ms.us","lib.mt.us","lib.nc.us","lib.nd.us","lib.ne.us","lib.nh.us","lib.nj.us","lib.nm.us","lib.nv.us","lib.ny.us","lib.oh.us","lib.ok.us","lib.or.us","lib.pa.us","lib.pr.us","lib.ri.us","lib.sc.us","lib.sd.us","lib.tn.us","lib.tx.us","lib.ut.us","lib.vi.us","lib.vt.us","lib.va.us","lib.wa.us","lib.wi.us","lib.wy.us","pvt.k12.ma.us","chtr.k12.ma.us","paroch.k12.ma.us","ann-arbor.mi.us","cog.mi.us","dst.mi.us","eaton.mi.us","gen.mi.us","mus.mi.us","tec.mi.us","washtenaw.mi.us","vn","com.vn","net.vn","org.vn","edu.vn","gov.vn","int.vn","ac.vn","biz.vn","info.vn","name.vn","pro.vn","health.vn","xyz","ac.za","agric.za","alt.za","co.za","edu.za","gov.za","grondar.za","law.za","mil.za","net.za","ngo.za","nis.za","nom.za","org.za","school.za","tm.za","web.za","cc.ua","inf.ua","ltd.ua","beep.pl","*.compute.estate","*.alces.network","alwaysdata.net","cloudfront.net","*.compute.amazonaws.com","*.compute-1.amazonaws.com","*.compute.amazonaws.com.cn","us-east-1.amazonaws.com","cn-north-1.eb.amazonaws.com.cn","elasticbeanstalk.com","ap-northeast-1.elasticbeanstalk.com","ap-northeast-2.elasticbeanstalk.com","ap-northeast-3.elasticbeanstalk.com","ap-south-1.elasticbeanstalk.com","ap-southeast-1.elasticbeanstalk.com","ap-southeast-2.elasticbeanstalk.com","ca-central-1.elasticbeanstalk.com","eu-central-1.elasticbeanstalk.com","eu-west-1.elasticbeanstalk.com","eu-west-2.elasticbeanstalk.com","eu-west-3.elasticbeanstalk.com","sa-east-1.elasticbeanstalk.com","us-east-1.elasticbeanstalk.com","us-east-2.elasticbeanstalk.com","us-gov-west-1.elasticbeanstalk.com","us-west-1.elasticbeanstalk.com","us-west-2.elasticbeanstalk.com","*.elb.amazonaws.com","*.elb.amazonaws.com.cn","s3.amazonaws.com","s3-ap-northeast-1.amazonaws.com","s3-ap-northeast-2.amazonaws.com","s3-ap-south-1.amazonaws.com","s3-ap-southeast-1.amazonaws.com","s3-ap-southeast-2.amazonaws.com","s3-ca-central-1.amazonaws.com","s3-eu-central-1.amazonaws.com","s3-eu-west-1.amazonaws.com","s3-eu-west-2.amazonaws.com","s3-eu-west-3.amazonaws.com","s3-external-1.amazonaws.com","s3-fips-us-gov-west-1.amazonaws.com","s3-sa-east-1.amazonaws.com","s3-us-gov-west-1.amazonaws.com","s3-us-east-2.amazonaws.com","s3-us-west-1.amazonaws.com","s3-us-west-2.amazonaws.com","s3.ap-northeast-2.amazonaws.com","s3.ap-south-1.amazonaws.com","s3.cn-north-1.amazonaws.com.cn","s3.ca-central-1.amazonaws.com","s3.eu-central-1.amazonaws.com","s3.eu-west-2.amazonaws.com","s3.eu-west-3.amazonaws.com","s3.us-east-2.amazonaws.com","s3.dualstack.ap-northeast-1.amazonaws.com","s3.dualstack.ap-northeast-2.amazonaws.com","s3.dualstack.ap-south-1.amazonaws.com","s3.dualstack.ap-southeast-1.amazonaws.com","s3.dualstack.ap-southeast-2.amazonaws.com","s3.dualstack.ca-central-1.amazonaws.com","s3.dualstack.eu-central-1.amazonaws.com","s3.dualstack.eu-west-1.amazonaws.com","s3.dualstack.eu-west-2.amazonaws.com","s3.dualstack.eu-west-3.amazonaws.com","s3.dualstack.sa-east-1.amazonaws.com","s3.dualstack.us-east-1.amazonaws.com","s3.dualstack.us-east-2.amazonaws.com","s3-website-us-east-1.amazonaws.com","s3-website-us-west-1.amazonaws.com","s3-website-us-west-2.amazonaws.com","s3-website-ap-northeast-1.amazonaws.com","s3-website-ap-southeast-1.amazonaws.com","s3-website-ap-southeast-2.amazonaws.com","s3-website-eu-west-1.amazonaws.com","s3-website-sa-east-1.amazonaws.com","s3-website.ap-northeast-2.amazonaws.com","s3-website.ap-south-1.amazonaws.com","s3-website.ca-central-1.amazonaws.com","s3-website.eu-central-1.amazonaws.com","s3-website.eu-west-2.amazonaws.com","s3-website.eu-west-3.amazonaws.com","s3-website.us-east-2.amazonaws.com","t3l3p0rt.net","tele.amune.org","on-aptible.com","user.party.eus","pimienta.org","poivron.org","potager.org","sweetpepper.org","myasustor.com","myfritz.net","*.awdev.ca","*.advisor.ws","backplaneapp.io","betainabox.com","bnr.la","blackbaudcdn.net","boomla.net","boxfuse.io","square7.ch","bplaced.com","bplaced.de","square7.de","bplaced.net","square7.net","browsersafetymark.io","mycd.eu","ae.org","ar.com","br.com","cn.com","com.de","com.se","de.com","eu.com","gb.com","gb.net","hu.com","hu.net","jp.net","jpn.com","kr.com","mex.com","no.com","qc.com","ru.com","sa.com","se.net","uk.com","uk.net","us.com","uy.com","za.bz","za.com","africa.com","gr.com","in.net","us.org","co.com","c.la","certmgr.org","xenapponazure.com","virtueeldomein.nl","cleverapps.io","c66.me","cloud66.ws","jdevcloud.com","wpdevcloud.com","cloudaccess.host","freesite.host","cloudaccess.net","cloudcontrolled.com","cloudcontrolapp.com","co.ca","*.otap.co","co.cz","c.cdn77.org","cdn77-ssl.net","r.cdn77.net","rsc.cdn77.org","ssl.origin.cdn77-secure.org","cloudns.asia","cloudns.biz","cloudns.club","cloudns.cc","cloudns.eu","cloudns.in","cloudns.info","cloudns.org","cloudns.pro","cloudns.pw","cloudns.us","cloudeity.net","cnpy.gdn","co.nl","co.no","webhosting.be","hosting-cluster.nl","dyn.cosidns.de","dynamisches-dns.de","dnsupdater.de","internet-dns.de","l-o-g-i-n.de","dynamic-dns.info","feste-ip.net","knx-server.net","static-access.net","realm.cz","*.cryptonomic.net","cupcake.is","cyon.link","cyon.site","daplie.me","localhost.daplie.me","dattolocal.com","dattorelay.com","dattoweb.com","mydatto.com","dattolocal.net","mydatto.net","biz.dk","co.dk","firm.dk","reg.dk","store.dk","debian.net","dedyn.io","dnshome.de","drayddns.com","dreamhosters.com","mydrobo.com","drud.io","drud.us","duckdns.org","dy.fi","tunk.org","dyndns-at-home.com","dyndns-at-work.com","dyndns-blog.com","dyndns-free.com","dyndns-home.com","dyndns-ip.com","dyndns-mail.com","dyndns-office.com","dyndns-pics.com","dyndns-remote.com","dyndns-server.com","dyndns-web.com","dyndns-wiki.com","dyndns-work.com","dyndns.biz","dyndns.info","dyndns.org","dyndns.tv","at-band-camp.net","ath.cx","barrel-of-knowledge.info","barrell-of-knowledge.info","better-than.tv","blogdns.com","blogdns.net","blogdns.org","blogsite.org","boldlygoingnowhere.org","broke-it.net","buyshouses.net","cechire.com","dnsalias.com","dnsalias.net","dnsalias.org","dnsdojo.com","dnsdojo.net","dnsdojo.org","does-it.net","doesntexist.com","doesntexist.org","dontexist.com","dontexist.net","dontexist.org","doomdns.com","doomdns.org","dvrdns.org","dyn-o-saur.com","dynalias.com","dynalias.net","dynalias.org","dynathome.net","dyndns.ws","endofinternet.net","endofinternet.org","endoftheinternet.org","est-a-la-maison.com","est-a-la-masion.com","est-le-patron.com","est-mon-blogueur.com","for-better.biz","for-more.biz","for-our.info","for-some.biz","for-the.biz","forgot.her.name","forgot.his.name","from-ak.com","from-al.com","from-ar.com","from-az.net","from-ca.com","from-co.net","from-ct.com","from-dc.com","from-de.com","from-fl.com","from-ga.com","from-hi.com","from-ia.com","from-id.com","from-il.com","from-in.com","from-ks.com","from-ky.com","from-la.net","from-ma.com","from-md.com","from-me.org","from-mi.com","from-mn.com","from-mo.com","from-ms.com","from-mt.com","from-nc.com","from-nd.com","from-ne.com","from-nh.com","from-nj.com","from-nm.com","from-nv.com","from-ny.net","from-oh.com","from-ok.com","from-or.com","from-pa.com","from-pr.com","from-ri.com","from-sc.com","from-sd.com","from-tn.com","from-tx.com","from-ut.com","from-va.com","from-vt.com","from-wa.com","from-wi.com","from-wv.com","from-wy.com","ftpaccess.cc","fuettertdasnetz.de","game-host.org","game-server.cc","getmyip.com","gets-it.net","go.dyndns.org","gotdns.com","gotdns.org","groks-the.info","groks-this.info","ham-radio-op.net","here-for-more.info","hobby-site.com","hobby-site.org","home.dyndns.org","homedns.org","homeftp.net","homeftp.org","homeip.net","homelinux.com","homelinux.net","homelinux.org","homeunix.com","homeunix.net","homeunix.org","iamallama.com","in-the-band.net","is-a-anarchist.com","is-a-blogger.com","is-a-bookkeeper.com","is-a-bruinsfan.org","is-a-bulls-fan.com","is-a-candidate.org","is-a-caterer.com","is-a-celticsfan.org","is-a-chef.com","is-a-chef.net","is-a-chef.org","is-a-conservative.com","is-a-cpa.com","is-a-cubicle-slave.com","is-a-democrat.com","is-a-designer.com","is-a-doctor.com","is-a-financialadvisor.com","is-a-geek.com","is-a-geek.net","is-a-geek.org","is-a-green.com","is-a-guru.com","is-a-hard-worker.com","is-a-hunter.com","is-a-knight.org","is-a-landscaper.com","is-a-lawyer.com","is-a-liberal.com","is-a-libertarian.com","is-a-linux-user.org","is-a-llama.com","is-a-musician.com","is-a-nascarfan.com","is-a-nurse.com","is-a-painter.com","is-a-patsfan.org","is-a-personaltrainer.com","is-a-photographer.com","is-a-player.com","is-a-republican.com","is-a-rockstar.com","is-a-socialist.com","is-a-soxfan.org","is-a-student.com","is-a-teacher.com","is-a-techie.com","is-a-therapist.com","is-an-accountant.com","is-an-actor.com","is-an-actress.com","is-an-anarchist.com","is-an-artist.com","is-an-engineer.com","is-an-entertainer.com","is-by.us","is-certified.com","is-found.org","is-gone.com","is-into-anime.com","is-into-cars.com","is-into-cartoons.com","is-into-games.com","is-leet.com","is-lost.org","is-not-certified.com","is-saved.org","is-slick.com","is-uberleet.com","is-very-bad.org","is-very-evil.org","is-very-good.org","is-very-nice.org","is-very-sweet.org","is-with-theband.com","isa-geek.com","isa-geek.net","isa-geek.org","isa-hockeynut.com","issmarterthanyou.com","isteingeek.de","istmein.de","kicks-ass.net","kicks-ass.org","knowsitall.info","land-4-sale.us","lebtimnetz.de","leitungsen.de","likes-pie.com","likescandy.com","merseine.nu","mine.nu","misconfused.org","mypets.ws","myphotos.cc","neat-url.com","office-on-the.net","on-the-web.tv","podzone.net","podzone.org","readmyblog.org","saves-the-whales.com","scrapper-site.net","scrapping.cc","selfip.biz","selfip.com","selfip.info","selfip.net","selfip.org","sells-for-less.com","sells-for-u.com","sells-it.net","sellsyourhome.org","servebbs.com","servebbs.net","servebbs.org","serveftp.net","serveftp.org","servegame.org","shacknet.nu","simple-url.com","space-to-rent.com","stuff-4-sale.org","stuff-4-sale.us","teaches-yoga.com","thruhere.net","traeumtgerade.de","webhop.biz","webhop.info","webhop.net","webhop.org","worse-than.tv","writesthisblog.com","ddnss.de","dyn.ddnss.de","dyndns.ddnss.de","dyndns1.de","dyn-ip24.de","home-webserver.de","dyn.home-webserver.de","myhome-server.de","ddnss.org","definima.net","definima.io","bci.dnstrace.pro","ddnsfree.com","ddnsgeek.com","giize.com","gleeze.com","kozow.com","loseyourip.com","ooguy.com","theworkpc.com","casacam.net","dynu.net","accesscam.org","camdvr.org","freeddns.org","mywire.org","webredirect.org","myddns.rocks","blogsite.xyz","dynv6.net","e4.cz","mytuleap.com","enonic.io","customer.enonic.io","eu.org","al.eu.org","asso.eu.org","at.eu.org","au.eu.org","be.eu.org","bg.eu.org","ca.eu.org","cd.eu.org","ch.eu.org","cn.eu.org","cy.eu.org","cz.eu.org","de.eu.org","dk.eu.org","edu.eu.org","ee.eu.org","es.eu.org","fi.eu.org","fr.eu.org","gr.eu.org","hr.eu.org","hu.eu.org","ie.eu.org","il.eu.org","in.eu.org","int.eu.org","is.eu.org","it.eu.org","jp.eu.org","kr.eu.org","lt.eu.org","lu.eu.org","lv.eu.org","mc.eu.org","me.eu.org","mk.eu.org","mt.eu.org","my.eu.org","net.eu.org","ng.eu.org","nl.eu.org","no.eu.org","nz.eu.org","paris.eu.org","pl.eu.org","pt.eu.org","q-a.eu.org","ro.eu.org","ru.eu.org","se.eu.org","si.eu.org","sk.eu.org","tr.eu.org","uk.eu.org","us.eu.org","eu-1.evennode.com","eu-2.evennode.com","eu-3.evennode.com","eu-4.evennode.com","us-1.evennode.com","us-2.evennode.com","us-3.evennode.com","us-4.evennode.com","twmail.cc","twmail.net","twmail.org","mymailer.com.tw","url.tw","apps.fbsbx.com","ru.net","adygeya.ru","bashkiria.ru","bir.ru","cbg.ru","com.ru","dagestan.ru","grozny.ru","kalmykia.ru","kustanai.ru","marine.ru","mordovia.ru","msk.ru","mytis.ru","nalchik.ru","nov.ru","pyatigorsk.ru","spb.ru","vladikavkaz.ru","vladimir.ru","abkhazia.su","adygeya.su","aktyubinsk.su","arkhangelsk.su","armenia.su","ashgabad.su","azerbaijan.su","balashov.su","bashkiria.su","bryansk.su","bukhara.su","chimkent.su","dagestan.su","east-kazakhstan.su","exnet.su","georgia.su","grozny.su","ivanovo.su","jambyl.su","kalmykia.su","kaluga.su","karacol.su","karaganda.su","karelia.su","khakassia.su","krasnodar.su","kurgan.su","kustanai.su","lenug.su","mangyshlak.su","mordovia.su","msk.su","murmansk.su","nalchik.su","navoi.su","north-kazakhstan.su","nov.su","obninsk.su","penza.su","pokrovsk.su","sochi.su","spb.su","tashkent.su","termez.su","togliatti.su","troitsk.su","tselinograd.su","tula.su","tuva.su","vladikavkaz.su","vladimir.su","vologda.su","channelsdvr.net","fastlylb.net","map.fastlylb.net","freetls.fastly.net","map.fastly.net","a.prod.fastly.net","global.prod.fastly.net","a.ssl.fastly.net","b.ssl.fastly.net","global.ssl.fastly.net","fastpanel.direct","fastvps-server.com","fhapp.xyz","fedorainfracloud.org","fedorapeople.org","cloud.fedoraproject.org","app.os.fedoraproject.org","app.os.stg.fedoraproject.org","filegear.me","firebaseapp.com","flynnhub.com","flynnhosting.net","freebox-os.com","freeboxos.com","fbx-os.fr","fbxos.fr","freebox-os.fr","freeboxos.fr","freedesktop.org","*.futurecms.at","*.ex.futurecms.at","*.in.futurecms.at","futurehosting.at","futuremailing.at","*.ex.ortsinfo.at","*.kunden.ortsinfo.at","*.statics.cloud","service.gov.uk","github.io","githubusercontent.com","gitlab.io","homeoffice.gov.uk","ro.im","shop.ro","goip.de","*.0emm.com","appspot.com","blogspot.ae","blogspot.al","blogspot.am","blogspot.ba","blogspot.be","blogspot.bg","blogspot.bj","blogspot.ca","blogspot.cf","blogspot.ch","blogspot.cl","blogspot.co.at","blogspot.co.id","blogspot.co.il","blogspot.co.ke","blogspot.co.nz","blogspot.co.uk","blogspot.co.za","blogspot.com","blogspot.com.ar","blogspot.com.au","blogspot.com.br","blogspot.com.by","blogspot.com.co","blogspot.com.cy","blogspot.com.ee","blogspot.com.eg","blogspot.com.es","blogspot.com.mt","blogspot.com.ng","blogspot.com.tr","blogspot.com.uy","blogspot.cv","blogspot.cz","blogspot.de","blogspot.dk","blogspot.fi","blogspot.fr","blogspot.gr","blogspot.hk","blogspot.hr","blogspot.hu","blogspot.ie","blogspot.in","blogspot.is","blogspot.it","blogspot.jp","blogspot.kr","blogspot.li","blogspot.lt","blogspot.lu","blogspot.md","blogspot.mk","blogspot.mr","blogspot.mx","blogspot.my","blogspot.nl","blogspot.no","blogspot.pe","blogspot.pt","blogspot.qa","blogspot.re","blogspot.ro","blogspot.rs","blogspot.ru","blogspot.se","blogspot.sg","blogspot.si","blogspot.sk","blogspot.sn","blogspot.td","blogspot.tw","blogspot.ug","blogspot.vn","cloudfunctions.net","cloud.goog","codespot.com","googleapis.com","googlecode.com","pagespeedmobilizer.com","publishproxy.com","withgoogle.com","withyoutube.com","hashbang.sh","hasura.app","hasura-app.io","hepforge.org","herokuapp.com","herokussl.com","myravendb.com","ravendb.community","ravendb.me","development.run","ravendb.run","moonscale.net","iki.fi","biz.at","info.at","info.cx","ac.leg.br","al.leg.br","am.leg.br","ap.leg.br","ba.leg.br","ce.leg.br","df.leg.br","es.leg.br","go.leg.br","ma.leg.br","mg.leg.br","ms.leg.br","mt.leg.br","pa.leg.br","pb.leg.br","pe.leg.br","pi.leg.br","pr.leg.br","rj.leg.br","rn.leg.br","ro.leg.br","rr.leg.br","rs.leg.br","sc.leg.br","se.leg.br","sp.leg.br","to.leg.br","pixolino.com","ipifony.net","mein-iserv.de","test-iserv.de","myjino.ru","*.hosting.myjino.ru","*.landing.myjino.ru","*.spectrum.myjino.ru","*.vps.myjino.ru","*.triton.zone","*.cns.joyent.com","js.org","keymachine.de","knightpoint.systems","co.krd","edu.krd","git-repos.de","lcube-server.de","svn-repos.de","app.lmpm.com","linkitools.space","linkyard.cloud","linkyard-cloud.ch","we.bs","uklugs.org","glug.org.uk","lug.org.uk","lugs.org.uk","barsy.bg","barsy.co.uk","barsyonline.co.uk","barsycenter.com","barsyonline.com","barsy.club","barsy.de","barsy.eu","barsy.in","barsy.info","barsy.io","barsy.me","barsy.menu","barsy.mobi","barsy.net","barsy.online","barsy.org","barsy.pro","barsy.pub","barsy.shop","barsy.site","barsy.support","barsy.uk","*.magentosite.cloud","mayfirst.info","mayfirst.org","hb.cldmail.ru","miniserver.com","memset.net","cloud.metacentrum.cz","custom.metacentrum.cz","flt.cloud.muni.cz","usr.cloud.muni.cz","meteorapp.com","eu.meteorapp.com","co.pl","azurecontainer.io","azurewebsites.net","azure-mobile.net","cloudapp.net","mozilla-iot.org","bmoattachments.org","net.ru","org.ru","pp.ru","bitballoon.com","netlify.com","4u.com","ngrok.io","nh-serv.co.uk","nfshost.com","dnsking.ch","mypi.co","n4t.co","001www.com","ddnslive.com","myiphost.com","forumz.info","16-b.it","32-b.it","64-b.it","soundcast.me","tcp4.me","dnsup.net","hicam.net","now-dns.net","ownip.net","vpndns.net","dynserv.org","now-dns.org","x443.pw","now-dns.top","ntdll.top","freeddns.us","crafting.xyz","zapto.xyz","nsupdate.info","nerdpol.ovh","blogsyte.com","brasilia.me","cable-modem.org","ciscofreak.com","collegefan.org","couchpotatofries.org","damnserver.com","ddns.me","ditchyourip.com","dnsfor.me","dnsiskinky.com","dvrcam.info","dynns.com","eating-organic.net","fantasyleague.cc","geekgalaxy.com","golffan.us","health-carereform.com","homesecuritymac.com","homesecuritypc.com","hopto.me","ilovecollege.info","loginto.me","mlbfan.org","mmafan.biz","myactivedirectory.com","mydissent.net","myeffect.net","mymediapc.net","mypsx.net","mysecuritycamera.com","mysecuritycamera.net","mysecuritycamera.org","net-freaks.com","nflfan.org","nhlfan.net","no-ip.ca","no-ip.co.uk","no-ip.net","noip.us","onthewifi.com","pgafan.net","point2this.com","pointto.us","privatizehealthinsurance.net","quicksytes.com","read-books.org","securitytactics.com","serveexchange.com","servehumour.com","servep2p.com","servesarcasm.com","stufftoread.com","ufcfan.org","unusualperson.com","workisboring.com","3utilities.com","bounceme.net","ddns.net","ddnsking.com","gotdns.ch","hopto.org","myftp.biz","myftp.org","myvnc.com","no-ip.biz","no-ip.info","no-ip.org","noip.me","redirectme.net","servebeer.com","serveblog.net","servecounterstrike.com","serveftp.com","servegame.com","servehalflife.com","servehttp.com","serveirc.com","serveminecraft.net","servemp3.com","servepics.com","servequake.com","sytes.net","webhop.me","zapto.org","stage.nodeart.io","nodum.co","nodum.io","pcloud.host","nyc.mn","nom.ae","nom.af","nom.ai","nom.al","nym.by","nym.bz","nom.cl","nom.gd","nom.ge","nom.gl","nym.gr","nom.gt","nym.gy","nom.hn","nym.ie","nom.im","nom.ke","nym.kz","nym.la","nym.lc","nom.li","nym.li","nym.lt","nym.lu","nym.me","nom.mk","nym.mn","nym.mx","nom.nu","nym.nz","nym.pe","nym.pt","nom.pw","nom.qa","nym.ro","nom.rs","nom.si","nym.sk","nom.st","nym.su","nym.sx","nom.tj","nym.tw","nom.ug","nom.uy","nom.vc","nom.vg","cya.gg","cloudycluster.net","nid.io","opencraft.hosting","operaunite.com","outsystemscloud.com","ownprovider.com","own.pm","ox.rs","oy.lc","pgfog.com","pagefrontapp.com","art.pl","gliwice.pl","krakow.pl","poznan.pl","wroc.pl","zakopane.pl","pantheonsite.io","gotpantheon.com","mypep.link","on-web.fr","*.platform.sh","*.platformsh.site","xen.prgmr.com","priv.at","protonet.io","chirurgiens-dentistes-en-france.fr","byen.site","ras.ru","qa2.com","dev-myqnapcloud.com","alpha-myqnapcloud.com","myqnapcloud.com","*.quipelements.com","vapor.cloud","vaporcloud.io","rackmaze.com","rackmaze.net","rhcloud.com","resindevice.io","devices.resinstaging.io","hzc.io","wellbeingzone.eu","ptplus.fit","wellbeingzone.co.uk","sandcats.io","logoip.de","logoip.com","schokokeks.net","scrysec.com","firewall-gateway.com","firewall-gateway.de","my-gateway.de","my-router.de","spdns.de","spdns.eu","firewall-gateway.net","my-firewall.org","myfirewall.org","spdns.org","*.s5y.io","*.sensiosite.cloud","biz.ua","co.ua","pp.ua","shiftedit.io","myshopblocks.com","1kapp.com","appchizi.com","applinzi.com","sinaapp.com","vipsinaapp.com","bounty-full.com","alpha.bounty-full.com","beta.bounty-full.com","static.land","dev.static.land","sites.static.land","apps.lair.io","*.stolos.io","spacekit.io","customer.speedpartner.de","storj.farm","utwente.io","temp-dns.com","diskstation.me","dscloud.biz","dscloud.me","dscloud.mobi","dsmynas.com","dsmynas.net","dsmynas.org","familyds.com","familyds.net","familyds.org","i234.me","myds.me","synology.me","vpnplus.to","taifun-dns.de","gda.pl","gdansk.pl","gdynia.pl","med.pl","sopot.pl","gwiddle.co.uk","cust.dev.thingdust.io","cust.disrec.thingdust.io","cust.prod.thingdust.io","cust.testing.thingdust.io","bloxcms.com","townnews-staging.com","12hp.at","2ix.at","4lima.at","lima-city.at","12hp.ch","2ix.ch","4lima.ch","lima-city.ch","trafficplex.cloud","de.cool","12hp.de","2ix.de","4lima.de","lima-city.de","1337.pictures","clan.rip","lima-city.rocks","webspace.rocks","lima.zone","*.transurl.be","*.transurl.eu","*.transurl.nl","tuxfamily.org","dd-dns.de","diskstation.eu","diskstation.org","dray-dns.de","draydns.de","dyn-vpn.de","dynvpn.de","mein-vigor.de","my-vigor.de","my-wan.de","syno-ds.de","synology-diskstation.de","synology-ds.de","uber.space","*.uberspace.de","hk.com","hk.org","ltd.hk","inc.hk","virtualuser.de","virtual-user.de","lib.de.us","2038.io","router.management","v-info.info","wedeploy.io","wedeploy.me","wedeploy.sh","remotewd.com","wmflabs.org","half.host","xnbay.com","u2.xnbay.com","u2-local.xnbay.com","cistron.nl","demon.nl","xs4all.space","official.academy","yolasite.com","ybo.faith","yombo.me","homelink.one","ybo.party","ybo.review","ybo.science","ybo.trade","nohost.me","noho.st","za.net","za.org","now.sh","zone.id"]
            for (const r of rules) {
                if (d.endsWith('.' + r)) {
                    const m = d.substr(0, d.length - r.length - 1);
                    return m.substr(m.lastIndexOf('.') + 1);
                }
            }
            const m = d.substr(0, d.lastIndexOf('.'));
            return m.substr(m.lastIndexOf('.') + 1);
        }

        // SLD match
        if (getSLD(domain) === getSLD(origin)) { return; }

        // SLD does NOT match
        header.value = '';
        return;
    }
}

UPDATE: the line header.value = domain; near the end of script replaced by header.value = '';

And get the web extension CORS Everywhere with (which will deal with responses):
Enabled at startup = Checked
Force value of access-control-allow-origin = empty
Activation whitelist = empty

I would like to thank the author of HeaderEditor: @sylingd (see: https://github.com/FirefoxBar/HeaderEditor/issues/107).

Cheers

[Woofy-Wolf]

@crssi, I added them, and the browser is purring. :)

[crssi]

^^ Cool. Be aware that this is experimental and that the CORS is disabled in this case, to avoid breakages and be aware that you could get fooled with some phishing sites (not very likely, but danger is there).
In the upper solution the focus was to detect SLD (second level domain) and if match then Origin is not striped (to avoid breakages).
I have found now only one breakage, where a page is using integrated 3rd party search provider and the search for obvious reason does not work (if the upper rule is enabled). In that case the problematic request is over XHR.
I am still not sure what exactly to do with XHRs (allow or not). But as I said, I have focused to SLDs on request headers for now.
Now I will dig into response headers.

Anyway, it would be much, much better to have a separate web extension to deal with those, but I am not top notch programmer, unfortunately and have a zero knowledge in the web extension development.
Best would be if the SmartReferer WE (SR) would have this solution implemented. SR already has SLD detection implemented and referer header would also be very handy with the decision heuristics. For obvious reasons an additional WE would be throwing a dice confliction with other extensions that manipulate referer header.

[crssi]

@Woofy-Wolf, do you have any follow up? Everything is good? At least in the last week I had no single breakage.

@claustromaniac, source code of CORS Everywhere looks interesting to be combined with latest upper script into a new WE.

@All, is there any interest here, or should I close this topic to remove a "clutter"?

[claustromaniac]

I could write an extension for this, I've considered it many times. The main thing that keeps holding me back is the fact that whatever we do to deal with this will inevitably break other stuff, and I'm not just talking about site breakages. I'm more concerned about disrupting other extensions that modify headers (like uBO, uM, CB, SR, HE, long etc). It sucks, but until Mozilla resolves these bugs (and depending on what they end up doing), I don't see any optimal solution. We have to give up something one way or another.

Personally, I don't have to deal with this because I generally block most requests for third-party content. That's because most of what I do is just read stuff.

@ALL, is there any interest here, or should I close this topic to remove a "clutter"?

I am interested in this... I just feel like my hands are tied for now. Still, I'd leave it open, for visibility. BTW this one definitely deserves my special label...

[Thorin-Oakenpants]

leave it open for now

edit: and I wouldn't write an extension if it means uM, uBO could break

CB should be fine if you disable that one setting, wots SR? and why would HE break?

[Woofy-Wolf]

@crssi No site breakage so far! ha, well, plenty of site breakage, but not from this. Thank you.

[claustromaniac]

wots SR?

I called Smart Referer SR this one time because (I'm lazy) it was already mentioned in this thread.

and why would HE break?

It wouldn't necessarily break, or break other extensions. That depends on what you do with it. It has the potential to wreak havok simply because you can modify most headers with it if you want.

Anyway, I ran some tests for a while, and it seems my initial interpretation of the problem with OnHeadersReceived was partly wrong. It's a pretty serious issue when it comes to CSP and such headers, but if we only need to remove Origin request headers and inject ACAO response headers, the risk of conflicts is probably not that bad, actually.

I guess I'll see what I can do, but no promises.

[claustromaniac]

https://addons.mozilla.org/en-US/firefox/addon/privacy-oriented-origin-policy/
https://github.com/claustromaniac/poop

It's super minimalist (for now, at least). It uses the approach I came up with here, so it shouldn't break much, and it should be safe.

[crssi]

@claustromaniac that's cool, but needs some more work and brainstorming.
I am really happy to see your motivations.

For every response, where Origin is removed/altered at request, the ACAO should also be altered.

Secondly, we would like to avoid altering, where its not needed and/or gives us too many breakages

1. avoid, where whitelisted (we haven't talk about this yet)
2. avoid, where source and destination domain is the same and exit further execution, since the next step (3) is resource intesive.
3. avoid, where source SLD is same as destination SLD.

With your WE we have the first breakage... play any youtube video and you'll see right away.
In my latest "solution" this does not happen.
Damn, due to my stupidity, I have lost file with breakage URL examples I have collected and dealt with. Will try to create a new one.

I am very motivated to brainstorm together. Also might help with the ideas reading the code... but I am only "scripter" and do not have adequate knowledge to do quality coding.

Should we close this issue and make a brand new one with the lastest findings (to avoid clutter and TLDR)?
Also to continue further actions about your WE under your github repository issues?

Cheers

[claustromaniac]

For every response, where Origin is removed/altered at request, the ACAO should also be altered.

That's exactly what it does.

1. Yeah, this could use a whitelist. That will have to wait, though. UI's are not my thing :weary:
2. &
3. I see two problems with your approach:
   
   
   
   1. It won't work universally. There are scenarios where two very different hostnames belong to the same party.
   
   
   2. As you said, it's expensive performance-wise.
   
   

With your WE we have the first breakage... play any youtube video and you'll see right away.

This was a very useful example! What happens is that youtube includes credentials when it attempts to fetch the video, but instead of cookies it uses URL parameters as credentials. In v 0.1.2 I've left out those requests too, and I also left out all requests with an Authorization header. Neither of those are touched. @alexander255, you might want to do the same in Smart Referer if you still intend to implement this. You're more than welcome to borrow code or ideas from this tiny extension if there is anything of use to you there.

It should be pointed out that this tiny extension is perfectly safe from a security standpoint because injecting Access-Control-Allow-Origin: * can at worst cause shit to break. If a request is configured to include credentials, the same-origin policy will not fetch the resource when it reads an ACAO: * header, and it instead just errors-out (this is exactly what was happening with youtube). The only potential risks I see are actually privacy-related, but they are kinda far-fetched.

Should we close this issue and make a brand new one with the lastest findings (to avoid clutter and TLDR)?
Also to continue further actions about your WE under your github repository issues?

I'll leave that up to you.

Edit: rewording.

[crssi]

It won't work universally. There are scenarios where two very different hostnames belong to the same party.

Exactly, that why I have a breakages with your WE on internal web applications. ;)
If you do SLD matching then there are no breakages. ;)

As you said, it's expensive performance-wise.

SR is also doing sort of SLDs and we do not see heavy lifting. Same goes with my HE script + CORS Everywhere.

Cheers

[claustromaniac]

I meant that foo.bar and iamtotallydifferent can still be owned by the same party, which your approach doesn't cover. That's the limitation I see. Does v0.1.2 still break stuff for you?

[crssi]

^^ That is true, but from all the test browsing I have done, at those cases are no brekages when Origin is removed. So no harm.

[atomGit]

alexander255, you might want to do the same in Smart Referer if you still intend to implement this

waddabout Gorhill, should he be pinged regarding this since uM can spoof referrers?

[crssi]

Check for updates does not find yet 0.1.2 on AMO. Will try again later.

I am not sure, would need to check, but I am not sure that uM covers subdomains like SR does (SLD +TLD matching).

Cheers

[ghost]

claustromaniac has released _Privacy Oriented Origin Policy_ Firefox extension, on AMO and on his GitHub repository. Stated as experimental. I encounter no issues up to now.

[crssi]

@claustromaniac
Trying now on 0.1.3. OMG, you are a true wizard. :+1: :heart:
Internal applications works and almost everywhere (where needed) the Origin is filtered out. :+1:
I have found a few leakages, but its in a minority and do not see some serious problems with that, but will report you back when I collect more, just give me a few days (will stumble all around over a fiddler, where I can see the Origin easily).

Thank you :smile:

[Thorin-Oakenpants]

I'm just waiting for this to mature, and for all the extension clashing to be uber minimal.

But I gotta say, the name is not the best IMO. It might be fun to have an acronym that means :hankey: , but it's not professional "looking" (at least don't use a poop emoji icon to draw attention to it). Remember Crap Cleaner => CCleaner.

Just my opinion. Just give a thought :kiss:

:catpoop:

[atomGit]

keep the name and icon - it's cute ... my $.02

[crssi]

Well it doesn't give a shit about Origins. lol
For sure it doesn't represent the case, but I also find it cute. :smile:

[crssi]

@Thorin-Oakenpants in which direction are you aiming?

[Thorin-Oakenpants]

@crssi Not for me to decide, I just gave an opinion. Personally I think a turd/shit/poop/crap icon is tacky AF, isn't "professional" looking (and in that sense, undermines the quality and developer). People will judge based on looks. I know I do, e.g. when I come across a shitty (pun intended) website that doesn't know how to lay things out - maybe I'm biased, from seeing the results of people's first attempts at building UIs (lets not go there) where it just smacks of amateurism.

[atomGit]

um, pants, my friend ... have a look at your avatar

jus sayin :)

[Thorin-Oakenpants]

The repo is produced under an organization, plus it has no icon or anything. Does claustro's avatar have anything to directly do with what is presented on AMO to the public?

[crssi]

Funny something with my profile? user.js?
I can see on AMO there is a newer version (0.2.0) of PooP and I have 0.1.3, but check for updates doesn't find anything new.
Or is that "normal" behavior of WEs marked as experimental?

UPDATE: Doh... its fiddler proxy that is the culprit.

[claustromaniac]

@crssi Glad to help, and sorry for taking so long to get down to business in the first place. The extension itself is super small, so making it only took about an hour or two, tops (didn't check). It was all my fault for not testing OnHeadersReceived earlier to see how bad the conflicts were in reality.

I have found a few leakages, but its in a minority and do not see some serious problems with that, but will report you back when I collect more, just give me a few days (will stumble all around over a fiddler, where I can see the Origin easily).

Sure, I'm sure there's still some room for improvements. Ideally, there should be some way to detect if requests include credentials via some API, but that doesn't seem to exist (yet?) :disappointed:. That's why I resort to heuristics, and this approach also gives the priority to security and functionality (over privacy), hence the leaks.

I'm just waiting for this to mature, and for all the extension clashing to be uber minimal.

I'm pretty sure now the conflicts will only happen when using this with other extensions that modify Origin (haven't seen any) and/or ACAO, specifically (like CORS everywhere). I should actually remove the Experimental mark, because this is safe, but I should document it well first...

As for the name/icon... I'm glad it doesn't sound/look professional because I'm not professional. I generally find it more comfortable to lower people's expectations from the start than to deal with their disappointment when they discover that on their own. But, more than anything, I chose that name and icon because I couldn't come up with anything convincing (and I didn't give a :hankey:). Funny = easy, in this case. If you can think of something better feel free to give specific suggestions.

[crssi]

@Woofy-Wolf if you are interested, I have made one small change at https://github.com/ghacksuserjs/ghacks-user.js/issues/509#issuecomment-440196764 (what the change is is under "UPDATE" just after the script.

[crssi]

@claustromaniac
OK... everything looked quite OK with a few leaks, then it occurs me that I have uBO and uM very good tuned (by my standards) and wondered what would happen if I disable them (I know, what a heretic though, it almost make me puke).

So I have disabled uBO and uM, opened DDG, thinking about what to search looking at my mice and typed in logitech review.... and opened the following URLs:

https://www.trustedreviews.com/reviews/logitech-g903
https://www.cnet.com/reviews/logitech-revue-google-tv-review/
https://www.techradar.com/reviews/logitech-g513
https://www.lifewire.com/logitech-m325-review-2640083
https://www.logitech.com/en-us
https://www.logitechg.com/en-us
https://www.techhive.com/article/3310606/home-theater/logitech-k600-review.html

Test results with PooP (uBO and uM disabled)
None noticeable delays
No breakages found
Enormous amount of Origin leaks

Test results with PooP (uBO and uM enabled with a good filter sources)
None noticeable delays
No breakages found
Every once and then - minimum of Origin leaks

Test results with HE script + Cors Everywhere
None noticeable delays
No breakages found
0 (zero) of Origin leaks

PooP WE deals quite good but only if you have a very good filter sources for uBO and uM.
I still think that PooP should be a combination of PooP + approach used in HE script.

Cheers

[claustromaniac]

@crssi
Thanks for that. Keep in mind that less leaks doesn't mean your approach is better, it just means it's more aggressive. I assume you normally remove outbound cookies with uM, and that is why POOP modifies more requests when you leave it enabled, and less when you disable it. Your examples are good because they show something that is super prevalent in the web: requests to CDNs that include unnecessary (generally tracking) cookies.

I think I'll make POOP default to a more aggressive (but still perfectly safe) method that doesn't take into account cookies and URL parameters, and allow users to fallback to the less aggressive method or fully whitelist sites when something breaks. I think that would be a good way to go about it, because that way we can be more aggressive without having to sacrifice the same-origin policy, which is something I want to avoid.

I'll get to it as soon as I can, thanks again :+1:

[crssi]

Cool. :smile:
Its true that I have uM 3rd party cookies blocked, but I have so also in FF setings (so it should not matter),
Anyway, I did the same test with uBO disabled and uM enabled and it didn't make a difference and it should not be, since FF settings to block 3rd party cookies anyway.

I can't wait for your next version.... and thank You. :+1:

Cheers

[Atavic]

@crssi great efforts with Header Editor. I'd like to get CSS File queries blocked with it.
Related issue here

[crssi]

^^ I am not sure that this can be tacked with HE. It has nothing to do with requests and responds.
To do that we would need something (like injected sript) which would read @media and if the line is to be longer than some threshold, it should have been removed (or replaced or something).... just thinking out loud.
But would that action make us even more unique?
I think this should be something RFP should resolve.

[Woofy-Wolf]

@crssi thanks for your updated HE code. Thanks @claustromaniac for your WE.

[crssi]

@claustromaniac testing now 0.3.0
Can you make it strict stripping origin for font and stylesheet type of request?

[claustromaniac]

Sure thing. I'll add those as optional features in the next version. I work fast ^{[citation needed]}, but it will take a little while because I only started working on it today and I still have to put together the UI elements and stuff.

[claustromaniac]

I made a pre-release here. All feedback is welcome. Thanks in advance.

OT: Damn... I didn't expect such a backlog of stuff to read after just a couple of days of not paying attention to GitHub... Will have to read in chunks.

[crssi]

This looks awesome. Heavily relying on uBO anti-tracking filters I had leakages on some fonts and css's (one of the offenders was bootstrap cdn). Now (with this pre-release), those are also gone.
Please, give me a few days of monitoring and testing different setting, since I do not want prematurely jump into conclusions and give false report.

But before, can you explain more deep the methods of relaxed and aggressive modes?
Understanding those, will greatly improve testing methods/approach.

Do you have any "debug/log" output and where to find it?

What means "use Sync storage"?

Thank you and cheers

[claustromaniac]

• Aggressive mode is basically the same as relaxed mode, except it doesn't care if requests include cookies or the query section of the URL. In other words, it removes origins from all GET requests, simple as that.
• Relaxed mode is the same the extension was doing up to 0.3.0. It guesses which GET requests include credentials based on the presence of cookies, authorization and/or URL query.

When I say both modes are safe from a security standpoint, it is because of two things:

1. they only touch GET requests. This is important not only because altering other types would surely cause them to break, but more so because of the risk of CSRF, which is a different threat.
2. by using Access-Control-Allow-Origin: *, we ensure that if a request was flagged as including credentials (and it slipped past the relaxed mode somehow, or it was outright ignored by the aggressive mode), the same-origin policy will abort that request.

Edit: I should totally document all of this... and I should also mention that the aggressive mode will cause the browser to make less requests overall, because when a request for a script is aborted by the same-origin policy, all requests said script would normally initiate on its own just won't happen.

Do you have any "debug/log" output and where to find it?

Some actions are logged in the console, but the info is pretty minimal. I use the browser's built-in developer tools for my tests, but maybe I can improve the debugging info a little...

What means "use Sync storage"?

I should explain that better in the options page itself, right? :sweat_smile: I think most extensions normally use the local storage area for saving their settings, but if someone wants to sync their settings (with Mozilla's Sync service), they need to store them in the sync storage area. Even if one does not use Sync, storing data in the sync area should be OK because, in theory, the data wouldn't go anywhere if Sync is not enabled (and/or you're not logged in and such), but some people prefer not to store anything in there just in case (@earthlng I'm looking at you), that's why I make that optional (and default off). EDIT: I removed it in 1.0.0b2 because it turns out it has limited capacity.

[claustromaniac]

Just FYI, I made a second pre-release. I didn't touch the core functionality except for adding a few new optional strict filters, it's mostly just UI changes and minor bugfixes.

[claustromaniac]

I've been thinking that it would make sense for POOP to automatically remove Referer headers from the requests that it is already modifying. That would take about an extra 3 lines of code, and I don't think it would clash with anything.

I'm wondering if I should do it an optional thing, or what. Personally, I think the extension should just remove them without even asking. Users wouldn't want referer headers in those requests anyway, and if something breaks we can now (since 1.0.0b) whitelist sites and everything. I'm mostly thinking about people who install stuff without reading first: if they don't know that they are expected to deal with referers by other means, this extension will actually end up making them more unique.

Any thoughts? :-1::+1:?

:see_no_evil: :hear_no_evil: :speak_no_evil:?

[crssi]

When I rely heavily on uBO good filter lists, I have almost 100% sucess rate on relaxed + font, which is sufficiently great (at least for me).
But if I disable uBO and/or don't use good filter lists, then I have a lot of leakages... also a lot over XHR.
If you seek to extend, then I would also add removal possibility of etag and x-forward-for response headers.
I am not sure about referer, maybe its better to leave it to Smart Referer? IDK really.

Anyway, PooP seems to be a great extension and I am really grateful for your work.

[crssi]

Damn... too fast. I kinda take back what I have said about "almost 100%".
There are still leakages over XHR.
If I use PooP relaxed + font + XHR, than its OK, but I get a breakages at some login pages and from what I see, there would be none (from my samples) if there would be a SLD match auto allow.

[Atavic]

:+1: I needed some days to fully grasp what's going on in this thread. You guys are doing actual research and that's a marvellous endeavour.

[claustromaniac]

If you seek to extend, then I would also add removal possibility of etag and x-forward-for response headers.
I am not sure about referer, maybe its better to leave it to Smart Referer? IDK really.

That would fall out of the scope of this extension. I'm actually not looking for ideas to extend it for now, but rather I just considered stripping Referer headers specifically from the cross-origin requests that this extension already is handling, because when both headers are present, stripping the Origin headers alone can possibly turn out to be worse than not stripping anything. I assume some people will install this without RTFM first, and that may make them vulnerable. In other words, this extension would still not be a replacement for Smart Referer, because it would still touch only cross-origin requests (referers in other requests would be left intact). IDK, It makes sense to me, I'm just wondering if I should make it optional or not. I probably should.

Anyway, PooP seems to be a great extension and I am really grateful for your work.

And I'm really grateful for your help and for bringing this up in the first place. This kind of collaboration is one of the reasons I :heart: this repo!

If I use PooP relaxed + font + XHR, than its OK, but I get a breakages at some login pages and from what I see, there would be none (from my samples) if there would be a SLD match auto allow.

Well, yeah, that is expected. I understand the idea of allowing some requests through (with CORS) based on a SLD comparison, and I guess it is a common enough occurrence for that approach to be reasonable, but honestly, I'm not sure man. I mean, disregarding how safe that may seem in practice, there are security risks to it. However small those risks may be, I'm not sure I want to allow users to mess with that, especially if they don't understand the risks themselves.

The current approach does not disrupt the same-origin policy, it allows Firefox to keep taking care of security (hence the breakage), which is easier on my conscience :sweat_smile: That was the whole point of implementing an aggressive mode + whitelist: if something breaks, you either live with it, or you whitelist it. It's still an early stage of development though, maybe eventually I'll get around to improve the whitelisting feature so that it allows more fine-grained control, but that will not happen in this release. I didn't even think how I would go about that yet. Also, TBH, I don't want this to grow beyond the point where I can still maintain it. It's not quite there yet, but I try to keep that in mind.

[crssi]

That would fall out of the scope of this extension.

True

I'm actually not looking for ideas to extend it for now, but rather I just considered stripping Referer headers specifically from the cross-origin requests that this extension already is handling, because when both headers are present, stripping the Origin headers alone can possibly turn out to be worse than not stripping anything.

Understood and makes perfect sense. Will you replace it with destination?

Well, yeah, that is expected. I understand the idea of allowing some requests through (with CORS) based on a SLD comparison, and I guess it is a common enough occurrence for that approach to be reasonable, but honestly, I'm not sure man

Something like "do not touch Origin" where SLD origin and destination match should be safe, since nothing is altered. Or I don't see something?

This page https://www.techradar.com/reviews/logitech-g513 should be quite interesting for testing (try also with uBO off).

[claustromaniac]

Will you replace it with destination?

Umm. Right, I should do that.

Something like "do not touch Origin" where SLD origin and destination match should be safe, since nothing is altered. Or I don't see something?

Sorry, it was me who misunderstood (again). That would be safe, yeah. There is no reason not to add that as an option, at least :+1:

[claustromaniac]

1.0.0b3 is the current release candidate. It took a bit longer than expected because I've been pretty busy with other stuff, but it's looking pretty good to me. Let me know how it works for you. TIA

[crssi]

:+1:

I cannot switch to aggressive mode. :cry:

[claustromaniac]

:scream_cat: I'll check it out right away

[claustromaniac]

LOL that's embarrasing. I removed some attributes from some elements in the options page, because I didn't need them, but it seems I overdid it :sweat_smile: I'll do another release shortly

[claustromaniac]

done 1.0.0b4

[crssi]

that was fast :smile: 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. :+1: :heart:

Thank you and cheers

[claustromaniac]

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]

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. :smile:

You are fantastic.

[crssi]

Is it possible to whitelist per destination?
If I do XHRwith 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]

^^ 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. :hugs:

Cheers

[claustromaniac]

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 :sweat_smile: Then I'll have to write the documentation and all that, which is the boring part.

[claustromaniac]

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]

ˇˇ 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]

@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]

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]

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 :confused: 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]

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

[claustromaniac]

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]

Oh... I see.

[claustromaniac]

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]

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.
EDIT² I take that back. I really can't add this without making a pretty extreme rework.

[Woofy-Wolf]

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]

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]

@Woofy-Wolf, glad to help!

[crssi]

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. :smile_cat: :heart:

[ghost]

We have found Jesus. It disguises as @claustromaniac .

Is he Portuguese?!

[Thorin-Oakenpants]

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]

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]

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 :cat2:

[slowfar]

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.

[claustromaniac]

Very nice, @tartpvule. Not user-friendly, if you ask me, but your extension certainly seems to give more control (which was the main goal, I guess). When I can, I think I will update the documentation of my POOP extension (thinking back on it... man, what an honest name!) and link to yours while I'm still not actively maintaining it. I should have done that long ago, actually, but I've been kind of DEAD for a while.

Now... which of my several dozen notifications should I pick next?...

[Thorin-Oakenpants]

if you want to do anything with this: e.g add it to the wiki, then reopen or just tell me