Chromium Blog: April 2012
COLLECTED BY
Organization:
Internet Archive
These crawls are part of an effort to archive pages as they are created and archive the pages that they refer to. That way, as the pages that are referenced are changed or taken from the web, a link to the version that was live when the page was written will be preserved.
Then the Internet Archive hopes that references to these archived pages will be put in place of a link that would be otherwise be broken, or a companion link to allow people to see what was originally intended by a page's authors.
The goal is to
fix all broken links on the web .
Crawls of supported "No More 404" sites.
A daily crawl of more than 200,000 home pages of news sites, including the pages linked from those home pages. Site list provided by
The GDELT Project
The Wayback Machine - https://web.archive.org/web/20181021050221/https://blog.chromium.org/2012/04/
Like with other multithreaded applications, debugging Web Workers may be a tricky task and having good instruments makes this process much easier. Chrome Developer Tools provides full debugging support for scripts running in both dedicated and shared workers.chrome://inspect page. Each shared worker listed there has inspect and terminate links next to its URL. These links allow you to launch a Developer Tools window attached to that worker or terminate the worker respectively.documentation or ask us a question on Google+ and our discussion group .Posted by Yury Semikhatsky, Software Engineer
Web browsers are big, complicated pieces of software that are extremely difficult to secure. In the case of Chrome, it’s an even more interesting challenge as we contend with a codebase that evolves at a blisteringly fast pace. All of this means that we need to move very quickly to keep up, and one of the ways we do so is with a scaled out fuzzing infrastructure.LKGR (Last Known Good Revision) , and hammers away at it to the tune of around fifty-million test cases a day. That capacity has roughly quadrupled since the system’s inception, and we plan to quadruple it again over the next few weeks.
Managing test cases and infrastructure - To run at maximum capacity we need to generate a constant stream of test cases, distribute them across thousands of Chrome instances running on hundreds of virtual machines, and track the results.Analyzing crashes - The only crashes we care about for security purposes are the exploitable ones. So we use Address Sanitizer to instrument our Chrome binaries and provide detailed reports on potentially exploitable crashes.Minimizing test cases - Fuzzer test cases are often very large files—usually as much as several hundred kilobytes each. So we take the generated test cases and distill them down to the few, essential pieces that actually trigger the crash.Identifying regressions - The first step in getting a crash fixed is figuring out where it is and who should fix it. So this phase tracks the crash down to the range of changes that introduced it.Verifying fixes - In order to verify when a crash is actually fixed, which we run the open crash cases against each new LKGR build.
security principles , we’re helping to make the web safer by upstreaming the security fixes into projects we rely upon, like WebKit and FFmpeg . As we expand and improve ClusterFuzz, users of those upstream projects will continue to benefit.Posted by Abhishek Arya and Cris Neckar, Chrome Security Team
The Dart team invites you to the first global Dart hackathon, a collaboration between the Dart team and the developer community. Sign up and have fun hacking on Dart to build modern client and server side web apps and libraries.
Current hackathon locations include:
North America:
Silicon Valley, California, USA
South America:
Europe and Middle East:
London, England
Prague, Czech Republic
Tel Aviv, Israel
Asia:
Bacolod City, Philippines
Chandigarh, India
Goa, India
Karnataka, India
Manipal, India
New Delhi, India
Seoul, Korea
Tokyo, Japan
Hackathon dates vary by location. Check out the full list for the schedule.
Dart project is still in technology preview, which means you’ll be hacking on early access code, but that’s all part of the fun. We’re eager to see what you build, and we hope you can make it. Register today !Posted by Seth Ladd, Developer Advocate
Last January, Chrome was the first major browser to preview WebRTC , HTML5's new real time audio and video stack. Since then, we've been hard at work keeping up with the evolving specification, fixing bugs and listening to the web community’s feedback.What's in: JSEP JSEP (Javascript Session Establishment Protocol) is an API for signaling that allows for much more powerful apps and flexibility in choice of signaling protocols. To abstract the complexity, we provide and maintain a Javascript lib that makes browser to browser calls a few lines of Javascript.Topologies ICE / STUN / TURN ICE and STUN are standardized methods for establishing a peer-to-peer connection on the Internet, even if the two end points are behind private network addresses (NAT). Chrome’s current stack deviates from the official current standards. We are working to fix this.DTLS-SRTP DTLS-SRTP .VP8, iSAC, iLBC, G.711 What’s next?
Data API . Implementation will start once the network stack is ready. Screen sharing . PeerConnection proxying . The ability to relay a stream to a third party will not make our first version. Recording . MediaRecorder specification work has not been completed yet.
Comments, questions, kudos or tomatoes? Let us know on our discussion list .Posted by Serge Lachapelle, Product Manager
