Most Unit Testing Is Waste (2014) [pdf] - <AUTHOR> https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf <comment><USER2> My experience with testing is like that old adage about advertising, "I know I'm wasting 50% of my money but I don't know which 50%." Most of it is a waste but it's hard to know in advance which test will stop an engineer in a couple of years from altering some fundamental contract and bringing the system down.

<comment><USER3> I'll say that any unit test for a bug which would have been caught by a more sophisticated type system is a waste. I don't know how much time people spend writing such "obsolete tests", but I doubt it's insubstantial.

<comment><USER4> The problem is that sophisticated type systems only catch a subset of the bugs that a unit test can catch. For example, let's say I'm adding the ability to transfer funds from one account to the other in a banking application. I want to display a warning when the amount of money being transferred is over a certain percentage (let's say 95%) of the funds in the account. That's pretty easy to do in a unit test: create mock account, call the transferFunds() method, and verify that the warning is triggered when the value being transferred is over 95% of the amount in the account.

How would I do that with a type system?

<comment><USER5> At the risk of veering off topic, I'm genuinely curious what kind of bug that unit test is designed to catch?

Given that transferFunds shows a warning over that 95% threshold, what type of change is going to break that logic? Some sort of botched code rewrite where values doesn't retain their meanings? That batchMode shouldn't trigger the warning? That race condition between the check and the actual transfer?

Most of the unit testing I see is more like test-of-defintions (is fullName still 80 characters wide and doesn't accept null bytes?) which confuses me because a definition can only be correct or incorrect in context.

I accept the usefulness in dynamic languages in the absence of types. My Personal preference is for tests to be a bit higher level (does login with a username containing null still cause an exception?) but I have come to terms with the fact that few people agree with me across multiple organizations, so there must be some point to this trivial testing that is completely lost on me.

<comment><USER6> > My Personal preference is for tests to be a bit higher level (does login > with a username containing null still cause an exception?).

These tests are great, but what if username has a bunch of validations on it?

For example, it's reasonable to think a username field might be validated with:

\- Must be required

\- Within 1-32 characters that match a certain pattern (let's say a regex to limit it to lowercase letters, numbers and -)

\- Must not be a blacklisted word (admin, administrator, etc.)

\- Must be unique (enforced with a database index)

Pretty standard stuff. Are you going to write 5 integration tests for this? 4 to test each validation and then the success case? These would be tests that exercise your entire web framework's routing stack from request to response (ie. the user visiting a /register URL and then submitting the form).

Personally I would not. I would write 1 unit test for each of those things (4 unhappy cases where I assert a specific validation error for each invalid input and 1 happy case where with valid input I expect 0 validation errors). In this case, the "unit" would likely be a `register_user` function that accepts params as input and either aborts with validation errors, or succeeds by writing the record to the DB.

Then, for an integration test I would have 2 tests. One to make sure with invalid input I end up with some type of error displayed in the HTML response (it doesn't matter which one), and another test with the success case to make sure things work when they should (such as the user is registered and a new record was created in the DB).

So I end up with a tiny bit of overlap in tests. Technically the unit test for the success case doesn't need to be there since the integration test covers it but I usually include it for the sake of completeness because it's usually like 4 lines of code to make that test but I'm not 100% opposed to someone saying it should be left out.

</comment></comment></comment></comment></comment><comment><USER7> This paper is emblematic of a serious problem in the software development field: lack of empirical research. It is unsurprisingly filled with opinion and anecdote, with little mention of research in the area. And in the one actual study cited, "Does Test-Driven Development Really Improve Software Design Quality?", the author mis-characterizes the findings. Not that there is a huge set of research on unit testing to refer to--there isn't--and hence the problem.

"Software development has been characterized from its origins by a serious want of empirical facts tested against reality, which provide evidence of the advantages or disadvantages of the different methods, techniques or tools used in the development of software systems."[1] In my view, the best thing we could do is to adopt "Evidence-Based Software Engineering"[2] as other disciplines have. This is more likely to have a major positive impact than the newest and hottest language, tool, or technique.

[1] Reviewing 25 Years of Testing Technique Experiments. [https://www.researchgate.net/publication/220277637_Reviewing...](https://www.researchgate.net/publication/220277637_Reviewing_25_Years_of_Testing_Technique_Experiments)

[2] Evidence-Based Software Engineering. [https://dl.acm.org/citation.cfm?id=999432](https://dl.acm.org/citation.cfm?id=999432)

<comment><USER8> I agree entirely. The more tendency there is to push development as an "engineering" discipline, the more evidence based research needs to be used to solidify or disprove certain development dogmas repeated over and over again, which in many cases, seemingly have no empirical evidence beyond a few anecdotal success cases.

This is the norm in the industry, "you're doing it wrong, the best way is this way..."\--based on what evidence that pertains to this case or has proven generalized success applicable here?

In most cases, it's someone's successful anecdotal experiences which worked for the specific cases they were involved with. That doesn't mean those approaches can be abstracted away and generalized to all cases, but many in this industry do that regularly and critique others' approaches based on that. It becomes this competitive ego contest: well my work was at x, y, z solving q and was successful--making me an authority on a, b, c's problems solving p because x, y, z is a leader (appeal to authority fallacy)... etc.

It's one thing to treat development as much of an art (which to me, it very well still is) but once you start treating it as a concrete discipline, you need to provide the lyme, cement, aggregates, water... evidence and studies showing approaches and how they faired across controls and varied cases.

<comment><USER9> Agree with you and parent poster. I remember 15 years ago or more going through CMMI certification and there was a push to get to level 3. Our company hired a consultant who came in every eight weeks or so to track our progress, give direction etc.

On one of his visits he started interviewing engineers individually to see how things were going and I asked him what the point of it all was and I could tell he was quite taken back. But then, not surprisingly, he said to be more efficient developing software. I then asked him if he or any organization he'd worked with had ever actually tracked the time it took to implement the process, to which he answered no. Then I asked him, then how the hell do you know if any of this is making software development more efficient?

</comment></comment></comment><comment><USER10> I did not read the article. I did read all comments

Unit tests for the most part aren't about "testing". They are developer tool. To verify rthat modifications (refactoring, additions, bug fixes, etc) doesn't break contracts etc. Oh and showing that your code is a codependent mess of poorly isolated spagehtti, if your unit tests are hard to write, the code under test is a mess. Inittests are more useful in languages with loose or poor type systems.

Many unit tests are not written well. testing more than the interface/contract. Or full of complexity boilerplate and mock. Which means code needs fixing.

<comment><USER11> Unit tests don't guarantee that your code units are well designed. You can still write unit tests for spaghetti code. In fact, sometimes it encourages it because it encourages antipatterns like dependency injection; because developers get the urge to inject mock objects into the units from the unit tests.

Just think about it at a high level. If your module depends on another module, is it really always necessary that this module be substitutable for another module that has the same interface (e.g. another similar module or a mock)? 99% of the time, the answer is no! In fact it's often a problem because this wrongly assumes that if a class exposes the required interface, then it is compatible. There is more to compatibility than just interface; if the submodule maintains its own state (OOP), then its behaviour can change in a way which could break the dependent logic. You can't have Dependency Injection for everything because it's never so simple; these customizable parts of the code have to be designed very carefully.

<comment><USER12> I actually don't get where you are going with this breakdown. Can you give me an example.

<comment><USER11> I mean when you have a class which, instead of importing/including/requiring its dependencies directly, expects instances of various classes to be passed into its constructor for example. So the class cannot do its job unless you pass its dependencies into its constructor... This is an antipattern which unit tests tend to encourage because it allows you to decouple the unit logic from its dependencies and it makes it easy to inject mocks in the place of dependencies.

A unit test should only test a single class so that means you need to mock out all other classes which your class depends on. Mocking out dependencies in the test code is difficult or not feasible and that's why developers often resort to Dependency Injection in their source code but as mentioned before, it is an antipattern.

Also, I noticed that a lot of developers confuse unit tests with integration tests but the definition is quite clear: If your test covers more than one class without mocks, then it's an integration test. Integration testing does not necessarily mean end-to-end testing. It could just be a single class with its internal dependencies.

<comment><USER13> Passing dependencies in the constructor is the only acceptable way of having stateful dependencies (like a database or some external services). I am assuming you are against passing things like Math libraries by creating an instance, which I would agree with.

The only reason dependency injection gets a bad rep is magical frameworks which obscure the actual wiring and end up causing bigger problems.

<comment><USER11> I also would not pass in a database client instance. I would pass in the config for the database client though.

I think that the class which ineteracts with the database directly via the client should be tightly coupled to the database client. It's not very often that you change database and when you do, you can just swap out that entire class completely. Classes which interact with the database should expose simple interfaces for performing actions against the database and those wrappers should be replaceable.

<comment><USER13> Then how would you handle connection pooling, if every class which interacts with the database has its own instance of the database client?

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> The thing is that most people don't understand that the code needs to be tested anyway. If you don't test it, you are just an idiot who has no proof that the code does what it claims to do.

Now because you have to test it anyway, you can just simply spend the same time writing a unit test instead of executing the code with manually configured non-repeatable test cycles, a.k.a clicking through the UI, or sending Postman requests, etc.

Also it's kind of selfish not to make something repeatable by others.

And as someone pointed out before me, unit tests are not about testing at all. It's a documentation about the system, and what it's supposed to do. Also it's the way to stop the next person who works on the code to ruin something by not knowing the business rules.

<comment><USER15> To add to this sentiment, tests also give teams confidence that is needed. It gives engineers confidence when developing new features because the test suite will break if you introduce a regression. It gives engineers confidence during deployment/CD.

While the tangible benefits of unit tests are very important, there are other intangible benefits that are equally important.

<comment><USER16> I'd say that confidence is a tangible factor.

The single most important reason to test your code seems to be that it allows you to refactor your code while ensuring it still meets the original outside expectations.

The author's main gripe seems to be about tightly coupled tests that make refactoring larger systems more difficult, and about prioritizing meeting arbitrary metrics (lines of codes covered) rather that thinking critically about the actual benefits.

This is in line with his emphasis on integration tests determined by the business. I think that same thought process can be applied to internal components of code as well, and you can empirically determine the quality of your approach (roughly) by evaluating how often your tests change. If nearly every change breaks a test, that probably means they're low value/too tightly coupled.

Excessive mocking seems to be the biggest source of evil in that regard.

</comment></comment></comment><comment> ed-209 "The cross product of those paths with the possible state configurations of all global data (including instance data which, from a method scope, are global) and formal parameters is indeed very large. And the cross product of that number with the possible sequencing of methods within a class is countably infinite."

Sounds more like a condemnation of OOP than of unit testing, and I do genuinely feel sorry for the unit testing, OOP purists out there. I prefer to design more functional methods, which operate on parameters and injected config instead of instance state and/or globals (cringe). Incidently, this approach makes full coverage attainable.

"Large functions for which 80% coverage was impossible were broken down into many small functions for which 80% coverage was trivial. ... Of course, this also meant that functions no longer encapsulated algorithms. It was no longer possible to reason about the execution context of a line of code in terms of the lines that precede and follow it in execution"

I can reason about such an implentation MUCH more effectively by glancing at the small bit of higher level code which integrates everything (and as mentioned above by foresaking instance state and polymorphism). This strikes me as a bit like advocating a flat directory structure cause it's important to be able to see all your files at once.

<comment><USER17> Yeah a lot of the 90s/early 2000s OOP stuff I learned in school seemed to always result in really tightly coupled systems and bespoke webs of tests and fixtures that strung along weird dependency chains in unwieldy spaghetti piles that did no good. Following TDD has helped me land at decoupled functional interfaces like the ones you've described, and it all scales and composes so nicely, yet stays very tractable.

Robert Martin sketched 2 diagrams in [1] that elegantly illustrate these two different design patterns and how testable usually means composable and more tractable:

[1] [http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms- Ar...](http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms- Architecture.html)

<comment><USER18> I wish he gave actual examples to illustrate what he was talking about. So you have an additional API layer the tests hit to call the functions you're testing? Do endpoints map to classes? Modules? So aren't you just tightly coupling this API to your service? When the service changes, you still have to update the API. Can you explain to me how this solves the problem?

</comment></comment></comment><comment><USER19> One of the things I dislike the most about unit tests is how it's used for "quality theater". Some examples:

\- Trying to use coverage percentage metric as a sign of quality. As if a simple percentage means anything about the quality of the tests. It's as useless as using lines of code as a way to measure progress.

\- Not recognizing that useless unit tests are harmful for the code maintenance. It makes refactoring code into better structure difficult and developers just give up because it's too much work to fix the tests that weren't even providing any value in the first place. This ignorance is expressed in statements like how there's a testing "pyramid" with unit tests at the bottom and end to end tests at the top. Which is a nice sounding soundbite and image, but is useless. Forget pyramids, just write tests where it makes sense.

\- Code review comments that try to look smart with "where's the unit test?" Then the developer doesn't want a long drawn out fight about how a unit test would be useless here since there's a huge crowd just cargo cult yelling "code coverage!" "unit tests are good!" "pyramid!" So the developer just writes the stupid test to get the code merged. This is also an example of how harmful code reviews can sometimes be, when there's a popular stupid idea, code reviews perpetuate it because the developers who know better just get tired of fighting the same fight over and over again.

I really hate useless unit tests. I've seen tests that setup a mock, configure it to return a value when called, call the code using the mock, then check the returned value is the mocked value. This tested absolutely nothing! I've seen unit tests that verify every line of the method was called, completely pointless. The point is supposed to be to verify that for a given input, it has a given output, not lock it into a specific implementation by verifying every line of code ran a certain way.

There is an idea for structuring software "functional core, imperative shell". Write the software this way and the natural place for unit tests and integration tests becomes obvious. But nope, the industry is all about unit test coverage percentage, stupid pyramids, looking good in code reviews. It's all quality theater, not actual focus on quality.

<comment><USER20> > I really hate useless unit tests. I've seen tests that setup a mock, > configure it to return a value when called, call the code using the mock, > then check the returned value is the mocked value. This tested absolutely > nothing!

I've had a similar disagreement about the validity of such a test.

The other mocking issue I've seen, is people mocking blackbox third-party APIs over which they have absolutely no control, which sometimes leads to passing unit tests, failing integration tests and head scratching all around.

<comment><USER21> I'm with you people on this mocking issue. It is about time that mocking be recognised as an anti-pattern in automated testing, or at least as an undesirable tool of last resort.

Mocks often contain the same bad assumptions and misunderstandings about the mocked API which the developer used during the implementation of the unit they are trying to test.

If you feel the need to mock something then you should first ask yourself whether an integration test can do the job for you. Actually, I would generalise this advice to: Don't write a unit test when you can write an integration test.

</comment></comment></comment><comment><USER22> > If you find your testers splitting up functions to support the testing > process, you're destroying your system architecture and code comprehension > along with it. Test at a coarser level of granularity.

The emphasis here should be on the reason for splitting up functions. Long, complex functions can be difficult to understand, and removing a few lines in exchange for a (well named) function call is very beneficial for the reader. The opportunity for testing comes from this delegation. A function call is a contract, and the test ensures it complies. Now the reader can comprehend what the code is doing at a higher level; trusting the sub functions do what they intend.

<comment><USER23> It's quite the opposite: The whole point of the architecture is often to facilitate testing. If we didn't have to write tests we could do without a lot of that boilerplate.

</comment></comment><comment><USER24> Doing a typical "front-end" mobile application I write the following tests:

* Integration tests that test the API I get a ton of value out of it though it's sometimes hard to guarantee a certain state at the API's end. But I use them while building the API's but they also can detect any kind of problem after an API upgrade etcetera

* Unit tests that test data transformations This is stuff like date formatting, building headers into a request given certain input, building more complex ViewModels that take a few structs as input and turn them into something that reflects the actual process happening in the view. They're valuable while building the logic, help separating the logic since you need to make it testable and also help a ton if you find a bug since a bug simply means adding another test case to see if something goes wrong and then fix it.

I don't think I even get to 30% code coverage but I think what I cover is super valuable and the other 70% is usually mostly CRUD boiler plate.

<comment><USER25> I personally find testing incoming APIs a waste. Sometimes I write tests to verify that I treat the incoming data correctly if I transform it in fancy ways, but other than that, you should trust the API contract. It's almost like writing tests for the frameworks you're using.

Granted, that's from a unit test perspective. Integration tests of APIs are invaluable. I wish we had them already where I currently work.

<comment><USER26> > but other than that, you should trust the API contract

As someone who's been working in corporate integration for the past 6 years..

Never trust a contract. Be in WSDL, OpenAPI spec, Word documents or otherwise. I've worked with large tech vendors, I've worked with finance, I've worked with large consultancies. The only people that seem to get it right, is the people you don't want to work with because it's soul-crushing - think HL7 et al.

<comment><USER25> The point is you can't write unit tests for broken API contracts, so either you trust that the contract is upheld, or you've got bigger problems on your hands.

<comment><USER26> Do you mean integration tests? I don't think API contracts should be a part of a unit test. A unit test should be self-contained, unless of course there is a tight coupling to an API.. Which I would steer clear from.

That's why I value integration tests over most thing. I can see immediately that something is broken at a high level, what business impacts it has and explain what systems are affected.

</comment></comment></comment></comment></comment><comment><USER27> I got progressively more and more frustrated with this article, largely because he keeps making statements about the impossibility of covering all states a class may take on (true!) but then followed up with espousing more use of integration and system tests, which are clearly combinatorial harder to test "completely". He also implied at the very beginning that somehow this was driven by the switch from FORTRAN to OOP, as if FORTRAN avoided this combinatorial explosion (magic!) and it's only because of polymorphism that we live in the "unit testing is good" world.

The logical contradictions eventually overcame me.

<comment><USER28> > espousing more use of integration and system tests, which are clearly > combinatorial harder to test "completely"

The point is that when you do integration tests, you will test the underlying classes the way in which it _actually matters_. You can't test every possible condition a unit can have, but you can test for the most likely.

<comment><USER29> This is my experience too. Realism in testing is criminally underrated while code coverage is criminally overrated.

IME unit tests can only effectively substitute for integration tests where you're testing logical/algorithmic code with simple function inputs/outputs.

<comment><USER30> I somewhat agree, somewhat disagree. IMO the largest value I get from unit tests is the confidence that I can make changes and understand what breaks. Refactoring w/o unit tests makes me feel like I am flying blind

<comment><USER31> The units we test are almost never big enough for internal refactoring. It's the decomposition into units that wants refactoring, and there the test suite actively fights back (mock expectations in particular).

If there were enough code involved in a test that we could meaningfully refactor it while keeping the test green, we would call it an integration test.

</comment></comment></comment></comment></comment><comment><USER32> A thread from 2017: [https://news.ycombinator.com/item?id=15591190](https://news.ycombinator.com/item?id=15591190)

2016: [https://news.ycombinator.com/item?id=12666454](https://news.ycombinator.com/item?id=12666454)

2016: [https://news.ycombinator.com/item?id=11799272](https://news.ycombinator.com/item?id=11799272)

2014: [https://news.ycombinator.com/item?id=7353767](https://news.ycombinator.com/item?id=7353767)

</comment><comment><USER33> When I started programming, I'd think up lots of clever ways to avoid repeating things. Ten years on, that code is a nightmare to maintain because changing the behaviour for just _one_ call site of hundreds is next to impossible, because everything gets funnelled through one extremely DRY group of modules.

Redundancy vs. Dependencies: it's the dependencies which kill you. Redundancy is often a _good thing_.

If you state an algorithm only once, as the implementation, then the next programmer only knows what it does, not whether it's correct.

This is, in my opinion, the main value of unit tests: state the algorithm twice, once as implementation and once as expectations, and _if they don 't agree_ then something's wrong. While the odds of a bug existing in any line of code haven't changed, the odds that the exact same bug exists in both sides are much lower.

Any bugs which survive that are probably in design rather than implementation, ie. my mental model of what the module should achieve is wrong somehow. Catching that is a job for integration tests.

I definitely agree with the 80/20 rule here. 100% code coverage is neither necessary nor desirable, and 20% is fine if it's the most valuable 20%.

</comment><comment><USER34> Unit Tests = The assurance/confidence that you get, if something changes logic, this test will break & you will know it. Aside from just limiting bugs - this is more powerful.

<comment><USER35> 95% of the time when a unit test fails for me, it is the test that need fixing instead of my code. It hardly inspires confidence.

<comment><USER36> To me this suggests that there is no clear understanding what your units are supposed to do.

My second theory would be that the unit tests are written by the inexperienced developers while the good developers write the other code.

<comment><USER35> The tests will involve 5 mocked dependencies just to test a simple if statement. They test the implemention and are a waste of time.

Isolated units that are well tested usually don't need to be updated in my experience so they rarely break.

<comment><USER12> Tests that have 5 mocked dependencies is usually a signed we done messed up somewhere.

</comment></comment></comment></comment></comment><comment><USER37> Kent Beck (yes, _the_ Kent Beck): "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence"

[https://stackoverflow.com/a/153565](https://stackoverflow.com/a/153565)

</comment><comment><USER38> > If you want to reduce your test mass, the number one thing you should do is > look at the tests that have never failed in a year and consider throwing > them away. They are producing no information for you — or at least very > little information.

I feel like there is some subtlety here that most will miss. Specifically, "and consider". That is the part we are really bad at.

<comment><USER39> Those tests are helpful when you do major architectural changes, which may not happen every year.

Tests also help in general development. Make some changes, then fix the tests. If you are running tests locally on your machine (and offline) how can you be sure that every time a test fails locally the failure is logged?

<comment><USER40> There's a difference between tests that haven't broken because they are in stable code, and tests that haven't failed because they are testing tautologies or even just completely failing to break when the underlying code is broken.

I've lost count of how many times I've gone into an old test suite at work and found that the tests were still passing even though the code they were testing had completely changed or been removed.

Sometimes tests are written very poorly. The codebase benefits from their removal.

</comment></comment></comment><comment><USER41> I've never tested 100% of my code.

But I've also never written a unit test that didn't expose bugs.

That's mainly because I know what parts of the code will be dicey, and focus unit tests on them.

<comment><USER42> That's funny. I only write tests to prove that the program does what it's meant to do and not to find bugs.

The goal is to prevent a future programmer, including myself, from breaking any of the declared properties.

<comment><USER43> Tests don't prove anything, they just show the intended behaviour. Only full verification proofs show correctness.

Too often I've seen "tests show it's correct" suites horribly fail to provide value when the behaviour changes in a unit of business logic and the brittleness needs to be unwound and replaced with robust assumptions.

</comment></comment></comment><comment><USER44> This is very interesting, when you contrast it to [[https://dl.acm.org/citation.cfm?id=3106270](https://dl.acm.org/citation.cfm?id=3106270)].

I'm always weary of arguments that rely on 'unit tests are more complex than the code'. If that's true, then it's correct. Tests have to encapsulate the software contract that's being enforced and should be more complex than the underlying code.

</comment><comment><USER45> The utility of unit tests greatly depends on the type of software you're building. Building a DB without tests is difficult and unlikely to win many customers - particularly when news of that gnarly data race comes out. Whereas a crud webapp where everyone can see what's working and what's not is a bit hit or miss.

At the very least testing helps communicate to a code reviewer "hey this thing does what I think it does".

</comment><comment><USER46> When implementing lexers and parsers for language specifications, I have taken the approach of testing each token (keyword, number, etc.) for the lexer for each EBNF symbol. This repeats tests for common keywords and other constructions, but means I can see that the lexer handles all the tokens in each EBNF symbol. In this way, these tests are more BDD (behavioural driven development) in style, but without things like gherkin/cucumber. With this approach, I do full coverage tests for a given symbol/token, and just check the basic symbol/token case elsewhere.

I do a similar thing with the parser tests -- have a test for each valid complete symbol production, and then tests for as many error cases that the parser can handle for that symbol.

With that base, I can add additional tests for bugs and additional error recovery cases I implement.

I never see unit tests as a waste as they provide a set of regression tests that are invaluable for refactoring and making other changes to the code, like implementing new features or better error handling.

</comment><comment><USER47> Most insurance is waste

<comment><USER48> If your house didn't burn in the last two years, consider not insuring it anymore.

</comment></comment><comment><USER49> I don't just code for a single project. I create libraries when I write a piece of code that I know will be useful down the line. And for those libraries that are going to be reused throughout many applications I think unit testing is gold.

</comment><comment><USER50> Absent from this discussion is the use of generative testing. At the unit level they can automatically enumerate a variety of scenarios the programmer would likely overlook.

<comment><USER51> I just discovered this, only it was called 'property based testing'. Do you recommend any resources for learning to use it effectively? I haven't dug in yet, but so far it hasn't clicked when thinking about it. I like the idea a lot, but I guess I don't see where it would be most useful for my own code.

</comment></comment><comment><USER52> I run a one-man project and I write test first unit tests for all of my code. This has enabled me to advance the code with new functions without breaking current API's. The tests are not in the way and usually doesn't need to change because I change the implementation. It has been tremendous for productivity because I don't need to worry about if stuff breaks. I can trust my tests for changing those and so far they have always done that.

</comment><comment><USER53> After 15 years of writing unit tests, I haven't reached the same conclusion as the author.

What I've found in my time is that unit testing can be good, but like anything it's not a panacea. It requires discipline, and like normal code, it has code smells.

Black box unit tests are the most likely to be good tests, and white box unit tests are the most likely to be bad tests. The more you depend on the inner workings of a function in order to test it, the more likely it is that you are coupling your test to the implementation rather than the purpose of the unit being tested. Once you tie to the implementation, refactoring becomes a LOT harder, because changes will break the tests even if they don't break the functionality.

Mocks are also a major source of trouble, and more likely to be a code smell. If your tests are using a mock to test how many times your unit called it, either your tests are bad or your architecture is wrong.

There are three main kinds of code:

\- Code that fetches data

\- Code that stores data

\- Code that transforms data

Mocks are necessary when you mix these. If you have a function that opens a DB connection, fetches data, transforms the data, and then stores the data, you now have an extra problem to deal with (the database), when all you wanted to do was test the transformation. Things would be far easier if you separated the transformation out, tested that in isolation, and then integrated that encapsulated functionality with fetching/storing code. This also improves separation of concerns and code duplication, since now your fetching/storing code can be generalized and also tested in isolation.

Actually I lie. There is a fourth kind of code: code that modifies state. This is the evilest, smelliest code around, and it's also something that unfortunately we can't get completely away from. But we can manage it, by isolating state, reducing the need for or scope of the state, and providing "configuration object" function entry points to make testing these monstrosities less nasty.

Code coverage is not just a measure of quality, but also of waste. If your code is not being called, then one of three things is happening:

1\. It's error checking code for another API it's calling, which you normally shouldn't be writing tests for (unless that API is known to be buggy and you need to guard against it).

2\. It's not contributing to the goals of the program, and can be taken out.

3\. It does contribute to the goals of the program, in which case you need a test for it.

You can't reach 100% code coverage because of (1). But you absolutely should check WHICH code is covered in your tests because of (2) and (3). Anything higher than 80% coverage is pure luck, and tells you nothing about quality or wastage. In many cases, even 60-70% is sufficient.

<comment><USER54> If you don't use mocks then won't you just end up with integration tests?

<comment><USER43> Who cares what they're called as long as they're fast and don't crash when running at scale/fill the disk or memory

<comment><USER54> Because if you're not using mocks the tests get unweildy. Suddenly changing components three layers down the dependency tree breaks "unit" tests at the top. Those are the tests you just end up @ignore'ing.

<comment><USER46> Mock things like database access, or better yet pass the database connection via an interface and create a test version of the database access so you can create a database-like thing for your tests (e.g. an in-memory database).

If you are depending on another component of the application (a lexer, a JSON class, a maths function, etc.) don't mock that because if that class breaks you _want_ tests to fail instead of silently passing because the broken class/function was mocked.

If you are depending on thirdparty libraries, don't mock those unless you have to (i.e. if you cannot run the tests). This will help avoid unexpected bugs after upgrading libraries or if supporting different versions of a library.

If you are writing code for a complex infrastructure (e.g. an plugin for an IDE), try to use test-specific versions of enough of the infrastructure to get the rest functioning, and use the real versions of as much as you can. This will help pick up issues in your code when new versions of that infrastructure make changes -- you want your tests to fail in this case, as the real code would fail.

Understand why your tests are breaking and address that. Use @Ignore as a last resort. If APIs or behaviour has changed, update the code and tests to reflect that. If you are supporting different versions, create version-specific compatibility layers.

<comment><USER54> As someone that has written thousands of tests - what I disagree with you on is when writing unit tests those application components should have their own tests. Then you can cleanly mock them. Even if they are utilities etc.

Same goes for application code in the same service or whatever. Mock those calls and only test your unit of code.

If you don't do this things can be fine. But at some point the code base will become unwieldy and changing code in one place will break tests all over the place.

Integration tests are fine and they have their place but are not a substitute for proper unit tests.

</comment></comment></comment></comment></comment></comment><comment><USER55> I've generally preferred integration tests to unit tests but Storybook has completely changed how I write React components, for the better.

<comment><USER56> Agreed on integration tests over unit tests. I get the most bang for my buck with them. Storybook is pretty nice. I use it for developing smaller components, more of the building blocks of the application. Have you ever checked out Kent C Dodd's react-testing-library? It was a refreshing approach to testing react components IMO and it has gained quite a bit of adoption.

<comment><USER55> The docs for react-testing-library look like they offer a great deal of wisdom in a tiny package. I find my React components tend to be simple enough that I'm generally far more concerned about whether the CSS works than the JS, leading me to probably keep my focus on Storybook for the moment but I suspect I'll be reaching for react-testing-library before too long. Thanks for the heads up about it.

</comment></comment></comment><comment><USER57> I wrote a response to this article (and the follow-up) here: [https://henrikwarne.com/2014/09/04/a-response-to-why-most- un...](https://henrikwarne.com/2014/09/04/a-response-to-why-most-unit-testing- is-waste/)

</comment><comment><USER58> I agree. Unit Test is for testing API usage, not implementation. We can use it to figure out the API design good or not.

But the problem, is API change is very often, and we don't want to change both implementation and test just for the sake of API change.

Integration test is enough in most case.

Even API is the implementation details of an abstraction.

</comment><comment><USER59> This article seems to ignore the fact that unit tests are typically made for other programmers down the line as a form of documentation, as an informal description of business rules, and as a way to gauge whether new code will break the product in a very obvious way.

</comment><comment><USER60> tl;dr I made it to "Testing does not increase quality; programming and design do" and quit.

It seems clear that the author has a strong opinion on this and perhaps that has been formed by exposure to unit tests done wrong. I suppose his article is worth reviewing and asking if any of my unit tests suffer from the problems he identified. I think most of his complaints relate to badly applied unit tests and I think we can all agree that _any_ methodology can be badly applied. That does not provide grounds to condemn the methodology.

Having used Fortran (and Macro-11) as the first languages I employed professionally, I do not recall any thrust for unit testing at that time. Maybe it was just the shop I worked in. More recently I have used unit tests for Go, C/C++, Python, Perl, Java, shell scripts and probably some I'm forgetting. I wouldn't consider coding anything w/out some kind of unit test.

Back to the quote "Testing does not increase quality; programming and design do", I disagree vehemently with the claim that testing does not increase quality. While true that one cannot 'test in' quality, I find that designing code to be testable provides higher quality results. This is particularly true in languages such as shell scripts that often start small and grow until they are hundreds of lines of in-line code. Testable code is generally better partitioned and structured than it would otherwise be.

A second benefit to unit testing is immediate feedback and completion of parts of the system. I get a feeling of accomplishment when I complete something that passes its tests and prefer that to deferring satisfaction until the entire thing works.

Finally, if I test the bits in isolation, I can provide them data for all of the corner cases I think could cause trouble and make sure they work for a wider range of inputs than could easily be done during integration testing. When I do get to the point where I put the bits together, I have a much higher success rate with integration testing.

</comment><comment><USER61> Obligatory(?) "Unit testing without integration testing" pic:

[https://www.reddit.com/r/ProgrammerHumor/comments/5pbl2q/two...](https://www.reddit.com/r/ProgrammerHumor/comments/5pbl2q/two_unit_tests_but_no_integration_test/)

<comment><USER36> We have this one in our office: [https://twitter.com/dave1010/status/613601365529657344](https://twitter.com/dave1010/status/613601365529657344)

</comment></comment><comment><USER62> > If you find your testers splitting up functions to support the testing > process, you're destroying your system Why Most Unit Testing is Waste 4 > architecture and code comprehension along with it. Test at a coarser level > of granularity.

This is very much in line with DHH's opinion about testing in general (the discussion "TDD is dead" is about this). He said that he doesn't want to split logic for the sake of testing, so HE drives the design NOT tests. I very much agree with this. I think a human can design better code (meaning that's easier to use, so easier to consume by other humans) than any automated process (like TDD).

I noticed his blog post quotes this PDF: [https://dhh.dk/2014/tdd-is-dead- long-live-testing.html](https://dhh.dk/2014/tdd-is-dead-long-live- testing.html)</comment>


Facebook Container for Firefox - <AUTHOR> https://www.mozilla.org/en-US/firefox/facebookcontainer <comment><USER3> Third party cookies, and any way to fingerprint a specific user starting from high entropy user agents to screen resolution, font fingerprinting or canvas data, should be considered a breach of the browser security model.

All sites should run in containers and no advertiser should be able to track you across sessions. When I want 3rd party interaction, I should need to opt in and connect the current site with Facebook or some other 3rd party.

<comment><USER4> Ever encountered Google ReCaptcha when you've turned off third party cookies or while in incognito/private mode? It's a nightmare, even if you're logged into a Google account. You can be shown upto 7-8 challenges, painfully slow loading images and Google's insistence that they encountered malicious traffic from your IP when attempting to use the audio version. What's even worse is they track your mouse movements and fast solvers like me are penalized since they think I'm not human anymore.

As much as I hate third party cookies, turning them on drastically simplifies the captcha solving process. So much so, I now use a separate browser profile with third party cookies allowed, just for the sake of captcha heavy sites.

Given that Google benefits by tracking my activities and free labor from my captcha solving, they will always punish privacy conscious users via such dark patterns.

<comment><USER5> The optimist in me thinks that if browsers started to disallow third party cookies, ReCaptcha might have to adapt to the change and make it easier to solve if third party cookies are blocked. After all, if they didn't, they'd risk website owners moving away from ReCaptcha because visitors could no longer interact with the site.

The pessimist in me thinks that if a browser were to disallow third party cookies, users might simply switch to a different browser that does allow them.

<comment><USER6> I don't think it has so much to do with reCAPTCHA as much as it has to do with Cloudflare and website owners themselves. Most reCAPTCHA challenges come in the form of Cloudflare challenge passage pages. Website owners have 5 options to choose from regarding challenges:[1]

— Essentially off: Challenges only the most grievous offenders

— Low: Challenges only the most threatening visitors

— Medium: Challenges both moderate threat visitors and the most threatening visitors

— High: Challenges all visitors that have exhibited threatening behavior within the last 14 days

— I'm Under Attack!: Should only be used if your website is under a DDoS attack (Visitors will receive an interstitial page while we analyze their traffic and behavior to make sure they are a legitimate human visitor trying to access your website)

I think a lot of companies set it to "High" and forget about it, not realizing that it's ruining the experience for a lot of users.

[1]: [https://www.cloudflare.com/a/firewall/ebelinski.com#security...](https://www.cloudflare.com/a/firewall/ebelinski.com#security_level)

<comment><USER7> It doesn't ruin the experience of anyone except a couple of overly technical users and customers in the wrong locations.

It's very good at blocking malicious traffic though and it's totally worth losing a pair of users for that.

<comment><USER6> Yes, it's the users that are wrong!

</comment></comment></comment></comment></comment></comment><comment><USER8> We're going from cold war to all-in.

Not just a privacy question. Reddit nags me every time I hit the front page, even returning from a story, asking me to log in. For most sites I need to create ublock filters to prevent pop-ups with useless "we use cookies", subscription requests, ads or social media bars that fills half the screen, etc. etc. etc.

Every newspaper I read has decided that autostarting video and streaming is a good idea.

Yes, HN is OK, but sites that it points to are not.

I'm giving up on the web.

<comment><USER9> When you mentioned reddit I thought you were talking about their "install the app" pop up. They have by far the worst mobile experience out of any site I've use more than once in the last 2 years.

<comment><USER10> Fortunately it takes one tap to update your preference to have it stop nagging you to install the app.

[https://www.reddit.com/r/redditmobile/comments/6hk9ot/androi...](https://www.reddit.com/r/redditmobile/comments/6hk9ot/androiddear_reddit_no_i_do_not_want_your_app_stop/)

<comment><USER11> It should not be opt-out though

<comment><USER12> How would you ever know it exists then. No, they should give you the option to be reminded again, or be done with it. But since we are talking about deleting all cookies, where do you think this information would be added?

</comment></comment></comment></comment></comment><comment><USER13> I used Firefox's containers for about a day, and then I discovered the privacy.firstparty.isolate option (in about:config), which effectively gives every site its own container with no user effort. That, combined with Cookie AutoDelete, seems to work well.

<comment><USER14> My use case is multiple Google accounts. I can log in to multiple Google accounts at the same time in different containers and answer emails very easily.

<comment><USER15> You can be logged into multiple Google Accounts at the same time without the extension. Just click the little profile icon in the top right and click "Add Account."

I'm logged into four, including a Gapps account.

<comment><USER16> Have they fixed the issues though where some of their apps only work with the primary account you're logged in with? (e.g. the first one)

<comment><USER17> Google Play Console only works with your primary account.

</comment></comment></comment></comment></comment><comment><USER18> If you use Firefox Containers, including the Facebook Container, please also use Cookie AutoDelete [1] to get rid of cookies from closed tabs across containers. Otherwise, in my observation, sites will still be able to track you if you reuse a container (even after closing all tabs of that container) for a specific site.

[1]: [https://addons.mozilla.org/en-US/firefox/addon/cookie- autode...](https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/)

<comment><USER19> It sounds like you're after Temporary Containers: [https://github.com/stoically/temporary- containers](https://github.com/stoically/temporary-containers)

That gets you a clean container every time you click the button. Very useful for development testing, too :).

<comment><USER20> what's the use case difference between that and porn mode browsing? i can't really tell when i should use one and the other.

<comment><USER21> The best feature (at least for me) is that you can whitelist some specific websites to always open in a new temporary container, without any extra effort, while leaving the rest of your websites like they are today.

For example, I have YouTube (and any other Google website) to always open on a temporary container but other sites like HN and Reddit are on a normal and permanent container.

</comment></comment></comment></comment><comment><USER22> If anyone in your household uses FB from the IOS or android mobile app from wifi, it will have both your IP address and GPS coordinates. Correlating that multiple people share one residence or workplace is easily done for FB. You can keep playing a shell game like run all your desktop PC traffic through a VPN somewhere so that the FB container doesn't show up as the same geolocation, but you or an ignorant non technical user you live or work with will slip up.

Edit: fb also buys geolocation data from organizations that do the modern equivalent of wardriving. Correlating GPS location with RSSI of specific wifi SSIDs and AP MAC addresses. If anyone near you uses the app, even if their phone has all location services turned off, you're still geoprofiled to within a city block.

<comment> dao- What's your point? Facebook still won't know what websites you visit on your PC. It also doesn't have geolocation access there unless you explicitly grant it.

<comment><USER22> That the targeted advertising and profiling will still come to you. Live with a person who joins fb mommy groups and buys diapers online? Prepare for a barrage of relevant ads. The main point is that the combination of relationship-inference and geolocation can undo probably 70% of your own privacy protection measures, through ignorant ordinary use of the fb app by friends, family and coworkers. Then combine that with fb facial recognition profiling from photos third parties may upload...

<comment> dao- Sure, they will still track you as best as they can (though as I said Facebook doesn't have geolocation access on desktop). This doesn't change the fact that without your browsing profile, Facebook will have less knowledge about you than it would normally have, period. Facebook can't "undo" that.

<comment><USER23> I think that was the OP's point. FB woule have geolocation information on you because thanks to someone else's use of your WiFi network on their cellphone, FB can now associate your IP address with a geographical location.

So even though you're on desktop and haven't provided them with location permissions, they can still identify your location based on your IP address.

<comment> dao- Ah, okay. I still don't see how this would undo preventing Facebook from knowing what websites you visit. The location of your PC seems like an entirely separate data point.

</comment></comment></comment></comment></comment></comment><comment><USER24> I've been trying to use Firefox's containers for a while. They are pretty clunky - you need to open a blank container tab using a menu and then enter the url. I forget to do that all the time, so after some time you are just logged into everything in the "global" container, or logged in to google and twitter in the same container etc.

 _If you check the "Always open this page in this container thing" \- then it prompts you with an "are you sure you want to open this page in this container" every time you go to that page which is very annoying._ Edit - <USER2> is not true - there's a checkbox to "remember your choice". I don't know why I didn't see it.

They are error prone enough that they aren't good tracking protection. Just use ublock origin or a similarly good privacy plugin to globally block as much tracking as you can.

The facebook container eliminates some of those annoyances, but only for facebook.

<comment><USER25> > then it prompts you with an "are you sure you want to open this page in this > container" every time you go to that page which is very annoying.

That isn't true - you say yes/no the first time and then it's automatic. Works great for me.

I create a container for every service I want to stay logged into and whitelist the specified sites with Cookie Autodelete (which is container aware), then auto delete all other cookies on tab close.

<comment><USER26> Yeah, I'm not getting it after the first "Are you sure?" prompt, but that first one is annoying. I already checked the box asking to always open foo.com in a specific container. Why is it asking again?

Also, I'd love to do this in my bookmarks, instead of having to visit each site and set the container one-by-one.

<comment><USER27> > I already checked the box asking to always open foo.com in a specific > container. Why is it asking again?

I have some sites that I almost always want to open in a specific container. Except when I don't.

I suspect this double-confirmation is for people like me: I can chose between "always open this site in this container" and "always suggest opening this site in this container".

<comment><USER28> I actually have a few cases like this as well, but they are very common cases I encounter 20-30 times a day.

I thought containers were clunky too until I went looking for bug reports for the functionality I wanted (always open domain in container) and found out I just wasn't using them right.

I'm actually really impressed with how polished it is given the complexities it entails

<comment><USER29> Is there an official article/tutorial detailing how to use them and use cases with examples?

<comment><USER28> From searching I just found a Mozilla help page[1] that seems to have much of the useful info, along with some links to other articles.

Not sure of it or something similar was referenced at some point during the extension install process.

1: [https://support.mozilla.org/en- US/kb/containers](https://support.mozilla.org/en-US/kb/containers)

</comment></comment></comment></comment></comment></comment></comment><comment><USER30> IMHO, this is how containers should really work:

\- Every website (domain) should get its own container by default. I _don 't_ want to configure stuff when visiting a new domain.

\- If I want domains to share a container, then I don't mind having to configure that.

\- When clicking a link inside a container that points to a different domain, then the link should open in the container for the domain pointed to.

\- When clicking a link, I should have the opportunity to edit the link before opening it, to avoid information leakage from one container to another.

\- Cookies may be saved per container (default). But I should be able to turn cookies off for a specific container.

\- Containers should work against fingerprinting, i.e. by perturbing browser characteristics slightly. This should work by default per container and per session. It should be configurable.

\- If some well-known websites only work with multiple domains, then that is ok. These domains can be grouped into one container. Firefox can distribute a "whitelist" for such configurations. Please don't bother me with the specifics, but enable me to figure out what the settings are for a container, and to change those settings.

\- Container settings should be synced over my devices. Needless to say, containers should work on all platforms.

<comment><USER30> Btw, the ground rule I used here is that the amount of "security-related mental-gymnastics" I have to perform to stay on the safe side during normal browsing _should be zero_.

</comment></comment><comment><USER31> Don't blame them for taking advantage of the current media attention facebook is getting to bump firefox containers a bit! It's pretty neat technology.

</comment><comment><USER32> /sigh. Yet another "privacy" solution that's solves the wrong problem.

You prevent the big bad company from _spying_ on your browsing activity while, at the same time, explicitly posting to the big bad company's first-party site messages containing all the juicy bits of private information that you went through all that effort to prevent them from inferring through your other activities.

And we pretend this is helping, rather than just adding noise to an already confusing technical landscape.

<comment><USER33> Sorry, you're not seriously entertaining the idea that browsers should just turn off facebook for everyone, are you? There are plenty of parts on this planet where facebook is the main page in people's lives, like it or not, and the problem to solve is one of people's attitude towards that being okay. Not the availability of facebook. You don't change people's minds from "this is useful to me on an hourly basis" to "I won't use this" without going through (many) intermediate step(s), and this is a GREAT intermediate step for those people who can't (for whatever reason) give up facebook, but do understand that maybe it's time to restrict what facebook sees a little. And then we keep the pressure on, as society. This is a long battle, we're nowhere near done.

<comment><USER34> Big companies like this never go away. They just reshape their public image and keep doing what they are doing. The Facebook thing will blow over. He has friends in high places. Right now this is a show for the public. Later its forgotten and Zuckerberg is back doing whatever he wants to do.

<comment><USER33> Big companies like this have never existed before. It's hard to remember, but 10 years ago there was no "massive Facebook" or anything of the same scale. Amazon, Apple, you name it: NONE of them have been around long enough for a claim that "they never go away" to make any kind of sense.

<comment><USER35> The same shape no.

But big invasive entities have always existed. In france, coal mines almost owned the lifz of their worker : when they shop, where they slept, etc. News were only on a few newspapers or tv channels linked to the same top people, one source of info to tell you what to think, do and to buy.

The government has always collected a lot of infos to.

Before that, the church did. They polished the global personnal data collection but called it confession. They mastered the ad, it was for all people to see on sunday. Very useful for population control and black mail.

So unless people learn to see the red flags and react, the next wolf will it the sheeps like always.

</comment></comment></comment></comment></comment><comment><USER36> Made a jump to Firefox as primary browser on macOS this month. My setup involves heavy use of the new containers feature and a tree-style vertical tab panel, which AFAIK is unique to Firefox and offers neat visual browsing history.

Extension rundown:

— kesselborn's Conex, a Spotlight-like quick container switcher/tab finder. It's set to auto-hide tabs not in the current container, and I use it to routinely create one-off containers for specific tasks

— piro's Tree Style Tab, with a workaround setting to make it play well with Conex and a couple of custom styling rules

— MarsCat's Switch Container, which allows to re-open a tab in another container (used with caution)

What unblocked the switch for me:

— There's now a working tree-style tabs extension in Quantum

— The new Web Authentication API removes the need for Keychain integration in the long run

I'm wary of getting too used to a heavily customized setup, and am still figuring out the best way to back up my Firefox profile. Previously I relied mostly on stock Safari and Chrome, which is still great for its developer's tools.

<comment><USER37> > tree-style vertical tab panel, which AFAIK is unique to Firefox

For the major browsers, yes. Some Chromium off-shoots have them though.

<comment><USER36> I stand corrected, also I should've added "on Macs". I've been keeping an eye on Doogie[0], but its maintainer doesn't have the resources to maintain another build.

Curious if anyone can weigh in with similar alternatives available on macOS.

[0] [https://cretz.github.io/doogie/](https://cretz.github.io/doogie/)

<comment><USER37> You're talking to the maintainer :-) Yeah, I don't use Apple products so looking for someone to do the work. In the meantime, I am not too familiar with mac alternatives, but these days CEF, QtWebEngine, etc aren't that difficult to use if you want to roll your own (mine is just Qt + CEF).

<comment><USER36> Hey, that's unexpected and awesome! I hope to be able to help with the build after I upgrade to latest OS version.

Concepts on which Doogie is built sound very reasonable and I'm pretty sure they inspired my current setup. Native approach to bubbles vs. workspaces is better than shoehorning containers and tree-style tabs into that with a bunch of extensions in Firefox.

</comment></comment></comment></comment></comment><comment><USER38> You can also run multiple Firefox profiles at the same time, each with different extensions. Something like:

        $ firefox -ProfileManager -no-remote &

Also interesting:

[https://github.com/mozfreddyb/webext- firstpartyisolation](https://github.com/mozfreddyb/webext-firstpartyisolation)

[https://github.com/stoically/temporary- containers](https://github.com/stoically/temporary-containers)

<comment><USER39> You can also create and launch Firefox profiles in a running Firefox instance on the about:profiles page.

</comment></comment><comment><USER40> I have a similar need for Google. I have two gmail accounts. One is to preserve my privacy. But I can only open one at the time. That's acceptable since I forward mails.

But then, everything I do at Google is tracked and associated with this opened gmail account.

Once we are connected to Google, we are kind of logged in Google. They can track everything we do, even searches.

The problem I'm facing is that I can't keep the Google agenda opened for one user, and be connected to Google gmail as the other user. That's how far the "logging to Google" has got.

<comment><USER41> Why not use different browsers, like chrome and firefox, or, purely within firefox, different browser profiles?

<comment><USER42> Or, purely within the same Firefox profile, different containers? (I recognize that that's coming back to square one.)

</comment></comment></comment><comment><USER25> In my opinion Containers are the best thing in Firefox. I'm sacrificing battery life just so I can use them on my Mac.

I finally feel free to search for whatever I want and not have second thoughts.

<comment><USER43> > I finally feel free to search for whatever I want and not have second > thoughts.

Doesn't Google also link sessions through IP Address? That combined with "how you usually browse" \+ interests is a very powerful deanonymization tool.

<comment><USER25> You may be very right.

I haven't encountered any targeting related to search terms yet, but I'm sure they have the capability.

I do need to make the leap to DuckDuckGo at some point!

<comment><USER44> Making the leap to DDG was way easier than I thought and I am really pissed now that I didn't do it months ago. As other have said, you can generally find anything you want and, if not, you always have !g. However, I now have an intuition as to what sort of searches might yield good results. Either way, I encourage everyone to do it. Just change your search engine to DDG in your browser and, after a couple of searches, you will forget it's not Google.

</comment></comment></comment></comment><comment><USER45> Here's a link to when this was first appeared on HN (March 27): [https://news.ycombinator.com/item?id=16688681](https://news.ycombinator.com/item?id=16688681)

The comments have input from the add-on's author (groovecoder).

</comment><comment><USER46> Its funny with all the focus on Facebook, while Google tracking is so much more widespread

<comment><USER47> Google didn't elect Trump

<comment><USER48> Yeah, the American people elected Trump in an extremely rare case of the public taking back the election from corporate behemoths.

But let's pretend that Google hasn't had enormous sway over the White House and hasn't been rubbing shoulders with Obama and other Democrats [1][2][3][4]. Let's also ignore the fact that much of Silicon Valley publicly supported Hillary and opposed Trump, with big outspoken critics including Microsoft, Faceboook, and Apple.

It's a shame to see indoctrination stretching to users of this site such that people here legitimately believe that a bunch of Russians locked away in some computer lab single-handedly elected the only man who challenged the prospect of perpetually living under the oligarchical thumb of the Bushes and the Clintons.

[1] [https://theintercept.com/2016/04/22/googles-remarkably- close...](https://theintercept.com/2016/04/22/googles-remarkably-close- relationship-with-the-obama-white-house-in-two-charts/)

[2] [https://www.washingtonpost.com/politics/how-google-is- transf...](https://www.washingtonpost.com/politics/how-google-is-transforming- power-and-politicsgoogle-once-disdainful-of-lobbying-now-a-master-of- washington- influence/2014/04/12/51648b92-b4d3-11e3-8cb6-284052554d74_story.html)

[3] [https://www.theguardian.com/us-news/2015/dec/18/google- polit...](https://www.theguardian.com/us-news/2015/dec/18/google-political- donations-congress)

[4] [http://dailycaller.com/2017/08/09/google-higher-ups-love- don...](http://dailycaller.com/2017/08/09/google-higher-ups-love-donating-to- democrats-not-republicans/)

<comment><USER42> This is off-topic, and your idea of how Trump got elected is not the only — or even one of the popular — view.

Closer to the topic: what Facebook enabled was far more effective targeting, by agents not authorized by the targets, on a massive scale. That's a lot different than the "bunch of Russians locked away in some computer lab single- handedly elected" rhetoric.

<comment><USER48> It's as on topic as the parent comment. I have to yet to see even a single fact to back up your claim. If someone is going to spread disinformation and not present any facts, then I am going to post a sourced rebuttal. Feel free to change my mind with actual facts instead of undermining the voters who disagreed with your political outlook and then blaming the results on some ludicrous notion of a bogeyman.

<comment><USER42> Yes, your parent comment introduced the topic of Trump's election, though still in the context of online tracking. Pardon my poor choice of words above.

> I have to yet to see even a single fact to back up your claim.

Here's the first result from a Google search I just did: [https://www.wired.com/story/russian-facebook-ads-targeted- us...](https://www.wired.com/story/russian-facebook-ads-targeted-us-voters- before-2016-election/)

> If someone is going to spread disinformation and not present any facts, then > I am going to post a sourced rebuttal.

I don't see any sourced rebuttal.

> instead of undermining the voters

I didn't undermine any voters. I made no claims about any voters. I commented only on the targeting, and that the targets hadn't consented to their data being accessed.

> blaming the results on some ludicrous notion of a bogeyman.

A calmer rhetoric would be more productive to discourse. Targeted advertising is not a "bogeyman". Stolen data and privacy concerns are not bogeymen. That people put up lots of private info that can be used to accurately profile them is a fact. That ads can be effective has been proven from the time ads were invented, and that targeted ads can be even more effective — especially in a political context — has also been studied and concluded lots of times. See [1] and [2].

Frankly, now that you've brought up backing of claims, I'm a bit discouraged to have to defend stuff like this against clearly biased political rhetoric.

1: [http://politics.oxfordre.com/view/10.1093/acrefore/978019022...](http://politics.oxfordre.com/view/10.1093/acrefore/9780190228637.001.0001/acrefore-9780190228637-e-217)

2: [https://www.gsb.stanford.edu/faculty- research/publications/a...](https://www.gsb.stanford.edu/faculty- research/publications/advertising-effects-presidential-elections)

</comment></comment></comment></comment></comment></comment><comment><USER49> I've used a separate container tab for facebook in firefox (nightly) for some time now, along with uMatrix, uBlock origin, and privacybadger. I downloaded my info from fb a few days ago, and was pleasantly surprised at how _little_ info they had on me - they only have 2 advertisers with my contact info (email id). I click stuff on fb, but don't post, and occasionally have had message exchanges with friends.

</comment><comment><USER50> I did the same for many years, blocking third party cookies, having a different browser profile, but none matters.

Recently I downloaded all my fb data and I found that fb gives a tool to advertisers where they can upload my contact information to join all the dots.

The heading says "Advertisers who uploaded a contact list with your info"

[https://imgur.com/a/FRsUP](https://imgur.com/a/FRsUP)

<comment><USER51> That's kinda the opposite. The brands somehow had your info (from accounts you may have created with them, for instance), which they explicitly imported into Facebook specifically to show ads to you etc.

<comment><USER50> Yes, it seems like that, and thats what I am trying to say, that browsers are just one vector, users information is collected from number of sources: \- apps you use on your mobile \- your email/phone (example: which you gave to a Pizza company is same as of your fb) \- Your address which is with a local store nearby etc. etc.

All this information is collected to connect all the dots.

When I was going through the advertiser list, I was kinda shocked coz I never give my any detail to them, and still they have somehow uploaded it to fb. FB should ask the advertisers about source of data.

</comment></comment></comment><comment><USER52> Unsurprisingly there is no Google container for Firefox

<comment><USER53> You can use containers for any website / group of webistes.

The specific Facebook-only container extension is for people who don't want to hassle of organizing their containers themselves and only want one for Facebook.

<comment><USER54> Hey why is Firefox giving Facebook preferential treatment?

<comment><USER55> Preferential? Other than publicity, I'd say it's the opposite. Though I see your point.

</comment></comment></comment></comment><comment><USER56> I don't trust Facebook. I am 'aware' of the importance of privacy. I install 'Facebook Container' because I prefer to install an extension to keep Facebook kind of controlled than to delete my account.

It doesn't make sense to me. If you are so privacy concerned it seems to me that the step you should take is to delete your account but not to look for ways to avoid being tracked by the company you don't trust, although you use its services.

If this extension is not for Facebook users but for everyone, why don't implement it by default and for a lot of other websites?

<comment><USER57> > It doesn't make sense to me. If you are so privacy concerned it seems to me > that the step you should take is to delete your account but not to look for > ways to avoid being tracked by the company you don't trust, although you use > its services.

A lot of people I know use Facebook because they _have_ to. For instance, a friend of mine keeps track of job postings that are only posted in certain Facebook groups.

I would modify the argument such that if you're so privacy concerned, don't put any personal information on Facebook, and limit what Facebook has access to (which is what the container extension is doing).

</comment></comment><comment><USER58> Im using uBlock origin and PrivacyBadger, will this cover something Im missing?

<comment><USER53> PrivacyBadger might not block all trackers. Firefox containers "block" _all_ trackers (or rather, they allow all trackers but limit the information they can gather completely).

</comment></comment><comment><USER59> GNOME Web (Epiphany) lets you easily save a web page as web application, so that it gets an own desktop icon and browser profile to separate it from your normal browser.

</comment><comment><USER60> Heck yeah, I've been dreaming of this for a while. Or really, something that can work on _any_ website you configure it to work on, not just fb.

Or specifically, I'd love one that worked for google search (not neccesarily all google products, which would be hard, but one which let me search without being able to tie me to my other internet use including other google products).

<comment><USER61> Checkout Ghostery. It does a pretty good job with blocking trackers of any type. Ghostery is owned by a company that is backed by Mozilla, and claims to not share any data with third parties.

<comment><USER60> I've been using Disconnect, I may try Ghostery instead.

Disconnect inteferes with a lot of websites from working, and I think (like I think Ghostery which works similarly) does not do the same thing(s) that Firefox Containers do. I actually didn't realize the general Firefox Containers feature existed, and will also explore that more.

</comment></comment></comment><comment><USER62> They have the right intention. But how is this useful? As far as I can tell, it does not prevent FF from leaking information that helps FB generate a fingerprint. I'd still reveal the same IP address (would be cool if Mozilla provided a VPN that all FB traffic goes through), the same browser, the same OS, screen resolution etc...

</comment><comment><USER63> I'm glad they released this and hit got some headlines because I tried it, realized how necessary it was and then learned about Firefox containers in general.[0]

Now I'm using them for Gmail, Youtube, Twitter & FB. The three amigos, the internet bad guys. I really should just delete the last two accounts, but I feel a heck of a lot better now. I used to keep those in Microsoft Edge, a browser pretty much relegated to that dirty, social media duty alone. If I can use Firefox for everything, and cut off Google while I'm at it, even better.

[0][https://www.youtube.com/watch?v=Gy7lyvAfOSw](https://www.youtube.com/watch?v=Gy7lyvAfOSw)

</comment><comment><USER64> I hadn't used Firefox for anything practical in years except testing things of my own for compatibility. Now I launched it from a clean state, installed that extension and logged into Facebook... and it is still slow as molasses. It feels like downgrading the hardware to something 1/10th as powerful than what I'm used to. My point of comparison on this hardware is Safari, which I use for regular everyday default web browsing. It's not just Facebook on Firefox either; everything is sluggish and even typed text lags noticeably behind, which is something I hadn't experienced on anything since the iPhone 4 iOS 7 upgrade.

</comment><comment><USER65> Can't this be easily bypassed by Facebook? Given the amount of information usable to fingerprint browsers with JS enabled can't FB do some basic tricks like IP + WebRTC local IP + WebGL fingerprint + Canvas Fingerprint , etc...?

<comment><USER66> Yeah, their fingerprinting would be incredibly well trained, and I imagine would work perfectly well on sparser data.

</comment></comment><comment><USER67> This should be enabled by default in Firefox, as is the tracking in Facebook.

Hardly will Facebook care for the couple of hundreds that install and use something like this, but it will be much more efficient if browsers are pre- enabled with this feature.

<comment><USER68> It may not be completely legal for Firefox to do that. I don't know though.

</comment></comment><comment><USER69> Is this any different than Firefox's regular container support?

<comment><USER70> It's got Facebook in the name to ride the hate wave? I'm so glad Mozilla hired a Marketing team... /s

<comment><USER71> IIRC, this was just one engineer's side project to take their existing container tech, which might be too 'advanced' for most users, and make a one- off addon that more users might be interested in.

Do you think that Mozilla's marketing of Firefox as more privacy focused is a bad thing?

<comment><USER70> > Do you think that Mozilla's marketing of Firefox as more privacy focused is > a bad thing?

Not at all. This just strikes me as desperation, jumping on the hate train against Facebook because it's easy. Instead I'd like to see them actually develop their container functionality into a mainstream feature for the browser that might gain enough attention to make people start asking why Chrome, Safari, or Edge don't do the same.

I could see it very easily existing somewhere between the "New Window" and "New Private Window" menu options. They'd just need to rebrand it as something other than "containers" for the masses to understand it. "Private Window" would have been good but unfortunately that's been taken, in hindsight they should have gone with something that more clearly convey's the "burned after reading" forgetful nature of the private window because I think private conveys secret/isolated without the self destruction that comes with a Private/Incognito window..

People understand the Private/Incognito window, it wouldn't be hard to explain that a container window exists somewhere between a regular window and Private/Incognito. They could also easily surface or suggest sites you might want to containerize.

</comment></comment></comment></comment><comment><USER61> Have been using Ghostery on Safari for quite some time, and I dont see how this Facebook Container can be anywhere close to what Ghostery provides. The number of trackers on any website, is just mind blowing.

I believe Ghostery works with all browsers and I strongly suggest everyone use it, in addition to what ever ad blocker, container, VPN service you intend to use, even if you are using Facebook Container for Firefox.

<comment><USER6> Ghostery has a shady history of selling data it collects on you to advertising companies. The data collection feature was previously called Ghostrank, and now it's called Human Web. I'm not sure what Ghostery does with the data since it got acquired by Cliqz in 2017, but I'd be careful.

<comment><USER61> Wow, good to know! thanks for sharing this info. Will check and figure out what is a better alternative.

</comment></comment></comment><comment><USER72> why not just use the Private / incognito mode every time you want to use Facebook directly or indirectly?

That way any Facebook-owned service like logins and website comments plugin will work as expected but will not follow you around in your regular browser window!

________________________

From the extension page:

> "Clicking Facebook Share buttons on other browser tabs will load them within > the Facebook Container. You should know that using these buttons passes > information to Facebook about the website that you shared from."

> "Because you will be logged into Facebook only in the Container, embedded > Facebook comments and Like buttons in tabs outside the Facebook Container > will not work. This prevents Facebook from associating information about > your activity on websites outside of Facebook to your Facebook identity.

> In addition, websites that allow you to create an account or log in using > your Facebook credentials will generally not work properly. Because this > extension is designed to separate Facebook use from use of other websites, > this behavior is expected."

</comment><comment><USER73> They have a newer version that can handle custom isolated tab groups not just Facebook.

[https://addons.mozilla.org/en-GB/firefox/addon/multi- account...](https://addons.mozilla.org/en-GB/firefox/addon/multi-account- containers/)

<comment><USER74> The Facebook container is the "newer" extension, IIRC, released after the Cambridge Analytica news. Both extensions use an API called contextualIdentities: [https://developer.mozilla.org/en-US/Add- ons/WebExtensions/AP...](https://developer.mozilla.org/en-US/Add- ons/WebExtensions/API/contextualIdentities)

</comment></comment><comment><USER75> Looks like what it does is deleting a bunch of cookies.

If it only was that easy!

The real problem is not cookies.

I can already delete those.

The real problem is fingerprinting.

<comment><USER76> And all this talk of cookies leaves out html5 features like localStorage. Targeting only mechanism for tracking does not solve the tracking problem.

</comment></comment><comment><USER77> This might have been commented already, but: maybe have something similar for Google also? Now I'm not an expert, but ghostery/duckduckgo privacy essentials/ublock and so on "blockers" tell me that Google is responsible for a majority of the tracking

</comment><comment><USER78> Uh it says I'm on Firefox 52 and can't install this. But I'm on Firefox 59.

<comment><USER79> You probably have the privacy.resistFingerprinting preference set to true. This spoofs your browser version.

<comment><USER78> Yep that fixed it. Thank you!

</comment></comment></comment><comment><USER80> I'm in favor of putting Facebook in a container.

I further suggest to throw the container into a fire.

</comment><comment><USER81> What makes containers and other related things here better than just downloading something like PrivacyBadger and using some anti-tracking uBlock lists? I'm assuming it's because some things might still fall through the cracks?

</comment><comment><USER82> cool, but if anything tells me there's something wrong with permission systems it's this... the permissions it asked for, if that was any extension i'd be leery of it, but since this is from mozilla i trusted it..

</comment><comment><USER83> What I cannot find anywhere: how does this compare to Firefox' tracking protection feature? That would already block third-party requests to Facebook on other sites, wouldn't it?

</comment><comment><USER84> How in the world do you get this to work with subdomains in the general case? How do I just say "open all [sub]domains under example.com in their own container, end of story"?

</comment><comment><USER30> What about this is specific for Facebook?

Why not apply it to every website we visit?

</comment><comment><USER85> I don't use Facebook much but when I login I've been using Internet Explorer just for browsing Facebook. Otherwise IE would just sit there on my MS box.

</comment><comment><USER86> I would like to isolate every website I visit into a container, such that cookies or other tracking mechanisms are unable to be effective while on other pages.

<comment><USER87> What about ips?

<comment><USER88> To an extent, Tor can address this, though many sites make this exceedingly painful (Captchas, rate-limiting, outright blocking), and Tor itself is slow -- to set up, bandwidth, and latency.

I'm not sure if some middle tier of connection indirection, content caching- and-forwarding, or other mechanisms, might better address this.

There are protocols such as IPFS and browsers such as Min which might be a partial response to this:

[https://minbrowser.github.io/min/](https://minbrowser.github.io/min/)

</comment></comment></comment><comment><USER89> What's a Firefox container and why should I use one ?

<comment> dao- As the page explains: it prevents Facebook from tracking you across the Web.

<comment><USER89> No I read it, but I want to understand the technical details like how is this different from using Facebook in incognito window.

<comment> dao- Using Facebook in private windows only is a reasonable workaround that achieves roughly the same if you're disciplined. The addon is more user friendly.

</comment></comment></comment></comment><comment><USER90> Is the 'Facebook Container' extension different from I creating a new container myself and keeping only facebook in it?

</comment><comment><USER91> Half-OT: Somehow pages like dev.to or whatsapp always get opened in the default container, even if specified otherwise.

</comment><comment><USER92> for those wondering what's the difference between Facebook Container and Multi-Account containers:

[https://support.mozilla.org/en-US/kb/how-facebook- container-...](https://support.mozilla.org/en-US/kb/how-facebook-container- different-multi-account-con)

</comment><comment><USER93> Currently it is not about my privacy and data (those has been lost and given away far ago). It is about my time.

</comment><comment><USER94> > In addition, websites that allow you to create an account or log in using > your Facebook credentials will generally not work properly. Because this > extension is designed to separate Facebook use from use of other websites, > this behavior is expected.

As much as I love these kinds of things, this is going to break something for my less tech-y family. As such, I can't let them use this kind of thing.

<comment><USER95> Maybe you should can't let them use Facebook logins?

<comment><USER94> They have existing apps that wouldn't let them do that. I'm not about to control my mother's choices.

</comment></comment></comment><comment><USER96> I like this, but 2018 Internet is essentially needing this for _every_ website you visit.

</comment><comment><USER97> Time for a Facebook browser, I guess. Circumventing the middle man is the next logical step.

</comment><comment><USER98> Firefox Containers don't seem to work in Private Mode. Also Privacy Badger, btw.

<comment><USER99> How would you use Firefox Containers _in_ Private Mode? Private Mode is essentially a container that destroys itself when you close it.

<comment><USER98> Well, I didn't know that Private Mode worked as a container.

I thought it merely didn't store browsing history and cookies between sessions by default, while allowing tabs to share data between them for each session.

</comment></comment></comment><comment><USER100> Is there an advantage to this over Chrome Profiles, a feature built-into the browser?

<comment><USER101> See "How does this compare to the Facebook Container extension?": [https://addons.mozilla.org/en-US/firefox/addon/multi- account...](https://addons.mozilla.org/en-US/firefox/addon/multi-account- containers/?utm_source=blog.mozilla.org&utm_campaign=firefox_frontier&utm_medium=referral)

It is also my understanding that Chrome Profiles are per-window, while Firefox containers are per-tab.

</comment></comment><comment><USER102> can someone explain why this is necessary? shouldn't anything that happens outside of any site stay outside that site, why a special extension just for facebook?

<comment><USER103> Let's say you go to example.com and they're using a Facebook Pixel for analytics - so example.com can continue marketing that widget to you after you've left their site.

Well, when you visit example.com/shop/widget1 you essentially load a 1x1 pixel image from the url ads.facebook.com/pixel?metadata=goes-here and you web browser sends your Facebook cookie along side the request (as it does for every request to _.facebook.com).

So Facebook knows what site you've visited and what your interest are so that example.com can better market to you, their prospective customer.

The web relies on cookies so you can remain logged in, have a shopping cart, and do most everything else that is stateful (though sometimes this stuff gets implemented in the browser's webdata cache called localStorage). The container effectively makes the "session" - all data that is identifying - unique to the tab. So you couldn't open a second tab and remain logged in to your bank account, for example.

_the urls are examples; I'm on my phone, not on my laptop.

<comment><USER104> Can't the websites share that information with facebook by proxying that information? It'd be the same workaround as for ads if you host them it's very hard for someone else to block them, especially if you use dynamically named divs, image sizes etc.

<comment><USER103> No. You're not providing your Facebook cookie to the third party site. So, there is no way to associate your identity on example.com with your Facebook profile.

Think of it this way, if you have an authentication ticket, such as what is in a session cookie, then you have access to your account. If someone intercepted that ticket / cookie, they could maliciously act on your behalf and play around on your Facebook - just like you. Your browser therefore doesn't send cookies to domains that aren't specified as trusted by the originator of the cookie; I.e. third parties.

So example.com and Facebook wouldn't be able to associate the two identities.

*except of course through some interesting trickery like browser fingerprinting.

</comment></comment></comment></comment><comment><USER105> Great initiative. I'm wondering why no Google container?

</comment><comment><USER106> I need a Google container for firefox.

<comment><USER107> There you go: [https://addons.mozilla.org/en-US/firefox/addon/google- contai...](https://addons.mozilla.org/en-US/firefox/addon/google- container/?src=search)

</comment></comment><comment><USER108> i have deleted all facebook accounts. easy and clean solution. also i suggest to use several browsers to login google accounts and browse daily. therefore activities totally separated and tracking is getting hard with combination of cookie removal. etags are still big problem though.

</comment><comment><USER109> Up! Following.

</comment><comment><USER110> I normally avoid posting on threads like this, because there's more pile-on then there is coherent discussion, but I think there are some things missed here, and I want to elevate the discussion.

Let's take a step back for a moment from the fact that this is extremely one- sided, since there are many sites used all over the web which have a view on most of your browsing traffic, like Google Analytics (try and pry that from the cold, dead hands of administrators), to reddit, to other ad networks. I'll assume that the reader would just respond that we should do this for all sites.

Think a bit about the generalized business model of contracting out to third- party vendors. When you go the supermarket, it's very likely that the cash registers came from IBM (at least in the US). When you go to a restaurant, your payments are likely to be handled by Authorize.net (not to mention the credit networks), when you go to a hotel, the wifi is handled by some third- party company.

In each of these cases, there is a valuable service being provided to a company, and any service that has a large enough market penetration has access to a large amount of information about you. Third-party vendor relationships are not going to go away.

So what does this mean for the net? What effect will this have on the world? In the best case for anyone who thinks this is a good idea, it won't catch on, doesn't go mainstream, and a small amount of invisibility is granted to the few users who adopt this. But what happens if this were to become the default way the web works? Think about the wrench/security XKCD ( [https://xkcd.com/538/](https://xkcd.com/538/) ). If browsers started doing this, than the companies who depend on these services will just find other solutions. Already, many sites use url redirectors in order to accomplish this (think: Google Search), if we try to prevent redirects, then you break the web.

Okay, nuclear option, we decide to break the web, and require all users to manually confirm before doing redirects. There will be sites concerned enough about the drops in traffic that would be caused by forcing redirects that they'll stop using them. Does that mean this practice will stop?

Of course not! The next step is out-of-band network requests. You request data from a site, they ping the third-party, no muss, no fuss, and you're never the wiser. Well, what happens in that case? Suddenly, you go from a situation where companies are using third-party services via the browser, where the end user's interface to the third-party is entirely secured from the company receiving the service, to a world where all of this information is proxied the third party, meaning that instead of less companies being able to track you, suddenly more companies are able to track you.

I for one, hope that this does not catch on. Not because I care one way or the other about the tracking (I think there are better solutions _) but because I think this is an effort that will hurt both the web, and eventually users.

_ My thoughts on this: I find this akin to state surveillance. It's inevitable. The 'solution' to state surveillance is not hoodies and masks, but instead sousveillance (which means granting distributed surveillance powers to the masses, like way a large number of police issues came to light). Put the power in the hands of the people. How does this apply to web traffic? Same thing, instead of having traffic available to a few companies, make it scattershot, and make sure everyone has access. Surfing the web? Make browsers overfetch. DNS lookup for the letter p? grab everything from park to porn to production. That way, there is no loss of power

</comment><comment><USER111> Now do it for Google!

</comment><comment><USER112> Just as alternative, I am using this and it works great: [https://github.com/jmdugan/blocklists/blob/master/corporatio...](https://github.com/jmdugan/blocklists/blob/master/corporations/facebook/all)

(I don't use FB)

</comment><comment><USER113> Good start targeting one of the biggest offenders. Now make the next step implementing full blown ad blocker the way Brave has done it.

<comment> dao- Firefox has tracking protection. It's a pretty effective ad blocker for me.

<comment><USER111> That's absolutely wrong! Tracking protection just results in dumber ads. But they still clutter your pages and waste your bandwidth.

<comment> dao- That tracking protection is a good enough ad blocker for me is absolutely wrong? You do realize that tracking protection actually blocks ads, don't you?

<comment><USER111> I did not know that, sorry. I thought it blocks tracking cookies and stuff. Does it actually hide advert elements from the page? If yes, I can see how it can be good enough for most people.

</comment></comment></comment></comment></comment><comment><USER114> Stop "containing" Facebook, just quit it. These workarounds are just keeping you from facing the real problem: the time and mental effort spend on Facebook.

<comment><USER115> Quitting Facebook doesn't solve the problem that containing it solves.

</comment></comment><comment><USER116> Mozilla likes so much to trend, but this container wouldn't have done anything against the current Facebook leak.

<comment><USER117> It's not like they could have. They do what they can.

</comment></comment><comment><USER118> Firefox is one of the worst browsers in terms of security, so much malware just slips right through it, not to mention web designers don't bother testing on firefox much.

<comment><USER119> Citation?</comment></comment>