@cypnk i have never used these modes

i have wondered how they differ from my normal FF setup running anti-tracking (privacybadger), extensive adblocking (ublock origin), and manual cookie whitelisting (denies cookie by default)?

i know incognito mode deletes history when you quit...

@alyx The number of plugins you have also increases your attack surface. uBlock and Privacy Badger are brought to you by the Good Guys(tm), but they still add to the risk that one of these can be compromised at some point

Ideally, the browser itself will have this functionality built in, but with the exception of "Brave" browser, I don't know of any others that do

@cypnk right, add-ons and system specs, even fonts, add to your fingerprint which is shitty

i tried to minimize that a couple years ago but at least in FF on windows it was pretty hopeless feeling unless i wanted to ditch all add-ons

but beside the fingerprinting risk, i was wondering if i'm still hitting most of the incognito checkboxes w/ this (simple) add-on combo

@cypnk re-reading your comment i don't think you were exclusively referring to the fingerprint issue re: increased attack surface

to that point, i wonder how FF's massive add-on infrastructure revamp will affect size of attack surface. i don't know about that.

@alyx I don't use FF for casual browsing these days; Only dev work so I do need quite a few plugins

In Chrome these are currently installed:
uBlock Origin
Privacy Badger
HTTPS Everywhere and
Disable HTML5 Autoplay

@cypnk mm. i use HTTPS Everywhere as well

(it's not ready for FF57 yet, but there is a webextension alternative that tries to indiscriminately use HTTPS on every site (vs. HTTPS E's whitelist approach))

i guess i will investigate incognito / private browsing to better understand them

@alyx I think the hiccups should be ironed out pretty soon. They've been announcing webextensions for quite some time, so I'm sure they're already working on a stable version that doesn't try HTTPS on everything

@cypnk yes, HTTPS E WE for FF is in the works. just mentioned cuz i've been going through that WE status worksheet today

@cypnk @alyx Brave browser changes what ads you see, not sure it prevents ad-network malware delivery.

If you're blocking 3rd-party cookies, which breaks almost nothing, fingerprinting should be basically restricted to the site you visit. If they're pushing that function to third parties, then not even that.

As for attack surface, I suspect the couple of add-ons that otherwise drastically reduce the attack surface for compromised content delivery are always going to be a net win.

@rysiek It seems to work in FF. I have no-script installed and settings to forget all cookies on exit. Which I guess is a roundabout way to get "Incognito"

@cypnk there's a private browsing mode in FF too. What I wonder is if this site detects FF private mode too.

@rysiek Yup. It does. It only happens when I enable JavaScript so Firefox is leaking incognito mode info as well

@cypnk right, so they're using JavaScript to detect this? Interesting.

@rysiek Yeah. Something either failing in adblocking (I have uBlock Origin) or there's a secondary route that's causing the browser itself to leak the status

@cypnk @rysiek
maybe they just check if you have any tracking cookies, and if you don't, then you're probably using private mode.

@rysiek @cypnk afaik it's possible to detect visited links, so you can check if a specific url has been visited.
If history is turned off entirely, you can add a redirect or push a history item through JS, then add an <a> element somewhere with the same URL and check its state.

@cypnk @rysiek it actually seems like that specific attack vector has been taken care of:
https://stackoverflow.com/questions/7290959/how-can-i-detect-visited-and-unvisited-links-on-a-page#7291538

@grainloom @rysiek Once again, JS proves to be the weak point

@grainloom @cypnk yeah, it's an old one. I remember this being a think some decade ago or so.

@rysiek @cypnk they have other ways though, at least for detecting if something has been loaded (this probly won't detect private browsing): measuring loading times.
If stg has been cached, it will load faster.
This, afaik, does not have a mitigation.
(but it still doesn't answer how private browsing is detected)

@wxl Yup. They want to turn YouTube into an interactive juggernaut in addition to reinforcing its status as a media hub. Hard to do that without WebRTC

@cypnk at least Firefox gives you an option to turn it off. :/

@sikkdays Pretty much. Chrome is the new IE anyway. All that malarkey about standards is really about cornering the market for their own media empire (coming soon, courtesy of YouTube)

@mattskala Absolutely! There are some mitigations in uBlock, but that too is a game of whack-a-mole by and large. I think the Anti Virus approach to ad-blocking isn't going to work. Signatures change too frequently

@mattskala @cypnk Not a high priority. Adblockers are always detectable, and their primary function is not to be undetectable (unlike the virus/AV game.)

@varx @cypnk Being detectable interferes with their primary function, and it's not obvious to me why it would be necessary. The bits on the wire could be the same regardless of whether all of them end up displayed on the screen.

@mattskala @cypnk They have to be detectable because they interfere with the functioning of the page; they change what scripts are loaded, and it's trivial to discover that.

You can play a cat-and-mouse game and even go so far as to modify the site's Javascript to bypass the bits that notice the adblocker, but at that point you're deep into diminishing-returns territory.

@cypnk @mattskala Compare to things like anti-cheating code in games. It's a very high priority for the "cheating code" to remain undetected.

@varx @cypnk We may place different values on the returns involved. As far as I'm concerned the pop-up that starts with "We noticed..." is a *big problem*, worth a lot of effort to prevent, and that effort is central to what I expect from my ad blocker.

@mattskala @varx @cypnk The site necessarily needs to know whether the ads it wants to run are actually running, otherwise it could be held accountable for fraud.

@Tablesaw @varx @cypnk That's the site's problem. I am under no obligation to help.

@nolan @cypnk also at some point you actually have to implement statistical normalization. No plugins installed at all? probably in private browsing. etc, etc.

@nightpool @nolan Curious thing is that I had uBlock Origin, Privacy Badger, and HTTPS Everywhere enabled in private browsing. That's the same list as my regular browsing

@nolan @cypnk Would it not be obvious simply by the 'quietness' of private-browsing? Rather than simply not leaking data, wouldn't a browser have to replace whatever kinds of data it hands out in regular-browsing mode? If this is so, I think it'd probs. be hard to generate convincing spoof data in a manner that wasn't detectable to clever server-side data-gatherers..

@ej @nolan That would also block visitors who are coming from a fresh installation of a browser. I think it's some other combination of data

There is some difference in the header data
E.G. Here are my incognito headers vs regular headers in Chrome (courtesy of DuckDuckGo)

@cypnk @nolan In this particular case, then, wouldn't you either have to stop passing the referrer header field in regular browsing mode too, or else start passing (say) "referrer=fictional-domain.org" in private browsing mode, so's the server can't see the difference between modes?

@ej @nolan It may not be just that. I can confirm that the page loads fine with JS disabled so this is a multi-faceted fingerprint issue

@pnathan Which means MIT Review is scattering cookies all across the web (since HTTPS requested cookies shouldn't cross-pollinate across domains). That's a bigger problem if true

@cypnk I am speculating out of my butt.

but if I wanted to detect private mode, I'd try to integrate with popular sites and if their cookies were not set, I'd heuristically estimate that the person was probably in a private mode. ::shrug::

@pnathan Are you sure that's speculation, cause that sounds ingeniously diabolical :P

MIT can certainly hire tracking services that already provide analytics to other sites. There's no reason they couldn't then check with that service(s) to make sure cookies are still being set

@cypnk haha I'm just avoiding a scala refactor right now and trying to arrange babysitting. this is not high-level thinking. :)

but it seems the most direct way to answer the question, since incognito is all *about* clearing history/cookies. And so very very very many cookies are set these days.

Alternatively, some APIs are being poked in ways that also are an adequate proxy metric.

@pnathan @cypnk that’s exactly how I’d do it

@KitRedgrave Yup. It comes back only when I set "allow all on this page" for no-script

@DistroJunkie @grainloom I just confirmed that it fails in Tor Browser Bundle as well

This is a seriously worrying trend. If someone under a repressive regime wishes to gain access to information, they must bypass petty revenue protection schemes

@cypnk @DistroJunkie we should just kill JS finally
>.>

and yes I know that's p much impossible by now and yes i'm angry

@grainloom @DistroJunkie We all have to weigh the costs and benefits of any convenience

At some point, the sacrifices become untenable in a functioning free society. That's true whether it's JavaScript, credit bureaus, cops, or other widespread "thing" that we take for granted as a necessity without questioning the cumulative detriments

And the detriments are indeed cumulative