Well, in all honesty web workers are explicitly NOT like worker threads. In particular, they are shared-nothing, as opposed to the shared-memory model of worker threads. While it's possible to use worker threads in a shared-nothing manner with careful discipline, that's not how they're typically used.
All of which is to say that we _have_ learned something over the years, even if the "something" is that shared-memory multi-threaded programming is somewhat error-prone and pretty much impossible to debug sanely when something goes wrong...
Of course we have also learned that programmer/debugger convenience is worth a few machine cycles, and that works fine until you start trying to pump MB/s worth of data across that shared-nothing boundary. Then you discover that we do still have hardware limitations and start implementing some sort of COW setup.;)
> Are they really rendering everything with software?
Yes.
> No wonder they make a 3GHz quad-core feel like a 486.
I think you're remembering your 486 through rose-colored glasses... I remember how Really Fast it felt in 1992, and how slow the same exact machine felt doing the same tasks in 1997.
But yes, between huge images, alpha blending, fixed-position backgrounds (requiring recomposite on every scroll movement), etc using the CPU for your compositing does start to become a bottleneck.
> you have software tools to edit and encode H.264
Most such tools, and most H.264 encoders in cameras explicitly say that their licenses are valid for noncommercial use of the H.264 output only, if you actually read the licensing.
Of course videos on your homepage would in fact be noncommercial. But I'm curious about the bad faith argument the grandparent mentions...
Daylight savings time is just a matter of user presentation; it doesn't change what time the computer thinks it is now, because this last is measured as the amount of time elapsed since an arbitrary starting point around 1970. In particular, across DST boundaries nothing interesting happens to the computer's clock; it just keeps incrementing by 1 every ms.
Leap seconds change what time the computer thinks it is. In particular, they change the number of elapsed ms since that arbitrary starting point, by fiat.
If leap seconds were just a matter of user presentation, like DST, there would be no problem, because as far as computer timekeeping would be concerned they wouldn't really exist; they would just be an artifact of the way we humans like to see our times printed.
> which is the most standards-compliant browser engine on the market
That statement is false, on the face of it. For example, Webkit's support for CSS2.1 is probably the worst of the 4 major browser engines (Trident, Gecko, Webkit, Presto). It claims to implement all the bits, but does it with the most bugs. Similar for CSS3 Selectors (where it's the one engine of the 4 that claims to implement them but has known significant bugs in the implementation; the only one worse off is Trident, which has no support for them at all).
Of course if you define "standards" as "draft proposals published by Apple employees" the calculus can look different...
> The way I understand it, electrons don't move much slower than light.
Electrons move slowly.;)
Electrical signals (aka electromagnetic waves) in wires move at speeds that depend on the wire and the insulation around (and within, for coax) the wire. Speeds can be as high as 0.95c and as low as 0.4c with pretty typical wiring setups.
He disabled access to the http-accessible administration user interface from the WAN side. He did not disable all access (e.g. he left the "phone home to the hardcoded secure server IP for configuration updates" functionality, which is what Verizon presumably used here). Of course he can disable that too, if he wants to...
> but unless his terms of service clearly authorize Verizon's actions
They do, as mentioned elsewhere in this thread.
> They might lose a lot of customers if they did this, but it would be within their legal > rights to do so
I think we should consider ourselves lucky, for once, that Verizon's contract-writing lawyers are good enough that they can manage to fix a significant security problem, not lose customers, _and_ not do anything illegal all at the same time. Never thought I'd have a good thing to say about telco TOS contracts...
> No one is holding a gun to the person accessing a site
For government sites this is starting to not be true. If the law requires you to do something (e.g. file a tax return) and the only sane way to do it is through a web site (e.g. because it needs some obscure IRS form not at your local library and the IRS is only providing forms via its site), then in fact someone is holding a gun to you to access the site. That's what it means for the law to require something: a gun is being held.
> So what obligation does flickr have towards blind browsers
Probably none.
> The site is rather obviously designed for people that can see.
When viewing, sure (though it has more than just images; users can provide alt text for the images and other related information which could be of interest to someone who can't see the image). But as you yourself pointed out, flickr has both content consumption and content upload functionality. I know of several blind users who make use of flickr to post photos they take. Should the flickr upload UI be available to such users? Why or why not? They're just like any other user who takes photos and wants to post them for their family to see or whatever. Note that last I checked said flickr UI is in fact harder to use than it should be if you're not sighted.
The thing is that there's no good reason for a web page to be "designed from the ground up to be used by the not handicapped". In fact, the original design of the web is quite amenable to use by people who may be blind, for example.
Since I fully expect that some government websites will become required-to-use (by law) in the next decade or so (e.g. as it becomes impossible to get most IRS forms other than off the IRS website), those websites need to be accessible to everyone. The other option, of course is NOT requiring them to be used, but we're not heading that way as far as I can see.
Of course in the real world there are compromises; no one is suggesting that the IRS site be accessible to someone who is deaf, blind, and quadraplegic, if nothing else because the technology to do it via smell is simply not there.;) But making a reasonable effort to not exclude people who are blind or just nearsighted (e.g. by not using 5pt fonts; lots of nearsighted people there) or colorblind (a fairly large number of people there) doesn't seem unreasonable.
Or put another way, what's the point of a government website if a large fraction of its target audience can't use it? Perhaps the information should then be shared in some other way, not via the web.
> so do you think this would make a difference on a 12-core monster processor?
It depends on your workload and possibly your virus scanner setup. A number of virus scanners perform scans on every single file creation. If you're doing a lot of those (think compiling a large program), the virus scanner becomes _very_ noticeable. The same issue can arise with the OS search indexer, for that matter; disabling both for the relevant directories can give a noticeable performance boost to compiling. When I've tried doing that with a mozilla objdir, compile times got about 2-3x faster... Of course more cores _may_ mitigate the problem, though this isn't a task that parallelizes any better than compiling itself does.
1) "Undo Closed Tab" is present in at least three places (context menu, keyboard shortcut, main menu). 2) "Close Other Tabs" is right there in the tab context menu.
That's just the obvious things I use every day in a "vanilla Firefox" that were on your list...
This isn't money for finding bugs. This is money for, once you have found a bug, reporting it to Mozilla as opposed to selling it on the black market or just posting it on your blog so as to 0-day users.
That is, the assumption is that people are looking for bugs and are perhaps finding them. The bounty is to convince them to do things _after_ that in a way that does minimal harm to Mozilla's user.
Its not very easy to do the IP address thing. For one thing, often the browser has no idea what IP addresses are involved (e.g. if it uses a third-party networking library; something that's common with browsers that are the default on their OS, since they just use the OS-default network library). For another, even if you technically know surfacing that information can be... difficult. Firefox has this issue, for example; they're working on a patch along the lines you describe, and it requires adding a whole bunch of new APIs to propagate the information.
> How does your DNS stack pick up a new IP address for a host name once it's already been > resolved?
It doesn't. The way you do this is to return a list of two IP addresses for the hostname when it's first resolved; the first IP is your server and the second is the user's router.
Then you serve stuff up as normal. When you want to carry out an attack, you point the browser to a url that has your hostname (probably in an iframe that's part of your page) and have your server refuse the connection. When that happens the browser will fall back to the next IP in the list and try it (that's how round-robin DNS works), and load a page from the router; if you pick the path part of your url right, this would be the login page. Now the key here is that web browser security policies are based on hostnames, not IP addresses. So the router's login page is now same-origin with yours and you can run script that does things to it. Like filling in the default admin username/password and submitting the form, for example. Or direct XMLHttpRequest access with the right Cookie headers, whatever.
Changing the default password definitely helps.
Some browsers are working on changes that would deny attempts to connect from a public IP to one on the local network, no matter what the hostnames are. That would stop this cold.
> Competing browsers advance the state of the web art faster than a single dominant player.
OK, fair. Google's main concern is that the state of the web advance fast enough to stay ahead of Silverlight and company, as well as catch up as much as possible to actual desktop apps. Having multiple browsers may be beneficial here, indeed.
> Google wins if there's multiple high quality browsers.
Do they? They win if people visit Google properties. Whether that needs multiple high quality browsers is debatable. It probably does need _a_ high quality browser.
> Mozilla wins if there's multiple high quality browsers and Google keeps paying them.
Why is the Google part there a necessity? Mozilla wins (per their mission) if they can prevent a single entity from restricting what people can do on the web or how they use the web, whether that entity is Microsoft, Google, Apple, Facebook, or someone else. Right now things are going ok on the Microsoft front there; not necessarily as well for the other three I listed.
> Opera wins if companies continue to buy their browser engine for embedding, and Google > keeps paying them.
Wouldn't that be an "or" instead of an "and"? In any case, you seem to be assuming they can't find other revenue sources before the money in the bank runs out if Google stops paying them, just as you do for Mozilla. That's a hefty assumption.
> Apple wins if the browsers on their platforms are good enough to allow you to leave > Microsoft
Apple wins if they can sell you hardware. They win extra if they can control information flow on said hardware. They're doing a pretty good job of the latter on their mobile platforms, including use of all the tactics we saw coming from Microsoft in the late 1990s (coopting standards bodies by implementing stuff unilaterally and then proposing it for standardization, promoting their non-standard features for use on mobile-targeted sites so as to lock out other UAs from those sites, locking out competing rendering engines from their platform, etc). On the desktop, the situation is somewhat different, but the desktop market is a bit of a sideshow for Apple at this point, from what I can see.
Agreed on your characterization of IE on the strategic level; on the tactical level they're actually doing a really good job of implementing current standards. Other UAs have more breadth than IE8 (in the sense of implementing more features), but IE8 has quite good depth (in the sense of not creating buggy implementations); much better than some of the other rendering engines. In fact, they have a bit of a tendency to implement the letter of the spec even when the spec makes no sense as written.... That is to say, their nefarious strategic plan is actually advancing.;)
> for example, standards don't seem to have been Job One for some time
Standards have in fact been Job One, but the nice thing with standards is that there are so many to choose from. If you don't have the resources to implement them all, or think some of them are actively bad for the web (P3P comes to mind), you don't implement them. See also http://dbaron.org/log/2006-08#e20060818a
What has _not_ been Job One, unlike Apple, is making up new functionality and proposing it for standardization. Maybe it should have been; it's certainly an effective marketing technique for making it seem like you're ahead on standards.
Sort of. There have been several projects developed behind closed doors and then crash-landed in Webkit when done. In fact, that's happened with Safari's JS engine.
The 2008 information is there. The 2009 information can't be put up until the 2009 tax returns are filed, at the very least, which may well not have happened yet (depending on the exact fiscal year and extension situation; I'm not privy to the details).
Slashdot Mirror
1) Mozilla's goal is an open web, not "making a browser". Making a browser is a means to an end.
2) I'm curious about your use of "instead" instead of "in addition to".
Well, in all honesty web workers are explicitly NOT like worker threads. In particular, they are shared-nothing, as opposed to the shared-memory model of worker threads. While it's possible to use worker threads in a shared-nothing manner with careful discipline, that's not how they're typically used.
All of which is to say that we _have_ learned something over the years, even if the "something" is that shared-memory multi-threaded programming is somewhat error-prone and pretty much impossible to debug sanely when something goes wrong...
Of course we have also learned that programmer/debugger convenience is worth a few machine cycles, and that works fine until you start trying to pump MB/s worth of data across that shared-nothing boundary. Then you discover that we do still have hardware limitations and start implementing some sort of COW setup. ;)
> like we did in the 1990s?
Except back then we didn't...
> Are they really rendering everything with software?
Yes.
> No wonder they make a 3GHz quad-core feel like a 486.
I think you're remembering your 486 through rose-colored glasses... I remember how Really Fast it felt in 1992, and how slow the same exact machine felt doing the same tasks in 1997.
But yes, between huge images, alpha blending, fixed-position backgrounds (requiring recomposite on every scroll movement), etc using the CPU for your compositing does start to become a bottleneck.
> you have software tools to edit and encode H.264
Most such tools, and most H.264 encoders in cameras explicitly say that their licenses are valid for noncommercial use of the H.264 output only, if you actually read the licensing.
Of course videos on your homepage would in fact be noncommercial. But I'm curious about the bad faith argument the grandparent mentions...
Daylight savings time is just a matter of user presentation; it doesn't change what time the computer thinks it is now, because this last is measured as the amount of time elapsed since an arbitrary starting point around 1970. In particular, across DST boundaries nothing interesting happens to the computer's clock; it just keeps incrementing by 1 every ms.
Leap seconds change what time the computer thinks it is. In particular, they change the number of elapsed ms since that arbitrary starting point, by fiat.
If leap seconds were just a matter of user presentation, like DST, there would be no problem, because as far as computer timekeeping would be concerned they wouldn't really exist; they would just be an artifact of the way we humans like to see our times printed.
> which is the most standards-compliant browser engine on the market
That statement is false, on the face of it. For example, Webkit's support for CSS2.1 is probably the worst of the 4 major browser engines (Trident, Gecko, Webkit, Presto). It claims to implement all the bits, but does it with the most bugs. Similar for CSS3 Selectors (where it's the one engine of the 4 that claims to implement them but has known significant bugs in the implementation; the only one worse off is Trident, which has no support for them at all).
Of course if you define "standards" as "draft proposals published by Apple employees" the calculus can look different...
> This is problematic on slow links where every byte is precious (dial-up)
How is it more problematic than the default setup today, where the updates are downloaded automatically, but not applied automatically?
> This is problematic in managed environments where the end user does not have write-
> permission to the filesystem containing the software
Not any more so than the current behavior.
> I hope it can be disabled.
Reading comprehension?
> Isn't that basically what parent was saying?
Pretty much, except for the bit about how fast electrons move. They tend to move at speeds measured in millimeters per second.
> The way I understand it, electrons don't move much slower than light.
Electrons move slowly. ;)
Electrical signals (aka electromagnetic waves) in wires move at speeds that depend on the wire and the insulation around (and within, for coax) the wire. Speeds can be as high as 0.95c and as low as 0.4c with pretty typical wiring setups.
> He disabled access from the WAN side
He disabled access to the http-accessible administration user interface from the WAN side. He did not disable all access (e.g. he left the "phone home to the hardcoded secure server IP for configuration updates" functionality, which is what Verizon presumably used here). Of course he can disable that too, if he wants to...
> but unless his terms of service clearly authorize Verizon's actions
They do, as mentioned elsewhere in this thread.
> They might lose a lot of customers if they did this, but it would be within their legal
> rights to do so
I think we should consider ourselves lucky, for once, that Verizon's contract-writing lawyers are good enough that they can manage to fix a significant security problem, not lose customers, _and_ not do anything illegal all at the same time. Never thought I'd have a good thing to say about telco TOS contracts...
> No one is holding a gun to the person accessing a site
For government sites this is starting to not be true. If the law requires you to do something (e.g. file a tax return) and the only sane way to do it is through a web site (e.g. because it needs some obscure IRS form not at your local library and the IRS is only providing forms via its site), then in fact someone is holding a gun to you to access the site. That's what it means for the law to require something: a gun is being held.
> So what obligation does flickr have towards blind browsers
Probably none.
> The site is rather obviously designed for people that can see.
When viewing, sure (though it has more than just images; users can provide alt text for the images and other related information which could be of interest to someone who can't see the image). But as you yourself pointed out, flickr has both content consumption and content upload functionality. I know of several blind users who make use of flickr to post photos they take. Should the flickr upload UI be available to such users? Why or why not? They're just like any other user who takes photos and wants to post them for their family to see or whatever. Note that last I checked said flickr UI is in fact harder to use than it should be if you're not sighted.
The thing is that there's no good reason for a web page to be "designed from the ground up to be used by the not handicapped". In fact, the original design of the web is quite amenable to use by people who may be blind, for example.
Since I fully expect that some government websites will become required-to-use (by law) in the next decade or so (e.g. as it becomes impossible to get most IRS forms other than off the IRS website), those websites need to be accessible to everyone. The other option, of course is NOT requiring them to be used, but we're not heading that way as far as I can see.
Of course in the real world there are compromises; no one is suggesting that the IRS site be accessible to someone who is deaf, blind, and quadraplegic, if nothing else because the technology to do it via smell is simply not there. ;) But making a reasonable effort to not exclude people who are blind or just nearsighted (e.g. by not using 5pt fonts; lots of nearsighted people there) or colorblind (a fairly large number of people there) doesn't seem unreasonable.
Or put another way, what's the point of a government website if a large fraction of its target audience can't use it? Perhaps the information should then be shared in some other way, not via the web.
> so do you think this would make a difference on a 12-core monster processor?
It depends on your workload and possibly your virus scanner setup. A number of virus scanners perform scans on every single file creation. If you're doing a lot of those (think compiling a large program), the virus scanner becomes _very_ noticeable. The same issue can arise with the OS search indexer, for that matter; disabling both for the relevant directories can give a noticeable performance boost to compiling. When I've tried doing that with a mozilla objdir, compile times got about 2-3x faster... Of course more cores _may_ mitigate the problem, though this isn't a task that parallelizes any better than compiling itself does.
Your list contains at least two inaccuracies:
1) "Undo Closed Tab" is present in at least three places (context menu, keyboard shortcut, main menu).
2) "Close Other Tabs" is right there in the tab context menu.
That's just the obvious things I use every day in a "vanilla Firefox" that were on your list...
This isn't money for finding bugs. This is money for, once you have found a bug, reporting it to Mozilla as opposed to selling it on the black market or just posting it on your blog so as to 0-day users.
That is, the assumption is that people are looking for bugs and are perhaps finding them. The bounty is to convince them to do things _after_ that in a way that does minimal harm to Mozilla's user.
Its not very easy to do the IP address thing. For one thing, often the browser has no idea what IP addresses are involved (e.g. if it uses a third-party networking library; something that's common with browsers that are the default on their OS, since they just use the OS-default network library). For another, even if you technically know surfacing that information can be ... difficult. Firefox has this issue, for example; they're working on a patch along the lines you describe, and it requires adding a whole bunch of new APIs to propagate the information.
> How does your DNS stack pick up a new IP address for a host name once it's already been
> resolved?
It doesn't. The way you do this is to return a list of two IP addresses for the hostname when it's first resolved; the first IP is your server and the second is the user's router.
Then you serve stuff up as normal. When you want to carry out an attack, you point the browser to a url that has your hostname (probably in an iframe that's part of your page) and have your server refuse the connection. When that happens the browser will fall back to the next IP in the list and try it (that's how round-robin DNS works), and load a page from the router; if you pick the path part of your url right, this would be the login page. Now the key here is that web browser security policies are based on hostnames, not IP addresses. So the router's login page is now same-origin with yours and you can run script that does things to it. Like filling in the default admin username/password and submitting the form, for example. Or direct XMLHttpRequest access with the right Cookie headers, whatever.
Changing the default password definitely helps.
Some browsers are working on changes that would deny attempts to connect from a public IP to one on the local network, no matter what the hostnames are. That would stop this cold.
If Inkscape/Batik follow your proposal, why should anyone else (e.g. browser developers) care about what they cook up?
> Competing browsers advance the state of the web art faster than a single dominant player.
OK, fair. Google's main concern is that the state of the web advance fast enough to stay ahead of Silverlight and company, as well as catch up as much as possible to actual desktop apps. Having multiple browsers may be beneficial here, indeed.
> Google wins if there's multiple high quality browsers.
Do they? They win if people visit Google properties. Whether that needs multiple high quality browsers is debatable. It probably does need _a_ high quality browser.
> Mozilla wins if there's multiple high quality browsers and Google keeps paying them.
Why is the Google part there a necessity? Mozilla wins (per their mission) if they can prevent a single entity from restricting what people can do on the web or how they use the web, whether that entity is Microsoft, Google, Apple, Facebook, or someone else. Right now things are going ok on the Microsoft front there; not necessarily as well for the other three I listed.
> Opera wins if companies continue to buy their browser engine for embedding, and Google
> keeps paying them.
Wouldn't that be an "or" instead of an "and"? In any case, you seem to be assuming they can't find other revenue sources before the money in the bank runs out if Google stops paying them, just as you do for Mozilla. That's a hefty assumption.
> Apple wins if the browsers on their platforms are good enough to allow you to leave
> Microsoft
Apple wins if they can sell you hardware. They win extra if they can control information flow on said hardware. They're doing a pretty good job of the latter on their mobile platforms, including use of all the tactics we saw coming from Microsoft in the late 1990s (coopting standards bodies by implementing stuff unilaterally and then proposing it for standardization, promoting their non-standard features for use on mobile-targeted sites so as to lock out other UAs from those sites, locking out competing rendering engines from their platform, etc). On the desktop, the situation is somewhat different, but the desktop market is a bit of a sideshow for Apple at this point, from what I can see.
Agreed on your characterization of IE on the strategic level; on the tactical level they're actually doing a really good job of implementing current standards. Other UAs have more breadth than IE8 (in the sense of implementing more features), but IE8 has quite good depth (in the sense of not creating buggy implementations); much better than some of the other rendering engines. In fact, they have a bit of a tendency to implement the letter of the spec even when the spec makes no sense as written.... That is to say, their nefarious strategic plan is actually advancing. ;)
> That Mozilla will remove Google from the search engine dropdown?
Presumably not, since it's there because it's the search engine users want, not because of the money.
Note that in some locales, where Google gives worse results than other search engines, it's not the default search engine.
Now your point seems to be that if Google were to do this then Mozilla would lose revenue. This is probably true.
> for example, standards don't seem to have been Job One for some time
Standards have in fact been Job One, but the nice thing with standards is that there are so many to choose from. If you don't have the resources to implement them all, or think some of them are actively bad for the web (P3P comes to mind), you don't implement them. See also http://dbaron.org/log/2006-08#e20060818a
For the specific thing keeping Mozilla from a 100/100 score on Acid3, see http://weblogs.mozillazine.org/roc/archives/2010/06/not_implementin.html
What has _not_ been Job One, unlike Apple, is making up new functionality and proposing it for standardization. Maybe it should have been; it's certainly an effective marketing technique for making it seem like you're ahead on standards.
Sort of. There have been several projects developed behind closed doors and then crash-landed in Webkit when done. In fact, that's happened with Safari's JS engine.
> Where is such information?
On the page you linked to.
> The information here is getting stale:
The 2008 information is there. The 2009 information can't be put up until the 2009 tax returns are filed, at the very least, which may well not have happened yet (depending on the exact fiscal year and extension situation; I'm not privy to the details).