Wednesday, September 14, 2016

Angular, version 2: proprioception-reinforcement

Today, at a special meetup at Google HQ, we announced the final release version of Angular 2, the full-platform successor to Angular 1.

What does "final" mean? Stability that's been validated across a wide range of use cases, and a framework that's been optimized for developer productivity, small payload size, and performance. With ahead-of-time compilation and built-in lazy-loading, we’ve made sure that you can deploy the fastest, smallest applications across the browser, desktop, and mobile environments. This release also represents huge improvements to developer productivity with the Angular CLI and styleguide.
Angular 1 first solved the problem of how to develop for an emerging web. Six years later, the challenges faced by today’s application developers, and the sophistication of the devices that applications must support, have both changed immensely. With this release, and its more capable versions of the Router, Forms, and other core APIs, today you can build amazing apps for any platform. If you prefer your own approach, Angular is also modular and flexible, so you can use your favorite third-party library or write your own.
From the beginning, we built Angular in collaboration with the open source development community. We are grateful to the large number of contributors who dedicated time to submitting pull requests, issues, and repro cases, who discussed and debated design decisions, and validated (and pushed back on) our RCs. We wish we could have brought every one of you in person to our meetup so you could celebrate this milestone with us tonight!
Angular Homepage.png

What’s next?

Angular is now ready for the world, and we’re excited for you to join the thousands of developers already building with Angular 2.  But what’s coming next for Angular?


A few of the things you can expect in the near future from the Angular team:


  • Bug fixes and non-breaking features for APIs marked as stable
  • More guides and live examples specific to your use cases
  • More work on animations
  • Angular Material 2
  • Moving WebWorkers out of experimental
  • More features and more languages for Angular Universal
  • Even more speed and payload size improvements


Semantic Versioning

We heard loud and clear that our RC labeling was confusing. To make it easy to manage dependencies on stable Angular releases, starting today with Angular 2.0.0, we will move to semantic versioning.  Angular versioning will then follow the MAJOR.MINOR.PATCH scheme as described by semver:


  1. the MAJOR version gets incremented when incompatible API changes are made to stable APIs,
  2. the MINOR version gets incremented when backwards-compatible functionality are added,
  3. the PATCH version gets incremented when backwards-compatible bug are fixed.


Moving Angular to semantic versioning ensures rapid access to the newest features for our component and tooling ecosystem, while preserving a consistent and reliable development environment for production applications that depend on stability between major releases, but still benefit from bug fixes and new APIs.

Contributors

Aaron Frost, Aaron (Ron) Tsui, Adam Bradley, Adil Mourahi, agpreynolds, Ajay Ambre, Alberto Santini, Alec Wiseman, Alejandro Caravaca Puchades, Alex Castillo, Alex Eagle, Alex Rickabaugh, Alex Wolfe, Alexander Bachmann, Alfonso Presa, Ali Johnson, Aliaksei Palkanau, Almero Steyn, Alyssa Nicoll, Alxandr, André Gil, Andreas Argelius, Andreas Wissel, Andrei Alecu, Andrei Tserakhau, Andrew, Andrii Nechytailov, Ansel Rosenberg, Anthony Zotti, Anton Moiseev, Artur Meyster, asukaleido, Aysegul Yonet, Aziz Abbas, Basarat Ali Syed, BeastCode, Ben Nadel, Bertrand Laporte, Blake La Pierre, Bo Guo, Bob Nystrom, Borys Semerenko, Bradley Heinz, Brandon Roberts, Brendan Wyse, Brian Clark, Brian Ford, Brian Hsu, dozingcat, Brian Yarger, Bryce Johnson, CJ Avilla, cjc343, Caitlin Potter, Cédric Exbrayat, Chirayu Krishnappa, Christian Weyer, Christoph Burgdorf, Christoph Guttandin, Christoph Hoeller, Christoffer Noring, Chuck Jazdzewski, Cindy, Ciro Nunes, Codebacca, Cody Lundquist, Cody-Nicholson, Cole R Lawrence, Constantin Gavrilete, Cory Bateman, Craig Doremus, crisbeto, Cuel, Cyril Balit, Cyrille Tuzi, Damien Cassan, Dan Grove, Dan Wahlin, Daniel Leib, Daniel Rasmuson, dapperAuteur, Daria Jung, David East, David Fuka, David Reher, David-Emmanuel Divernois, Davy Engone, Deborah Kurata, Derek Van Dyke, DevVersion, Dima Kuzmich, Dimitrios Loukadakis, Dmitriy Shekhovtsov, Dmitry Patsura, Dmitry Zamula, Dmytro Kulyk, Donald Spencer, Douglas Duteil, dozingcat, Drew Moore, Dylan Johnson, Edd Hannay, Edouard Coissy, eggers, elimach, Elliott Davis, Eric Jimenez, Eric Lee Carraway, Eric Martinez, Eric Mendes Dantas, Eric Tsang, Essam Al Joubori, Evan Martin, Fabian Raetz, Fahimnur Alam, Fatima Remtullah, Federico Caselli, Felipe Batista, Felix Itzenplitz, Felix Yan, Filip Bruun, Filipe Silva, Flavio Corpa, Florian Knop, Foxandxss, Gabe Johnson, Gabe Scholz, GabrielBico, Gautam krishna.R, Georgii Dolzhykov, Georgios Kalpakas, Gerd Jungbluth, Gerard Sans, Gion Kunz, Gonzalo Ruiz de Villa, Grégory Bataille, Günter Zöchbauer, Hank Duan, Hannah Howard, Hans Larsen, Harry Terkelsen, Harry Wolff, Henrique Limas, Henry Wong, Hiroto Fukui, Hongbo Miao, Huston Hedinger, Ian Riley, Idir Ouhab Meskine, Igor Minar, Ioannis Pinakoulakis, The Ionic Team, Isaac Park, Istvan Novak, Itay Radotzki, Ivan Gabriele, Ivey Padgett, Ivo Gabe de Wolff, J. Andrew Brassington, Jack Franklin, Jacob Eggers, Jacob MacDonald, Jacob Richman, Jake Garelick, James Blacklock, James Ward, Jason Choi, Jason Kurian, Jason Teplitz, Javier Ros, Jay Kan, Jay Phelps, Jay Traband, Jeff Cross, Jeff Whelpley, Jennifer Bland, jennyraj, Jeremy Attali, Jeremy Elbourn, Jeremy Wilken, Jerome Velociter, Jesper Rønn-Jensen, Jesse Palmer, Jesús Rodríguez, Jesús Rodríguez, Jimmy Gong, Joe Eames, Joel Brewer, John Arstingstall, John Jelinek IV, John Lindquist, John Papa, John-David Dalton, Jonathan Miles, Joost de Vries, Jorge Cruz, Josef Meier, Josh Brown, Josh Gerdes, Josh Kurz, Josh Olson, Josh Thomas, Joseph Perrott, Joshua Otis, Josu Guiterrez, Julian Motz, Julie Ralph, Jules Kremer, Justin DuJardin, Kai Ruhnau, Kapunahele Wong, Kara Erickson, Kathy Walrath, Keerti Parthasarathy, Kenneth Hahn, Kevin Huang, Kevin Kirsche, Kevin Merckx, Kevin Moore, Kevin Western, Konstantin Shcheglov, Kurt Hong, Levente Morva, laiso, Lina Lu, LongYinan, Lucas Mirelmann, Luka Pejovic, Lukas Ruebbelke, Marc Fisher, Marc Laval, Marcel Good, Marcy Sutton, Marcus Krahl, Marek Buko, Mark Ethan Trostler, Martin Gontovnikas, Martin Probst, Martin Staffa, Matan Lurey, Mathias Raacke, Matias Niemelä, Matt Follett, Matt Greenland, Matt Wheatley, Matteo Suppo, Matthew Hill, Matthew Schranz, Matthew Windwer, Max Sills, Maxim Salnikov, Melinda Sarnicki Bernardo, Michael Giambalvo, Michael Goderbauer, Michael Mrowetz, Michael-Rainabba Richardson, Michał Gołębiowski, Mikael Morlund, Mike Ryan, Minko Gechev, Miško Hevery, Mohamed Hegazy, Nan Schweiger, Naomi Black, Nathan Walker, The NativeScript Team, Nicholas Hydock, Nick Mann, Nick Raphael, Nick Van Dyck, Ning Xia, Olivier Chafik, Olivier Combe, Oto Dočkal, Pablo Villoslada Puigcerber, Pascal Precht, Patrice Chalin, Patrick Stapleton, Paul Gschwendtner, Pawel Kozlowski, Pengfei Yang, Pete Bacon Darwin, Pete Boere, Pete Mertz, Philip Harrison, Phillip Alexander, Phong Huynh, Polvista, Pouja, Pouria Alimirzaei, Prakal, Prayag Verma, Rado Kirov, Raul Jimenez, Razvan Moraru, Rene Weber, Rex Ye, Richard Harrington, Richard Kho, Richard Sentino, Rob Eisenberg, Rob Richardson, Rob Wormald, Robert Ferentz, Robert Messerle, Roberto Simonetti, Rodolfo Yabut, Sam Herrmann, Sam Julien, Sam Lin, Sam Rawlins, Sammy Jelin, Sander Elias, Scott Hatcher, Scott Hyndman, Scott Little, ScottSWu, Sebastian Hillig, Sebastian Müller, Sebastián Duque, Sekib Omazic, Shahar Talmi, Shai Reznik, Sharon DiOrio, Shannon Ayres, Shefali Sinha, Shlomi Assaf, Shuhei Kagawa, Sigmund Cherem, Simon Hürlimann (CyT), Simon Ramsay, Stacy Gay, Stephen Adams, Stephen Fluin, Steve Mao, Steve Schmitt, Suguru Inatomi, Tamas Csaba, Ted Sander, Tero Parviainen, Thierry Chatel, Thierry Templier, Thomas Burleson, Thomas Henley, Tim Blasi, Tim Ruffles, Timur Meyster, Tobias Bosch, Tony Childs, Tom Ingebretsen, Tom Schoener, Tommy Odom, Torgeir Helgevold, Travis Kaufman, Trotyl Yu, Tycho Grouwstra, The Typescript Team, Uli Köhler, Uri Shaked, Utsav Shah, Valter Júnior, Vamsi V, Vamsi Varikuti, Vanga Sasidhar, Veikko Karsikko, Victor Berchet, Victor Mejia, Victor Savkin, Vinci Rufus, Vijay Menon, Vikram Subramanian, Vivek Ghaisas, Vladislav Zarakovsky, Vojta Jina, Ward Bell, Wassim Chegham, Wenqian Guo, Wesley Cho, Will Ngo, William Johnson, William Welling, Wilson Mendes Neto, Wojciech Kwiatek, Yang Lin, Yegor Jbanov, Zach Bjornson, Zhicheng Wang, and many more...


With gratitude and appreciation, and anticipation to see what you'll build next, welcome to the next stage of Angular.

Tuesday, September 13, 2016

RC7 Now Available

Today we’re happy to announce that we are shipping Angular 2.0.0-rc.7. This small release is focused on bugfixes.

What's fixed?

  • Lazy loading with webpack bundled projects
  • RxJS issues for developers using ES5
  • IDE Docs Integration - IDEs such as VS Code should now pull in the latest Angular Decorator documentation as reference
Read the full release notes

Wednesday, September 7, 2016

Angular 1.6 - Expression Sandbox Removal

Important Announcement

The Angular expression sandbox will be removed from Angular from 1.6 onwards, making the code faster, smaller and easier to maintain.

The removal highlights a best practice for security in Angular applications: Angular template, and expressions, should be treated similarly to code and user-provided input should not be used to generate templates, or expressions.
Removing the expression sandbox does not change the security surface of Angular 1 applications. In all versions of Angular 1, your application is at risk of malicious attack if you generate Angular templates using untrusted user-provided content (even if the content is sanitized to contain no HTML). This is the case with or without the sandbox and the existence of the sandbox only made some developers incorrectly believe that the expression sandbox protected them against such attacks.

What is the expression sandbox?

Angular puts an emphasis on the idea of separating business logic from user interface rendering. Application business logic should always reside in the code of controllers and components, where it can be unit tested effectively and more easily maintained.
Angular expressions were designed to allow a limited subset of JavaScript inside templates to support the basic logic that is necessary to be able to render the user interface. Angular templates encourage a clear separation of concerns between the simple logic used in rendering and the more complex logic of the application business domain.

The expression sandbox is a mechanism that checks Angular expressions to attempt to prevent accidental access to arbitrary JavaScript code and to discourage business logic from appearing in templates.

Why did we add the sandbox?

We added the sandbox to check that applications were not naively running JavaScript in their expressions since this implies that the template could be doing too much work. The aim was to provide feedback to the developer to prevent them from inadvertently designing applications that would be difficult to test and maintain.
Some time after the sandbox appeared in the codebase, a developer noticed that they could create an XSS attack to an Angular application if they had access to the template such that they could insert an arbitrary Angular expression. A number of these attacks were due to vulnerabilities in the sandbox combined with access to the template. Examples of these have been published on the web:
  • This blog post describes an attack that can be made if the template contains user provided content.
Initially we thought that we could tighten up the sandbox to prevent these attacks. But it became apparent that this was not an adequate defense: control of the Angular templates makes applications vulnerable even when the sandbox is completely secure:
  • This blog post shows a (now closed) vulnerability in the Plunker application due to server-side rendering inside an Angular template.
  • This blog post describes an attack, which does not rely upon an expression sandbox bypass, that can be made because the sample application is rendering a template on the server that contains user entered content.
The only effective security strategy is to ensure that users are never able to provide content that will be used in an Angular template, or expression.

As long as the Angular templates, and expressions, are not constructed using user provided content, there is no possibility of attack via these methods.

Why are we removing the sandbox?

While the sandbox was not a security defense mechanism, developers kept relying upon it as a security feature even though it was always possible to access arbitrary JavaScript code if a malicious user could control the content of Angular templates in applications.

Unfortunately we continued to patch up Angular 1 whenever people found new ways to undermine the sandbox despite the fact that it was not a defense mechanism.

These patches sent the wrong message to developers that they could continue to rely upon the sandbox for security, when they could not.

Removing the sandbox has the following benefits:

  • It clarifies to developers that Angular expression sandbox is not a security feature
  • It simplifies the parser codebase making it easier to maintain and extend.
  • It reduces the size of the parser codebase and therefore the size of the core Angular library distribution file (~1.3% smaller for angular.min.js.gzip).
  • It removes extra checks thus improving the speed and performance of Angular at runtime (~14% faster for complex expression parsing).
  • It provides opportunities to add further performance improvements to the parser.

You can view and comment on the Pull Request that removes the sandbox here.

What are the security implications?

If an attacker has access to control Angular templates or expressions, they can exploit an Angular application regardless of the version. There are a number of ways that templates or expressions can be controlled:

  • Generating Angular templates on the server containing user-provided content
  • Passing user-provided content in calls to these methods on a scope:
    • $watch(userContent, ...)
    • $watchGroup(userContent, ...)
    • $watchCollection(userContent, ...)
    • $eval(userContent)
    • $evalAsync(userContent)
    • $apply(userContent)
    • $applyAsync(userContent)
  • Passing user provided content in calls to services that parse expressions:
    • $compile(userContent)
    • $parse(userContent)
    • $interpolate(userContent)
  • Passing user provided content as the predicate parameter to the orderBy filter:
    • {{ value | orderBy : userContent }}

Each version of Angular 1 up to, but not including, 1.6 reduced the surface area of the vulnerability but never removed it.

If you dynamically generate Angular templates or expressions from user-provided content then you are at risk of XSS whatever version of Angular you are using.

If you do not generate your Angular templates or expressions from user-provided content then you are not at risk of this attack whatever version of Angular you are using.

See the Angular 1 security guide (once the PR has landed) for more information about the sandbox and possible vulnerabilities if you allow access to Angular templates.

What should I do?

If all your templates are static HTML files, or files that are generated without any user-provided input (e.g. using jade), and you are not generating any Angular expressions from user-provided content, then no action is needed and all the security measures provided by Angular are in effect.

If you dynamically generate Angular templates, or expression, using user-provided content then you should conduct a security review of your deployment and assess the risk that the user-provided content poses.

If you have to keep on using the user-provided content then the safest option is to ensure that it is only present in the part of the template that is made inert via the ngNonBindable directive. Be aware that you must ensure that all HTML is sanitized from the user content to prevent a malicious user from closing the tag containing the ngNonBindable directive and getting access to the rest of the template.

Size and performance comparison

Initial benchmarks of the removal show a small file size decrease and an increase in performance of the parser:

  • Gzipped size (angular.min.js.gzip) is 734 bytes smaller (1.3% smaller)
  • Complex expression parsing benchmark 76ms less time (14% faster)


Thursday, September 1, 2016

Angular 2 RC6


Angular 2.0.0-rc.6 is now available on npm! New in this release candidate:

The API surface is now final for all stable API symbols. This also means that previously deprecated APIs are removed in RC6.

For full details, see the CHANGELOG.md.

Faster Angular 2

Ahead of Time (AoT) Compilation

We’re really excited about the speed and bundle size improvements developers get when compiling applications ahead of time.  To take advantage of AoT compilation, you’ll need to install the @angular/compiler-cli and make a small addition to your tsconfig.json file.

  "angularCompilerOptions": {
    "genDir": "./ngfactory"
  }

Once you make this change, you can run the Angular compiler from the command-line, by typing ngc.

Then update your bootstrap from
import {platformBrowserDynamic} from '@angular/platform-browser-dynamic';
platformBrowserDynamic().bootstrapModule(MyAppModule)
to
import {platformBrowser} from '@angular/platform-browser';
platformBrowser().bootstrapModuleFactory(MyAppModuleNgFactory)

These two changes will get you started with using ngc and AoT, but we have more documentation and tools coming. Developers looking to try AoT may run into errors the first time they try - don’t panic! One of the benefits of the introduction of NgModules is that your code does not have to change based on whether you’re running in AoT or just in time (JiT) mode, so you can continue to be productive while we continue to improve these tools and work with third-party library authors to make sure code is AoT compilable.

ES2015 modules

In RC6, we’ve changed the output structure of our NPM packages to better enable tools like Rollup and Webpack2 to optimize your applications during bundling.

Each @angular/* package now contains:
  • “ESM” code - this is ES5 code with ES2015 style import/exports. This works great with Rollup and Webpack2 and allows more efficient tree shaking. This code replaces the commonJS source in the root of each directory.
  • A UMD bundle in the bundles/ directory of each package.
  • A new field in the package.json - “module” - that allows Rollup and Webpack to opt into using the ESM code.
For most users, this should work with no changes - but in case of any issues, here’s a list of config setups for various tooling: https://gist.github.com/robwormald/29f3dcda1a06b955d83fccb2a94586eb

If you’ve previously deep imported from @angular packages (e.g. @angular/core/src/foo/bar), note that this no longer works in RC6. Always import from the root of a package (eg, @angular/core). Deep imports are private APIs, and likely to change.