It might happen, but it hasn't happened with VP9. It also hasn't happened with Opus.
Furthermore the AV1 license is structured so that if you sue someone for using AV1, you lose your own rights to use AV1. Thus, only pure-troll entities will be able to initiate such lawsuits. That limitation didn't apply to previous codecs.
You mean: "no legitimate technical reason that I, not being a browser developer, can think of off the top of my head".
Keeping everything running on Windows XP is actually an enormous pain. All kinds of important improvements like faster rendering and more secure sandboxing rely on features that aren't present in XP. To preserve XP compatibility you have to add "if (windowsXP)" code paths (which in some cases means entirely different implementations of large chunks of functionality) and keep testing them, which means bloated and more fragile code as well as lots of extra work.
The H265 rollout has been slow because its licensing is such a disaster. Why would you be in a rush to ship H265 when you have no idea how much you will have to pay patent holders for the units you are shipping?
AV1 does not have this problem. It's a no-brainer to implement and ship it ASAP. Within two years all new chips will have it.
Soon it will become clear that H265 will see very little usage outside broadcasting. The H265 patent pools will drop any pretense of encouraging broad H265 adoption and focus on extracting maximum revenue from those vendors foolish enough to have shipped H265 in advance of a clear licensing story. As soon as the inevitability aura around H265 dissipates, the non-TV vendors will drop it like a hot potato.
It was Microsoft who drove the purchase price of browsers to zero, when they gave away IE to try to "cut off Netscape's air supply" in the famous phrase.
Google has never really "funded" Mozilla; they have always paid for search traffic, just like they pay Apple for iOS search traffic.
Getting an early start loading speculatively fetched data into the cache is a big part of the performance win from speculative execution. Throwing that away will be a significant performance hit.
Bitcoin's proof-of-work is not the only way to implement a blockchain. Real-life applications don't want PoW (and it's an environmental disaster), but you can do interesting blockchain things without it using known identities.
AOM uses a clever license that basically means you can't sue people over AOM codecs while at the same time using them yourself. More details: https://tech.slashdot.org/comm...
With all the backing AOM has, supporting its codecs will be mandatory for tech companies that make real products, so they will not want to sue AOM codec users.
Pure patent troll outfits can have a go, and some probably will. But AOM will fight, and probably win, perhaps buying off the plaintiffs if that becomes necessary.
Opus has been out for years and despite a lot of noise from holders of audio patents, Opus is fine.
Also, if AOM blesses the new image format, the AOM license kicks in, which says a) by using that AOM codec, you agree to license your patents to other users and b) if you sue anyone for using the codec, you lose your royalty-free rights to AOM members' patents covering the codec.
So if you sue users of an AOM codec, you'd better be a pure patent troll and not trying to use the format yourself, or you'll be countersued into oblivion. This reduces the pool of entities which can viably attack AOM codecs.
No doubt there are cases where it makes sense. But the Next Big Image Format needs to be a lot better than that. HEIC is, but it's patent encumbered. Hopefully this new AV1-based format will be even better, and patent-unencumbered too.
JPEG2000 compression isn't that much better than JPEG. In some cases it actually looks worse than JPEG at the same file size. See e.g. http://vterrain.org/Imagery/JP... No point in going to the trouble of deploying a new standard image format everywhere if you don't get huge gains.
Also JPEG2000 only aimed to be royalty-free for "Part 1", the core codec. The patent status of the other 13 parts of the standard is murky.
Mozilla developers like Anne know more about browser development than you do.
In Gecko, restricting new DOM APIs to secure contexts is simply a matter of adding an attribute to the WebIDL: https://github.com/mozilla/gec...
Probably something similar will be added to the CSS property list.
There is also a single method you can call on the internal interface of a 'window' object to determine if you're in a secure context. https://dxr.mozilla.org/mozill...
Selective disabling of new features is already standard practice. New features are almost always guarded by hidden preferences so they can be safely disabled just before release if a showstopper bug turns up, or so that they can be incrementally worked on over multiple releases without being shipped in a half-done state.
It makes snooping much more expensive and it makes passive undetectable snooping impossible. To snoop, they have to install software on the user's computer, or the target server, or else get a CA to generate a certificate they can use to MITM the connection. All of these things are expensive to do at scale, and detectable. In the latter case, the bad certificate can be recorded and constitutes proof of the CA's misbehavior; if a rogue CA is found to have misissued a certificate, there are consequences, as Symantec and Startcom found out.
Firefox hasn't applied the new approach to anything yet. Neither has Chrome. Chrome will probably follow Firefox's lead here.
Note that Anne's guidelines explicitly make an exception to allow a feature to work in insecure contexts if another major browser (Chrome) is already doing so. Mozilla isn't going to do anything suicidal like stop features from working in Firefox when they work in Chrome.
Among other reasons for TLS, anything accessible over the Internet via non-TLS HTTP can be hijacked for DDoS attacks via the "Great Cannon": https://en.wikipedia.org/wiki/...
It all depends on the complexity of the page. It is not difficult to find pages that are slow to render, especially if you are fullscreen on a 4K display, say. Maybe you don't visit such pages, but lots of users do.
This has nothing to do with tabs loading. It's about rendering what's already loaded.
Good browser performance already depends on predictive behavior, such as kicking of DNS lookups early when you hover over links. I don't know what you have against predictive behavior, but the alternative is a slower browsing experience.
Slashdot Mirror
Lots, of course. A few examples:
Microsoft: https://github.com/Azure/ioted...
Baidu: https://github.com/baidu/rust-...
Google: https://github.com/google/xi-e...
What are you talking about? Firefox doesn't implement anything related to SSDP.
Pocket doesn't "spy" nor are users forced to use it. You just made that up.
That feature has been designed and is being implemented --- slowly, since it's not the top of the priority list for various reasons.
It might happen, but it hasn't happened with VP9. It also hasn't happened with Opus.
Furthermore the AV1 license is structured so that if you sue someone for using AV1, you lose your own rights to use AV1. Thus, only pure-troll entities will be able to initiate such lawsuits. That limitation didn't apply to previous codecs.
You mean: "no legitimate technical reason that I, not being a browser developer, can think of off the top of my head".
Keeping everything running on Windows XP is actually an enormous pain. All kinds of important improvements like faster rendering and more secure sandboxing rely on features that aren't present in XP. To preserve XP compatibility you have to add "if (windowsXP)" code paths (which in some cases means entirely different implementations of large chunks of functionality) and keep testing them, which means bloated and more fragile code as well as lots of extra work.
The H265 rollout has been slow because its licensing is such a disaster. Why would you be in a rush to ship H265 when you have no idea how much you will have to pay patent holders for the units you are shipping?
AV1 does not have this problem. It's a no-brainer to implement and ship it ASAP. Within two years all new chips will have it.
Soon it will become clear that H265 will see very little usage outside broadcasting. The H265 patent pools will drop any pretense of encouraging broad H265 adoption and focus on extracting maximum revenue from those vendors foolish enough to have shipped H265 in advance of a clear licensing story. As soon as the inevitability aura around H265 dissipates, the non-TV vendors will drop it like a hot potato.
Google allows software decoding of VP9 in Chrome, so presumably they'd allow AV1.
A lot of people running browsers are on mains electricity where power consumption is not much of an issue, but bandwidth consumption is.
VP9 hasn't become dominant but it has been beating HEVC in many markets. http://1yy04i3k9fyt3vqjsf2mv61...
It was Microsoft who drove the purchase price of browsers to zero, when they gave away IE to try to "cut off Netscape's air supply" in the famous phrase.
Google has never really "funded" Mozilla; they have always paid for search traffic, just like they pay Apple for iOS search traffic.
Wow. That's basically a declaration of surrender by the chairman of MPEG. This is a great day for free software. It's been a long time coming.
Getting an early start loading speculatively fetched data into the cache is a big part of the performance win from speculative execution. Throwing that away will be a significant performance hit.
How long does the memory on a USB stick last?
Bitcoin's proof-of-work is not the only way to implement a blockchain. Real-life applications don't want PoW (and it's an environmental disaster), but you can do interesting blockchain things without it using known identities.
VP9 took off. Opus took off. I'm not sure why you'd say this.
AOM uses a clever license that basically means you can't sue people over AOM codecs while at the same time using them yourself. More details: https://tech.slashdot.org/comm...
With all the backing AOM has, supporting its codecs will be mandatory for tech companies that make real products, so they will not want to sue AOM codec users.
Pure patent troll outfits can have a go, and some probably will. But AOM will fight, and probably win, perhaps buying off the plaintiffs if that becomes necessary.
Opus has been out for years and despite a lot of noise from holders of audio patents, Opus is fine.
Also, if AOM blesses the new image format, the AOM license kicks in, which says a) by using that AOM codec, you agree to license your patents to other users and b) if you sue anyone for using the codec, you lose your royalty-free rights to AOM members' patents covering the codec.
So if you sue users of an AOM codec, you'd better be a pure patent troll and not trying to use the format yourself, or you'll be countersued into oblivion. This reduces the pool of entities which can viably attack AOM codecs.
No doubt there are cases where it makes sense. But the Next Big Image Format needs to be a lot better than that. HEIC is, but it's patent encumbered. Hopefully this new AV1-based format will be even better, and patent-unencumbered too.
JPEG2000 compression isn't that much better than JPEG. In some cases it actually looks worse than JPEG at the same file size. See e.g. http://vterrain.org/Imagery/JP...
No point in going to the trouble of deploying a new standard image format everywhere if you don't get huge gains.
Also JPEG2000 only aimed to be royalty-free for "Part 1", the core codec. The patent status of the other 13 parts of the standard is murky.
Since last year.
Mozilla developers like Anne know more about browser development than you do.
In Gecko, restricting new DOM APIs to secure contexts is simply a matter of adding an attribute to the WebIDL:
https://github.com/mozilla/gec...
Probably something similar will be added to the CSS property list.
There is also a single method you can call on the internal interface of a 'window' object to determine if you're in a secure context.
https://dxr.mozilla.org/mozill...
Selective disabling of new features is already standard practice. New features are almost always guarded by hidden preferences so they can be safely disabled just before release if a showstopper bug turns up, or so that they can be incrementally worked on over multiple releases without being shipped in a half-done state.
There's very little extra work required here.
It makes snooping much more expensive and it makes passive undetectable snooping impossible. To snoop, they have to install software on the user's computer, or the target server, or else get a CA to generate a certificate they can use to MITM the connection. All of these things are expensive to do at scale, and detectable. In the latter case, the bad certificate can be recorded and constitutes proof of the CA's misbehavior; if a rogue CA is found to have misissued a certificate, there are consequences, as Symantec and Startcom found out.
Firefox hasn't applied the new approach to anything yet. Neither has Chrome. Chrome will probably follow Firefox's lead here.
Note that Anne's guidelines explicitly make an exception to allow a feature to work in insecure contexts if another major browser (Chrome) is already doing so. Mozilla isn't going to do anything suicidal like stop features from working in Firefox when they work in Chrome.
Among other reasons for TLS, anything accessible over the Internet via non-TLS HTTP can be hijacked for DDoS attacks via the "Great Cannon": https://en.wikipedia.org/wiki/...
It all depends on the complexity of the page. It is not difficult to find pages that are slow to render, especially if you are fullscreen on a 4K display, say. Maybe you don't visit such pages, but lots of users do.
This has nothing to do with tabs loading. It's about rendering what's already loaded.
Good browser performance already depends on predictive behavior, such as kicking of DNS lookups early when you hover over links. I don't know what you have against predictive behavior, but the alternative is a slower browsing experience.