Joint 3D Face Reconstruction - <AUTHOR> https://github.com/YadiraF/PRNet <comment><USER2> The shortened HN title here is nonsensical.

In this context, "joint" means "together" or "at the same time". The work's title, "Joint 3D Face Reconstruction and Dense Alignment", essentially means "Face Reconstruction with simultaneous Dense Alignment". The HN title should mention both parts, or remove the word "joint".

<comment><AUTHOR> yep - my mistake.

</comment></comment><comment><USER3> University of Basel has some nice project for 3d Modeling. They also have a scala project for 3d face model construction using Gaussian Processes. All the recent 3d modeling papers use Basel Face Model.

[https://www.futurelearn.com/courses/statistical-shape- modell...](https://www.futurelearn.com/courses/statistical-shape-modelling/)

[http://gravis.dmi.unibas.ch/PMM/](http://gravis.dmi.unibas.ch/PMM/)

[https://github.com/unibas-gravis/scalismo-faces](https://github.com/unibas- gravis/scalismo-faces)

</comment><comment><USER4> New meme? [https://github.com/YadiraF/PRNet/raw/master/Docs/images/reco...](https://github.com/YadiraF/PRNet/raw/master/Docs/images/reconstruct.jpg)

</comment><comment><USER5> I just realized what this would be great for: Avatars in VR games. Snap a photo or video of your face and have it put straight into your character complete with animations. Excellent.

<comment><USER6> Check out an iPhone app called AffdexMe. It turns a photo into an animated 3d avatar in a few seconds.

I work in AR/VR and we are evaluating whether the iphone can be used for decent facial capture.

<comment><USER7> Isn't the answer already yes? [https://m.youtube.com/watch?v=i51CizUXd7A](https://m.youtube.com/watch?v=i51CizUXd7A)

I'd love to know what it's short comings are vs other solutions

</comment></comment></comment><comment><USER8> Wonder why it's written in Python 2.7 and not 3?

<comment><USER9> In my experience with scientists, they just use the tools that know how to use and have available. So maybe they just got the set-up for 2.7 on their personal/work computers or maybe some tool/library is using 2.7?

</comment></comment><comment><USER10> Nice project! I've been dabbling in DL for about a year (skimmed Stanford CNN course, Silver's RNN course, Andrew Ng's old ML course, etc.). While I can recreate basic stuff like MNIST, I don't feel like I can attack a problem like Pose estimation yet. How long does it take? Is it about diving deep into a single problem? Is it worth doing a nanodegree to shore up gaps?

</comment><comment><USER11> I wonder if this can be extended for the whole body, so as to produce a 3D scan of the skin, and measure the evolution of moles and skin issues.

<comment><USER12> >and measure the evolution of moles and skin issues

be still my heart!

</comment></comment><comment><USER13> Only white people used as examples. Might be useful to literally diversify your dataset.

<comment><USER14> This is somewhat ironic given that all five of the paper's authors are East Asian.

<comment><USER15> Fei Fei Li recently pointed out in a talk that if you search google images for "grandma" you get very biased results. They're all white grandmothers!

So it may be that the data sources the authors had are biased too. In any case this is an issue that should be addressed.

<comment><USER16> That made me wonder about what would happen if google started grouping concepts (eg words for grandmother in other languages will almost certainly give you differing results) rather than words...

Possibly (probably) the cognitive load on people might lead to bad A/B test results, but it would be a curious thing to explore - cultural bias would get a bit of a beating I'd imagine.

</comment></comment></comment></comment><comment><USER17> Good READMEs are important and this is a great example of a good README. The gif at the top alone instantly tells you a lot about what the project is about.

</comment><comment><USER18> Looking through the repo, anyone help me find where they put the vertices data that maps to image set?

</comment><comment><USER19> Have at it, deep fake geeks...</comment>


Show HN: Prison.news an aggregator for the prison industry/inmate families - <AUTHOR> https://www.prison.news/ <comment><AUTHOR> Thanks. Are other products deal with inmates families. There really is no where lack hacker news or a centralized site to get information like this.

</comment><comment><USER2> Nice!

</comment><comment><USER3> What a niche.</comment>


The Navy basically admitted that the littoral combat ship is a failure - <AUTHOR> http://www.businessinsider.com/us-navy-littoral-combat-ship-problems-2018-4 <comment><USER2> These are supposed to be small, cheap ships. Now they're being criticized for not doing everything. That's... odd.

US military in general goes through cycles where one vehicle is supposed to do everything (that way we can save money, just build one type of vehicle that can go anywhere, survive anything, do anything!) and then when that results in an ungainly, extremely expensive vehicle, they switch to multiple specialized vehicles (that way we can save money, just make each vehicle only do what is needed for a specific role and cut out the unnecessary bits!). Then when that results in vehicles specialized for role A that fail in role B, they switch back to the one-vehicle-does-everything plan.

Apparently we're on a "one vehicle do everything" upswing right now.

The parallels to software development are left as an exercise to the reader.

<comment><USER3> It wouldn't be all that surprising if they managed to make them just the wrong size.

(too big to really be cheap and too small to really do anything)

</comment></comment><comment><USER4> These business articles are always so vague. I learned very little. Why is it bad? It has bad radar? Why is a new ship going to be better? Can't you just install a better radar on these ships?

</comment><comment><USER5> I got a tour on one of the first two LCS ships a while back. It was pretty apparent that it wasn't fit for purpose.

One glaring example was that its hull could be Swiss-cheesed by a mere 50 caliber machine gun.

Another bad sign was that their proposed solution for dealing with small incoming boats was to drive the ship in a manner that swamped the enemy with wakes.

I understand the need to let R&D take risks, but I think LCS made it too far off the drawing board.

<comment><USER2> When was the last time a hostile .50 cal round struck a US Navy ship (any)?

Vietnam? _shrug_

<comment><USER6> The Narco Cartels will surely be terrified of any ship they can sink with an M2.

<comment><USER7> Narcos will not attack the US Navy because it is not about a single battle. They would not risk retaliation from the US military.

</comment></comment></comment></comment><comment><USER8> Compare with this new Russian patrol vessel:

[http://www.thedrive.com/the-war-zone/19796/russias-new- littl...](http://www.thedrive.com/the-war-zone/19796/russias-new-little- missile-packing-patrol-ship-is-a-pretty-genius-design)

 _...packed into a vessel displacing roughly 1,700 tons. In comparison, the Freedom class of Littoral Combat Ships, although faster, don 't pack anywhere near this must punch and they have over double the displacement. They likely cost far more per hull too—basically half a billion dollars each._</comment>


What's new in Swift 4.1 - <AUTHOR> https://www.hackingwithswift.com/articles/50/what-s-new-in-swift-4-1 <comment><USER3> Is this used outside the Apple eco-system much? I admit I haven't looked at Swift in 2 years or more.

I find the omission of features like namespaces really strange. I realize that namespaces don't jive with how Obj-C and Obj-C frameworks see the world and that Swift and Obj-C need to play together, but dealing with global namespace pollution and collisions in 2018 just seems...sad? They're hobbling the language in various ways due to NS*/Cocoa framework stuff.

Another weird omission is lack of any kind of concurrency story. Right now, this just seems like Apple's "me-too" version of Java/C#, but what does it actually bring to the table that would make it a worth-while investment if I'm not an iOS developer?

<comment><USER4> > Another weird omission is lack of any kind of concurrency story

Grand Central Dispatch (GCD or libdispatch) is generally the concurrency story on Darwin platforms. There has been an ongoing effort to port it to Linux. Not sure how complete that is but I linked the Github below. Swift on Linux still has a lot of rough edges in general.

[https://developer.apple.com/documentation/dispatch](https://developer.apple.com/documentation/dispatch)

[https://github.com/apple/swift-corelibs- libdispatch](https://github.com/apple/swift-corelibs-libdispatch)

<comment><USER5> A good read on the future of Swift concurrency is this from Chris Lattner, [https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...](https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782). I think currently still slated for Swift 5

<comment><USER6> This is going to be very interesting to watch. They decided to add concurrency after having built an extraordinary complex language. Something people like rob pike thought would be very hard to do (and as both a go and a swift coder, i must say i tend to think he's probably got a point).

<comment><USER7> The concurrency model was planned before the first betas but has been delayed. The devs always knew how they wanted concurrency to work.

<comment><USER6> I didn't know that, but i'm not surprised because chris lattner clearly knows what he's doing. I'm still curious to see how it ends up integrating in a language that's been evolving a lot since its design.

Saying that they managed to keep concurrency orthogonal to the rest of the language means Rob Pike was "wrong" (or at least what i understood from his point).

However, after reading the conversations around the async proposal, it seems to me on the contrary that it is very tightly related to other parts (such as error throwing mechanism, GCD library and syntax in general).

We'll see. I wish i didn't have the feeling swift core team is understaffed, because at least for iOS development it is really a joy to program with.

</comment></comment></comment></comment></comment></comment><comment><USER8> This is great news for developers who use Apple products.

I'm happy they're trying to improve the cross-platform story but I'm not sure I could ever completely trust the ecosystem when it's so tightly bound to MacOS/iOS (standard library still not complete, 3rd party libraries may only work or be well tested on Apple platforms, new features may take time to land on other platforms.)

<comment><USER9> > standard library still not complete

Define "complete." I would say if you count the Foundation library - <USER2> ships with Swift - as part of the standard library, things are pretty darn complete.

> new features may take time to land on other platforms

Not as far as Swift itself is concerned. Ever since Swift went OSS, new releases land for Linux and macOS at the same time.

<comment><USER8> There is a significant amount of functionality in Foundation unavailable on other platforms:

[https://github.com/apple/swift-corelibs- foundation/blob/mast...](https://github.com/apple/swift-corelibs- foundation/blob/master/Docs/Status.md)

<comment><USER9> Numbers-wise, yes. Day-to-day-usage-without-a-trivial-workaround-wise, no.

</comment></comment></comment></comment><comment><USER10> conditional conformance is a game changer.

<comment><USER11> Does that exist in other languages, a quick look doesn't show up anything for python/c++

<comment><USER12> Dunno about python (but then again it's a dynamic language...), and it's been an endless discussion for c++ AFAIK.

Other than that it's actually rather common in statically typed languages (except Go ;P). From the top of my head e.g. Java, C#, Typescript, Kotlin, Rust, Haskell all offer constraints for generics.

<comment><USER13> I think your comment is a bit… not sure what the word is, under-appreciating the feature? Over-selling some languages?

Because AFAIK Java (or C#?) does not have constrained _interface_ conformance, it only has bounds on functions (which Swift already had). That is you can say

        static <T extends Comparable<? super T>> void sort(MyList<T> list)

such that you can only sort lists of comparables, but you can't say

        class MyList implements Comparable<T extends Comparable<? super T>>

such that MyList implements comparable IIF its items are comparable.

<comment><USER12> Agh, yes. I already regret putting Java in that list with its wonky implementation. :)

But it certainly works with others, e.g. something like this:

        public class SortedList<T> : ICollection<T>,IEnumerable<T> where T : IComparable<T>

<comment><USER13> Is that C#? So it does have optional interface implementation? TIL.

<comment><USER12> Huh? I'm not sure where you're getting at.

<comment><USER13> I'm only asking if the snippet you posted is C# or something else, and noting that if it's C# I have learned something new about the language.

Except now that I look at it more specifically, it looks like a bound on the class's generic parameter rather than a condition on the interface implementation?

As in you're defining a SortedList class which implements ICollection and IEnumerable but requires T:IComparable, not defining a SortedList class which implements IEnumerable _if_ T is IComparable.

And if that reading is correct, Java can do it just fine:

        class SortedList<T extends Comparable<T>> implements Collection<T>, Iterable<T>

however it's got nothing to do with conditional conformance.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Implementing conditional conformances alone removed a lot of duplicate code from the standard library. I always like to think that the amount of gyb[^1] files in the source code is a good indicator of how far Swift is in its development.

[1]: gyb, a template processor, is a workaround for features that the standard library needs, but that are not (completely) implemented yet.

</comment><comment><USER15> Can anyone explain whats the reasoning behind renaming flatMap?

<comment><USER13> The SEP makes it pretty clear: [https://github.com/apple/swift- evolution/blob/master/proposa...](https://github.com/apple/swift- evolution/blob/master/proposals/0187-introduce-filtermap.md)

Basically, they did not rename flatMap they renamed _one specific overload_ :

        Sequence.flatMap<U>(_: (Element) -> U?) -> [U]

or in Haskell parlance

mapMaybe :: (a -> Maybe b) -> [a] -> [b]

which _filters_ after mapping more than it flattens (in fact the Rust and OCaml versions are called filter_map). The issue is that due to Optional promotion you could misuse flatMap (where you should have used map I guess) and could get this filtering behaviour unexpectedly instead of the straightforward mapping you would be expecting (it also led to extra branches and optional wrappings and unwrappings).

</comment></comment><comment><USER16> _" things that didn't work before will now"_

Just the words I want to hear when I upgrade my programming language by one minor version.

<comment><USER17> You are taking something out of context and commenting just to be snarky. This is not a case that you commonly use:

var left: [String?] = ["Andrew", "Lizzie", "Sophie"]

var right: [String?] = ["Charlotte", "Paul", "John"]

left == right

This works fine, for example:

var left: [String] = ["Andrew", "Lizzie", "Sophie"]

var right: [String] = ["Charlotte", "Paul", "John"]

left == right</comment></comment>


Why Are There No Mosquitoes at Disney World? (2018) - <AUTHOR> https://www.youtube.com/watch?v=_30jPKzWdN0 <comment><AUTHOR> > You see rather than blindly spraying insecticides over the entirety of the > property, which is twice the size of Manhattan, Disney instead uses various > methods to carefully track where and when to spray. The program maintains > over 60 traps across the area of Walt Disney World.

> They'll then bring those traps, filled with mosquitoes, back to a lab where > the mosquitoes are frozen to death and analyzed. The team looks at > everything from what kind of species they are, to their concentration, to > how old they are and how many of them were ready to lay eggs. By looking at > all this data for all of these traps, Disney is able to paint themselves a > picture of what parts of the property need the most attention when it comes > to eliminating the bugs.</comment>


The Z3 Theorem Prover released under MIT license - <AUTHOR> https://github.com/Z3Prover/z3 <comment><USER3> Amazing!

When I was prototyping a programming language with support for _contracts_ (or _refined types_ , e.g. `x : int if x > 0`), I tested a few different SMT solvers, including AltErgo, CVC and Yices (these seemed to be the most used open source solvers).

However, none of them were nearly as useful as Z3. In particular, they had no concept of a _stack_ that allows the user to define different assertions _locally_ , and then cancel them later. Without the stack, one would need to restart the solver and re-declare all variables (with all their constraints) for every function call with a constraint, compared to a single SMT script for each function verified in Z3.

Also, Z3 supports much more theories, in particular it supports non-linear integer arithmetics (which is an undecidable, incomplete theory), either by using some heuristics, or by translating the statements into the theory of real arithmetics (which is complete and decidable).

</comment><comment><USER4> For one example of why Z3 is cool, check out this application to "peephole" compiler optimizations: [http://blog.regehr.org/archives/1170](http://blog.regehr.org/archives/1170)

Also take a look at the "licensing" section to see why switching to the MIT license is a big deal. Even open source software projects like LLVM have had to worry about whether using Z3 was OK or not. Now they don't any more!

</comment><comment><USER5> I'm working with Z3 now, and it's been a real joy. One of the biggest advances in programming languages in recent years, perhaps. Glad to see it open-sourced and moved to Github.

<comment><USER6> Can you elaborate on what exactly do you do with it, and how?

<comment><USER7> I am not the OP, but I'm using Z3 in my research to help with the formal verification of hardware and firmware.

My problem is as follows. I have a microcontroller which runs firmware. I want to verify various things about the hardware+firmware combination. For instance, I may be interested in proving that user mode firmware cannot change the MMU configuration.

There are many parts to this problem. First is verifying that the kernel doesn't expose routines that let you do these kinds of things. This is a kind of s/w verification problem, somewhat well studied. Second, you want to make sure there are no h/w bugs in the microcontroller itself which the user mode software can exploit to do bad stuff. This is traditional h/w verification, also well-studied. The third is that there aren't weird corners of the microcontroller ISA specification itself which can be exploited. This is also a kind of h/w bug albeit a specification bug.

The third part is where Z3 comes in because often, there isn't any specification, and if there is, it's a bunch of PDFs or word documents. What we want is to generate a formal specification, which you can examine using formal tools to prove that it satisfies certain properties. And then we want to prove that our implementation conforms to this specification. We're using some techniques from program synthesis with Z3 as the solver for this.

<comment><USER8> Hi, I can't see an email address in your profile so sorry for the public message. With the lowRISC project [http://lowrisc.org/](http://lowrisc.org/) and related research at University of Cambridge we're becoming very interested in formal verification of hw+sw. I found this work out of Kaiserslautern interesting <[http://www-eda.eit.uni- kl.de/eis/research/publications/paper...](http://www-eda.eit.uni- kl.de/eis/research/publications/papers/DAC2011.pdf>). Could you say any more about your research? I'd be very interested in an email conversation - I'm at email@example.com

</comment></comment></comment></comment><comment><USER9> Note that the Z3 source code has been available for a while, but a commercial license was $10,000.

<comment><USER10> $ 10,000 seems like a magic number. Another Microsoft Research project, Detours [1] costs $ 9,999.95.

[1] [http://www.microsoftstore.com/store/msus/en_AU/pdp/Microsoft...](http://www.microsoftstore.com/store/msus/en_AU/pdp/Microsoft- Research-Detours-v3-Professional/productID.254378300)

<comment><USER11> Yes

It's cheap enough for a company to buy it without many signatures, but also on the upper scale of what people who "don't want Open Source" can pay.

</comment></comment></comment><comment><USER12> I hope they will open source Microsoft.Automata too, it was very useful for a project where I had to generate samples of strings that had to conform to multiple regex :

[http://research.microsoft.com/en- us/projects/automata/](http://research.microsoft.com/en-us/projects/automata/)

<comment><USER13> There are potentially patents on the code, e.g. [https://www.google.co.nz/patents/US8515891](https://www.google.co.nz/patents/US8515891) which discusses PEX + regex (mentioning SMT solvers).

</comment></comment><comment><USER14> Great project by MS research: good to see they picked a great license! See [http://rise4fun.com](http://rise4fun.com) for more great projects like that.

</comment><comment><USER15> Could someone who knows about these things, compare Z3 with the Google or- tools? ([https://code.google.com/p/or-tools/](https://code.google.com/p/or- tools/))

Pro's/Con's of the two?

</comment><comment><USER16> z3 is something I didn't know about until encountering it here. Spent the last few hours playing with the solver, it's quite interesting especially since I've had a fair amount of exposure to Scheme. Felt right at home after getting it up and running.

Glitch-free compiling and installing under FreeBSD. The only problem was finding documentation. Rise4fun.com is mentioned in another post, the exact URL for getting started is [http://rise4fun.com/Z3/tutorial/guide](http://rise4fun.com/Z3/tutorial/guide). Also, very useful information here-- [http://www.smt-lib.org/](http://www.smt- lib.org/)

</comment><comment><USER17> Could please someone informed explain how is this more restricted to only prove theorems, instead of being a more general prolog-like system?

From the Microsoft Research page, I read:

> _Z3 is a high-performance theorem prover being developed at Microsoft > Research. Z3 supports linear real and integer arithmetic, fixed-size bit- > vectors, extensional arrays, uninterpreted functions, and quantifiers. Z3 is > integrated with a number of program analysis, testing, and verification > tools from Microsoft Research._

And with my current knowledge (which is low on the matter) I can't reconcile arithmetic, arrays, quantifiers, etc. with general program verification...

<comment><USER18> Z3 is an SMT solver ([https://en.wikipedia.org/wiki/Satisfiability_modulo_theories](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories)). You can think of it like a SAT solver with extra optimizations for certain domains, so that it doesn't need to do bit-blasting to e.g. compare integers. SMT is NP-complete, just like SAT, but it is decidable (so the solver will "eventually" give you a yes/no answer, though "eventually" could be a long time).

This is in pretty stark contrast to Prolog, which includes features which make it undecidable. Therefore you can make Prolog loop infinitely, while that is not possible in an SMT solver.

<comment><USER19> Uhm you can throw diophantine equations after Z3 which certainly isn't a decideable problem. I have no idea whether it errs on the side of termination (i.e. not giving an answer) or non-termination (i.e. running forever).

<comment><USER20> The very first example on Github show that checking a conjecture results in one of 3 outcomes:

\- Unsatisfied (unsat)

\- Satisified (sat)

\- Unknown (unknown)

</comment></comment></comment></comment><comment><USER21> I've used model checkers before, but never SMT solvers. Looks really cool!

Anyway, here's a great post on solving a Project Euler problem using Z3/SMT- lib, which may be inspiring for other novices like myself:

[http://blogs.teamb.com/craigstuntz/2014/07/07/38818/](http://blogs.teamb.com/craigstuntz/2014/07/07/38818/)

</comment><comment><USER22> I heard Microsoft uses provers to check (automated verification) third party kernel mode device drivers. Is that the Z3 proofer? I searched on Google and got several results but the meaning of the term "kernel" is overloaded and means different things in operating systems and proofers/solvers.

<comment><USER23> This page says that the driver verifier uses the SLAM verification engine - <USER2> am not sure whether/how that is related to Z3:

[http://research.microsoft.com/en- us/projects/slam/](http://research.microsoft.com/en-us/projects/slam/)

<comment><USER24> SLAM2 uses Z3 for a few things, AIUI.

</comment></comment></comment><comment><USER25> This is really huge.

Maybe Idris or Coq integrate Z3.

<comment><USER26> One of the main devs of Z3, Leonardo de Moura, is acutally working on a new, dependently typed, theorem prover called "Lean": [http://leanprover.github.io/](http://leanprover.github.io/)

<comment><USER27> Is Lean an LCF system or Curry-Howard based? It seems to be the latter, but if so, what's it's main advantage over the many other Curry-Howard based systems?

</comment></comment></comment><comment><USER28> You can try Z3 online here: [http://rise4fun.com/Z3/](http://rise4fun.com/Z3/)

</comment><comment><USER29> This is a really great library. Thanks to Microsoft :).

</comment><comment><USER30> I wonder, does Code Contracts use Z3?

<comment><USER31> Code Contracts are just assertions. Pex can use them though and is built on Z3, iirc.

<comment><USER30> They seem to be more than assertions. You get warnings at build time and clearly some proving engine must be in use.</comment></comment></comment>


Elon Musk Wants to Put Up 40k Satellites, Bring Internet to the Whole World - <AUTHOR> https://www.popularmechanics.com/science/a32266155/elon-musk-spacex-starlink-internet-testing/ <comment><USER2> I thought this was already established for a while now

<comment><USER3> Last year it was 30K. The real news here is the beta timeline.

</comment></comment><comment><USER4> Hell ya</comment>


Mutation Testing: The Blind Spot in Your Testing - <AUTHOR> http://www.sealights.io/blog/mutation-testing-the-blind-spot-in-your-testing/?pi_campaign_id=2863 <comment><USER2> Important read to everyone who cares about software quality!</comment>


NASA's 'impossible' EM Drive works: German researcher confirms (2015) - <AUTHOR> http://www.physics-astronomy.com/2015/07/nasas-impossible-em-drive-works-german.html <comment><USER2> This paper (non-paywall version)[1] is from last August.

It's another one of those phenomenon that's so near the noise threshold that it's hard to measure reliably. They get forces around 70 μN. This is very small, and although they have a balance sensitive enough to measure it, there are lots of effects which can produce tiny forces like that.

The experimental work described in the paper is disappointing, in that the original cavity system apparently had a Q of something like 100,000, but their system only has a Q of 50, because it's mistuned for the microwave oven magnetron they're using. ("Unfortunately, the absorption peak at the resonance we were aiming at was smaller then expected (probably also due to misalignments after soldering).") The highest thrust reported by anybody with this is 720 mN, but that was in air. They're almost four orders of magnitude below that, in vacuum. For reference, the ion thrusters on the Dawn spacecraft deliver 90mN.

If they had hardware that generated 720mN in air, and tried that in hard vacuum, that would be useful. (In air, all sorts of things, such as heating or electrostatic repulsion, can generate air movement and thus tiny amounts of thrust. So results in air are not too interesting.)

[1] [http://moscow.sci- hub.bz/ded43880657f12f27fc596f46abbbfe6/10...](http://moscow.sci- email@example.com)

</comment><comment><AUTHOR> Paper cited by article does not confirm it works: "Our test compaign therefore cannnot confirm nor refute the claims of the EMDrive but intends to independantly assess possible side-effects in the measurement methods used so far"

[http://forum.nasaspaceflight.com/index.php?topic=38577.msg14...](http://forum.nasaspaceflight.com/index.php?topic=38577.msg1440938#msg1440938)

Wondering why didn't NASA send a EMDrive to space already and just see if it works or not on real conditions instead of testing it on a laboratory?

<comment><USER3> I imagine the cost coupled with the timeline of other experiments. It's certainly not a trivial thing to do.

</comment></comment><comment><USER4> Ok, so this article says:

> The EM drive is so thrilling because it yields enormous amounts of > propulsion

Yet IFL-Science says:

> What it actually does is produce a tiny, tiny amount of thrust via a method > that's not entirely understood.

I know which one I trust.. Can this be down voted for not been factual.?

<comment><AUTHOR> tiny, tiny amount of thrust during large, large amounts of time = enormous amounts of propulsion...

I know article is awful, sorry about that; submited only just because I wanted to read more comments about EMDrives on HN as I think they are cool; and the way HN works old threads are never seen again by most users...

<comment><USER4> haha, no need to apologise, this site is full of educated people who make up their own mind. I think I snapped a little with my comment (mid way building an iPhone App so stressed) Apologies.

</comment></comment></comment><comment><AUTHOR> [https://en.wikipedia.org/wiki/RF_resonant_cavity_thruster](https://en.wikipedia.org/wiki/RF_resonant_cavity_thruster) [http://forum.nasaspaceflight.com/index.php?topic=39004.0](http://forum.nasaspaceflight.com/index.php?topic=39004.0)

</comment><comment><USER5> A functioning massless drive is arguably as unlikely as a perpetual motion machine.

It's not really worth paying attention to claims that someone built one other than perhaps as entertainment value.

<comment><USER6> It IS a perpetual motion machine.

Stick a few of them on a generator's rotor so that they'll spin it when powered. Use the generated power to run them, and harvest the excess. Infinite free energy!

</comment></comment><comment><USER7>
      Best way to test the engine is for Elon Musk to make one and send it up on his rocket if it works then he can bring his timeline for mars down a few years.

</comment><comment><USER8> Can we get a [2015] tag?

</comment><comment><USER9> Oh cool, another crack pot physics post on hacker news!

<comment><USER10> If you have sure-fire evidence that this is indeed 'crackpot' then you should bring it forward otherwise you're offering an opinion minus pertinent observation or support. Perhaps I'm wrong but why should that be interesting enough to post here? Most of the British newspapers including the Guardian and Daily Mail provide an outlet for such comments.

</comment></comment><comment><USER11> tl;dr: no it doesn't; no it wasn't</comment>


Prisoners update Facebook statuses from Jail in India - <AUTHOR> http://ibnlive.in.com/news/jailed-murder-accused-update-facebook-kerala-home-minister-under-fire/437494-62-126.html

<comment><AUTHOR> Politicians can do any violence and wander around the country without being accused, and if they are arrested or put into jail, they can live in a way however they like ie, use phones,use internet,smoke weeds etc.

In the same country a person has been acquitted of stealing Rs 57 after 29 years.</comment>


Tremor-cancelling spoon for Parkinson's tremors - <AUTHOR> https://www.liftlabsdesign.com/ <comment><USER2> Things like this are just a total blessing to people who need them and its awesome to see affordable technology like this taking place for people who can't even take part in the one of the most important functions of life. A lot of people are talking about if there is a big enough market/etc, we should probably assume the creator only wants to cover his cost since this invention was probably created by people who had family suffering from such a thing. Any profits would probably make the inventor(s) delighted.

</comment><comment><USER3> I'm a little late commenting, but I developed a Windows app [1] that does exactly this for the mouse. It basically applies some fancy FIR filters to the x and y deltas. [1] www.steadymouse.com

<comment><USER4> Wonderful; like OS X's "Slow Keys" but for the mouse pointer instead. This should be included as a built-in accessibility option in every operating system.

Have you thought about open-sourcing your implementation to encourage others to take a jab at it and port it to other platforms?

<comment><USER3> Hey, thanks! I'd also love to see it built in to operating systems someday. It'd be much cleaner and easier to implement there as well. When I wrote steadymouse I had two choices: 1) Implement a driver (which is overkill if you ask me) or 2) Use a mouse hook in a very convoluted way (As is, the low level mouse hook doesn't easily let you "modify and pass on" mouse data). Applying DSP math to the mouse would be much easier within the OS. As for open sourcing the project, I've considered it and may eventually go that route. I'd like to clean it up first though and have the time to stay a part of the active development...maybe it's just hard for me to let go.

<comment><USER5> Thanks for the product, and thanks for considering to make it opensource. If you decide to go that route and have issues deciding what license to use, etc, please let me know, I can put you in touch with an expert in licensing, etc who can help you for free. And contribute code, ofc.

<comment><USER3> Wow, I really appreciate that! /I must admit, the community here really impresses me with comments like this.

</comment></comment></comment></comment></comment><comment><USER6> My brother has downsyndrome and struggles with muscle control. When he eats he tremors quite a bit losing food on his plate forcing him to take a desperate eat fast approach to his meals. He has gone through quite a bit of muscle therapy to help. Needless to say, I will be buying this for him and can't wait to see what other types of people find an improvement in their lives with this product.

</comment><comment><USER7> I think some will remember the news story that Sergey Brin has the Parkinson's mutation. He is keen to fund technologies that makes progress in this field. That would indeed be welcome. Diagnosing Parkinson's with confidence with a specific authoritative test is no easy task. For my dad, the doctors cannot decide if it is essential tremor or Parkinson's.

I recall a post on HN which showed that our vocal signals have enough information to help wwith such diagnosis. Voice as carried by phone's now dont have the spectral resolution for this. However it might have enough bandwidth if voice is coded for that purpose. Seems like a worthy problem to take a stab at.

I think the corresponding NPR story [https://news.ycombinator.com/item?id=7752627](https://news.ycombinator.com/item?id=7752627) was posted a few days ago but did not make the front page. So I am glad this made it.

<comment><USER8> This video left a deep impression on me:

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

I didn't realize how this sort of tech can be so life changing (or life giving)

<comment><USER9> That video is incredible to watch.

It is so amazing that I am slightly worried that it might be faked.

I really hope that this technology becomes an economically-viable and long- term means of helping parkinson's tremors.

</comment></comment></comment><comment><USER10> This is interesting, but IMHO, will not be as useful in most cases of Parkinson's disease.

1) Parkinsonian tremor is typically at rest or with distraction. When you actually engage in purposeful action, such as using a spoon, the tremor usually dampens or goes away.

2) The main problem in Parkinson's is actually "bradykinesia" or slowness of movement. A more accurate term, in my opinion, is slowness of motor planning, that is, the brain systems cannot process the information require to, and then generate, a plan of movement for the limbs fast enough. The spoon won't fix that.

3) Parkinsonian and other forms of tremor do have relatively safe and effective treatments in medications or deep brain stimulation implantation.

My thoughts are - this spoon, if it works and isn't a mechanical nightmare, would be useful in a limited subset of cases where the tremor resembles another condition known as essential tremor, where the tremor instead is an intention or action tremor, where purposeful activity amplifies the tremor. Even so, these would only be in those patients who cannot get deep brain stimulation surgery for some reason. The reason being that DBS, while brain surgery, once done, is the more elegant solution. I.e. your tremor goes away, rather than requiring a superficial "hack" like this spoon.

<comment><USER11> This is such an HN reply. Tear everything to shreds. Who cares if it "would be useful in a limited subset of cases where the tremor resembles another condition known as essential tremor"? Seriously, no one is forcing you to buy one. Be happy that people who are sick get the dignity of feeding themselves back. This is only positive. This can only get better. FFS...

<comment><USER12> > _Tear everything to shreds._

That's also called "constructive feedback" or "having something useful to say". OP offered his thoughts on the best cases where this technology could be applied while explaining how Parkinson actually works and how this limits the usefulness of this solution. If this is "such an HN reply", then this is also the kind of reply for which I come back to this site.

<comment><USER13> Lets just be clear... He recommended BRAIN SURGERY rather than a simple "hack" spoon.

<comment><USER14> Well, so would I. The spoon doesn't cure the symptoms.

<comment><USER15> I don't know the exact numbers, but I definitely feel like brain surgery carries a much higher risk with it than a new spoon. Some people might prefer not to take that risk, especially in cases of elderly people who may not be strong enough to survive surgery.

</comment></comment></comment></comment></comment></comment><comment><USER16> My grandfather has Parkinson's. My dad has slightly noticeable hand tremors - no diagnosis at this point. I haven't read up on the likelihood that I'll get it, but I assume that I'm at high risk.

That said, this looks pretty neat and seems like basically a spoon version of Canon AF lenses. Will definitely look into these for my grandpa :)

<comment><USER17> Likewise, my grandfather most likely had Parkinson's towards the end of his life. My father has had essential / familial tremor for 3 decades or so.

I did at one point did check out my genetic risk factors as determined by 23 and Me, back when they provided trait mapping services. Turns out I have a higher than average lifetime risk.

It's all ugly shit. Even essential tremor is non-trivial. I'm glad innovations of all kinds are being made in this field.

<comment><USER18> No shit. ET is set off by everything - exercise, alcohol, caffeine, lack of sleep, etc. In a perverse way it forces you to stop addictions to stimulants, otherwise you can't help but look 50 years older in front of friends and family because your fingers shake nonstop.

</comment></comment></comment><comment><USER19> Heard about this on All Things Considered this week: [http://www.npr.org/blogs/health/2014/05/13/310399325/a-spoon...](http://www.npr.org/blogs/health/2014/05/13/310399325/a-spoon- that-shakes-to-counteract-hand-tremors)

</comment><comment><USER20> This is wonderful!

I have to wonder - why is it that it took so long to come up with such a simple idea for such an obvious problem?

I'd like to blame it on the "get rich, web app startup" mentality, but really, that's a fairly recent thing.

Perhaps this is a harder problem than it seems? Or is it true that all our new inventors are chasing riches?

<comment><USER21> Many things are obvious once you've seen them done.

<comment><USER20> I realize that, and know my comment sounds naive - but.

We have people who study earthquakes, and gyroscopes, and nerve disorders. And we have the internet so they can all easily share ideas & research.

Is this idea REALLY so "un-obvious"?

<comment><USER22> Do we have people who study all three?

<comment><USER12> It _is_ , in my opinion, an obvious solution. Or at least it should be for anyone who took control theory classes (or learned it by itself). So I guess is that a/ people who know engineering don't know what medical problems are, and (more likely) b/ there's a long, long way from an idea to working product.

<comment><USER23> Don't mean to put too fine a point on it, but could you give me any example of a consumer solution throughout history that you would not class as obvious? I'm wondering what your standards are.

</comment></comment></comment></comment></comment></comment><comment><USER24> This sort of filtering should also be put in a mouse driver

<comment><USER22> Apparently user gottebp did just that: [https://news.ycombinator.com/item?id=7753993](https://news.ycombinator.com/item?id=7753993)

</comment></comment><comment><USER25> As a sufferer of early onset parkinson's, it's great to see products like this being developed. Hats off.

</comment><comment><USER26> I would like to "sponsor" a few of these for folks. Does anyone know of a resource, non-profit, or...something that can help facilitate that?

<comment><USER27> Their homepage says they match dollar for dollar for those in need. Get in touch with them.

</comment></comment><comment><USER28> My grandfather had parkinsons and this would have been a true blessing to him. I watched in frustration many times as he had a hard time doing tasks like this.

Seeing this kind of GOOD being invented makes me happy. This made my day.

</comment><comment><USER29> I wonder why wouldn't be possible to use some kind of passive method for tremor cancellation, like a miniature version of a steadicam. [http://en.wikipedia.org/wiki/Steadicam](http://en.wikipedia.org/wiki/Steadicam)

</comment><comment><USER30> I like the idea, but I think the spoon is a bit shallow. It would be hard to eat soup with it.

<comment><USER31> There's multiple attachments for the spoon. One of them might be a larger spoon.

</comment></comment><comment><USER32> Well done, Really great work!

</comment><comment><USER23> Let's entertain the notion, prevalent here, that this idea itself (like all ideas themselves) is worth absolutely nothing, and that any one of the teams in the world who have access to gyroscopes, servos, and microchips, _should_ have the right to reproduce this hack at unit cost and drive these guys out of business. Its cost is listed at $295.00[1] and this is their only product. It's huge compared to what the best facilities and teams in the world can produce to the same specifications, relatively unaesthetic as a utensil in its present form as compared to what a better-funded team can produce in a matter of weeks, and is clearly first-generation. They have no brand in the medical space. It is an eating utensil, yet it is not waterproof.

It is, however, patented.[2] This single fact allows this company (in its present form) to exist, to have done its research, to have raised its investment, and to bring their prototype in the form we currently see to market, at the price that it is currently listed at.

But patents are "wrong" and "stifle innovation".

Granted it's pretty obvious that this makes a huge difference in people's lives. So perhaps we should leaven our desire that their margin disappear, with hoping that more teams are somehow magically and irrationally in a position to do the world's R&D before losing their shirts as their margins disappear from under them. Having seen the size of this thing, the fact that it's not waterproof, the lack of an existing trusted brand-name behind the product, and a lack of any distribution except their web site (see their FAQ) shows that there is no way that is the best that any team in the world can build now that they've seen how it's done. Therefore, lacking protection, this team would no longer be competitive in a short number of weeks/months.

We can, however, agree that it is good that this has been made. So, how shall we reconcile this? Well, perhaps we should simply hope that funding, such as they have raised, would magically continue to be available even without any any margins that are guaranteed in the results (should they succeed in embodying their claims), which would allow the investors to recoup their investment. In short, we need investors to be crazy enough to keep funding innovations such as this one, while we remove the protections that would justify that craziness. Basically, we would have to hope that investors never catch on.

This is crucial for our purposes, as otherwise ideas such as this would not exist. Someone could have had this idea in 1999 or 1989. But without the investment, it might have stayed at the "worth-nothing" idea stage, rather than what we might call the "worth-nothing-but-has-now-actually-beend- developed-and-actually-been-built-and-proven-and-it's-no-longer-a-pipe-dream" worth-nothing stage. Which the rest of us deserve to access for free without investing anything.

There is an analogy to be made here with Tesla, who died nearly penniless: his meager earnings had come from his patent royalties. Imagine if we had the ability to rewrite history and take even this away from him, along with the food from his stomach and equipment from his labs, so that Edison and the rest of the world's teams would have full access to all of his inventions, working or impractical, without any protection. Imagine what progress that would have led to.

In summary:

1- ideas like this deserve no patent protection

2- teams should prove incredibly speculative techniques such as this for free and with no compensation or protection

3- investors should continue to invest in such ideas forever, even after it becomes abundantly clear that there is no way to recoup the investment in such a fledgling idea.;

</sarcasm>

Just kidding!! Phew. I hope we can all agree how ridiculous the above position would be. It's great that these guys brought their patented, high-margin product to the world. All this _could_ have been done in 1984 - 40 years ago - if someone had had the 'wortheless' idea then -- and we would all have access to it today.

It took a team's phenomenal genius and dedication today to bring this to market, and the whole world will have it soon - unlike any of the Idea Sunday ideas that have no such protection, were never fully developed, and for which the entire program was crapped.

Here's to sane patents and to the progress they bring!

[1] [http://store.liftlabsdesign.com/](http://store.liftlabsdesign.com/) $ 295.00. Note that my estimated margin at this price: (for copycat) 98.64% margins - ex assumed "worthless" idea - assuming a COGS at scale of $4, which is enough for several batteries, gyroscopes, microchips, cases, what have you. If we assume a $20 cost of goods that margin shrinks to 93.22% gross profit, again excluding the idea (which we assume is "worthless") or its development (which we assume the world should have access to for free, now that they've proven it.)

[2] [http://www.cnet.com/news/smart-spoon-helps-stabilize- parkins...](http://www.cnet.com/news/smart-spoon-helps-stabilize-parkinsons- tremors/)

<comment><USER33> I didn't downvote you despite my almost reflexive tendency to downvote posts bitching about being downvoted.

That said, I was strongly inclined to ding you for the sarcasm. Any point you might have been trying to make is obscured by the cloud of superiority and smugness your tone radiates, and, personally, I find that both off-putting and un-constructive. You could most assuredly use this invention as a means of starting a discussion about crap patents — a position with which I probably even agree in this instance — without burying your point beneath your invective.

<comment><USER23> The fact that one of the responses, ronaldx, completely agrees with the point that I put in sarcasm, stating "The problem is that your sarcastic position sounds pretty good to me", shows that while the position seems smug and superior to you, it is actually a reasonable one around here.

The sarcastic part literally sounds pretty good to people here, and two posters have expressed agreement with it.

And look at the result. We have two very good comments agreeing with the sarcastic part (or denying its premise), and which we can now turn to.

<comment><USER33> Again, I'm not saying your position is wrong. I'm saying that your point is buried beneath your sarcasm and your ceaseless series of edits and revisions.

<comment><USER23> rosser: please bear in mind that while you are saying "I'm not saying your position is wrong", two respondents actually agree with the position taken in the marked "sarcastic part" :)

so this certainly identifies an avenue for discussion, even if you do not prefer this way of bringing it up.

<comment><USER34> Please keep in mind what the poster is saying then, despite your position being worthy of discussion your tone is stifling enough as to make further discussion unpalatable.

<comment><USER23> I believe it is the facts in this case that make the discussion unpalatable for certain posters.

For example, separately, I actually wrote to this company during the comment thread, and received a reply. I found their reply very informative and posted it to the main thread (here: [https://news.ycombinator.com/item?id=7753308](https://news.ycombinator.com/item?id=7753308)) with a simple statement which nobody could find objectionable. It is my impression that someone nevertheless managed to find the facts themselves objectionable.

<comment><USER35> What "facts"? The fact that it wasn't any company research, but actually university-funded? The fact that the inventor was doing a PhD, not working for free?

<comment><USER23> Yes, those facts among others. If anything these facts imply he "wouldn't have needed" his patents, in order to get funded and build the thing.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER36> Holy crap was I confused for a minute, I misread the title as "Tremor- canceling spoon for Pakistan's tremors." I was just thinking "there must be A LOT of earthquakes in Pakistan."

... Anyway this is a great invention, even if it's not intended to be used during earthquakes ;-)

</comment><comment><USER23> I made a point about the importance of patents for this invention, but it is better to receive it straight from the source: [http://imgur.com/Q99L8V3](http://imgur.com/Q99L8V3)

(the bottom just quotes my letter, already visible)

This product and company would not exist without patents on what amounts to an idea.

<comment><USER37> Huh? All your e-mail exchange proves is that he believed, at one point, patents were a good idea.

In fact, it doesn't even prove that: If a stranger approached me about my company's patents, you can bet I'd smile and nod say, "Yes, they're important", like he did -- regardless of what I actually believe.

Establishing a written record of anything else sounds like a great way to throw that investment -- valuable or not -- in the trash. Especially when the remark is made to someone like you who then turns around and posts it to the public!

As someone who both holds several patents _and_ has actually seen this device in person, I think you're trying way too hard to craft your point.

(throwaway because my anti-procrast is on, oh well)

<comment><USER23> Of course the email isn't meant to prove anything, I was just curious how long his development time took. I only asked about the length of time of development, nothing else, he volunteered the extra information, which is that he would not have been able to raise any money without them (including what sounds like a research grant) and that it was crucial to getting to market at all (or whatever he said).

As it's all in the past, I don't see that this would help his patent case today in any way. ("Please uphold the patent, because I really needed it back when it was just an idea" doesn't seem a convincing reason to uphold a patent today, as they are now on the market.)

So I read the information he volunteered as stemming from his experience and perspective, rather than his interests.

I also see projects fail completely every day which could have succeeded with a minimum level of patent protection on their narrow inventions. So there may be a built-in survival bias, and you will not necessarily hear about these projects, which fail to raise even a preseed research grant "round" to complete development, but are abandoned isntead.

Page Rank was also patented by Larry Page. In stark contrast to the view presented on Hacker News, ideas are extremely worthwhile and patents are one of the most important tools any entrepreneur has for getting to market with real innovation, which is unsure and costly, and requires people to buy in at a pre-revenue stage.

The mechanism patents due this via is a full monopoly for a limited time. We can see this in the price set on this invention (that we're discussing), which is a monopoly price and will be upheld due to the fact that competitors are not allowed in the same space.

In countries that do not acknowledge these patents, a $79 equivalent could appear shortly. It can even be objectively better. Nevertheless, this is the price we pay for this invention to exist at all, and but for the patent system this invention would not exist at all. (In reality.)</comment></comment></comment>


Adblockers Performance Study - <AUTHOR> https://whotracks.me/blog/adblockers_performance_study.html <comment><USER2> FWIW, Chromium devs have just responded[1] to the massive amount of feedback they got on the mailing list, like [2] and [3].

One of the main pain points raised was the lack of any way to dynamically add rules, as well as the low maximum number of rules allowed (30k). Seems they've decided to support dynamic rule addition, as well as increasing the number of rules, though probably not by orders of magnitude by the sound of it.

Proof is in the pudding though.

[1]: [https://groups.google.com/a/chromium.org/forum/#!topic/chrom...](https://groups.google.com/a/chromium.org/forum/#!topic/chromium- extensions/WcZ42Iqon_M)

[2]: [https://groups.google.com/a/chromium.org/forum/#!topic/chrom...](https://groups.google.com/a/chromium.org/forum/#!topic/chromium- extensions/hQeJzPbG-js)

[3]: [https://groups.google.com/a/chromium.org/forum/#!topic/chrom...](https://groups.google.com/a/chromium.org/forum/#!topic/chromium- extensions/veJy9uAwS00)

<comment><USER3> Hey, dislaimer: I worked on this study. Thank you for your comment.

To me this reaction from the Chromium devs is missing one of the most fundamental issues. I'm not fundamentally against the declarative API because of technical limitations; I am against it because it is a strong innovation lock. The current extension ecosystem is flexible enough to allow hundreds (maybe thousands) of people to actively work on privacy-enhancing extensions (ad-blockers, anti-tracking, etc.) and the technologies, heuristics, solutions to protect users' privacy on the Web are constantly evolving. The APIs are not used today the same way they were used 2 years ago. If Chrome decides to "freeze" the blocking capabilities of the browser into a declarative API that no one but Chrome devs can improve, they will be preventing people from finding new solutions to tracking and advertising (at least from extensions). It does not matter if they replicate 100% of the capabilities of today's ad- blockers, as long as it does not allow evolution and adaption it will become obsolete. There is precedent in this matter: Safari also has a similar API and it has been a _huge pain_ for ad-blockers developers. The reason is simple: Apple or Google do not have the same strong intensives that we have to continuously improve the blocking capabilities of the user agent. My fear is that this declarative API will be an ok-replacement for today's content blockers, but will not allow the same kind of fast paced development we benefit from today in the space of privacy extensions.

<comment><USER4> Speaking as a user (and early developer) of Safari's content blockers; I have almost never run into an issue with them. What kind of development do you fear will be stifled by Apple and Google not having incentives to improve the blocking (which I find somewhat strange in the former case, anyways)?

<comment><USER3> What I'm afraid of is the following:

* The blocking engine operated by either Safari or Chrome is a black-box and independent devs will have a harder time understanding it, tweaking it, improving it, debugging it.

* Chrome devs are now playing nicely and get feedback and propose some improvements to the APIs but there is no warranty this will happen again, or that they will invest time/energy in the future improving this part of the browser.

* It's harder to work with this API than a JavaScript code-base you control.

* Chrome seems a bit better here but for Safari the documentation is pretty poor.

* You also don't get feedback regarding the rules which matched on a page and this makes it harder to debug or give nice insights to users.

That's only a few points from my personal experience but I discussed multiple times with developers of other privacy-enhancing extensions/apps and we shared similar feelings.

<comment><USER5> > Chrome devs are now playing nicely and get feedback and propose some > improvements to the APIs but there is no warranty this will happen again, or > that they will invest time/energy in the future improving this part of the > browser.

I think this is especially true. It is somewhat similar to many other Google products like Maps and Translate. They start as a good free product, but as soon as they gain enough traction the rules change. I think once this declarative Api is the standard for ad blockers in browsers Google will start exercising its control over it for its own benefit.

<comment><USER6> This is their long game. To me all the push Google did with https, and certificate pinning etc makes much more sense. I was wondering why they were pushing it so hard.

I mean after they essentially blocked ways to use proxy to filter the content, next logical step is to restrict API.

<comment><USER7> If you want to proxy your HTTPS traffic you add a local CA, and Chrome does not apply certificate pinning. Pinning is only for certs that chain back to the default CAs, specifically so people who need to proxy can do so.

(Disclosure: I work for Google, though not on Chrome)

<comment><USER6> Sure, but then you're still at the mercy of the browser.

The API change is totally unnecessary, yet is happening despite many protests.

The concern is that it was performance and privacy issue, which looks like a total BS (even according to the link we are discussing).

The extensions are installed by the user, so what not let them decide what to do with their browser? If it's really a concern, I don't think anyone would oppose if google would educate user what API given extension is using.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> So Ghostery benchmarks and is the fastest? Fine. But Ghostery does not belong in that test at all. Of course it can be faster. It misses a lot of the most important features! Like custom lists. Totally an ad.

<comment><USER9> Scroll to the footer and you'll see that this is Ghostery's website.

I wouldn't really call promoting their own product on their own webpage an ad.

<comment><USER10> A rose by any other name would smell as sweet. Ghostery doesn't want their bias to be obvious to the non-discerning user because it's obviously an attempt to reclaim market share using dirty tactics.

<comment><USER11> Fighting one dirty tactic (manifest v3) with another, though. I'm more alarmed about the former.

<comment><USER10> If you're alarmed about Manifest v3, we welcome you into the Firefox fold.

Of course we've had our own issues with WebExtensions but since it's not politically motivated these issues will hopefully be resolved.

</comment></comment></comment></comment></comment><comment> move-on-by Thanks for the interesting read! Just right off the bat, I'm a little cautious of benchmarks done by Ghostery that happens to show Ghostery is incredibly fast. Not that anything else stood out to me as suspicious, just a comment. Perhaps they are The fastest _because_ they are benchmarking and have fixed bottlenecks.

Beyond all that, I'm a huge fan of ad blockers and use them as an attempt to reduce tracking and targeting and it's abundantly clear to me that they greatly speed up many webpages. The amount of junk that so many sites load, no doubt it even saves me data on my data plan.

It seems like common sense to not trust a company whose main income is based on advertising to be making decisions on ad blocking.

<comment><USER3> Thanks a lot for your comment. The project is open source and everything needed to run the study comparisons is available as well there: [https://github.com/cliqz- oss/adblocker/tree/master/bench/com...](https://github.com/cliqz- oss/adblocker/tree/master/bench/comparison)

We would be really happy to see people running the same benchmarks and try to reproduce the results!

<comment><USER12> Hi,thanks for this fast ad-block software. After I give it a try,it does not provide an option let me subscribe easylist or something like that.Then I open a website,lots of ads are still there,right click on ad image,there is no option to remove them.

From a user opinion,it may not ready for everyday using.

</comment></comment></comment><comment><USER13> > This work was motivated by one of the claims formulated in the Manifest V3 > proposal of the Chromium project: "the extension then performs arbitrary > (and potentially very slow) JavaScript", talking about content-blockers' > ability to process all network requests. From the measurements, we do not > think this claim holds, as all popular content-blockers are already very > efficient and should not incur any noticeable slow-down for users.

There's a few issues with the conclusion here. First, they article measures and discusses only the time required to block a single request. Modern web pages are issuing many, many more requests than that, like the 35 that this page issues. At median timings, that would put the DuckDuckGo blocker at almost 300ms, well within what humans can notice.

The second is that this API is not used solely by the popular content blocking extensions, but by a variety of other extensions. The Chome team's performance concerns likely stem from the fact that a user won't be able to differentiate the browser slowing down and an errant extension slowing down the network requests, and there are examples of extensions that use this API to issue additional network requests or do slow things down. If you cherry-pick the good citizens of this API to show that performance isn't a problem in general, you're not showing that performance can't or shouldn't be the reason, just that it isn't the reason for the fast good citizens. What this data could be used to argue is that imposing strict deadlines on the execution time of these extensions would allow the content blockers that the community cares about to continue to function as they do today while also placing a performance cap on bad extensions.

<comment><USER3> Thanks for the replay. Disclaimer, I worked on this study.

> There's a few issues with the conclusion here. First, they article measures > and discusses only the time required to block a single request. Modern web > pages are issuing many, many more requests than that, like the 35 that this > page issues. At median timings, that would put the DuckDuckGo blocker at > almost 300ms, well within what humans can notice.

That is true, but on the other hand the DuckDuckGo blocker is the exception here and they could likely improve this performance if it becomes their focus (one way would be to use one of the faster open-source alternatives). If you consider uBlock Origin, Adblock Plus or Ghostery, we see that even blocking 100 requests would not take much time (probably around 1 ms with Ghostery).

> The second is that this API is not used solely by the popular content > blocking extensions, but by a variety of other extensions. The Chome team's > performance concerns likely stem from the fact that a user won't be able to > differentiate the browser slowing down and an errant extension slowing down > the network requests, and there are examples of extensions that use this API > to issue additional network requests or do slow things down. If you cherry- > pick the good citizens of this API to show that performance isn't a problem > in general, you're not showing that performance can't or shouldn't be the > reason, just that it isn't the reason for the fast good citizens. What this > data could be used to argue is that imposing strict deadlines on the > execution time of these extensions would allow the content blockers that the > community cares about to continue to function as they do today while also > placing a performance cap on bad extensions.

There are indeed examples of extensions doing bad things: collecting private data, etc. But we are talking about diminishing the potential privacy protection of _all_ users to prevent some abuse. On the other hand, the manifest v3 will not prevent extensions from being slow, or doing bad things. Extensions will still be able to use content-scripts, inject arbitrary content in pages or send any private data home. WebRequest listeners will also still be accessible (only not in blocking mode) which can allow any data collection.

So yes, I think these changes could in theory prevent some cases of abuse, but I strongly believe that they will overall weaken the privacy protection of users and that this is not an acceptable trade-offs.

<comment><USER4> > On the other hand, the manifest v3 will not prevent extensions from being > slow, or doing bad things. Extensions will still be able to use content- > scripts, inject arbitrary content in pages or send any private data home. > WebRequest listeners will also still be accessible (only not in blocking > mode) which can allow any data collection.

I can choose to not install extensions that do these things, while using ones that only have a manifest list…

<comment><USER3> I agree with you, and that's why I would like to see this declarative API being an addition to the current WebRequest API. This way there could be extensions using it exclusively and users could decide to pick these if they offer sufficient privacy protection for their taste. On the other hand, you would still have the option of installing more powerful extensions using the dynamic APIs (allowing things which will _never_ be possible with the declarative API).

<comment><USER4> Yup, I'm not saying that the old API should be killed; it's just that it's convenient to have the new one and be able to "trust" the extension to not be able to slow down my browsing, steal information from the page, etc. but also be able to fall back to something I _do_ trust for what gets through if necessary.

</comment></comment></comment></comment></comment><comment><USER14> > This work was motivated by one of the claims formulated in the Manifest V3 > proposal of the Chromium project: "the extension then performs arbitrary > (and potentially very slow) JavaScript", talking about content-blockers' > ability to process all network requests. From the measurements, we do not > think this claim holds, as all popular content-blockers are already very > efficient and should not incur any noticeable slow-down for users. Moreover, > the efficiency of content-blockers is continuously improving, either thanks > to more innovative approaches or using technologies like WebAssembly to > reach native performance.

Not commenting on if the proposed V3 changes are a good idea or not but aren't the changes not supposed to prevent badly written extensions from slowing everything down?

It might be the case these adblockers are well written but you can't guarantee that for all extensions. If a user doesn't have an obvious way to know it's the fault of an extension then Chrome gets the blame.

By the way, I have a Chrome extension that from its own tab requests many pages from arbitrary domains to examine their content. I need to modify the request headers going out and observe the response headers coming in, but only for requests made from the extension (so it's not impacting other tabs at all). I'm guessing V3 impacts this only if the request header modifications are dynamic and can't be added via the fetch API?

<comment><USER3> > It might be the case these adblockers are well written but you can't > guarantee that for all extensions. If a user doesn't have an obvious way to > know it's the fault of an extension then Chrome gets the blame.

It has been suggested in another comment that Chrome could give visual indications of the performance of extensions. They already do some of this to track the memory used.

</comment></comment><comment><USER15> Perfect way of showing that Google's performance argument is bullshit: just measure. And congrats on being faster than uBlock Origin, not an easy feat.

<comment><USER16> > _congrats on being faster than uBlock Origin_

I'd like to see a comparison against the WebAssembly build of uBlock Origin though. uBlock Origin uses WebAssembly in Firefox to speed up some functions. I'm not sure if Chrome allows add-ons to use WebAssembly yet.

<comment><USER15> Ah, that's an interesting point, did not know that it could not use WebAssembly in Chrome yet ([https://github.com/WebAssembly/content-security- policy/issue...](https://github.com/WebAssembly/content-security- policy/issues/7)). Would it be interesting to measure indeed, although the amount of wasm code there seems to be minimal so far.

<comment><USER3> As far as I know WebAssembly in uBlock Origin is currently used for two things:

1\. Matching the $domain option using an optimized Trie data-structure

2\. Parsing domains using the public suffix list, also based on a Trie data- structure

I would love someone well-acquainted with the uBlock Origin code-base to update the benchmark so that we can compare.

Edit: All the code to create the dataset (as well as the dataset used for the study itself) and to run the benchmark and analyze the results (create the plots, etc.) is available on the repository and should be reasonably easy to run locally.

<comment><USER17> The same code used to match the `domain=` option is also used to match all filters which are essentially just a plain hostname, i.e. `||example.com^` -- which is a majority of filters found in filter lists.

</comment></comment></comment></comment></comment><comment><USER18> Ghostery does not support custom external lists, which is why it is useless

<comment><USER12> True,I can't using local AD list,it doesn't work like adp or ublock,which is not user friendly.

</comment></comment><comment><USER19> Background: [https://bugs.chromium.org/p/chromium/issues/detail?id=896897...](https://bugs.chromium.org/p/chromium/issues/detail?id=896897&desc=2#c23) : a proposed change to Chrome that would limit adblock extensions.

<comment><USER20> It also screws over people who use Tampermonkey.

</comment></comment><comment><USER21> Worth keeping in mind here is that Ghostery is proprietary, while uBlock is free software. You should never trust proprietary extensions with your data.

<comment><USER22> Unless you audit the source of every piece of software you use as well as that of every compiler used in making their binaries, you aren't in a position to make that sort of absolute statement. OSS has benefits but for most users they are delegating the code review to someone else, which makes it very similar to proprietary code.

There is an argument to be made about motives with free vs non-free software, but open vs closed source is for most people much less important.

<comment><USER23> Transparency in software releases isn't all-or-nothing. The parent comment makes a good point about preferring more transparency (free and open source software) over less transparency (proprietary software) as a consumer.

However, the parent comment is a bit misplaced since Ghostery appears to be released under the Mozilla Public License 2.0.

[https://github.com/ghostery/ghostery- extension/blob/master/L...](https://github.com/ghostery/ghostery- extension/blob/master/LICENSE)

</comment></comment></comment><comment><USER5> This is great news, but I think most people already using ad blockers know that even slow ad blocker improves loading speed of web pages. Even if blocking a request takes 10ms, it's still a win when it block something like a tracker which records every click and mouse movement on the page.

</comment><comment><USER24> Can we not have editorialized title please?

<comment><USER25> Yeah... that's barely even what the article is about, based on a brief skim. They seem to disagree with what Manifest v3 is trying to accomplish, but the article doesn't even use the word "bullshit".

(Disclaimer: I work for a non-Google Alphabet company.)

<comment><USER26> Agree with the need not to editorialize, but that is indeed what the article is about. The entire impetus for measuring the performance impact of ad blockers is to disprove one of the two cited reasons for Manifest v3, namely that there are real-world measurable performance benefits to preventing ad blockers from intercepting web requests.

</comment></comment></comment><comment><USER4> > This work was motivated by one of the claims formulated in the Manifest V3 > proposal of the Chromium project: "the extension then performs arbitrary > (and potentially very slow) JavaScript", talking about content-blockers' > ability to process all network requests. From the measurements, we do not > think this claim holds, as all popular content-blockers are already very > efficient and should not incur any noticeable slow-down for users. Moreover, > the efficiency of content-blockers is continuously improving, either thanks > to more innovative approaches or using technologies like WebAssembly to > reach native performance.

I don't think it's valid to debunk this claim without testing the speed of manifest/content blocker list-based blocking.

<comment><USER27> I believe this article _does_ debunk the Google performance claim. It doesn't really matter if the "manifest" system is perfectly fast (exactly 0 seconds); this article shows that the current blockers are fast enough that they are indistinguishable from zero. There is limited room for improvement here (so limited as to be effectively none).

<comment><USER13> Again, it doesn't debunk it because the claim isn't "Current content blockers are not performant", it is that the API allows extensions to do things which cause performance issues, and there's a long tail of extensions that use this API and do create human noticeable delays. If you cherry pick performant examples and then try to debunk the whole landscape, it simply doesn't work.

<comment><USER27> > Again, it doesn't debunk it because the claim isn't "Current content > blockers are not performant", it is that the API allows extensions to do > things which cause performance issues, and there's a long tail of extensions > that use this API and do create human noticeable delays.

Both of these arguments are easily rebutted and have already been in this thread. As others have pointed out, the modified API still allows extensions to do things which cause performance issues, just not in that particular path. (Also, preventing ad load can improve page load performance so much that even a "slow" adblocker may make up the difference anyway.)

> If you cherry pick performant examples

I don't think these examples are cherry-picked; they're among the most popular adblockers in the landscape:

* [https://www.tomsguide.com/us/pictures-story/565-best-adblock...](https://www.tomsguide.com/us/pictures-story/565-best-adblockers-privacy-extensions.html)

* [https://www.digitaltrends.com/web/best-ad-blockers-for-chrom...](https://www.digitaltrends.com/web/best-ad-blockers-for-chrome/)

As others have pointed out, you can measure and break or shame poorly performing blockers without punishing the ones that work well. So:

> and there's a long tail of extensions that use this API and do create human > noticeable delays.

There's a long tail of extensions that are poorly behaved _in general_. You can punish those ones without killing the ones that don't suck.

</comment></comment></comment></comment><comment><USER28> I'm curious how filtering proxies like Privoxy, Proxomitron, Proximodo/Proxydomo, etc. compare --- it's an extra (local) hop of network latency, but those are pure native code. I've been using one for a long time (ever since I heard of them) and it effectively works across all the browsers on the system, even those built-in to other apps (often only for the purpose of showing ads...) Even for those who don't routinely use multiple browsers, given how increasingly user-hostile and unconfigurable they are becoming, I think it makes sense to move filtering into its own application.

<comment><USER29> The problem with those external HTTP filtering proxies is that the usage of SSL/TLS is pervasive nowadays.

<comment><USER28> At least some of those support MITM using a local CA.

</comment></comment></comment><comment><USER30> Ghostery is owned by an advertising company. It does not allow custom lists.

</comment><comment><USER31> I'm surprised that Brave performs so poorly. Isn't the whole point of having a dedicated privacy-aware browser supposed to be so that the ad/tracker blocking code can be written directly in C++ and not have to run in Javascript and talk over plugin APIs?

Maybe these results are only applicable to the desktop version of Brave?

<comment><USER32> Some things are very wonky with the experiment:

Brave is intentionally slow on parsing and do as much work there because it doesn't parse from client code, it only use already parsed lists from memory.

"The memory usage of Brave could not be evaluated using the devtools and thus is not included in this section." That doesn't make sense, I wonder if it's maybe using a very old version based on the old muon code base? If you can get the memory from Chrome you can get it from Brave.

No information was given about versions that were tested.

Total parsed rules is too small.

<comment><USER3> > Some things are very wonky with the experiment:

Thank you for taking the time to read this study. We do not think we claimed anything that was false in this study (although the scope might not be as wide as some would expect or desire); this is not a reason to be dismissive. We have ourselves a lot of respect for the work done at Brave.

> Brave is intentionally slow on parsing and do as much work there because it > doesn't parse from client code, it only use already parsed lists from > memory.

That was indeed one of the things measured, but not the most important one. In fact we explicitly say that this is a one time operation and does not necessarily matter, especially if as you suggest you can perform this work backend-side and ship the serialized version to clients. What is more interesting is the time it takes for matching requests.

> "The memory usage of Brave could not be evaluated using the devtools and > thus is not included in this section." That doesn't make sense, I wonder if > it's maybe using a very old version based on the old muon code base? If you > can get the memory from Chrome you can get it from Brave.

If we got this thing wrong we would be very happy to update the results with the correct measurements. The version we used was the latest version from `master` on the following repository: [https://github.com/brave/ad- block](https://github.com/brave/ad-block)

> No information was given about versions that were tested.

This is indeed unfortunate and we will be correcting this. The measurements were performed last week with the latest version of each projects but we should definitely indicate the exact version used.

> Total parsed rules is too small.

Too small for what exactly? Easylist is one of the most popular lists and it's pretty common to use it as a base-line for comparison. It is trivial to re-run the experiment with different lists given that all the code is open-source.

</comment></comment></comment><comment><USER33> You know what slows down browsing the internet?

Ads.

<comment><USER34> Javascript.

</comment></comment><comment><USER35> TIL: DDG has an adblocker. Good to know and I hope they can improve it.

</comment><comment><USER36> Only part of the argument with ad blockers is speed. The rest of the argument is trust. So, how do you make money?

As far as I know, ublock Origin has no profit motive whatsoever. Correct me if I'm wrong.

</comment><comment><USER37> Also, how about blocking on the DNS level? Why does this article concerned with in browser ad blocking only? I bet it is much less resource utilisation if you do it in lower layers.

<comment><USER38> DNS adblocking sucks because it takes too long to turn off when a website breaks because of ads.

<comment><USER37> On contrary, I do not want to use any website that breaks because of ads.

<comment><AUTHOR> Yes, that's another way to look at it. But it is not necessarily true for all the users.

<comment><USER37> I understand, I never implied that it is for all users, I was just mentioning that there are other options than JS ad filtering.

Btw. DNS based filtering works for non tech-savvy users like my parents who would certainly fall for malicious ads which are frequent even on Google. And guess how ransom-wares spread.

[https://www.zdnet.com/article/skype-served-up-malware- throug...](https://www.zdnet.com/article/skype-served-up-malware-through-in- app-malicious-ads/)

<comment><AUTHOR> Yes, I think there are certain domains specially spyware, malware that need to be blocked altogether and DNS blocking is the most optimal way for that, specially considering the wide adoption of IoT, where extensions cannot run.

</comment></comment></comment></comment></comment></comment><comment><USER39> > All benchmarks were ran on an X1 Carbon 2016 (i7 U6600 + 16 GB) in Node.js > 11.9.0.

They should test on average hardware and not on the top one. Take a 2013 year Celeron or Atom with 2 Gb of RAM and HDD and test on it.

Regarding privacy, I think the code that blocks network requests could run in an isolated environment so that it cannot send the information about requests outside.

<comment><USER40> I think it should be on a desktop class machine. I'm less concerned about absolute numbers and more with variance. Laptops generally cannot dissipate all the heat from full CPU usage for more than a minute or two. Benchmark runs, if they exercise the CPU hard for any length of time, get thermally limited and the results end up with substantially more variance.

Even things as simple as build times, I've seen vary by 20+%.

<comment><USER3> Benchmarking is always a hard problem - no such thing as spherical chickens in a vacuum. That said we'd love to at least standardize the setup for other people running the benchmarks; that is why we opened all the code and data, as a starting point.

For the study, measurements were run with one of our personal laptops (an X1 Carbon from 2016 with an i7 U6600 CPU and 16 GB of Ram, which is indeed a pretty powerful machine). We tried very hard to limit the impact of frequency throttling due to limited thermal dissipation of the device for the long- running benchmarks. In fact, for the measurements we put the laptop outside at 0 degrees Celsius, and we could observe that the CPU temperature did not go beyond 60 degrees (which is pretty low).

Do you have any suggestions on how we could improve this setup? We welcome all contributions.

</comment></comment></comment><comment><USER41> I don't see Firefox mentioned once in this whole article, so I assume it isn't meant for the sole browser I am using. Therefore this performance study is useless for me.

</comment><comment><USER42> Faster still is DNS-based, network-wide blocking with pi hole.

<comment><USER43> If that works for you, that's great. But it's a pretty crude tool. Kind of like wood carving with a chainsaw; some people swear by it and it's undeniably efficient, but other tools give you more delicate control. I wouldn't go without ublock origin's cosmetic filters which I use to block many things that aren't ads (such as those annoying floating bars at the top and bottom of the screen a lot of websites use just to annoy users (sorry, _" improve conversion"_) and waste vertical screen space.) uMatrix (and to a lesser degree, advanced mode in ublock origin) also lets you differentiate between blocking on first party or 3rd party. For instance I block youtube on every website except youtube.com

</comment></comment><comment><USER44> why is adblock not included?

<comment><USER3> Good point and we should certainly have mentioned it. AdBlock is using the same underlying engine that Adblock Plus is developing (adblockpluscore), which means they have the same performance when it comes to matching requests (there could still be differences in the extension itself but that was not measured in the study).

Source: [https://github.com/betafish-inc/adblock- releases#intro](https://github.com/betafish-inc/adblock-releases#intro) and [https://en.wikipedia.org/wiki/AdBlock](https://en.wikipedia.org/wiki/AdBlock)

</comment></comment><comment><USER8> Anyone notice who posted this? Ghostery did.

Look at that sub history..

[https://news.ycombinator.com/submitted?id=kkm](https://news.ycombinator.com/submitted?id=kkm)

They should be shamed. I'll make sure to tell anyone I see mention them to stay clear.

</comment><comment><USER45> Google, the worlds largest advertising company, abuse market share to crush those that would stand in their way. I stopped using Chrome when this was proposed, and you should too!

Article provides evidence that Google's pretext of performance doesn't hold water.

</comment><comment><USER46> This has to be one of the stupidest performance reviews I have ever seen.</comment>


The State of HTML5 Mobile Game Development - <AUTHOR> http://www.html5gamedevelopment.org/StateofHTML5GameDevelopment

<comment><USER2> Thank you! I've been doing some on and off research on this topic and was very discouraged, but this cheered me up. It was nice to see everything put together in one place...

</comment><comment><USER3> Best part about this presentation is the term "got a little Zucked". Zucked adj. Butthurt about the lack of progress on HTML5.</comment>