Author Archive: Bronwen Matthews

Open@Adobe Anniversary

This month marks the fourth anniversary of the Open@Adobe initiative, a site presenting a definitive view of the openness efforts at Adobe. Over the past few years, Adobe has released over 100 pieces of technology under open source licenses, as well as contributed to many notable open source projects. Adobe has also contributed to the community in the form of active members and chairs/co-chairs of numerous standards bodies such as  IETF, ECMA and ISO and authors of W3C standards like CSS, WCAG and ARIA.

Learn more about Adobe’s role in driving innovation and making the Web open in the Open@Adobe Fourth Anniversary blog post.

Adobe’s RTMFP Profile for Flash Communication Released

Adobe’s Secure Real-Time Media Flow Protocol (RTMFP) is a general purpose data transport protocol designed for real-time and peer-to-peer (P2P) communication, and is the foundation of Flash’s P2P capabilities. RTMFP is documented in RFC 7016  published November 2013 by the Internet Engineering Task Force (IETF).

We have now submitted a companion specification, “Adobe’s RTMFP Profile for Flash Communication” to the IETF Internet-Drafts repository.

This new specification shows how developers can create applications that interoperate with Adobe Flash and Adobe Media Server in client-server and direct client-to-client modes using RTMFP. We believe RTMFP also has applicability beyond Flash, and this specification can help developers understand how to use RTMFP in their own innovations for next-generation real-time and P2P applications.

Adobe continues to develop technologies using RTMFP within Adobe Flash and Adobe Media Server including features like Multicast and Groups, being used today by our customers to deliver high quality video experiences across public and corporate networks.

We are excited to continue making contributions to standards organizations such as the IETF that further Internet technologies for developers and users. As a technology leader, Adobe collaborates with stakeholders from industry, academia and government to develop, drive and support standards in existing and emerging technologies, policy areas, and markets, in order to improve our customers’ experience.

We welcome comments and feedback to help us improve the quality, clarity, and accuracy of this specification and we are excited to see what the Internet community creates with it.

Michael Thornburgh
Senior Computer Scientist

Update: Alignment of Adobe-Approved Trust List (AATL) and EU Trust List (EUTL)

As mentioned in our previous post, Alignment of Adobe-Approved Trust List (AATL) and EU Trust List (EUTL) we have been busy working on the integration of the EU Trust List into Adobe Acrobat and Reader software. Our January 14, 2014 release of Adobe Reader and Acrobat 11.0.06 takes another significant step towards that ultimate goal. In this version of the product, you will notice new UI to manage the EUTL download. For instance, we’ve added new controls in the Trust Manager Preferences as shown below.

EUTL pic

 

 

While we continue with our beta testing phase of this process, the general user will not be able to download an EUTL. But, as soon as beta is complete, we’ll be moving the EUTL into production, where everyone will have access.

Steve Gottwals
Senior Engineering Manager, Information Security

John Jolliffe
Senior Manager, European Government Affairs

The W3C Updates Process for More Agile Standards Development

For much of my 40 year career, the development of standards, both IT standards and those of other fields, proceeded in much the same way. A group, often under the guidance of a national or international standards organization, would work out a proposal, pretty much in private, and submit it to a series of reviews by other people interested in standards. The process under which this happened was quite formalized and participation was rather limited. Though the process worked, it was originally designed for a time when communication was by mail and it often took a long time to conclude.

The Internet, e-mail and other social technologies have changed how we communicate. Experience with software development has changed how we organize and realize projects. Communication is immediate (and often continuous) and software is constructed using agile methodologies that break the work into relevant chunks that are realized in succession (rather than trying to do the whole project at once and then test and deliver – i.e. the “waterfall model”). It is time that standards development, at least for IT standards, exploits these cultural changes to make the standards development process more effective.

The World Wide Web Consortium (W3C) has undertaken updating its process to allow more agile standards development. Over the last five years, the W3C has opened up much of its standards work to public participation on a daily (if desired) basis. But, there are aspects of the current W3C Process that act as barriers to more agile standards development. One of these is the assumption that all parts of a potential standard will progress at the same rate; that is, all parts of a standard will be accepted and reach deployment at the same time.

In the past, a specification would go through a number of public Working Drafts, become a Candidate Recommendation and finally a W3C Recommendation. When the relevant Working Group believed that they had completed their work on the specification they would issue a Last Call. This Last Call was a request for confirmation that the work was complete by people outside the Working Group. All too frequently, this Last Call was both too late (to make changes to the overall structure of the standard) and too early because many relevant detailed comments were submitted and needed to be processed. This led to multiple “Last Calls.” When these were done, the next step, Candidate Recommendation, was a Call for Implementations. But, for features that were of high interest, experimental implementations began much earlier in the development cycle. It was not implementations, but the lack of a way of showing that the implementations were interoperable that held up progression to a Recommendation.

So, the W3C is proposing that (where possible) standards be developed in smaller, more manageable units, “modules.” Each module either introduces a new set of features or extends an existing standard. It’s size makes it easier to review, to implement and completely specify. But even the parts of a module mature at different rates. This means that reviewers need to be notified, with each Working Draft, which parts are ready for serious review. This makes the need for a Last Call optional. It is up to the Working Group to show that they have achieved Wide Review of their work product. This involves meeting a set of reasonable criteria rather than a single specific hurdle. With this change, Candidate Recommendation becomes the announcement that the specification is both complete and it has been widely reviewed. This is the time at which the final IPR reviews are done and the Membership can assess whether specification is appropriate to issue as a Recommendation. It is also time that the existence of interoperable implementations is demonstrated.

With these changes, it becomes much easier to develop all the aspects of a standard – solid specification, wide review, implementation experience and interoperability demonstrations – in parallel. This will help shorten the time from conception to reliable deployment.

Stephen Zilles
Sr. Computer Scientist

CSS Shapes in Last Call

(reposted from the Web Platform Blog)
The CSS Working Group published a Last Call Working Draft of CSS Shapes Module Level 1 yesterday. This specification describes how to assign an arbitrary shape such as a circle or polygon to a float and to have inline content wrap around the shape’s contour, rather than the boring old float rectangle.

A Last Call draft is the signal that the working group thinks the specification is nearly done and ready for wider review. If the review (which has a deadline of January 7th, 2014) goes well, then the spec goes on to the next step. At that point, the W3C invites implementations in order to further validate the specification. We at Adobe have been implementing CSS Shapes in WebKit and Blink for a while, but this milestone opens the door for more browsers to take up the feature.

This means that 2014 will be the year you’ll see CSS Shapes show up in cutting-edge browsers. The effort then moves to making sure these implementations all match, and that we have a good set of tests available to show interoperability. My hope is that by the end of next year, you’ll be able to use shapes on floats in many browsers (with a fallback to the normal rectangle when needed).

Alan Stearns
Computer Scientist
Web Platform & Authoring

SVG-in-OpenType Enables Color and Animation in Fonts

After two years of discussion and development, the W3C community group (CG) SVG Glyphs for OpenType recently finalized its report for an extension to the OpenType font format. This extension allows glyphs to be defined in the font as SVG (Scalable Vector Graphics). Such OpenType fonts can display colors, gradients, and even animation right “out of the box,” that is, when rendered by a font engine that supports this extension.

While the initial use case, emoji, is described in our Typblography article “SVG in OpenType: Genesis,” this extension to OpenType allows for a broad range of applications: colored illuminated initial capitals, creative display titling, logo and icon fonts, and educational fonts that show kanji stroke ordering and direction. These use cases are central to Adobe’s roots and continuing exploration of how best to thrill customers with rich visual expressiveness, in this case through typographic innovation.

The bulk of the specification was crafted by Adobe and Mozilla. I teamed up with Cameron McCormack and Edwin Flores of Mozilla to edit the report. Chris Lilley of the W3C chaired the CG. Mozilla’s implementation in Firefox was the first such (the Typblography article above contains instructions on how to see SVG-in-OT in action in Firefox). We will be presenting the CG’s final report to ISO MPEG’s Open Font Format (OFF) committee in January 2014 for formal inclusion in their specification. An MPEG approval of the specification would mean automatic acceptance into the OpenType specification.

Adobe has contributed extensively to the OFF and OpenType specifications since their inception, starting of course with inclusion of our Compact Font Format (CFF) into OpenType in the mid-nineties. In subsequent years, we proposed several additional tables, table extensions, and features to improve text layout and to accompany advances in Unicode (variation sequences, for example) – extensions which have been implemented by OpenType font engines across the board, including those of Apple, Microsoft, and Google.

Sairus Patel
Senior Computer Scientist
Core Type Technologies

 

Alignment of Adobe-Approved Trust List (AATL) and EU Trust List (EUTL)

Adobe has long recognized the value of digital signatures as a tool for driving secure transactions in Europe. As a continuation of our previous investments in qualified signature technology, we see the integration of the EU Trust List into Adobe Acrobat and Reader software as the next logical step. Though this sounds like a relatively simple problem, in reality it took some time, requiring agreement with a number of stakeholders outside of Adobe. ETSI’s June 19 announcement of TS 119 612 v1.1.1: Electronic Signatures and Infrastructures (ESI); Trusted Lists is the culmination of many months work by interested stakeholders, and the first step in creating a solution.

Over the past few years, our commitment to advancements in digital signatures has made Acrobat and Reader one of the most readily available means for EU citizens to receive signed electronic documents based on qualified certificates. Some of our most significant milestones include:

  • Developing the “Adobe-Approved Trust List” (AATL) to ensure that qualified certificates issued by valid Certification Service Providers could be recognized by our products.
  • Working with the European Telecommunications Standards Institute (ETSI) to develop the technical specification for PDF Advanced Electronic Signature (PAdES), incorporated into the Adobe Acrobat PDF Reader product in 2009.
  • Enabling the manual import of qualified certificates, in Acrobat 9 and later, into the trust list within Acrobat or Reader, so that qualified signatures are validated.

Our approach has had some limitations. Currently, only certificates imported by the user or included in the AATL are “trusted,” and therefore recognized as valid by Adobe software. Other qualified certificates – including those on the national trust lists – are not recognized by Adobe as legitimate sources.  As a result, users and Certification Service Providers are asking Adobe to do more to recognize national trust lists within Adobe software.

ETSI’s announcement of TS 119 612 v1.1.1: Electronic Signatures and Infrastructures (ESI); Trusted Lists  is the culmination of many months of work by interested stakeholders, including Adobe, and at last provides a stable means of streamlining the recognition of trust lists within software applications. A key concern has been to ensure that there is a stable standard that describes how proprietary trust lists (such as the AATL) interact with national trust lists. This involves a number of separate issues including:

  • The national trust list description needs to be consistent to allow certificates to be read by software applications, otherwise some certificates from certain countries will not be readable
  • Trust lists are built into a number of software applications, most notably web browsers. A standard is needed to ensure that software applications all react in a consistent way when reconciling certificates that are in both the proprietary trust list and the national trust list.

A stable specification is a significant milestone, as it will allow software manufacturers and vendors, including Adobe, to implement the new features into future versions of their software. From an Adobe perspective we are working through a number of technical considerations. Many of these are unique to Adobe, including:

  • Updates – With hundreds of millions of instances of Acrobat/Reader in the world that could potentially encounter a digital signature that needs validation, sending updates is a non-trivial matter from an engineering and bandwidth perspective.
  • User experience – The same functional version is shipped globally. Since not all users will want or require the EUTL functionality, we are investigating the best way to make this option available, and the frequency with which updates will be offered.

It is not our policy to comment publicly on the roadmap for any of our software, however we consider these issues entirely solvable and are working hard to find good solutions. More details of specific implementation plans will be made available in due course.  In the meantime, we look forward to the adoption of the standard by the EC within the planned new Trust Services Regulation, which will replace the current e-Signatures Directive.

Steve Gottwals
Group Product Manager, Acrobat

John Jolliffe
Senior Manager, European Government Affairs

Adobe Support for Encrypted Media Extensions

Adobe is actively supporting the development of the Encrypted Media Extensions (EME) to the HTML5 standard. We are working on implementations of the EME and its companion specification, MSE (Media Source Extensions) and have been regular participants in the task force working sessions and email discussions.

HTML has grown to include many capabilities which were previously only provided by browser plugins like Adobe Flash. As a result, more developers are choosing to build applications using Open Web technologies. However, there are applications that are not possible to build today without extending the browsers capabilities. The inclusion of the <video> tag in particular has been a huge step forward, but that capability is limited to playing unprotected videos. To enable the playing of protected videos like feature-length Hollywood films, developers are forced to rely on plugins or non-standard browser extensions. As Adobe supports Open Web development more and more, we need to find a way to provide this capability to developers. I believe the EME specification will help us provide this capability for customers using our Adobe Primetime products.

This EME specification provides benefits to multiple parties. Content providers will benefit from more standardization of the formats used for delivering protected audio and video, lowering their cost for delivering the content. Developers will benefit from easier and faster cross-platform development by leveraging the common Web stack along with the EME APIs. End users will benefit from being able to stay within the familiar browser environment instead of being forced out to standalone proprietary applications. End users may also benefit from increased content options, due to the lower costs to content providers I mentioned above. Everyone will benefit from the reduced API surface area (as compared to existing plugin based solutions) this exposes to malicious code on the web.

The EME working group has published its First Public Working Draft. We are working with the group to address the issues that have been raised so far and constructive comments are welcome. Adobe is working on our own implementations of EME and once ready, we will make them as widely available as possible. Adobe’s goal is to enable more content to flow to more people on more platforms. I believe strongly that this effort will help us towards achieving that goal.

Joe Steele
Sr. Computer Scientist
Runtime Engineering

OpenCL Enables More Compelling and Efficient Applications

We live in a world with an embarrassingly wonderful variety of choices when it comes to processors, monitors, video cards, and other components that make up the computers and devices we use every day. As a user, this variety is great because it encourages vendors to innovate and compete with one another, creating progressively more awesome hardware. As a programmer, this same variety is challenging because each vendor’s components use their own proprietary programming models and interfaces. Writing applications that perform correctly and efficiently on all that hardware would be overwhelmingly difficult without industry standard APIs. For example, just about every graphics accelerator vendor has a different way to program their chips or talk to their accelerators, which is why just about every video card vendor implements OpenGL, an industry standard graphics API. This then allows software developers to write applications that use OpenGL to take advantage of the wide variety of graphic accelerators found on users’ machines without having to write special code for each and every video card in the market.

Over the last ten years, hardware and software vendors have worked to figure out how to do for parallel programming and parallel processors what OpenGL did for graphics programming and graphics accelerator cards. CPU vendors now routinely introduce processors with multiple cores, hyperthreading, and other features that allow software to perform many operations at once. GPU vendors similarly design new chips designed to allow their massively parallel compute cores to perform general purpose programming tasks, in addition to the extreme graphics performance for which they were originally conceived. For a company like Adobe, whose applications need to squeeze every bit of performance and efficiency from every user’s machine, writing programs that run well on each vendor’s architecture and that take advantage of each vendor’s innovations would be inordinately difficult without an open, vendor-neutral API for parallel programming that was designed to address the variety of processors in the market today and yet to come. Thus is was that, five years ago, Khronos, the same industry consortium that governs OpenGL, convened a new working group to standardize just such an API, the Open Computing Language more commonly known as OpenCL.

I have the honor and pleasure of being Adobe’s voice and vote in the OpenCL working group. Because OpenCL, like its graphics cousin, OpenGL, is fundamentally implemented by hardware vendors, the OpenCL working group primarily consists of hardware companies. Consequently, I am often asked why Adobe is actively involved in creating an open standard for computing hardware. The answer is deceptively simple:  a good, open standard for parallel computing helps us deliver better software, and merely hoping that OpenCL will be that standard without our input is wishful thinking.

We want to deliver software that is fun to use, runs fast, and consumes as little power as possible, something that is increasing more challenging in today’s fragmented world. We write desktop software that runs on Mac OS and Windows, mobile software that runs on iOS, Android, and Windows 8, and server software that runs on Windows and Linux. Our software uses chips built by different vendors, including NVIDIA, AMD, Intel, and ARM. We also have more than a decade’s worth of experience designing and developing parallel computing systems, Pixel Bender and Halide being two well known strategic investments Adobe made in this space. Through those experiences, we gained a hard-won perspective that we can be even more successful by joining forces with the community at large, that using an open standard makes our jobs a lot easier – writing great software that runs on different operating systems, form factors, and chip sets – and allows us to spend more time building software that runs quickly and efficiently on your computers and devices.

Returning to the original question, we know that open standards are good for the industry and enables us to most easily write great software that runs well on the widest variety of hardware. Even though Adobe does not build hardware and, therefore, does not implement OpenCL, we use OpenCL and we know what features we need, from OpenCL and from OpenCL hardware, to enable us to build even more compelling and efficient applications. So, we openly participate in the discussion to develop the standard, adding our experience, perspective, and vision for creating great software running on great hardware, with the goal of shaping and influencing OpenCL to evolve in a way that is advantageous to Adobe’s customers. With our continued participation and influence, and with the cooperation and support of our vendor partners, Adobe has high hopes for the power of the computers and devices in your future, and for the capability, efficiency, and experience of the software you’ll run on them.

Eric Berdahl
Sr. Engineering Manager