惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

K
Kaspersky official blog
小众软件
小众软件
Engineering at Meta
Engineering at Meta
博客园 - 三生石上(FineUI控件)
WordPress大学
WordPress大学
G
Google Developers Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
V
V2EX
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Google DeepMind News
Google DeepMind News
Security Archives - TechRepublic
Security Archives - TechRepublic
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
C
Check Point Blog
aimingoo的专栏
aimingoo的专栏
罗磊的独立博客
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
MongoDB | Blog
MongoDB | Blog
L
LINUX DO - 热门话题
酷 壳 – CoolShell
酷 壳 – CoolShell
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
H
Help Net Security
Martin Fowler
Martin Fowler
G
GRAHAM CLULEY
Simon Willison's Weblog
Simon Willison's Weblog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - Franky
V
Vulnerabilities – Threatpost
云风的 BLOG
云风的 BLOG
博客园_首页
C
Cybersecurity and Infrastructure Security Agency CISA
量子位
Stack Overflow Blog
Stack Overflow Blog
Recent Announcements
Recent Announcements
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
I
Intezer
Scott Helme
Scott Helme
A
About on SuperTechFans
博客园 - 司徒正美
Hacker News: Ask HN
Hacker News: Ask HN
The GitHub Blog
The GitHub Blog
Forbes - Security
Forbes - Security
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
博客园 - 聂微东
人人都是产品经理
人人都是产品经理
The Cloudflare Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Spread Privacy
Spread Privacy
T
Tailwind CSS Blog
S
Security Affairs
宝玉的分享
宝玉的分享

David Baron's Weblog

Software engineering, responsibility, and ownership Software engineering, responsibility, and ownership David Baron's weblog: Security and Inequality Running animations on the compositor thread David Baron's weblog: Payments on the Web Thoughts on migrating to a secure Web David Baron's weblog: The need for government David Baron's weblog: Priority of constituencies How browser developers should seek feedback from Web developers A possible approach to shorter release cycles David Baron's weblog: Fifteen years Why debug builds (and assertions) are important Ten years of the Mozilla Foundation Open licensing at the W3C Why adding compositing and blending to CSS is harder than it looks How you can help with removing -moz- prefixes Moving bug history out of the primary display of a bug report Beware of locale-specific behavior in the C library Eating dogfood and shipping software Specification style and the future of the Web The bug system I wish I had CSS border-image changes and unprefixing Improving font size readability on Firefox for Android David Baron's weblog: CSS Animations, part 2 Hue-preserving color inversion with SVG filters Changes to handling of @-moz-keyframes David Baron's weblog: window.matchMedia() David Baron's weblog: CSS Animations What does a blur radius mean? Crash analysis in the future David Baron's weblog: calc() David Baron's weblog: colorDepth David Baron's weblog: Hidden complexity in specifications The most important field in a bug report: the summary WOFF font format submitted to W3C David Baron's weblog: :-moz-any() selector grouping setTimeout with a shorter delay Faster repainting in SVG foreignObject David Baron's weblog: Distributed Extensibility David Baron's weblog: Broadening crash analysis Correlating crashes with binary extensions or plugins David Baron's weblog: ex-HTML Downloadable font formats for the Web Web Accessibility as a Political Movement David Baron's weblog: CSS priorities David Baron's weblog: Bug priorities David Baron's weblog: Semi-vacation Some new CSS features in Firefox 3 David Baron's weblog: New selectors David Baron's weblog: The age of bugs Seeking a good Linux distribution David Baron's weblog: Teaching to the test David Baron's weblog: March 2008 David Baron's weblog: February 2008 David Baron's weblog: January 2008 David Baron's weblog: October 2007 David Baron's weblog: September 2007 David Baron's weblog: August 2007 David Baron's weblog: June 2007 David Baron's weblog: April 2007 David Baron's weblog: March 2007 David Baron's weblog: January 2007 David Baron's weblog: September 2006 David Baron's weblog: August 2006 David Baron's weblog: July 2006 David Baron's weblog: May 2006 David Baron's weblog: February 2006 David Baron's weblog: January 2006 David Baron's weblog: December 2005 David Baron's weblog: October 2005 David Baron's weblog: September 2005 David Baron's weblog: June 2005 David Baron's weblog: May 2005 David Baron's weblog: April 2005 David Baron's weblog: March 2005 David Baron's weblog: February 2005 David Baron's weblog: October 2004 David Baron's weblog: September 2004 David Baron's weblog: August 2004 David Baron's weblog: June 2004 David Baron's weblog: May 2004 David Baron's weblog: April 2004 David Baron's weblog: March 2004 David Baron's weblog: February 2004 David Baron's weblog: January 2004 David Baron's weblog: November 2003 David Baron's weblog: October 2003 David Baron's weblog: September 2003 David Baron's weblog: August 2003 David Baron's weblog: July 2003 David Baron's weblog: June 2003 David Baron's weblog: May 2003 David Baron's weblog: April 2003 David Baron's weblog: March 2003 David Baron's weblog: February 2003 David Baron's weblog: January 2003 David Baron's weblog: December 2002 David Baron's weblog: November 2002 David Baron's weblog: September 2002
David Baron's weblog: Tying ecosystems through browsers
David Baron · 2015-08-03 · via David Baron's Weblog

One of the principles behind HTML5, and the community building it, is that the specifications that say how the Web works should have enough detail that somebody reading them can implement the specification. This makes it easier for new Web browsers to enter the market, which in turn helps users through competitive pressure on existing and new browsers.

I worry that the Web standards community is in danger of losing this principle, quite quickly, and at a cost to competition on the Web.

Some of the recent threats to the ability to implement competitive browsers are non-technical:

  • Many leading video and audio codecs are subject to non-free patent licenses, due at least in part to the patent policies and practices of the standards bodies building such codecs.
  • Implementing EME in a way that is usable in practice requires having a proprietary DRM component and then convincing the sites that use EME to support that component. This can be done by building such a component or forming a business relationship with somebody else who already has. But this threat to browser competition is at least partly related to the nature of DRM, whose threat model treats the end user as the attacker.

Many parts of the technology industry today are dominated by a small group of large companies (effectively an oligopoly) that have an ecosystem of separate products that work better together than with their competitors' products. Apple has Mac OS (software and hardware), iOS (again, software and hardware), Apple TV, Apple Pay, etc. Google has its search engine and other Web products, Android (software only), Chrome OS, Chromecast and Google Cast, Android Pay, etc. Microsoft has Windows, Bing, Windows Phone, etc. These products don't line up precisely, but they cover many of the same areas while varying based on the companies strengths and business models. Many of these products are tied together in ways that both help users and, since these ties aren't standardized and interoperable, strongly encourage users to use other products from the same company.

There are some Web technologies in development that deal with connections between parts of these ecosystems. For example:

  • The Presentation API defines a way for a Web page to show content on something like a Chromecast or an Apple TV. But it only specifies the API between the Web page and the browser; the API between the browser and the TV is completely unspecified. (Mozilla participants in the group tried to change that early in the group's history, but gave up.)
  • The future Web Payments Working Group (which I wrote about last week) is intended to build technology in which the browser connects a user making a payment to a Web site. This has the risk that instead of specifying how browsers talk to payment networks or banks, a browser is expected to make business deals with them, or make business deals with somebody who already has such deals.

In both cases, specifying the system fully is more work. But it's work that needs to happen to keep the Web open and competitive. That's why we've had the principle of complete specification, and it still applies here.

I'm worried that the ties that connect the parts of these ecosystems together will start running through unspecified parts of Web technologies. This would, through the loss of the principle of specification for competition, makes it harder for new browsers (or existing browsers made by smaller companies) to compete, and would make the Web as a whole a less competitive place.