Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Etags: solutions besides clearing/disabling cache [which does clear/block etags, sorry about the confusion] #179

Closed
Thorin-Oakenpants opened this Issue Jul 24, 2017 · 113 comments

Comments

Projects
None yet
@Thorin-Oakenpants
Copy link
Member

Thorin-Oakenpants commented Jul 24, 2017

Test 1

Use this ETag Test PoC, type in something unique, close the browser, restart.

I do not use disk cache, but I do use memory cache (RAM). My settings on close are to clear "cache". This is the same as in the Clear recent history> dialog - where "cache" is also checked.

Note: I am not allowing JS, as it is not needed

user_pref("privacy.clearOnShutdown.cache", true); // 2803 - on close
user_pref("privacy.cpd.cache", true); // 2804 - manual clearing 

Expected results: To not be tracked
Actual results: I failed the test. I was tracked.

Test 2

Repeat the test but use a different string, and instead of closing the browser, simply clear your cache via History>Clear Recent History ( or Ctrl-Shift-Del )

Result: Same - I was tracked

Test 3

Go to JoDonym landing page

Actually this test will no longer work. JoDonym used to have an ETag test. If you cleared your cache, AFTER the landing page and THEN performed the test, the ETag would be green, otherwise it would be red - which led me to believe that clearing cache cleared the godamn cache.

So what the heck is going on?

Clearing cache should clear the cache - right? Eg if I start a new FF session, clear the cache, load a page and look at the media elements (page info> media tab), you can see contents. In the past if you cleared cache, this would all no longer be shown.

I KNOW memory cache used to get cleared from my experience with JoDonym and from looking at items in the cache - both with FF's UI, and with extensions in the past. I have only ever used memoery cache.

So either some pref is causing a block on this (eg FPI) or Mozilla decided that memory cache no longer needed cleaning?

Class, discuss!

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 24, 2017

Here's an old JoDonym to show what I'm talking about. It seems Authentication, and Cache (E-Tags) are no longer shown/run

oldjodonym

@Atavic

This comment has been minimized.

Copy link

Atavic commented Jul 24, 2017

Cookieless Cookie Fake Test: The test page mentioned by Pants uses the IP address for session tracking and the user agent but not ETags.

This test should use ETags, instead.

@Just-me-ghacks

This comment has been minimized.

Copy link
Collaborator

Just-me-ghacks commented Jul 24, 2017

http://lucb1e.com/rp/cookielesscookies/

Results:
browser.cache.memory.enable TRUE & same IP - I was tracked.
browser.cache.memory.enable FALSE & same IP - I was not tracked.
browser.cache.memory.enable TRUE & different IP - I was not tracked.

This "test" could be fake! We need a more reliable ETag test.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 24, 2017

As mentioned in the FPI sticky - https://bugzilla.mozilla.org/show_bug.cgi?id=1371651 - FPI & about:cache (for a fleeting moment before I looked it up, I thought this might be a smoking gun - but it's just the about:cache page, not the actual cache). However, these tests should be done in a nilla profile

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 24, 2017

PS: the code is here on github - https://github.com/lucb1e/cookielesscookies

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 24, 2017

I want a medal ... 14 years ... https://bugzilla.mozilla.org/show_bug.cgi?id=231852

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 24, 2017

bit of a recent'ish discussion going on here and you have to read thru the chaff to get to the wheat - https://groups.google.com/forum/#!topic/mozilla.support.firefox/ZE0_3tKGlUU (yeah yeah shitty google groups - go use a secondary browser like I do)

About 53.7% of way down

The purge-on-exit settings that Firefox affords in its GUI are not deleting its web cache on exit.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 24, 2017

OK, I thought about this and now someone mentioned it (see last post for link) - modify headers. Well, I listed a WE one a few weeks ago .. its still installed ...

I blocked Etags by using the extension Modify Headers and added a filter
for ETag. Now my browser does not keep or return ETags any more.

But he doesn't say any more than that


https://en.wikipedia.org/wiki/List_of_HTTP_header_fields - ETag is a response field. Should be simple enough to block that

DONE - sorted - ETAG free baby

Edit: just need to do some more tests

--
That test site seems whacked. Between FF close/open - sometimes I get tracked, sometimes I don't (and I'm not doing anything different, not even manually clearing cache etc which my settings should do anyway)

@Atavic

This comment has been minimized.

Copy link

Atavic commented Jul 24, 2017

Noscript. NoScript's ABE (Application Boundaries Enforcer) allows stripping etags.

Secret Agent generates spoof ETags headers with random values, preventing ETags being misused for tracking.

Run a local proxy as Privoxy that can block ETag headers.

@2glops

This comment has been minimized.

Copy link
Collaborator

2glops commented Jul 24, 2017

Tor Browser 7.0.2 (vanilla)
TB with stored text > tracked by number of visits but not by stored text
TB with stored text + new identity > not tracked

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 24, 2017

Secret Agent isn't even on AMO. I've already scoped it out. And I think noise is worse than block. Its a stupid solution IMO to generate these headers for everything. I know about Privoxy, I used to use it (Windows). In fact, I've been meaning to add it to my router (DD-WRT'd and all). I want solutions for Firefox, in Firefox.

This Modify Header Value (HTTP Headers) I have tried and tried and tried and cannot get it to work (and yet no one seems to think its broken). Github page listed in addons sticky. I cannot get it to block ETag as far as I can tell. This looks like a very good extension, but I'm f**ked if I can make it work properly.

Now NS's ABE - well? Please provide. NoScript>Options>Advanced>ABE>User ... add this rule - and provide the rule ( https://noscript.net/abe/abe_rules.pdf - this is over my head, maybe someone can craft a rule for blocking/stripping outbound ETag HTTP Headers )

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 24, 2017

Edit: an old read but might explain something - transparent proxies - http://lifecs.likai.org/2011/07/kissmetrics-and-life-of-etag.html

@Atavic

This comment has been minimized.

Copy link

Atavic commented Jul 24, 2017

Installed Modify Header Value (HTTP Headers) on FF ESR 52.0
In HTTP Headers options I created a new entry with:

URL *
Header Name If-None-Match
Header Value *
Then I picked Add.

The test passed.

I get 2 Visits repeatedly if I pick Remove instead of Add.

@Forsaked

This comment has been minimized.

Copy link
Collaborator

Forsaked commented Jul 25, 2017

@Atavic This way every other Website breaks its layout/design.

@Atavic

This comment has been minimized.

Copy link

Atavic commented Jul 25, 2017

You can whitelist sites, deactivate your filtering choice or launch a second browser with this WebExtension on AMO, part of these projects by Andy Portmen.

The HTTP Entity Tag is used to reduce the server bandwidth when a resource was previously stored in the cache. Abusing the ETag values allows browser's tracking: the ETag value is unique as an MD5 or SHA1 hash. You can either strip the hash value from every If-None-Match header value with Privoxy or spoof it with Secret Agent Add-on: its spoofing feature adds a random hash to outgoing requests, while its whitelist feature allows you to specify trusted hosts. For Privoxy issues there's an active forum.

@ghost

This comment has been minimized.

Copy link

ghost commented Jul 31, 2017

LOL!

Hmmm .. where did zymase's comment go? .. Yup, this is testing ETags zymase, there is no JS, no cookies, no dom etc etc

That's why I had removed my comment. Thanks for not including in your brief recall of my shame the fact I love chocolate and mini-skirts!

Yeah, I had commented too quickly, suggesting the LocalStorage to be an explanation of the cache issue detailed by this thread. I then took the time to read extensively, and at this time I've installed The Secret Agent add-on (from developer's page mentioned above by Atavic, when unavailable on AMO).

Hey! I'm a secret agent man as sung by Austin Powers; yeah! -- Seriously, the add-on is most interesting, testing it right now as I said. One thing is sure, the cache issue revealed, exposed, applied with the ETag Test PoC is obsolete with Secret Agent.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Jul 31, 2017

There's something whacky about how we're doing the tests or that test page. I found i am not tracked when I run CCleaner, so to me that means the test is using some form of persistent disk data

Edit: I have no cookies, no dom/local storage, no indexeddb, no service worker cache, no disk cache ... whacky!

@ghost

This comment has been minimized.

Copy link

ghost commented Jul 31, 2017

After some time testing the Secret Agent add-on I'm finally keeping it but will be using only its eTags & Caching feature because it seems to handle the eTag intrusion correctly by spoofing it.

Secret Agent has several other features but too many sites get problematic when these features are enabled. Of course the add-on has a whitelist which is flawless but I've had to whitelist domains, sites only because of the features I then removed. But whitelisting a site will then stop filtering its eTags as well.

In other words, only eTag spoofing and no sites (up to now) need to be whitelisted

Secret Agent then but only for eTag spoofing, which it does well, and which resolves the very concern of this thread, as I see it.

One last thing: Secret Agent is displayed with a toolbar button on its dedicated toolbar, positioned right under the urlbar and reserving the screen width for only its toolbar button followed by description of the add-on's status (what it's doing, is it on or off). Removing the toolbar button is possible, can then be positioned anywhere and the toolbar itself can be hidden with right-click on the tabs toolbar then uncheck Secret Agent toolbar. Of course Secret Agent toolbar button alone will not be followed by description of status as when it is on its toolbar, but hovering it provides the information and right-clicking it opens a drop-down menu for whitelisting the site, disabling/enabling Stealth Mode and access to Options.

Done this way, seems interesting to me.

@ghost

This comment has been minimized.

Copy link

ghost commented Aug 10, 2017

I don't like the idea of needing another addon (and why isn't it in AMO anyway? Not that I would use it if it were).

As I and the author understand it, cache in general is the problem: "[...] cache tracking issues [...]" and "[...] I currently have no straightforward answer since cache tracking is virtually undetectable, [...]" .
I don't understand, why is cache not cleared if Firefox is closed?
This tracking seems to be disabled if browser.cache.memory.enable is set to false (#179 (comment)).
I would prefer deleting the cache if Firefox is closed. This seems not to work? (#179 (comment)) What's the status on that?

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Aug 10, 2017

What's the status on that?

I have no idea. I want to get the FF55 changes finished. When I get back to this (do not know when), because it is intriguing, I will do more thorough analysis and testing. Better/more ETAG test sites, and also comparing the results using various FF releases. Whatever it is, my gut instinct is that since CCleaner cleans it, it must be local - and since all previous advice in forums, etc has been to clear "cache" - this no longer seems to work (on that one site) - hence I will setup and test old FF portables

@ghost

This comment has been minimized.

Copy link

ghost commented Aug 10, 2017

@Thorin-Oakenpants Thanks for your work then. This is indeed intriguing. I think this must be local indeed, because if I use a second profile, the tracking-cookie isn't there. I wouldn't bother with ETags, because the cache is the generic issue here and who knows that other techniques are used using cache. The real issue is, as you pointed out in your initial post, is that the cache is not being cleared -- if it's set to be cleared -- when FF is closed. I'd personally would want the cache to be cleaned when FF is closed (expected behavior), or I would disable cache altogether (not the preferred solution).

@ghost

This comment has been minimized.

Copy link

ghost commented Aug 10, 2017

Another fingerprinting test, and this one is the toughest I know : Cross-browser fingerprinting test 2.0

@ghost

This comment has been minimized.

Copy link

ghost commented Aug 11, 2017

Of course it's always possible to add a uBlockO filter to block Cross-browser fingerprinting test 2.0, such as /evercookie.js$important but that solves a test, an effect and not the cause. Moreover I doubt a site using evercookies would name their script evercookie.js.

@2glops

This comment has been minimized.

Copy link
Collaborator

2glops commented Aug 11, 2017

@zymase
You're right and I just deleted my comment after a short time while you were answering.
Gulty ! That will not happen again.

@ghost

This comment has been minimized.

Copy link

ghost commented Aug 11, 2017

@2glops it happens to everyone! If deleting a comment is authorized it's for a good reason.

So, we can use medicine to block evercookie.js (namely) but we cannot cure the fingerprinting disease :)

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Dec 4, 2017

some links for reference

@crssi

This comment has been minimized.

Copy link
Collaborator

crssi commented Dec 4, 2017

About ETags and performace...
To get rid of ETags, I have set:
user_pref("browser.cache.memory.enable", false);
user_pref("browser.cache.memory.capacity", 0);

No ETags, but I don't see any performance issues too.

@crssi

This comment has been minimized.

Copy link
Collaborator

crssi commented Dec 4, 2017

^^Is any of those master switch and I don't need the other one?

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented Dec 4, 2017

Yes, we already know that disabling memory cache also stops etags, because there is NO cache of any sort, so if-match-none headers are never sent (or so I assume). But browsing around with zero memory cache (we already have no disk cache) is a bit extreme. I am looking for a better solution.

What I am more concerned about right now is that clearing everything (manually or on close) does not clear the etags - not even in private browsing mode (are you hearing me Mozilla people who work on PB mode stuff) - so that is problem no. 1

Problem no 2 is that I want to remove outgoing (I think it's outgoing) If-None-Match headers and I can't - I am not a header specialist like earthlng, so I probably f**d it up. I want to use my cache if possible and not force everything to re-download.

As for your question, I would say that the first pref is a master switch, but don't quote me on it

@vertigo220

This comment has been minimized.

Copy link

vertigo220 commented May 20, 2018

@claustromaniac's method worked for me. Glad that's finally sorted out, been working on it on and off for a few days now. @Thorin-Oakenpants, I had the opposite problem as you at first: the tag wasn't present even after disabling Header Editor and reloading the page again. I wonder if your problem is related but in reverse. Maybe try disabling the rule, shift+F5, F5, enable the rule, shift+F5, F5. That's basically how I got it to show the tag then discard it again, and it seems to be working now. I guess there's some interference somewhere in there with all the back and forth and reloading and cache clearing.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented May 20, 2018

it might work for you on that site (or some sites) but will not work on all sites - the problem is the matching case - so this problem is not resolved IMO

meanwhile, I have two rules now, but again, its not a solution (and I do not know if this works properly), and I want to test a lot more in a nilla profile etc.

I need test sites that work with ETag only and one that works with etag only etc. But they still doesn't explain claustro's statement that both worked for him. I wish this was just built into RFP to be honest

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented May 20, 2018

^^ oh, and it used to work when we created the rule etc. So something has changed - either the extension or something in FF

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented May 20, 2018

I'm suspecting it might be an issue with the extension. Two of my oldest rules disappeared the last time I restarted the browser (just because).

Maybe it doesn't have anything to do with the casing, but rather with the way the extension saves the settings.. maybe something relevant changed in one of the updates in the time frame between the moment you created that rule and today (that you edited it, or created a new one).

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented May 20, 2018

should really start a new issue for this, with STR, test pages to use, findings etc, and THEN unleash on that issue I created at Header Editor's repo

I will test something: the rule that was lowercase, I edited and saved as ETag (i.e the header field to match) and then it worked. I can disable this, because I created a new rule for lowercase. i.e - I can retest lowercase
^^ and nope, didn't work - so a brand new rule created and it didn't work. IMO IDK WTF TBH anymore.

I can disable all rules and create a new ETag one and see what happens - yup, that worked. Definitely case is the case (see what I did there)

@vertigo220

This comment has been minimized.

Copy link

vertigo220 commented May 20, 2018

I created three rules: etag, ETag, and eTaG. Only the first worked. It also worked with all of them enabled, so maybe a bunch of different rules (ETAG, etag, ETag, Etag, ...) could be made, or maybe it could be done with regex (something like [Ee|Tt|Aa|Gg]). Or would that possibly make it stand out and be more unique? Also, are you testing with the ghacks link from claustromaniac's post? I just assumed you were, but if not that could explain the difference.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented May 20, 2018

I created three rules: etag, ETag, and eTaG. Only the first worked

Is that a typo. Because the first one, all lowercase, is what has been on our wiki since we added it, and is the one that doesn't work for me. And I thought you said switching to ETag as per claustro's info then it did work.

@vertigo220

This comment has been minimized.

Copy link

vertigo220 commented May 20, 2018

Not a typo. The first one ("etag") is the one I was using all along, but couldn't get it working (or verify that it was working). What I was saying worked from claustro's post was verifying it with the ghacks site. I'm not sure if the difference was just using a normal site vs the "flawed" test/PoC, or if the time I tried following Kane's instructions it just happened to not work. So does that mean you didn't try with the ghacks site? If that's the case, try that one with "etag."

@earthlng

This comment has been minimized.

Copy link
Member

earthlng commented May 20, 2018

OMG! before you guys all go nuts I'll step in here :)

The problem looks like it's caused by a recent change in FF, not the extension. Not too long ago all headers were exposed by FF in exactly the casing sent by the server. Then they changed it to all lowercase for a while and now they apparently changed it back to original casing (IDK when exactly).
@vertigo220 what version of FF are you using?

But the extension code has also changed since the last time I looked at it, and frankly is still less than ideal. For example certain headers can exist multiple times and the extension only mods the 1st one.
For ETag it probably shouldn't matter but you never know. fe. IDK what FF does when a server sends 2 ETag headers.

The best solution that doesn't rely on FF keeping its current way of providing the headers nor any potential future changes in the extension itself, is to use a custom function. That should also work with all FF versions (ESR52.x included) and all current, former and future releases of the extension.
And it bypasses the less than ideal implementation of the extension.

So, change your rule from Normal to Custom Function and paste this:

for (let a in val) {
    if (val[a].name.toLowerCase() === 'etag') { val[a].value = ''; }
}

Don't use this in Chrome though because Chrome preserves empty headers and it might end up sending an empty If-None-Match header, IDK.

You'll know that it works when "Number of visits" never goes higher than 2 @ https://lucb1e.com/rp/cookielesscookies/

@earthlng

This comment has been minimized.

Copy link
Member

earthlng commented May 20, 2018

Oh, and I forgot to mention that you can't rely on the devtools for headers because it doesn't accurately show changes made by extensions. In this case you'll see that it lists ETag in the response header despite it having been removed but you can deduce that the removal worked when you refresh and the next request header doesn't include If-None-Match. So despite being less than ideal the devtools are still somewhat useful because of the connection between these 2 headers.

@vertigo220

This comment has been minimized.

Copy link

vertigo220 commented May 21, 2018

Thanks @earthlng! That function is the only way, besides Secret Agent, that I've been able to pass the test at that site. And it's good to know it's more robust. Am I correct in understanding that code doesn't change the case, so etag=xyz will be set to etag="", ETag=xyz will be set to ETag="", and so on?

Also, I'm using Waterfox 56.2.0x64.

An OT question: could you or someone else tell me how I would make the following redirect work:

^http(s?)://www.amazon.com/gp/buy/spc/(.*) > https://smile.amazon.com/gp/buy/spc/handlers/display.html?

I figured out how to do it with Request Control, but since it seems Header Editor is capable of much more, I'm trying to transfer the rules from RC into it so I can reduce my number of addons. I've tried different variations, and the one I pasted here worked once (I think), but hasn't worked since.

@earthlng

This comment has been minimized.

Copy link
Member

earthlng commented May 21, 2018

Am I correct in understanding that code doesn't change the case, so etag=xyz will be set to etag="", ETag=xyz will be set to ETag="", and so on?

yes it doesn't change the case.

I'd recommend to stick with RC or Redirector for redirects because it's a lot easier to match precisely the request types that you want/need.

@vertigo220

This comment has been minimized.

Copy link

vertigo220 commented May 21, 2018

Thanks. I had my doubts, since it doesn't follow the "rules" in the examples from the wiki, but it does work, sort of. Unfortunately, it doesn't work when landing on the page, only when refreshing it, so I guess I'll have to ask on the HE repo.

@earthlng

This comment has been minimized.

Copy link
Member

earthlng commented May 21, 2018

HE is not great for redirects because I think it matches all request types. That can be pretty terrible actually.

Unfortunately, it doesn't work when landing on the page, only when refreshing it

It's probably not a normal link but uses some JS to load it. Use RC with request type Document and then always middle-click those links to open in a new tab, that should work.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented May 21, 2018

OMG! before you guys all go nuts I'll step in here :)

If that includes me, I'm sorry to say you're too late. Like...years late.

Thanks for the explanation and the solution, mate! BTW did someone translate the HE documentation to english without me finding out? Last time I checked it was only in japanese IIRC. Do you know japanese? 😝 (EDIT: NVM. I see that part is translated now)

I forgot to mention that you can't rely on the devtools for headers because it doesn't accurately show changes made by extensions. In this case you'll see that it lists ETag in the response header despite it having been removed but you can deduce that the removal worked when you refresh and the next request header doesn't include If-None-Match.

I pointed this out in my post above and everyone seemed to understand it. If my guess is right the inaccuracies should be in the response headers, especifically. Did you ever happen to investigate that too, by any chance? Just curious.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented May 21, 2018

BTW, one of my HE rules that disappeared from my list today just reappeared a while back. LOL! The other one is still MIA.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented May 21, 2018

I wasn't exactly going nuts. Was going to test it with different FF and HE releases later on. What threw me a little was vertigo not stating that he's on Waterfox of all things - i.e essentially FF56 with god knows what changes under the hood by Mr. Alex. Unless someone states it, I will assume they are on current FF stable. I already suspected something was different re version with the diff in case with my FF60.

Thanks for clearing up that it was FF, and thanks for the solution re case.

Clastro - have you looked inside the HE storage?

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented May 21, 2018

Wiki updated

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented May 21, 2018

Clastro - have you looked inside the HE storage?

And what should I be looking for in there, exactly? I'll probably wipe it and rewrite the few rules that I use, anyway. It's not much of a hassle.

I'm still wondering why we got different results with the casing in our tests earlier. I only had issues with the lowercase etag rule when I tried the PoC, but both etag and ETag seemed to work for me everywhere else.. Then again, I didn't test much. I didn't stay around here for too long.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented May 21, 2018

I have to admit that intrigued me as well (diff results), but now I no longer care. I've poked around the HE repo issues a few times, checking things out. The ones in English that is. I have no idea why you "lost" rules, I think I remember seeing some posts about it. It's never happened to me, I don't have any groups, and just one rule. But if it was a concern to you, because one "came back", then I suggested looking at the storage (you can peek inside these things - not sure what its using, localStorage or IDB of whatever) to see if it still existed. But if you're happy to just wipe the extension and UUID in total, and start over - be my guest. I'm not going to waste any more time on it.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented May 21, 2018

I'm not using groups either. I just had 5 rules and nothing really complicated. I wouldn't mind digging into the issue in other circumstances - and I probably will, if it turns out to be a recurring issue - but I'm pretty sure I'll invest less time rewriting them for the time being.

Plus, I get to save you the hassle of helping me with that! How nice is that? You sound tired enough as it is, 👖

@vertigo220

This comment has been minimized.

Copy link

vertigo220 commented May 21, 2018

@earthlng said:

It's probably not a normal link but uses some JS to load it. Use RC with request type Document and then always middle-click those links to open in a new tab, that should work.

It is JS, which is what gave me a hard time originally, but I already have it working in RC. I was just hoping HE could do the same thing so I could eliminate RC (nothing against it, just wanted to slim things down a bit).

@claustromaniac - Once you rebuild them, you should be sure to export them in case it happens again.

@earthlng

This comment has been minimized.

Copy link
Member

earthlng commented May 22, 2018

@claustromaniac

I pointed this out in my post above and everyone seemed to understand it.

yes I saw that, just wanted to re-confirm. And I'm not so sure everyone seemed to understand it :)

If my guess is right the inaccuracies should be in the response headers, especifically. Did you ever happen to investigate that too, by any chance? Just curious.

No I did not. As far as I can tell the inaccuracies are all over the place

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented May 22, 2018

I'm not so sure everyone seemed to understand it :)

That's ok. I admit I often come short when I try to explain stuff to others anyway.

No I did not. As far as I can tell the inaccuracies are all over the place

I've never seen inaccuracies in the request headers but I'll try to keep that in mind in case I ever do. I better stop trusting the devtools on that. Thanks again.

@vertigo220

This comment has been minimized.

Copy link

vertigo220 commented May 24, 2018

BTW, here's another, unrelated cache tracking technique you may or may not be aware of which, AFAICT, can't be defeated except by periodically clearing the cache. Thought you might find it interesting.

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented May 24, 2018

posted in #436

@claustromaniac

This comment has been minimized.

Copy link
Member

claustromaniac commented May 24, 2018

Done.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

Thorin-Oakenpants commented May 24, 2018

locking - if anyone has any etag question or issues, start a new issue

@ghacksuserjs ghacksuserjs locked and limited conversation to collaborators May 24, 2018

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