mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 12 uur 36 min geleden

Soledad Penades: webpack vs browserify

vr, 20/02/2015 - 10:10

I saw a project yesterday that was built using webpack, and I started to wonder what makes webpack better than Browserify? The website didn’t really explain to me, so I asked in Twitter because I was sure there would be a bunch of webpack experts ready to tell me—and I wasn’t wrong! ;-)

TL;DR

Webpack comes with “batteries included” and preconfigured, so you get more “out of the box”, it’s easier to get started, and the default outputs are really decent. Whereas with browserify you need to choose the modules you want to use, and essentially assemble the whole thing together: it’s slower to learn, but way more configurable.

Some of the most insightful replies:

@supersole it has way more out of the box, gives better control over optimizing how modules are bundled together. http://t.co/Xb81znvDn4

— James “Jimmy” Long (@jlongster) February 19, 2015

@supersole webpack is more opinionated, has more features in core (bullet point engineering). great if you dont like using npm search

— =^._.^= (@maxogden) February 19, 2015

@supersole It's much faster. Generates slightly smaller output by default. Custom loaders are easier to write.

— Kornel 「コルネル」 (@pornelski) February 20, 2015

Show me the data!

It really irks me when I get vague answers like “performance was better” but no numbers are provided. So I’m glad that the very awesome Kate Hudson indeed did some research for Mozilla’s Webmaker App, and so she could provide us with some numbers:

Webpack’s output can be from 8% to 16% leaner than Browserify’s (using uglify, which is pretty much the standard combination).

Of course this comes at a cost; Kate told me that generating the bundle takes longer with webpack, as it has to do more work than uglify does to get rid of dead code, etc. Also combining React with es6to5 and gulp and browserify didn’t really work well for them whereas webpack could take it easily.

I insist: this was a very specific use case. Your case might be totally different; don’t take this as a dogma.

Conclusion

I’m really used to Browserify even though I haven’t used probably 80% of its features. Maybe I’m missing out! But I don’t really need to change my tooling yet, I think.

On the other hand there are also some interesting features in Webpack like its ability to consume both AMD and UMD modules, and seems like it can also package static text easily whereas Browserify transforms are still a bit esoteric to me (yeeeah, I need to do my homework).

I always feel a bit unsure about introducing new tools, until there’s a certain mass of users (and they iron out the most terrible bugs too), but I will be keeping webpack on my radar.

Thanks to everyone that sent info! :-)

flattr this!

Categorieën: Mozilla-nl planet

Air Mozilla: Bay Area Rust Meetup February 2015

vr, 20/02/2015 - 05:00

Bay Area Rust Meetup February 2015 This meetup will be focused on the blocking IO system part of the standard library, and asynchronous IO systems being built upon mio.

Categorieën: Mozilla-nl planet

Manish Goregaokar: Superfish, and why you should be worried

vr, 20/02/2015 - 04:06
I'll be updating this post as I get more information .

For non-techies, skip to the last paragraph of the post for instructions on how to get rid of this adware.

Today a rather severe vulnerability on certain Lenovo laptops was discovered.


Software (well, adware) called "Superfish" came preinstalled on some of their machines (it seems like it's the Yoga series).


The software ostensibly scans images of products on the web to provide the user with alternative (perhaps cheaper) offers. Sounds like a mix of annoying and slightly useful, right?


Except to achieve this, they do something extremely unsafe. They install a new root CA certificate into the Windows certificate store. The software works via a local proxy server which does a man in the middle attack on your web requests. Of course, most websites of importance these days use HTTPS, so to be able to successfully decrypt and inject content on these, the proxy needs to have the ability to issue arbitrary certificates. It's a single certificate as far as we can tell (you can find it here in plaintext form)

It also leaves the certificate in the system even if the user does not accept the terms of use.

This means that a nontrivial portion of the population has a untrusted certificate on their machines.

It's actually worse than that, because to execute the MITM attack, the proxy server should have the private key for that certificate.

So a nontrivial portion of the population has the private key to said untrusted certificate. Anyone owning one of these laptops who has some reverse engineering skills has the ability to intercept, modify, and duplicate the connections of anyone else owning one of these laptops. Bank logins, email, credit card numbers, everything. One usually needs physical proximity or control of a network to do this right, but it's quite feasible that this key could be sold to someone who has this level of access (e.g. a secretly evil ISP). Update: The key is now publicly known

This is really bad.

Installing random crapware on laptops is pretty much the norm now; and that's not the issue. Installing crapware which causes a huge security vulnerability? No thanks. What's especially annoying is their attitude towards it; they haven't even acknowledged the security hole they've caused.

The EFF has a rather nice article on this here.

As far as we can tell, Firefox isn't affected by this since it maintains its own root CA store, however we are still trying to verify this, and will see if we can block it in case Firefox is affected, for example, if Superfish installs the cert in Firefox as well. If you have an affected system and can provide information about this, feel free to comment on that bug or tweet at @ManishEarth.

The application seems to detect Firefox and install some add ons as well as the certificate. We're looking into this, further insights would be valuable.

Superfish does NOT infect Firefox.

Chrome uses the OS's root CA store, so it is affected. So is IE.

 It turns out that internally they're using something called Komodia to generate the MITM; and Komodia uses a similar (broken) framework everywhere -- the private key is bundled with it; and the password is "komodia".

If you have friends at Microsoft who can look into this, please see if a hotfix can be pushed, blacklisting the certificate. Whilst it is possible for an "arms race" to happen between Superfish and Windows, it's unlikely since there's more scrutiny now and it would just end up creating more trouble for Superfish. The main concern right now is that rogue root CA cert is installed on many laptops, and the privkey is out there too. 


If you own a Lenovo laptop that came preinstalled with Windows (especially one of these models), please check in your task manager for an app called "VisualDiscovery" or "Superfish". Here's a small guide on how to do this. It's slightly outdated, but the section on uninstalling the program itself should work. Then, follow the steps here to remove all certificates with the name "Superfish" from the root store. Then go and change all your passwords;  and check your bank history amongst other things (/email/paypal/etc)  for any suspicious transactions. Chances are that you haven't been targeted, but it's good to be sure.

Categorieën: Mozilla-nl planet

Pagina's