Slashdot Mirror

Similar to Chrome, Apple's Safari browser is testing a warning system for when users visit websites that aren't protected by HTTPS encryption. "The feature for now is only in Safari Technology Preview 70, a version of the web browser Apple uses to test technology it typically brings to the ordinary version of Safari," reports CNET. From the report: Apple didn't immediately respond to a request for comment on its plans for bringing the warning to mainstream Safari. Apple's browser does warn you already if you have an insecure connection to a very sensitive website for typing in passwords or credit card numbers.

Adobe said on Tuesday it will stop distributing and updating Flash Player at the end of 2020 and is encouraging web developers to migrate any existing Flash content to open standards. Apple is working with Adobe, industry partners, and developers to complete this transition. From a blog post: Apple users have been experiencing the web without Flash for some time. iPhone, iPad, and iPod touch never supported Flash. For the Mac, the transition from Flash began in 2010 when Flash was no longer pre-installed. Today, if users install Flash, it remains off by default. Safari requires explicit approval on each website before running the Flash plugin.
In a blog post, the company wrote: "Adobe has long played a leadership role in advancing interactivity and creative content -- from video, to games and more -- on the web. Where we've seen a need to push content and interactivity forward, we've innovated to meet those needs. Where a format didn't exist, we invented one -- such as with Flash and Shockwave. And over time, as the web evolved, these new formats were adopted by the community, in some cases formed the basis for open standards, and became an essential part of the web. But as open standards like HTML5, WebGL and WebAssembly have matured over the past several years, most now provide many of the capabilities and functionalities that plugins pioneered and have become a viable alternative for content on the web. Over time, we've seen helper apps evolve to become plugins, and more recently, have seen many of these plugin capabilities get incorporated into open web standards. Today, most browser vendors are integrating capabilities once provided by plugins directly into browsers and deprecating plugins. Given this progress, and in collaboration with several of our technology partners -- including Apple, Facebook, Google, Microsoft and Mozilla -- Adobe is planning to end-of-life Flash. Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats."

Youenn Fablet, software engineer at Apple, writes: Today we are thrilled to announce WebKit support for WebRTC, available on Safari on macOS High Sierra, iOS 11, and Safari Technology Preview 32. [...] Currently, Safari supports legacy WebRTC APIs. Web developers can check whether their websites conform to the latest specifications by toggling the STP Experimental Features menu item "Remove Legacy WebRTC API". Legacy WebRTC APIs will be disabled by default on future releases. Websites that need to accommodate older implementations of the WebRTC and Media Capture specifications can take advantage of polyfill libraries like adapter.js. Peer5, a startup that offers serverless CDN for massively-scaled video streaming, writes in a blogpost: This is HUGE news for the computing industry. Since its introduction in 2011, WebRTC has become an incredibly important part of everyone's favorite platforms and applications. It is at the core of a few services that you might have heard of, including Google Hangouts, Facebook Messenger, Snapchat and Slack. WebRTC is also supported natively by most major web browsers, including Chrome, Firefox and Opera. But there were 2 big holdouts -- Microsoft's Edge browser and Apple's Safari. This meant that people using those browsers couldn't access WebRTC-based services without installing some type of plug-in. Well, those days are over given the WWDC news and Microsoft's announcement back in January regarding WebRTC support in Edge. Developers can now create compelling browser-based applications that incorporate real-time audio and video (and maybe even a peer-to-peer component) and know that 99% of the world's Web surfers will be able to use their services without having to install any plug-ins or additional software. This newfound ubiquity for WebRTC might even make a developer question whether he has to build a native iOS or Android app to deliver his service to end-users.

WebKit's bug-tracker now includes a comment from Friday noting "the bots all are red" on their git-svn mirror site, reporting an error message about a checksum mismatch for shattered-2.pdf. "In some cases, due to the corruption, further commits are blocked," reports the official "Shattered" web site. Slashdot reader Artem Tashkinov explains its significance: A WebKit developer who tried to upload "bad" PDF files generated from the first successful SHA-1 attack broke WebKit's SVN repository because Subversion uses SHA-1 hash to differentiate commits. The reason to upload the files was to create a test for checking cache poisoning in WebKit.

Another news story is that based on the theoretical incomplete description of the SHA-1 collision attack published by Google just two days ago, people have managed to recreate the attack in practice and now you can download a Python script which can create a new PDF file with the same SHA-1 hashsum using your input PDF. The attack is also implemented as a website which can prepare two PDF files with different JPEG images which will result in the same hash sum.

New submitter xogg writes: Battery Status API allows web sites to read the battery level of user's system. The API was found to bring privacy risks and abuse potential and a number of implementation bugs. Now with apparent no legitimate use cases, Mozilla is taking the unprecedented decision to vaporize a browser API due to privacy concerns. And apparently, WebKit, powering Apple's Safari follows. Is that the first time a browser reduces functionality following research reports warning of privacy risks?

Apple's web browser Safari 10, which will ship with macOS Sierra, will disable Flash, Java, Silverlight, QuickTime and other plug-ins by default. The move will help the company improve the overall web browsing experience by focusing on HTML5 content. From a post on WebKit blog, authored by Apple's Safari team: When a website directly embeds a visible plug-in object, Safari instead presents a placeholder element with a "Click to use" button. When that's clicked, Safari offers the user the options of activating the plug-in just one time or every time the user visits that website. Here too, the default option is to activate the plug-in only once.

An anonymous reader tips this post at Webkit.org: "Just a decade ago, JavaScript – the programming language used to drive web page interactions – was thought to be too slow for serious application development. But thanks to continuous optimization efforts, it's now possible to write sophisticated, high-performance applications – even graphics-intensive games – using portable standards-compliant JavaScript and HTML5. This post describes a new advancement in JavaScript optimization: the WebKit project has unified its existing JavaScript compilation infrastructure with the state-of-the-art LLVM optimizer. This will allow JavaScript programs to leverage sophisticated optimizations that were previously only available to native applications written in languages like C++ or Objective-C. ... I'm happy to report that our LLVM-based just-in-time (JIT) compiler, dubbed the FTL – short for Fourth Tier LLVM – has been enabled by default on the Mac and iOS ports. This post summarizes the FTL engineering that was undertaken over the past year. It first reviews how WebKit's JIT compilers worked prior to the FTL. Then it describes the FTL architecture along with how we solved some of the fundamental challenges of using LLVM as a dynamic language JIT. Finally, this post shows how the FTL enables a couple of JavaScript-specific optimizations."

stoolpigeon writes "Yesterday marked the release of Dart SDK 1.0, a cross-browser, open source toolkit for structured web applications. The Dart SDK 1.0 includes everything you need to write structured web applications: a simple yet powerful programming language, robust tools, and comprehensive core libraries. The language has been somewhat controversial, but Google continues to move it forward." Reader slack_justyb adds some more detail: "The new release brings a much tighter dart2js compiler reducing overall JavaScript output up to 40%; Dartium — a version of Google Chrome that has the DartVM in addition to the JavaScript VM as native to the browser; PUB, a package manager for Dart add-ons; and several favorite 3rd party plug-ins that now come out-of-box, in addition to a lot of work for Dart server-side tools that can work to automate server side tasks and help in the construction of web pages. However Dart has many critics not only from the IE and Apple camps, as one would guess, but from the Firefox and Opera camps as well. In addition to the low adoption of Dart from third parties there are some asking where does Dart go from here? Especially considering that Google is one of the strongest pushers for EcmaScript 6."

hypnosec writes "WebKit developers have already started discussing the removal of Chrome- and Chromium-specific code from the rendering engine in a bid to make the code easier to maintain. Just a couple of days back, Google announced it will go ahead with a WebKit fork to develop a new browser engine — Blink. According to Google, having multiple rendering engines — just like multiple browsers — will allow for innovation as well as contribute toward a healthy open-web ecosystem. The discussion was started by Geoffery Garen, an Apple WebKit developer. He said Google's departure is an 'opportunity to streamline' the code of WebKit, which would eventually make development 'easier and more coherent for everyone.' Garen expects that developers who will be working on WebKit in the future should help to clean up the code. However, Adam Barth and Eric Seidel — two Google WebKit developers — have already offered their help." Google plans on making the switch to Blink in the stable Chrome release in around 10 weeks. They've posted a half-hour video explaining how the transition will work.

hypnosec writes "WebKit developers have already started discussing the removal of Chrome- and Chromium-specific code from the rendering engine in a bid to make the code easier to maintain. Just a couple of days back, Google announced it will go ahead with a WebKit fork to develop a new browser engine — Blink. According to Google, having multiple rendering engines — just like multiple browsers — will allow for innovation as well as contribute toward a healthy open-web ecosystem. The discussion was started by Geoffery Garen, an Apple WebKit developer. He said Google's departure is an 'opportunity to streamline' the code of WebKit, which would eventually make development 'easier and more coherent for everyone.' Garen expects that developers who will be working on WebKit in the future should help to clean up the code. However, Adam Barth and Eric Seidel — two Google WebKit developers — have already offered their help." Google plans on making the switch to Blink in the stable Chrome release in around 10 weeks. They've posted a half-hour video explaining how the transition will work.

New submitter jgb writes "WebKit is, now that Opera decided to join the project, in the core of three of the five major web browsers: Apple's Safari, Google's Chromium and Opera. Therefore, WebKit is also a melting pot for many corporate interests, since several competing companies (not only Google and Apple, but also Samsung, RIM, Nokia, Intel and many others) are finding ways of collaborating in the project. All of this makes fascinating the study of how they are contributing to the project. Some weeks ago, a study showed how they were submitting contributions to the code base. Now another one uncovers how they are reviewing those submitted contributions. As expected, most of the reviews during the whole life of the project were done by Apple, with Google as a close second. But things have changed dramatically during the last few years. In 2012, Google is a clear first, reviewing about twice as much (50%) as Apple (25%). RIM (7%) and Nokia (5%) are also relevant reviewers. Code review is very important in WebKit's development process, with reviewers acting as a sort of gatekeepers, deciding which changes make sense, and when they are conforming to the project practices and quality standards. In some sense, review activity reflects the responsibility each company is taking on how WebKit evolves. In some sense, the evolution over time for this activity by the different companies tells the history of how they have been shaping the project."

DeviceGuru writes "Although IE remains the one of the top browsers on desktops, it's being trounced on tablets and smartphones by browsers based on WebKit, including Safari, the Android Browser, and Google Chrome. Faced with this uphill battle on handheld mobile devices, Microsoft MVP Bill Reiss has suggested that it might be time for Microsoft to throw in the towel on Trident and switch to WebKit (though Reiss later decided he was wrong). But although there are lots of points in favor of doing so, there are also some good reasons not to, including security and a need for healthy competition to avoid having mobile developers begin to target WebKit rather than standards."

99BottlesOfBeerInMyF writes "Anders Carlsson and Sam Weinig over at Apple just announced WebKit2, a rework of the WebKit engine that powers Chrome and Safari. This new version of WebKit incorporates the same style of split-process model that provides stability in Chrome, but built directly into the framework so all browsers based upon WebKit will be able to gain the same level of sandboxing and stability. AppleInsider has a writeup, and the team has provided 'high level documentation' as well. Both Palm and the Epiphany team are going to be happy about this."

99BottlesOfBeerInMyF writes "Anders Carlsson and Sam Weinig over at Apple just announced WebKit2, a rework of the WebKit engine that powers Chrome and Safari. This new version of WebKit incorporates the same style of split-process model that provides stability in Chrome, but built directly into the framework so all browsers based upon WebKit will be able to gain the same level of sandboxing and stability. AppleInsider has a writeup, and the team has provided 'high level documentation' as well. Both Palm and the Epiphany team are going to be happy about this."

DigDuality writes "Dieter@be over at Arch Linux forums, a release engineer for Arch Linux, got inspired by this post. The idea? To create a browser based on the Unix philosophy: 'Write programs that do one thing and do it well, programs that work well together, programs to handle text streams because that is a universal interface,' among other points. The result? A fast, low-resource browser named Uzbl, based on WebKit, which passes the Acid3 Test with a perfect score. The browser is controlled (by default) by vim-like keybindings, not too dissimilar to vimperator for Firefox. Things like URL changing, loading/saving of bookmarks, saving history, and downloads are handled through external scripts that you write (though the Uzbl software does come with some nice scripts for you to use). It fits great in a tiling window manager and plays extremely well with dmenu. The learning curve is a bit steep, but once you get used to it, it's smooth sailing. Not bad for alpha software. Though built for Arch, it has been reported to work on Ubuntu."

pizzutz writes "Andy Lawrence has posted a Javascript speed comparison for the recently released Firefox 3.5RC2 between Linux (Ubuntu 9.04) and Windows(XP SP3) using the SunSpider benchmark test. Firefox 3.5 will include the new Tracemonkey Javascript engine. The Windows build edges out Linux by just under 15%, though the Linux build is still twice as fast as the current 3.0.11 version which ships with Jaunty."

Shin-LaC writes "In a post on their official blog, WebKit developers introduced the 'next generation' of their JavaScript engine, SquirrelFish Extreme, claimed to be twice as fast as its predecessor. The post lists several changes contributing to the performance improvements, including 'bytecode optimization,' a 'polymorphic inline cache' (which sounds similar to V8's 'hidden class transitions'), and a 'context threaded JIT' compiler which generates native code (currently only for x86 processors), and is also applied to regular expressions. The new JavaScript engine is already available in the latest WebKit nightly builds. According to comparative benchmarks, the new engine is around 35% faster than the V8 engine recently introduced in Google Chrome, and 55% faster than Mozilla's TraceMonkey."

Shin-LaC writes "In a post on their official blog, WebKit developers introduced the 'next generation' of their JavaScript engine, SquirrelFish Extreme, claimed to be twice as fast as its predecessor. The post lists several changes contributing to the performance improvements, including 'bytecode optimization,' a 'polymorphic inline cache' (which sounds similar to V8's 'hidden class transitions'), and a 'context threaded JIT' compiler which generates native code (currently only for x86 processors), and is also applied to regular expressions. The new JavaScript engine is already available in the latest WebKit nightly builds. According to comparative benchmarks, the new engine is around 35% faster than the V8 engine recently introduced in Google Chrome, and 55% faster than Mozilla's TraceMonkey."

dotne writes "Microsoft has submitted Embedded OpenType (EOT) to W3C and a slimy campaign for EOT has been launched. EOT is a DRM layer on top of normal TrueType/Opentype files; EOT ties a font file to a certain web page or site and prevents reuse by other pages/sites. Microsoft's IE has supported EOT for years, but it has largely been ignored due to the clumsiness of having to regenerate font files when a page changes. Now that other browsers are moving to support normal TrueType and OpenType on the web (Safari, Opera, Mozilla, Prince), W3C is faced with a question: should they bless Microsoft's EOT for use on the web? Or, should they encourage normal font files on the web and help break Microsoft's forgotten monopoly?"

JavaScript is everywhere these days. Now WebKit, the framework behind (among others) Safari and Safari Mobile, as well as the yet-unreleased Android, is getting a new JavaScript engine called Squirrelfish, which the developers claim provides massive speedups over the previous one. The current iteration of the engine is "just the beginning," they claim; in the near future, six planned optimizations should bring even greater speed. With JavaScript surviving as a Web-page mainstay despite many early gripes, and now integral to some low-powered mobile devices, this may mean many fewer wasted seconds in the world.

enemi writes "Just a few days after Safari released version 3.1, Opera employee David Storey writes on his blog that they've overtaken Apple's browser in the Acid3 test. In the race to be the first to reach the reference rendering, Opera's software leads now with 98%, closely following by Safari with 96% and Firefox 3 beta 4 with 71%. He also noted the implemented features will not make a public appearance in the following weeks, because they are getting close to releasing Opera 9.5. That version has been under public testing since September and the new CSS3 color modes and font rendering features might further delay this. They will probably show the score in a preview build soon and wait for a post 9.5 stable build to release the new features to the public." Update: 03/26 21:21 GMT by Z : Opera is now at 100%, apparently, with Safari close behind at 98%. Update: 03/27 by J : Public build r31356 of WebKit (Safari's rendering engine) is at 100%.

Thwomp writes "Over at Coding Horror Jeff Atwood has an interesting writeup on JavaScript performance in the big four browsers. He used WebKit's newly announced SunSpider to produce the results. If a probable anomaly in the IE7 results is overlooked, Firefox 2 is the slowest of the bunch. Atwood has also benchmarked the latest Firefox Beta, and its performance seems to be improved significantly."

sandoz writes "Macenstein has up an interesting article with some evidence that running Safari seems to slow down unrelated programs. While the speed with which a browser renders a Web page is an important measure, the difference between browsers is usually a matter of a few seconds at most. To my mind, a more important measure of speed is how a browser affects the overall speed of your system." Some responses to the article suggest that memory handling in WebKit may be the culprit. The Safari developers have already responded to this article on the webkit.org blog. They explain why the slowdown might be occurring and how it's (probably) already been fixed in the nightly build. And they request more minimal test cases.