And if the fork diverges, then what? This is not a theoretical concern: Blink and WebKit are now quite different, and it's best to regard them as two different rendering engines. Is that bad?
> Maybe the rendering engine should be more akin to the Linux kernel and less akin to Windows?
This presupposes that the Linux kernel is at an optimum point in the design space. It's pretty clear to me that it isn't. In fact, I think the monoculture around open source kernels has been bad for OSS. I look forward to Fuchsia providing some much-needed competition, much in the same way LLVM provided much-needed competition to GCC.
At that time, 2001-2002, IE6 was highly praised. You don’t get to 96% marketshare by being something everybody hates. The hate came later when CSS demand ramped up and it became clear IE6 used a non-standard box model. Worse still MS essentially abandoned the browser, the result of total marketshare dominance, and tied it directly to the operating system.
The reason people are complaining about this is the lack of diversity. This has proven very bad in the past. It essentially makes the platform a proprietary space even if the dominant browser is open source. The key here is who directs the technology and direction of the platform.
Which we all use now anyway because it was right way to do it...
* {
box-sizing: border-box;
}I don't do that and I avoid code that does. In the days of IE7 I learned to write CSS code that was conformant to both box models. Now I just write to the standard box model. CSS isn't something that will ever be particularly challenging once you have gone through the extremes of edge case use cases.
At the time, the CSS specification didn't make it clear which way to calculate widths so Microsoft, probably due to their experience building graphical layout software, chose border-box while all other rendering engines at the time went content-box probably without considering the consequences. Realizing the error, the box-sizing property was added to CSS to fix this.
Imagination aside, IE3 was the first browser to offer any CSS support.
https://blog.teamtreehouse.com/box-sizing-secret-simple-css-...
https://quirksmode.org/css/user-interface/boxsizing.html
https://www.jefftk.com/p/the-revenge-of-the-ie-box-model
https://github.com/twbs/bootstrap/issues/12351
https://jgthms.com/minireset.css/
I remember having to deal with all these things when working with the company's aging CMS. It was a great tool, but the version the company was using was old (before standardized doctypes in 1999) and inserted a comment into the top line of code throwing all documents into quirks mode in IE.
The box model was corrected when IE released version 7, which still also featured quirks mode rendering for backwards compatibility.
For me personally, multiple independent implementations is a stamp of approval. It means that Google can't just sit on the standards committee, build something behind closed doors, and ship it, even if the result is open-source.
It means someone outside of that one company has to understand it, and be able to implement it. It can't be ridiculously complex, or have DOCX-style "just do what proprietary implementation X does" requirements. There has to be sufficient documentation. The implementations probably won't all have the same bugs -- I've heard avionics systems have multiple independent implementations for this very reason.
> Maybe the rendering engine should be more akin to the Linux kernel and less akin to Windows?
I fear it'll be more like Darwin. It's nice that XNU is "open source", perhaps, but nobody is taking advantage of this. I've never heard of anyone running XNU except as part of Apple's proprietary operating systems, and I've never heard of anyone forking it to run a custom version on their Apple hardware. I'm not even sure to what extent it's technically possible.
I would be much less worried if the single surviving browser engine were Gecko -- not because I think it's technically superior (I don't think it is), but because I trust Mozilla a lot more than I trust Google, or even Google+Microsoft. Mozilla is not good at design but they operate out in the open.
Seems like there's something called PureDarwin that's trying to do something with it now.
Both FreeBSD and OpenBSD maintain large patch-sets to be able to build Chromium. [1][2]
I don't know the current situation, but historically some of these patches have had problems reaching upstream because Free-/OpenBSD is not officially supported[3].
[1] https://svnweb.freebsd.org/ports/head/www/chromium/files/ [2] http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/chromium/... [3] https://codereview.chromium.org/180743014/#msg3
If Blink has a security vulnerability, like the recent WebSQL remote code execution, then in a monoculture that means everyone has this vulnerability.
There are several second-order reasons why a monoculture is damaging for the browser industry. I will give a few examples:
1. A monoculture encourages web developers to test on a single platform with the assumption that all other platforms, and even industry standards, are meaningless. Many of us are web developers, and most of us are guilty of dismissing low-share platforms during testing. But as long as some viable competitors exist, we nominally target the industry standards in the hope that by doing so, the platforms we do not test on will have a modest/tolerable (maybe even good) experience.
2. A monoculture is self-reinforcing. Losing established viable competitors makes it more difficult for new competitors to enter the market. If we allow second-tier browsers to be rendered meaningless, we all but ensure a long and (eventually) painful stagnation, and create an ever-larger hurdle for a new entrant to clear to reach any significance (as more an more of the web is designed to work with a single platform). While it may sound passably agreeable to have a Chrome monoculture in 2019, do we want to still have a Chrome monoculture in 2029? For my part, I hope we see an increasing set of options in most areas of life over time, even in "browsing," whatever that ends up looking like in 10 years.
3. We don't know what future stagnation will look like. We don't know what opportunities we will have lost by making it more difficult to compete or by losing the healthy diversifying force of competition. It's a classic problem of the unseen. Projecting forward, we predict testing will be a bit simplified, but we cannot know what innovations we'll never see (or won't see as quickly) because the hurdles for experimentation were too high. Today, if Firefox introduces a new feature, even though its usage is relatively small the usage is still large enough in absolute terms that the innovation isn't entirely under the radar for most of us. If Firefox's share were 0.8% instead of 8%, far fewer of us would even notice if they added a slick new feature, leaving the feature unheralded and obscure despite its potential wide appeal.
This is really no different than the Linux Kernel. People will take KHTML, Webkit, Blink, V8, JavaScriptCore and remix those into dozens of different products all with better web compatibility than something home grown from Microsoft with no chance of adoption.
[1]: https://css-tricks.com/the-ecological-impact-of-browser-dive...
If we really want diversity on the internet we should probably still be using Gopher and other internet clients.
This sort of thing boxes out other vendors/rendering engines and forces them to have to add non-standard features themselves. Vendor prefixes are not enough. If devs no longer test on non-Chromium platforms, vendor prefixes have to be adopted by non-Chromium engines or risk utter obsolescence. This is also true of Chromium forks. If a fork is a niche player, being open source doesn't buy you much because the Chromium governing body (i.e., Google) still has the lion's market share, and thus the decision-making authority for what the web should look like.
Where is Microsoft saying that?
Problems with monoculture: lack of innovation, a single agenda being pushed forward, anti-competitive behavior. Google doesn’t want technology X? X is dead. Google thinks Ad platform Y is bad? Y is dead. etc
So the whole thing is arguably suspect.
Google is a business like any other - and when they have the power to lever a monopolized situation - they will.
For example, they may start integrating technologies for which they have exclusive, or at least 'special' access. Can you imagine if all of a sudden Google apps start performing better than anyone else's?
Or what if they integrate technology that de-facto collects usage and behaviour - even from other domains - and then lever that competitively?
The power that Google already has, relatively unregulated is crazy. Remember that Google is the company that could change the outcome of elections ... possibly without us even knowing. They could drive markets up or down at will.
This would probably happen as a 'slow drip' - not one step being close enough to consumer awareness to create problems, and what with 'business friendly' politicians, nary a worry of legislation getting in the way.
They could introduce these technologies under the guise of 'improving user experience' (and maybe legitimately so to start), but other PM's, new CEO's etc. just take the opportunity before them. Why wouldn't they?
We worry a lot about 'Net Neutrality' at the network level, like it's a religion ... but that we don't worry about 'information neutrality' as well I find quite bizarre.
I suggest that having '1 major provider' may be a problem, doubly so if it's an entity like Google, and that frankly we don't really gain much from this fact at all. If Mozilla were the provider, great. Even Apple might be a better choice simply because they are not in the business of managing our information - at least right now, for them, it's a headache, not a revenue source.
So the concern is real.
This is already happening. I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome's dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower.
Now while I'm not sure I'm convinced that YouTube was changed intentionally to slow Edge, many of my co-workers are quite convinced - and they're the ones who looked into it personally. To add to this all, when we asked, YouTube turned down our request to remove the hidden empty div and did not elaborate further.
And this is only one case.
If this case hasn't already been run up to Microsoft's lawyers, start running it up to them. You'll be doing the world a service.
It is not the best time to strike now, once the timing is right, I am sure they will.
TBH, I consider Google much more evil than Microsoft, in or outside of Dev Circles. Microsoft dropped the evil baton and Google picked it up and sprinted away.
What Microsoft gain after Windows Phone YouTube app case? Nothing. Google successfully fucked up Microsoft.
And I've worked for Google in the past, but their main issue has always been that they change a lot which makes them a moving target which is annoying in its own way.
Microsoft earned its public image and while it's made nicer noises recently it's not an organisation that fills me with trust.
Uh, money? It might not exactly be a noble incentive for a lawsuit, but it's sure as hell an incentive, isn't it?
With a lot of legal issues, sometimes the only winning move is not to play.
They'll get a more level playing field.
CEO's generally don't order this stuff to happen. More often it's a director, manager, VP or whatever that's just really aggressive. Possibly the CEO knew or not.
When a company gets bloodied for a pile of money, they generally have to own up to it, which makes them look bad (by they way, these things do have a cumulative effect) - but more importantly, they have to at very least 'go through the motions' of getting staff to 'not do this stuff'.
So they have 'training' and 'oversight' etc.. However ingrained it is into behaviour (or even a single rotten apple) the likelihood of recursion goes down.
For example - if an inner legal team gets some responsibility for oversight on these issues, they can make life difficult for managers on these things.
I worked at a Fortune 50 that was sued by a patent troll, and it seriously and fundamentally changed internal culture to the point wherein we needed lawyers involved in everything, it was really bad. Obviously a negative example.
But especially Microsoft has enough $ to drag Google into court, they should do it.
That said: I'll bet $100 that MS might be doing some tricky things of their own anyhow.
I'd be curious to see how likely Microsoft would be to follow this approach rather than to just stick to using Blink... as they've already decided to do.
Google could start responding to YouTube requests with binary streams of gibberish if they want, MS would only have standing to sue as a content creator and advertiser on YouTube.
If Google is reverse engineering other browsers optimization paths and putting out content that is disagreeable to that optimization, that's possibly unfortunate but not illegal.
b) since Google's browser became the defacto standard browser thanks to Edge switching engines, hence the thread. The standard doesn't really matter anymore; Google makes most of them now as a matter of course anyway.
Click the "show desktop view" page on mobile firefox, reload, and suddenly the score is there. They're not discriminating that aggressively against competing desktop browsers. Yet.
Huh?
First, I can find nowhere that Chrome claimed to have better video-watching battery life (in fact, popular tech sites mention improving but still worse[1]).
Second, the only dip I can find in the public Edge battery life tests[2] was
April 2017 - 12.5 hours
Dec 2017 - 16 hours
May 2018 - 14.3 hours
vs Chrome's 9.3, 13.5, and 12.5 hours. Which means whatever happened last spring, Chrome also dipped.
And third, how about we talk about the kind of web browser battery benchmark based on playing fullscreen video and is defeated by adding a single hidden div? It's not testing battery life of a representative sample of what a web browser is actually used for (especially over 12+ hours), and obviously wasn't very resilient in the face of what a web browser has to actually handle.
Honestly it sounds like they added a div for unrelated reasons (accessibility, "security", ads, who knows), thought it was worth the performance tradeoff (or never measured), and it indirectly ended up making Edge better for real web content (as of the Win10 Oct update).
[1] https://arstechnica.com/gadgets/2018/05/edge-still-boasts-be...
[2] https://www.youtube.com/playlist?list=PLWs4_NfqMtoxOT8E8d5KP...
I'd suggest inspecting a few sites you watch video on. An empty div is the least weird thing you'll find.
This ultimately comes down to hardware limitations. GPUs are limited as to what they can compose during scanout, because of memory bandwidth limits. Each plane that you can alpha-blend together at scanout time multiplies the amount of memory fetches per dot you have to do. On today's high-DPI displays, the bandwidth going out to the display is very high to begin with, so you can't afford to multiply that by much. That is why putting something on top of a video is tricky: you're adding another layer to be alpha-blended on top, increasing your memory bandwidth by 50% over the two layers you already have (RGB for the background plus YUV for the video). The user's GPU may or may not support that--as I recall, prior to Skylake, Intel GPUs only had two hardware planes, for instance.
I'm not surprised that Microsoft just used "are there any DOM elements over the video?" as a quick heuristic to determine whether scanout compositing can be used. Remember that there is always a tradeoff between heuristics and performance. At the limit you could scan every pixel of each layer to see whether all of them are transparent and cull the layer if so, but that would be very expensive. You need heuristics of some kind to get good performance, and I can't blame Microsoft for using the DOM for that.
which, again, that's fine, but mayyyyybe they were a little lax in checking performance on nearly any other popular video site on the web to see if that heuristic is a good one?
Or maybe changing page layout in an extremely common way wasn't an effort to undermine a hyper specific benchmark?
Remember, if you put visible DOM elements on top of the videos, then you lose scanout compositing no matter what.
A lot of them? Vimeo, for instance, has a number of opacity: 0 and hidden divs over the video. Twitch has at least a couple of opacity: 0 divs on top.
Maybe we're interpreting the phrase
> hidden empty div over YouTube videos
differently? That's the structure I assume they were talking about.
Considering that it's now optimized and that's not what the original post said, I don't know why you'd assume that.
That's what this "empty div" is for if that's the one I think it is. It is the container for things like branding and annotations.
FWIW, I think you're a little credulous there; as I mentioned in my other comment[1], I can't find anything stating that Chrome starting beating Edge at the test (their videos actually claim the opposite) or anybody from Chrome boasting about it (articles from the time like yours[2] also say the opposite).
> On the other hand, pretty easy how such a div might trigger a less efficient path
I mean, sure, you can always fall off the fast path, but given how common transparent divs over video are, the battery benchmark should have come with even more caveats. Edge is the most battery efficient browser†!
† for playing fullscreen video††
†† Battery test not valid if the page doesn't use the exact layout youtube used in December 2017. Also not valid if testing vimeo, or twitch, or any porn site, or...
[1] https://news.ycombinator.com/item?id=18701430
[2] https://arstechnica.com/gadgets/2018/05/edge-still-boasts-be...
And while I agree that video overlays are common, I also think it's reasonable for such overlays to revert to a slightly less efficient path.
In my own web development activities I can point to hundreds upon hundreds of hidden, invisible, and obscured DOM elements that have no obvious reason to for existing to someone outside the code-base where you find the commen explaining the required work around, browser hack, or legacy constraint. I've also experienced wildly divergent performance on MS browsers compared to others when creating content, often from something as trivial as DOM order or composition.
Clearly Google owes me some money for my part in their ongoing conspiracy to hurt Edge. I'm flexible, I'll accept GCE credit :)
Hey, there's a new div in the DOM, the only possible reason for a change like that is so Chrome can advertise about beating Edge on a benchmark nobody cares about? Even though they never beat Edge on it and this "advertising" never took place?
This was the credulity I was talking about. These events didn't happen (you literally wrote the stories plural! about edge winning the benchmark) and the motivations make no sense. I'm not sure why you'd repeat it without even a warning that it may just be a narrative made up from grumblings about fixing a fast path heard third hand.
I do care about video playback battery performance. So much so, in fact, that I bought my current laptop specifically so it would last long when watching videos.
Also note that tablets, smartphones, the Macbook Air and the Surface are sold on their battery stamina, and specifically while watching videos. And how would you measure that? Youtube, of course!
Makes total sense, but if you're over-fitting for Youtube's exact layout in 2016, you're eventually going to have to update your optimizations. Sites don't stay the same forever.
Also, what can explain Edge failing to load Azure dashboard - was that a Google bug too? Ref: https://www.youtube.com/watch?v=5zMbfvEHlTU
Sure, and they did. And then next month it’ll be something else, and a new check. The next month it’ll be something else yet again, and yet another check. Pretty soon Microsoft’s codebase is littered with checks and guards against the random things Google does, and they’ll still always be a deploy behind. Google could keep this up for years.
Google of today is a collection of disjointed silos which don't work well together or they work together at all. The leadership of those silos is being aggressively staffed by "industry veterans" VPs and SVPs from Oracle, HP, Motorola and alikes. These folks build their little empires, not products. NIH spreads, internal "competition" starts, etc. This story should sound familiar to more experienced people from Microsoft... they've seen this development phase, they know what I am talking about... Microsoft's name for that was "IBM", Google simply calls that "Microsoft". And when you hear "We are not THAT yet" and people have need to say it, you probably turned into THAT.
Anyway, The idea of Chrome being so aligned with Youtube - over such minor gains over Edge - would today be just a wishful thinking. Until some major, major restructuring and changes to their recent corp "culture", Google will simply remain incapable of driving waaaaay more important product development changes across its product surfaces than this.
Given how easy it is to delete an offending div using the dev tools, it would be easily verified by web developers. There'd be a thousand blog posts and news stories saying "Google deliberately sabotages Edge on YouTube" and the public blowback would be pretty damaging I imagine.
As an aside- his points on why Chrome is a monoculture misses the point. Chrome is a monoculture for the same reason almost every other thing becomes at monoculture. It was, at one point, deserving of it as a product. Whether it was naturally the only one or the best. But now, they might not be the best out there. And when they go on to create barriers to competitors and lock-in, thereby making them artificially dominant, that is an anti trust case in the making, if the U.S. Justice Department had any teeth in that area.
It doesn't confirm Google's reasoning for the div
Because it's EVIL!
Also, have you tried opening Google.com, GMail, YouTube or Translate in Edge? You are bombarded with prompts to install Chrome. There is no way to disable them, not even when logged in.
Nothing is going to make me feel bad for Microsoft losing market share. This is the company that silently disabled microphone access for Chrome because it wasn't installed via the Microsoft store. I spent a month trying to figure out why my microphone suddenly wasn't working in any of my web apps. As much as I dislike what Google is doing, Microsoft has been doing far worse for much longer.
What's to stop "YouTube needs Genuine Chrome™ with Google Play® Support Services Installed"?
They could throw up a check and have "Youtube requires Chrome XX.X with the Evil-DRM plugin enabled" live whenever they want. It's the relevant market forces and ecosystem.
I worked on IE in the days when there were many crazy conspiracy theories about silverlight and IE collaborating to ruin the open web. This sounds similar.
Correlation does not imply causation: Yes, it might be true that companies make changes to their products that break stuff somewhere else. But to claim that it is done intentionally is very far fetched. Especially when you have to support so many different environments, it is close to impossible to thoroughly check all of them. Demanding that the performance is good even goes one step further than just demanding the service works.
- embrace and extend standards - secret apis - advocate for standards, then drop them for proprietary ones - perform hidden changes that make competitors look bad - then tout your advantages loudly
The only thing missing is outright paying people to not support your competitors.
Firefox, however, I feel bad for. Nerd advocacy was partially responsible for Chrome's rise to popularity, but the time has come to advocate for Firefox.
Seems counterproductive to me.
So, color me astonished, not.
The biggest feature difference for SharePoint cross-browser has historically been with the ActiveX controls. Say you had Word installed, there was a control to open documents with Word. As in, you could click save/view/edit rather than just whatever the browser default was. Or with Skype, to see a user's available/busy/away status next to their name on a SharePoint page. So if you're looking at a wiki or calendar for something, you might go "oh, the author is free, I can just ask." Chrome's plug-in model was much stricter than ActiveX. That's why you'd see some features in IE but not Chrome.
How is this productive?
They've already started. Google Meet (their version of Hangouts for enterprise) didn't work on non-Chrome browsers for a very long time. If you tried to do a video call with a non-Chrome browser, you were told to install Chrome and load the page in Chrome. The only reason they were able to get away with this is because Chrome has the high market share that it does. If they'd done this when Chrome had 10% market-share, the response from users would have been to stop using Google Meet. However, because they did this when Chrome has 70% market share (and climbing) there was hardly any outcry; those who didn't already have Chrome installed gave a resigned sigh and installed Chrome in order to participate in their work meetings.
Currently, all of Google's services work on non-Chrome browsers. But will that always be the case? I can very well imagine a world where Google starts making its services Chrome-only, citing, for example, that only V8 has the necessary Javascript performance to run Google's increasingly bloated webapps with adequate performance.
Like you said, it'll start as a slow drip, with the least popular and most obscure applications (for example: Google Play Music) being moved over first. Then, as users fail to object, they'll move over larger and larger applications. Even if they never make the "big-two" of YouTube and Google Search Chrome-only, they'll still be exerting a fair amount of pressure for users to switch to Chrome.
Google Earth is Chrome-only, because they use the Chrome-only NativeClient.
Google Hangouts dropped calling support on non-Chrome browsers for quite a while: https://news.ycombinator.com/item?id=15889018
YouTube (and perhaps GMail) is extra slow on non-Chrome browsers because they use a dropped-and-never-standardised feature that is available only on Chrome, and force a slow polyfill on Firefox (and perhaps Edge): https://twitter.com/cpeterso/status/1021626510296285185
I work on the Polymer team at Google, and have worked with YouTube on this. I can promise you that the folks at YouTube are working very hard on porting to the specs that are supported crossbrowser. Switching to the final versions of the specs is super high priority for all of us, there were just some changes between v0 and v1 that are hard to paper over, and as you might imagine, YouTube has a lot of code.
> Google Earth is Chrome-only, because they use the Chrome-only NativeClient
My understanding is that if it weren't for spectre, cross-browser Google Earth would very likely be shipping today. There is a web assembly version of Earth, but it needs threads and SharedArrayBuffer, which is disabled in most browsers today because of spectre-class security issues.
https://medium.com/google-earth/earth-on-web-the-road-to-cro...
https://developers.google.com/web/updates/2018/02/meltdown-s...
From my point of view, the moral of this story is that Chrome shouldn't be shipping v0 specs that are on by default.
It's not that people like me want to be cynical conspiracy theorists, it's just really frustrating to watch Google ship an unfinished API that's on by default, integrate it so tightly into its core products that it can't be easily updated after the spec changes, and then just kinda... sit on it. And it's really convenient that whenever Google messes up standards, it just happens to mess them up in a way that makes Chrome look better to normal users for all of its core products.
Heck, it's frustrating that Chrome is still shipping the v0 implementation. I don't want to be vindictive or bitter, but engineers on the Polymer team clearly thought the polyfill was fast enough for Firefox. They don't think it's fast enough that Chrome could be using it now?
I don't think I'm being a conspiracy theorist when I say that probably the reason why Chrome still ships with a working v0 implementation is because Youtube uses it. And it makes me feel weird to have a dominant browser deciding to contradict a standard because it makes a Google site fast. I think that's problematic and harmful for the open web.
So even though I know that the team's intentions are good, the intentions do nothing at all to mitigate or fix the harm. And I'm sure you can understand that when people talk about the dangers of a browser monoculture, it is exactly this kind of thing that we're afraid of. A lot of us feel like Google dev teams don't really have much respect for standards or community processes. Google tends to have an attitude that standards will always go the way it wants, and if other browsers are behind on that, we just need a little polyfill or stopgap or something until they catch up. Certainly they won't decide to go in a different direction.
Is that going to get better when Chrome has 95% market share? Won't Google devs feel even more emboldened to ship v0 implementations that disregard the standards process? Are there any new safeguards or internal policies being put into place to prevent devs working on Youtube or Gmail or Maps from building core infrastructure around browser APIs that haven't been standardized yet?
I'm sure the folks at YouTube are working very hard on porting to the Web standard, but the truth of the matter is:
1. Non-Polymer YouTube works just fine, and yet isn't served on Firefox and Edge;
2. Chrome shipped and continues to support a Chrome-only "standard", which is never going to be a Web standard, for some reason;
3. YouTube, a sibling product of Chrome, and supposedly a Web app, built a whole redesign around this when it wasn't even a Web standard, or even available in more than one browser, and now apparently can't do without, without dragging every browser that YouTube is not related to down.
On these counts, the apparent favouritism is clear.
> there were just some changes between v0 and v1 that are hard to paper over
I believe you. I also see that there's a polyfill for this. And yet, YouTube doesn't (need to) use it in the one browser that it's parent company makes?
> My understanding is that if it weren't for spectre, cross-browser Google Earth would very likely be shipping today. There is a web assembly version of Earth, but it needs threads and SharedArrayBuffer, which is disabled in most browsers today because of spectre-class security issues.
You mean, if it weren't for Spectre, a Web version of Google Earth would very likely be shipping today, using WebAssembly. Google Earth is currently available for the desktop in these forms: A native version, and a Chrome app. Yes, Chrome also happens to be a browser, but it is not just a browser, and Google Earth does (heavily) depend on its non-browser parts.
So, naturally, questions arise:
1. If it weren't for things like Google Earth and Hangouts, would Chrome's NativeClient still be around?
2. If it weren't for Chrome's NativeClient, could Google Earth and Hangouts have become the products that they have?
The answer to the second is easy: Hangouts did exist as an NPAPI plugin for a while, and does currently work on non-Chrome browsers via WebRTC, so it certainly could have used the exact same features on Chrome, and Google Earth has always had an installable, native, desktop version.
It's going to be unshipped around April.
Chrome shipped the v0 spec in order to prove out that the specifications were valuable and worth implementing. It took time to get the other browsers on board. Writing a major application like YouTube with the specs provided a lot of valuable feedback for the final version of the specification.
Today, the other browsers are very much on board with these specs, Firefox is even rewriting many parts of their UI with these same specs. Three years ago there was more skepticism, and by building real world applications we could figure out what works and what doesn't, and address the (very reasonable) questions that people had about their design.
> I believe you. I also see that there's a polyfill for this. And yet, YouTube doesn't (need to) use it in the one browser that it's parent company makes?
YouTube does actually use the Shadow DOM polyfill today, even in Chrome, and Shadow DOM is definitely the most complicated and arguably the most performance-critical spec involved. Polymer v1 uses the Shadow DOM polyfill by default even in Chrome because if it used native Shadow DOM it would be too easy to write an app that would only work properly in Chrome.
> You mean, if it weren't for Spectre, a Web version of Google Earth would very likely be shipping today, using WebAssembly.
Would you prefer that the NativeClient version of Google Earth not exist at all? The work that went into NativeClient has contributed to the wasm spec, and (I assume, but don't actually know) the NativeClient version of Google Earth was the basis of the wasm version.
Speaking just for myself, like, I get what you're saying, but I'm not sure how to actually translate it into action. If no one had used the v0 web component specs, then the v1 specs might never have gotten adopted at all, or at least would have been specified with way less experience on the table for how they need to work in the real world.
NativeClient is somewhat similar. It was a proposed standard that informed will (hopefully soon) be superceded by a final standard which could build on the lessons learned in building NativeClient.
Someone is going to be the first to ship a new feature. For a while, asm.js applications were really only usable in Firefox. They would technically run in other browsers through what amounted to a JS polyfill, but not very well. But Firefox's asm.js work was really good for the web, because they were able to gather a lot of real world info on how asm.js and similar techniques work in the wild.
Same thing with WebVR. As I recall, for a while Firefox was the only browser shipping experimental support for virtual reality in the web browser (someone correct me if I'm wrong here). Yes it's annoying when something works better in one browser than another, but how do you add new features to the web platform without experimentation and getting real world use?
The important thing is that the insights from shipping the experiment make it into a open specifications that are implemented cross browser.
Google Meet also appears to have updated to support the WebRTC spec (rather than the oddball implementation Chrome had) so long as your browser supports it: https://blog.mozilla.org/webrtc/firefox-is-now-supported-by-...
This is why Mozilla is pushing AV1 and VP8/VP9 so hard, being stuck with H.264 as the whole industry migrates to H.265 due to bandwidth savings is a major impediment, and the licensing body could easily extract usurious rent for H.265 if it becomes the only reasonable option: https://hacks.mozilla.org/2018/08/the-video-wars-of-2027/
And that article from Mozilla, I remember it, worst article from Mozilla for as long as I remember ( That is since Netscape Era ).
If that’s true, why are they a member of the AOM, which promotes the royalty free av1?
I think this is a repeat of the USB C engineering participation by Apple, they may roll it out to their tiny MacOS install base, but it could be years before AV1 is supported on iOS. Safari on iOS is where Apple likes to draw its line in the sand, it also happens to be where they have nearly 1 billion users, versus 70 million on MacOS: https://ngcodec.com/news/2018/10/9/whats-in-a-codec-hevc-ver...
What does Web Push have to do with WebRTC?
WRT VP8/VP9, bandwidth is much more of a concern than you make it out to be. Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low (say hello to congested towers, or fringe 700Mhz coverage where 500Kbps is all you get :P), thus the best compression possible ensures that video quality and usability is top notch.
By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs. Is it good for interop with a 2005 era deskphone? Sure, but not much else.
> Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low
I'm not using Google Meet on a cellular network. I'm using it on a wifi network. And if it comes to it, I'd rather have slightly worse video quality with H.264 than slightly better video quality with VP8/9 if it means it preserves my battery life (which is to say, set a network bandwidth target and then use whatever video quality meets that target).
> By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs.
It's apparently really hard to find an actual practical comparison of compression quality of H.264 vs VP8. What info I did find is about 8 years old now and itself was pretty wishy-washy. My vague impression of all of this is "lots of people think VP8 has better compression quality, but won't say by how much, while other people think you can get about the same results, but either way VP8 is rarely hardware-accelerated on mobile".
In any case, if you want better than H.264, how about H.265, which macOS and iOS both support? I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.
Great, I really don't care about Google's WebRTC app of the month, it is unlikely to be with us in 10 years.
Your root question about why Google hasn't supported Safari with their Meet product likely boils down to the codec wars, as without VP8/VP9 support, Safari does not support the WebRTC standard. A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center.
Another take is the failing tests listed here, Google could easily depend on a component that Safari has not implemented (once again not WebRTC spec compliant): https://wpt.fyi/results/webrtc?label=stable&aligned
> In any case, if you want better than H.264, how about H.265
H.265 is a patent encumbered, licensed codec that is only supported by Safari & Edge (if you download the H.265 codec manually on Win10). At this point, Apple, Mozilla, Google, Microsoft and others are working on AV1 as a successor: https://headjack.io/blog/hevc-vp9-vp10-dalaa-thor-netvc-futu...
> I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.
You can send literally anything in the SDP that you want, WebRTC is a forklift of traditional SIP onto the web, but with things like TLS enforced (otherwise idiots like the entire existing VoIP industry will run all signaling & calls over UDP with no crypto, then claim its "secure"). The only limitations you have are the codecs supported by your device, though you could totally write your own fairly complex codec in javascript :P
According to the page you linked, nobody is spec-compliant.
I'm going to guess that Google's lack of support for Safari boils down to video codec and nothing else.
> A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center.
Apple does not have any support for VP8/9, period. And I will be extremely surprised if they ever add support for a non-hardware-accelerated video codec. Apple believes in power efficiency over pretty much anything else, which makes hardware acceleration mandatory for something like this.
Last time I checked, Google Authenticator only works on Chrome.
Google Authenticator is available for Android, iPhone, and Blackberry, and not for any browser; there are a number of third-party implementations, however, including a Chrome/ChromeOS one.
https://www.theregister.co.uk/2018/02/13/telegram_messaging_...
https://www.theverge.com/2017/1/11/14237136/trump-leak-teleg...
https://gizmodo.com/why-you-should-stop-using-telegram-right...
But I did know that.
It was just that Everpedia used it for chat, and I was curious.
This would be solved if they did feature detection instead of browser sniffing, but given that the user agent hack works, they're very likely doing browser sniffing.
Better yet, they should probably wait to adopt new standards until things are actually standardized, instead of doing things as soon as they hit "experimental" status.
Put another way, isn't it OK for users to experience temporary discomfort and inconvenience? If it truly gets bad, someone else will eventually eat their lunch, and everyone (except Google!) is happy again. See: Microsoft.
Yes, but that was based on a comment that was twisted out of context, and is, moreover, demonstrably false.
> web will fail because of monoculture
Go ask a banana.