Microsoft may have billions of dollars, but I'd be interested to see how much of that went to the IE budget pre-Firefox. I tend to think not much
Really? How do you think Microsoft killed Netscape, if not by pouring far more money into IE than Netscape could hope to come up with?
IE6 was the best browser of its time, or at least a definite contender. It was clearly superior to contemporary Netscape. We forget this only because Microsoft let it molder for years, until it had been greatly outclassed by the competition. IE6 sucks now, but it didn't always — don't forget that.
How about applications people want and desktops that aren't user-hostile?
Not having to reboot is likely to be a feature mainly attractive for servers, not desktops. Although personally I'd like it for my desktop too, most desktop users reboot every day anyway. (If Ubuntu ships it by default in the server version they may as well do it for the desktop version too, though.)
In a semiring, the element "-b" need not exist. One straightforward example is the natural numbers 0, 1, 2,...: there's no number x such that 1 + x = 0, i.e., such that x = -1. Likewise, in a ring or semiring, 1/b need not exist. Again using the natural numbers, there is no natural number equal to 1/2. You don't even have to have any 0 or 1 element in a semiring (0 is required in rings, though).
Of course, the natural numbers can be extended to a field, where everything has a negative and everything except 0 has a reciprocal. But not all rings or semirings can be extended to fields. Consider the set of 32-bit integers with operations ^ (in place of +) and & (in place of *). 0 takes the place of 0 (since n ^ 0 == n for all n), and 0xFFFFFFFF takes the place of 1 (since n & 0xFFFFFFFF == n for all n).
Now, 1 & 2 == 0. If in any extension of this ring there were some n so that n & 1 == 0xFFFFFFFF (i.e., there were an inverse for 1 under the operation &), we would have 0 == n & 0 == n & (1 & 2) == (n & 1) & 2 == 0xFFFFFFFF & 2 == 2, a contradiction. Therefore, 1 cannot have any inverse under &, in any extension of this ring.
Man, we need more Slashdot articles involving real mathematics.
If I found a member of staff stripping a child? Citizen's arrest under Section 24 of the Police and Criminal Evidence Act as being an indictable offense.
According to Wikipedia, for your arrest to be lawful under the act you cite, you must have "reasonable grounds for believing that the arrest is necessary to prevent one of the following":
The person causing physical injury to himself or others
The person suffering physical injury
The person causing loss of or damage to property
The person absconding before a constable can assume responsibility for him
And it also can't be reasonably practicable for a constable to make the arrest. Neither of those conditions hold in this case. Definitely not the second.
It looks to me like trying citizen's arrest is a bad idea unless you're really sure it's absolutely necessary. Call the cops instead: they have more immunities, and know the law better.
It's also worth pointing out that in the present case, anyone who did what you suggest would have been simply wrong if the Supreme Court had happened to reject this particular appeal. The appeals court's ruling would have stood, and the conduct would have been lawful, so you'd have been guilty of wrongful arrest even if otherwise followed correct procedure for citizens' arrest.
Could you just explain your sentence "Of course, the one running the code would be able to figure out exactly what algorithm you're using."
I don't think it means what I (currently) think it means.
Well, to be honest I'm mostly guessing here, with no theoretical knowledge of cryptography (only knowledge of abstract algebra). If I understand correctly, there will be a one-to-one correspondence between the two binary operations on plaintext, and the two binary operations on ciphertext. That's what a homomorphism means, usually. So the processor will know the sequence of ciphertext operations, and if they know how those map to plaintext operations they'll know what they're doing to the plaintext, even if they don't know what the plaintext actually is.
Also, I should point out that not all (semi)ring operations are created equal. For instance, you can't have a homomorphism from the integers under ^ and & to the integers under + and *, unless it maps everything to zero. Since it's a homomorphism, you have f(x) = (f(x) + f(x))/2 = f(x ^ x)/2 = f(0)/2 = 0 for all x. In this case you can only have a nontrivial homomorphism the other way around, and only one of those -- all even numbers will get mapped to 0 (f(2n) = f(n + n) = f(n) ^ f(n) = 0) and all odd numbers will get mapped to f(1) (same logic). (I'm assuming ring here instead of semiring, but semiring is similar.)
So I'd imagine a lot depends on the exact operations supported on both sides, not just the fact that there is some ring homomorphism. Not to mention, of course, that it's not really a ring homomorphism: Wikipedia says there's a limit on the number of multiplications you can do before you have to re-encrypt it.
But I could be completely wrong on a lot of this. I haven't tried reading the actual paper.
They can, AFAICT. F must be expressed in terms of two binary operations that distribute (like * and +, or & and ^). The translated function G will consist of just replacing each instance of * with & and + with ^, or whatever the equivalent operations are. So you know exactly what they're doing.
. . . I'm not so sure about this, actually. You might not know what the binary operations actually signify. You could probably gain some info in any event, but the point is it might be a lot less than you'd gain if you could decrypt the data, if the method is actually secure.
So I don't see how the operations available can be as much as the usual operators on reals.
The idea seems to make the operations map to something like & and ^, so that you can recover all logical operators and make a virtual computer using them. & and ^ on the integers may not seem as powerful as * and + on integers/floating points/etc., but you can easily encode the latter as the former.
And then I could decrypt CryptB to get the B I wanted. Since MBI only ever have CryptA, function G and CryptB, I don't leak input A or output B to them (I'm not sure off the top of my head whether they can derive F from G)
They can, AFAICT. F must be expressed in terms of two binary operations that distribute (like * and +, or & and ^). The translated function G will consist of just replacing each instance of * with & and + with ^, or whatever the equivalent operations are. So you know exactly what they're doing.
I could have been wrong there, not actually a cryptographer.
Neither am I, but I'm a grad student in math, and I know my homomorphisms.:)
Here's a very simplified example of a homomorphism. I define a function
f(x) = 3x
This function is a homomorphism on numbers under addition. Its image "preserves" the addition operation. What I mean more precisely is
f(a) + f(b) = f(a + b)
That's pretty easy to verify for the function I've given.
But examples like you gave (semigroup homomorphisms) have existed for a long time. Basic RSA has that property. The key advance here is that you have a semiring homomorphism, where it preserves two operations, one of which distributes over the other. Like multiplication and addition, or bitwise and and xor. (For those who don't follow: x*(y + z) = x*y + x*z, x & (y ^ z) = (x & y) ^ (x & z). If you don't believe the second identity, try all possibilities.)
An example of a semiring homomorphism on the reals is f(x) = -x. Then f(x + y) = -(x + y) = f(x) + f(y), and f(xy) = (-x)(-y) = xy = f(x)f(y). (Unless you believe in Time Cube.)
It seems distributivity is enough to do complicated calculations. You could simulate and and xor gates, I guess. Then you could get ~x = x ^ -1, x | y = ~(~x & ~y), etc.: all possible binary operations. That's enough to build a virtual computer right there, all operating on encrypted data.
Of course, the one running the code would be able to figure out exactly what algorithm you're using. So it's not perfect. But it's pretty cool regardless.
No. The operations you get are addition and multiplication, that's it. Given E(x) and E(y), you can compute E(x + y) or E(xy), nothing else. And you do this without ever learning x or y. RTFWA.
The reason for the terminology is that the encryption function E is a ring homomorphism between plaintext and ciphertext. Some operation of addition is defined on both plaintext and ciphertext such that if x and y are plaintext, f(x + y) = f(x) + f(y). (The "+" on the left is addition of plaintext, the "+" on the right is addition of ciphertext: two totally different operations.) Multiplication is similar. You don't get to apply arbitrary homomorphisms to the data, it's the (predetermined) encryption function that's the homomorphism.
Actually, I don't see any mention of subtraction -- so maybe it's really a semiring homomorphism. With an actual ring homomorphism you'd also have f(x - y) = f(x) - f(y), and some 0 element with f(0) = 0. And maybe f(1) = 1, depending on definition.
How difficult is it to scream 'get out of my pants you paedophile!' ?
It's not difficult to hit yourself on the head with a hammer either, but there's a reason most people don't do it. Challenging authority figures will, by definition of authority, risk getting you into trouble.
Google have published articles stating that they could not use ogg for YouTube because it would double their bandwidth costs to maintain the quality they get from h264.
Chris DiBona said that on the whatwg list, but he's the open-source program manager at Google, not (AFAIK) part of YouTube specifically. As far as I know, it's not clear if he was giving official estimates from the YouTube team or speaking off the cuff. (It very much sounded like he was speaking off the cuff.) I'm not aware of any articles that Google has published about how much bandwidth Theora would use — could you provide links?
They want the standard to include h264 video.
Could you provide any source for that? Because various Google employees explained on the whatwg list why Chrome supported H.264, I've never heard of any of them advocating that the HTML 5 standard require it.
(Yeah, I know, this is Slashdot. I should replace "could you provide links?" with "you're making stuff up"/"that's BS"/etc., but I can't be bothered.)
No, the OSNews article does not want people to download the video instead. It merely summaries my letter, which asks that Mozilla do not advocate JavaScript to do video fallbacks, but instead use my code (Video for Everybody) that does the same thing even better and without any JavaScript.
What if I don't want to encode video in proprietary H.264 format? What happens if a browser (I don't know, IE9?) ships with support for <video>, but doesn't support either Theora or H.264, only some third format? Does your solution break in those cases?
You can probably guess that I personally am going to disable the HTML5 A/V elements and continue downloading video manually. That aside, browser based audio/video should provide basic playback functionality for the user without javascript enabled. The functionality should also be easily disabled or switched into "prompt to download" mode
All of this is already the case. Try out Chrome on Windows, or Firefox 3.5 on (AFAIK) any platform. You don't need JavaScript enabled (unless the page author is a jerk, but that's always true), and you can download from the context menu as you'd expect.
This has nothing to do with HTML 5 or the video tag. The javascript is used to create a fallback path for users who don't have a particular codec installed. It is not compulsory. Most linux machines install ogg theora with a media player package anyway, it's the rest of the world that need to download it.
<video> support in all browsers is cross-platform (except Chrome, which AFAIK doesn't support audio/video yet except on Windows, but that's an omission they're working on fixing). The browser doesn't have to rely on system libraries for decoding Theora any more than for decoding JPEG. Firefox 3.5 or recent Chrome supports Theora on Windows just as well as Linux. Better in Chrome's case for now, as noted.
Why is this even happening?
Surely video should never show it's innerHTML unless the tag isn't understood? Just like Iframe, just like Object, just like Embed, etc.
This is exactly correct. The HTML 5 standard specifies that "Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browser informing them of how to access the video contents." JavaScript is therefore not theoretically necessary for fallback to work.
However, if the browser supports <video> but not the specific codec used, I'm not aware of any way to arrange for fallback without JavaScript. This is the situation that, for instance, Wikimedia is in: it refuses to use H.264, only Theora, so it can't just use plain old <video> and rely on element-level fallback. Safari wouldn't work right in that case.
Some random Mozilla Hacks (note the word Hacks) blogger posts some code that web developers can use to implement HTML5 video (which does not use javascript, contrary to the implications in this article and summary?)
HTML5 video does provide a rich JavaScript API to allow programmatic manipulation of the video by script. This is, in fact, potentially a great advantage it has over Flash and other solutions. So it can use JavaScript, although it doesn't require it for basic functionality (e.g., "when the page loads, download and display a video with controls to allow the user to play and pause it").
My understanding is that the reason that people use flash and silverlight for video is so that people cannot save, reuse, and redistribute the content.
People use Flash because there's no easier and more widely-supported way to embed video into pages.
Even if these are not used for DRM consideration, flash is often a much smaller file than the other codecs.
Flash is not a codec. <video> can support any codec just as well as Flash can.
I can download the file and play it trough VLC, an open source solution.
People want to embed videos in a page, not just make them available for download. Compare how convenient PDF and HTML are: HTML is right there in your browser, integrated and customizable without having to use another app.
Basically, any major media company that buys into HTML 5 video tag will be strangled by the advocates who pushed it on them in the first place, monetarily. When the production studios offering the content find out that a free video application that plays their content without commercials (hypothetically) exists, they will pull out and said video site will collapse.
Such an app could be written for Flash video too, and probably has been.
Furthermore, there will be a minor codec war. Firefox will probably only support theora, Safari will only use h.264 (Apple will flatly refuse to use theora), same for google chrome, perhaps. Then, Microsoft will support the tag in IE, but provide support for WMV in the video tag (and possibly h.264 if we're lucky, since it's now licensed in Windows 7).
Google already supports Theora and Vorbis in Chrome (as well as H.264). Apple doesn't, but has previously claimed this is because of the risk of getting sued, and that's getting flimsier every day Google doesn't get sued, so we'll have to see how that plays out. God only knows what Microsoft will do; but hopefully the worst will be that you provide one type of content to IE, and one type to everyone else . . . just as with the rest of the web.
So, the video tag will slowly become just as crazy as the plugin-based video players of Web 1.0... except they will be written in slow javascript instead of the fast native code of the past. Primarily, because no one has agreed on how to do it so it isn't a standard.
Nothing performance-sensitive is written in JavaScript here. Everything involved in actually playing the video is native code.
Can you imagine going to a web site from a corporate locked down machine and attempting to install some untrusted codec?
All browsers that support <video> package the codecs they support in the default download. No user downloads are necessary. In the worst case, Flash can still be used as a fallback until all common browsers support <video>. After then, the author will just have to provide video in as many formats as necessary (hopefully, one) to ensure it will play in all browsers.
Google and apple would like them to be h264/aac, because everyone uses that already, even more recent people using flash.
Mozilla would like them to be ogg theora/vorbis, because they're open, even though nothing actually supports them.
Google Chrome supports OGG out of the box, as well as H.264. I don't think it's correct to cast them as opponents of OGG.
Unfortunately, parts of CSS have been raised to Final Call, then lowered back to draft status before. For example, CSS 2.1 has had that "honor", so it's impossible for anyone to say that this won't happen.
Sure. But again, the changes made are generally the ones that the implementers themselves approve of, and rarely to never waste a lot of effort by anyone. CSS2.1 has received clarifications and has had some unimplemented features cut; it hasn't dramatically changed already-implemented features. Individual features in a CSS spec can be much more stable than the spec as a whole.
Who uses Java applets? I know that Facebook uses one for their image uploads, and last I heard they were pretty big.
Wikipedia uses Java instead of Flash for playing audio and video (if your browser doesn't support <audio>/<video>), mainly because Java is open-source and Flash is not.
So you're going to give me built-in AdBlock Plus, Noscript, Flashblock and Element Hiding Helper?
No?
Then I'm sorry, but most people who care about plugins in the first place, just won't bother.
A "plugin", in web browser jargon, is an application that uses the simple, cross-browser NPAPI. Flash, Java, Silverlight, and Adobe Reader are good examples of plugins.
Plugins are very limited in what they can do: for instance, they can get direct input from the user and do direct output to part of the screen that the browser gives them. If you pay attention, you'll notice that things like Flash often are out of sync a bit with the rest of the page layout, like being drawn on top of everything even if they should be cut off. Plugins can't easily interface with the browser's UI or make other complicated changes. The NPAPI doesn't expose higher-level details like that to them. Plugins are invoked only when a particular media type needs to be handled, and exit when they're no longer needed. They can't be used for anything other than handling particular media types.
Since NPAPI is standard and stable, a given plugin can (AFAIK) run in any browser on the target platform that supports NPAPI (meaning everything except IE, as usual in web development). They also don't care what browser version you use them on. But they pay for this with inflexibility.
AdBlock Plus, Flashblock, and Element Hiding Helper are all examples of extensions, not plugins. You'll notice that in Firefox, there are separate tabs for "Extensions" and "Plugins" in the Add-ons window. Extensions can do much more than plugins. They have access to a large collection of hooks, and can run continuously. They can do things like edit menus, dynamically alter rendered content, and so on. But they pay for this by being browser-specific, and not even always being compatible between versions of the same browser.
Plugins are what the GP was objecting to, and plugins are bad. They're only really needed to handle nonstandard formats like Flash: if the format were openly specified, support could be integrated directly in the browser (as with HTML5's canvas, video, etc.). Plugins are always native compiled code, and so can introduce crashes, memory leaks, and serious security vulnerabilities if not well-written, and the NPAPI makes it hard to cordon them off into their own process to prevent this. Most plugins are closed-source and proprietary, even if you use an open-source browser or operating system.
Extensions are a totally different story. Extensions are most often written in JavaScript, so they introduce no special stability problems and are automatically at least visible-source. Firefox extensions are mostly open-source. The worst you can say for extensions is that they're often slow, and the popular ones should usually be integrated into the browser proper.
So extensions are okay. But if plugins were to die in favor of open standards, the web would be a much better place for it.
Acid 3 is, unfortunately, heavily dependent upon CSS3 functionality, which isn't officially standard yet and could change. So claiming that Acid3 is some kind of test only tests if you're compliant with drafts.
Bzzt. The only part of CSS3 that Acid3 tests is Selectors, which has been in Last Call since 2005, and hasn't been a draft since 2000. 92/100 tests are unrelated to CSS. As for Selectors, Last Call means that it's only open for final adjustments, not major reworking. No significant changes are likely to occur: all objections have been hashed out over the past four years, and further functionality is deferred to CSS4.
In particular, anyone even remotely familiar with the CSS WG's development process (e.g., by reading www-style) knows that it's very reluctant to change anything that's already interoperably implemented. Even if something is nominally a draft, any part that's been implemented is very likely to remain stable, with only adjustments to details and corner cases (and only then if implementers are okay with it). The entire Selectors specification has been interoperably implemented by multiple browsers for a long time now.
The people writing these standards are mostly the implementers (i.e., browser authors). They aren't going to implement a feature and then screw themselves over by gratuitously changing it after the fact.
Slashdot Mirror
Microsoft may have billions of dollars, but I'd be interested to see how much of that went to the IE budget pre-Firefox. I tend to think not much
Really? How do you think Microsoft killed Netscape, if not by pouring far more money into IE than Netscape could hope to come up with?
IE6 was the best browser of its time, or at least a definite contender. It was clearly superior to contemporary Netscape. We forget this only because Microsoft let it molder for years, until it had been greatly outclassed by the competition. IE6 sucks now, but it didn't always — don't forget that.
Yeah, great. No restarts.
How about applications people want and desktops that aren't user-hostile?
Not having to reboot is likely to be a feature mainly attractive for servers, not desktops. Although personally I'd like it for my desktop too, most desktop users reboot every day anyway. (If Ubuntu ships it by default in the server version they may as well do it for the desktop version too, though.)
a - b == a + (-b)
a/b == a*1/b
In a semiring, the element "-b" need not exist. One straightforward example is the natural numbers 0, 1, 2, ...: there's no number x such that 1 + x = 0, i.e., such that x = -1. Likewise, in a ring or semiring, 1/b need not exist. Again using the natural numbers, there is no natural number equal to 1/2. You don't even have to have any 0 or 1 element in a semiring (0 is required in rings, though).
Of course, the natural numbers can be extended to a field, where everything has a negative and everything except 0 has a reciprocal. But not all rings or semirings can be extended to fields. Consider the set of 32-bit integers with operations ^ (in place of +) and & (in place of *). 0 takes the place of 0 (since n ^ 0 == n for all n), and 0xFFFFFFFF takes the place of 1 (since n & 0xFFFFFFFF == n for all n).
Now, 1 & 2 == 0. If in any extension of this ring there were some n so that n & 1 == 0xFFFFFFFF (i.e., there were an inverse for 1 under the operation &), we would have 0 == n & 0 == n & (1 & 2) == (n & 1) & 2 == 0xFFFFFFFF & 2 == 2, a contradiction. Therefore, 1 cannot have any inverse under &, in any extension of this ring.
Man, we need more Slashdot articles involving real mathematics.
If I found a member of staff stripping a child? Citizen's arrest under Section 24 of the Police and Criminal Evidence Act as being an indictable offense.
According to Wikipedia, for your arrest to be lawful under the act you cite, you must have "reasonable grounds for believing that the arrest is necessary to prevent one of the following":
And it also can't be reasonably practicable for a constable to make the arrest. Neither of those conditions hold in this case. Definitely not the second.
It looks to me like trying citizen's arrest is a bad idea unless you're really sure it's absolutely necessary. Call the cops instead: they have more immunities, and know the law better.
It's also worth pointing out that in the present case, anyone who did what you suggest would have been simply wrong if the Supreme Court had happened to reject this particular appeal. The appeals court's ruling would have stood, and the conduct would have been lawful, so you'd have been guilty of wrongful arrest even if otherwise followed correct procedure for citizens' arrest.
Could you just explain your sentence "Of course, the one running the code would be able to figure out exactly what algorithm you're using." I don't think it means what I (currently) think it means.
Well, to be honest I'm mostly guessing here, with no theoretical knowledge of cryptography (only knowledge of abstract algebra). If I understand correctly, there will be a one-to-one correspondence between the two binary operations on plaintext, and the two binary operations on ciphertext. That's what a homomorphism means, usually. So the processor will know the sequence of ciphertext operations, and if they know how those map to plaintext operations they'll know what they're doing to the plaintext, even if they don't know what the plaintext actually is.
Also, I should point out that not all (semi)ring operations are created equal. For instance, you can't have a homomorphism from the integers under ^ and & to the integers under + and *, unless it maps everything to zero. Since it's a homomorphism, you have f(x) = (f(x) + f(x))/2 = f(x ^ x)/2 = f(0)/2 = 0 for all x. In this case you can only have a nontrivial homomorphism the other way around, and only one of those -- all even numbers will get mapped to 0 (f(2n) = f(n + n) = f(n) ^ f(n) = 0) and all odd numbers will get mapped to f(1) (same logic). (I'm assuming ring here instead of semiring, but semiring is similar.)
So I'd imagine a lot depends on the exact operations supported on both sides, not just the fact that there is some ring homomorphism. Not to mention, of course, that it's not really a ring homomorphism: Wikipedia says there's a limit on the number of multiplications you can do before you have to re-encrypt it.
But I could be completely wrong on a lot of this. I haven't tried reading the actual paper.
They can, AFAICT. F must be expressed in terms of two binary operations that distribute (like * and +, or & and ^). The translated function G will consist of just replacing each instance of * with & and + with ^, or whatever the equivalent operations are. So you know exactly what they're doing.
. . . I'm not so sure about this, actually. You might not know what the binary operations actually signify. You could probably gain some info in any event, but the point is it might be a lot less than you'd gain if you could decrypt the data, if the method is actually secure.
So I don't see how the operations available can be as much as the usual operators on reals.
The idea seems to make the operations map to something like & and ^, so that you can recover all logical operators and make a virtual computer using them. & and ^ on the integers may not seem as powerful as * and + on integers/floating points/etc., but you can easily encode the latter as the former.
And then I could decrypt CryptB to get the B I wanted. Since MBI only ever have CryptA, function G and CryptB, I don't leak input A or output B to them (I'm not sure off the top of my head whether they can derive F from G)
They can, AFAICT. F must be expressed in terms of two binary operations that distribute (like * and +, or & and ^). The translated function G will consist of just replacing each instance of * with & and + with ^, or whatever the equivalent operations are. So you know exactly what they're doing.
I could have been wrong there, not actually a cryptographer.
Neither am I, but I'm a grad student in math, and I know my homomorphisms. :)
Here's a very simplified example of a homomorphism. I define a function
f(x) = 3x
This function is a homomorphism on numbers under addition. Its image "preserves" the addition operation. What I mean more precisely is
f(a) + f(b) = f(a + b)
That's pretty easy to verify for the function I've given.
But examples like you gave (semigroup homomorphisms) have existed for a long time. Basic RSA has that property. The key advance here is that you have a semiring homomorphism, where it preserves two operations, one of which distributes over the other. Like multiplication and addition, or bitwise and and xor. (For those who don't follow: x*(y + z) = x*y + x*z, x & (y ^ z) = (x & y) ^ (x & z). If you don't believe the second identity, try all possibilities.)
An example of a semiring homomorphism on the reals is f(x) = -x. Then f(x + y) = -(x + y) = f(x) + f(y), and f(xy) = (-x)(-y) = xy = f(x)f(y). (Unless you believe in Time Cube.)
It seems distributivity is enough to do complicated calculations. You could simulate and and xor gates, I guess. Then you could get ~x = x ^ -1, x | y = ~(~x & ~y), etc.: all possible binary operations. That's enough to build a virtual computer right there, all operating on encrypted data.
Of course, the one running the code would be able to figure out exactly what algorithm you're using. So it's not perfect. But it's pretty cool regardless.
f(x) = x
No. The operations you get are addition and multiplication, that's it. Given E(x) and E(y), you can compute E(x + y) or E(xy), nothing else. And you do this without ever learning x or y. RTFWA.
The reason for the terminology is that the encryption function E is a ring homomorphism between plaintext and ciphertext. Some operation of addition is defined on both plaintext and ciphertext such that if x and y are plaintext, f(x + y) = f(x) + f(y). (The "+" on the left is addition of plaintext, the "+" on the right is addition of ciphertext: two totally different operations.) Multiplication is similar. You don't get to apply arbitrary homomorphisms to the data, it's the (predetermined) encryption function that's the homomorphism.
Actually, I don't see any mention of subtraction -- so maybe it's really a semiring homomorphism. With an actual ring homomorphism you'd also have f(x - y) = f(x) - f(y), and some 0 element with f(0) = 0. And maybe f(1) = 1, depending on definition.
How difficult is it to scream 'get out of my pants you paedophile!' ?
It's not difficult to hit yourself on the head with a hammer either, but there's a reason most people don't do it. Challenging authority figures will, by definition of authority, risk getting you into trouble.
Google have published articles stating that they could not use ogg for YouTube because it would double their bandwidth costs to maintain the quality they get from h264.
Chris DiBona said that on the whatwg list, but he's the open-source program manager at Google, not (AFAIK) part of YouTube specifically. As far as I know, it's not clear if he was giving official estimates from the YouTube team or speaking off the cuff. (It very much sounded like he was speaking off the cuff.) I'm not aware of any articles that Google has published about how much bandwidth Theora would use — could you provide links?
They want the standard to include h264 video.
Could you provide any source for that? Because various Google employees explained on the whatwg list why Chrome supported H.264, I've never heard of any of them advocating that the HTML 5 standard require it.
(Yeah, I know, this is Slashdot. I should replace "could you provide links?" with "you're making stuff up"/"that's BS"/etc., but I can't be bothered.)
No, the OSNews article does not want people to download the video instead. It merely summaries my letter, which asks that Mozilla do not advocate JavaScript to do video fallbacks, but instead use my code (Video for Everybody) that does the same thing even better and without any JavaScript.
What if I don't want to encode video in proprietary H.264 format? What happens if a browser (I don't know, IE9?) ships with support for <video>, but doesn't support either Theora or H.264, only some third format? Does your solution break in those cases?
You can probably guess that I personally am going to disable the HTML5 A/V elements and continue downloading video manually. That aside, browser based audio/video should provide basic playback functionality for the user without javascript enabled. The functionality should also be easily disabled or switched into "prompt to download" mode
All of this is already the case. Try out Chrome on Windows, or Firefox 3.5 on (AFAIK) any platform. You don't need JavaScript enabled (unless the page author is a jerk, but that's always true), and you can download from the context menu as you'd expect.
This has nothing to do with HTML 5 or the video tag. The javascript is used to create a fallback path for users who don't have a particular codec installed. It is not compulsory. Most linux machines install ogg theora with a media player package anyway, it's the rest of the world that need to download it.
<video> support in all browsers is cross-platform (except Chrome, which AFAIK doesn't support audio/video yet except on Windows, but that's an omission they're working on fixing). The browser doesn't have to rely on system libraries for decoding Theora any more than for decoding JPEG. Firefox 3.5 or recent Chrome supports Theora on Windows just as well as Linux. Better in Chrome's case for now, as noted.
Why is this even happening? Surely video should never show it's innerHTML unless the tag isn't understood? Just like Iframe, just like Object, just like Embed, etc.
This is exactly correct. The HTML 5 standard specifies that "Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browser informing them of how to access the video contents." JavaScript is therefore not theoretically necessary for fallback to work.
However, if the browser supports <video> but not the specific codec used, I'm not aware of any way to arrange for fallback without JavaScript. This is the situation that, for instance, Wikimedia is in: it refuses to use H.264, only Theora, so it can't just use plain old <video> and rely on element-level fallback. Safari wouldn't work right in that case.
Some random Mozilla Hacks (note the word Hacks) blogger posts some code that web developers can use to implement HTML5 video (which does not use javascript, contrary to the implications in this article and summary?)
HTML5 video does provide a rich JavaScript API to allow programmatic manipulation of the video by script. This is, in fact, potentially a great advantage it has over Flash and other solutions. So it can use JavaScript, although it doesn't require it for basic functionality (e.g., "when the page loads, download and display a video with controls to allow the user to play and pause it").
My understanding is that the reason that people use flash and silverlight for video is so that people cannot save, reuse, and redistribute the content.
People use Flash because there's no easier and more widely-supported way to embed video into pages.
Even if these are not used for DRM consideration, flash is often a much smaller file than the other codecs.
Flash is not a codec. <video> can support any codec just as well as Flash can.
I can download the file and play it trough VLC, an open source solution.
People want to embed videos in a page, not just make them available for download. Compare how convenient PDF and HTML are: HTML is right there in your browser, integrated and customizable without having to use another app.
Basically, any major media company that buys into HTML 5 video tag will be strangled by the advocates who pushed it on them in the first place, monetarily. When the production studios offering the content find out that a free video application that plays their content without commercials (hypothetically) exists, they will pull out and said video site will collapse.
Such an app could be written for Flash video too, and probably has been.
Furthermore, there will be a minor codec war. Firefox will probably only support theora, Safari will only use h.264 (Apple will flatly refuse to use theora), same for google chrome, perhaps. Then, Microsoft will support the tag in IE, but provide support for WMV in the video tag (and possibly h.264 if we're lucky, since it's now licensed in Windows 7).
Google already supports Theora and Vorbis in Chrome (as well as H.264). Apple doesn't, but has previously claimed this is because of the risk of getting sued, and that's getting flimsier every day Google doesn't get sued, so we'll have to see how that plays out. God only knows what Microsoft will do; but hopefully the worst will be that you provide one type of content to IE, and one type to everyone else . . . just as with the rest of the web.
So, the video tag will slowly become just as crazy as the plugin-based video players of Web 1.0... except they will be written in slow javascript instead of the fast native code of the past. Primarily, because no one has agreed on how to do it so it isn't a standard.
Nothing performance-sensitive is written in JavaScript here. Everything involved in actually playing the video is native code.
Can you imagine going to a web site from a corporate locked down machine and attempting to install some untrusted codec?
All browsers that support <video> package the codecs they support in the default download. No user downloads are necessary. In the worst case, Flash can still be used as a fallback until all common browsers support <video>. After then, the author will just have to provide video in as many formats as necessary (hopefully, one) to ensure it will play in all browsers.
Google and apple would like them to be h264/aac, because everyone uses that already, even more recent people using flash. Mozilla would like them to be ogg theora/vorbis, because they're open, even though nothing actually supports them.
Google Chrome supports OGG out of the box, as well as H.264. I don't think it's correct to cast them as opponents of OGG.
Unfortunately, parts of CSS have been raised to Final Call, then lowered back to draft status before. For example, CSS 2.1 has had that "honor", so it's impossible for anyone to say that this won't happen.
Sure. But again, the changes made are generally the ones that the implementers themselves approve of, and rarely to never waste a lot of effort by anyone. CSS2.1 has received clarifications and has had some unimplemented features cut; it hasn't dramatically changed already-implemented features. Individual features in a CSS spec can be much more stable than the spec as a whole.
Who uses Java applets? I know that Facebook uses one for their image uploads, and last I heard they were pretty big.
Wikipedia uses Java instead of Flash for playing audio and video (if your browser doesn't support <audio>/<video>), mainly because Java is open-source and Flash is not.
You want no plugins, huh?
So you're going to give me built-in AdBlock Plus, Noscript, Flashblock and Element Hiding Helper?
No?
Then I'm sorry, but most people who care about plugins in the first place, just won't bother.
A "plugin", in web browser jargon, is an application that uses the simple, cross-browser NPAPI. Flash, Java, Silverlight, and Adobe Reader are good examples of plugins.
Plugins are very limited in what they can do: for instance, they can get direct input from the user and do direct output to part of the screen that the browser gives them. If you pay attention, you'll notice that things like Flash often are out of sync a bit with the rest of the page layout, like being drawn on top of everything even if they should be cut off. Plugins can't easily interface with the browser's UI or make other complicated changes. The NPAPI doesn't expose higher-level details like that to them. Plugins are invoked only when a particular media type needs to be handled, and exit when they're no longer needed. They can't be used for anything other than handling particular media types.
Since NPAPI is standard and stable, a given plugin can (AFAIK) run in any browser on the target platform that supports NPAPI (meaning everything except IE, as usual in web development). They also don't care what browser version you use them on. But they pay for this with inflexibility.
AdBlock Plus, Flashblock, and Element Hiding Helper are all examples of extensions, not plugins. You'll notice that in Firefox, there are separate tabs for "Extensions" and "Plugins" in the Add-ons window. Extensions can do much more than plugins. They have access to a large collection of hooks, and can run continuously. They can do things like edit menus, dynamically alter rendered content, and so on. But they pay for this by being browser-specific, and not even always being compatible between versions of the same browser.
Plugins are what the GP was objecting to, and plugins are bad. They're only really needed to handle nonstandard formats like Flash: if the format were openly specified, support could be integrated directly in the browser (as with HTML5's canvas, video, etc.). Plugins are always native compiled code, and so can introduce crashes, memory leaks, and serious security vulnerabilities if not well-written, and the NPAPI makes it hard to cordon them off into their own process to prevent this. Most plugins are closed-source and proprietary, even if you use an open-source browser or operating system.
Extensions are a totally different story. Extensions are most often written in JavaScript, so they introduce no special stability problems and are automatically at least visible-source. Firefox extensions are mostly open-source. The worst you can say for extensions is that they're often slow, and the popular ones should usually be integrated into the browser proper.
So extensions are okay. But if plugins were to die in favor of open standards, the web would be a much better place for it.
Acid 3 is, unfortunately, heavily dependent upon CSS3 functionality, which isn't officially standard yet and could change. So claiming that Acid3 is some kind of test only tests if you're compliant with drafts.
Bzzt. The only part of CSS3 that Acid3 tests is Selectors, which has been in Last Call since 2005, and hasn't been a draft since 2000. 92/100 tests are unrelated to CSS. As for Selectors, Last Call means that it's only open for final adjustments, not major reworking. No significant changes are likely to occur: all objections have been hashed out over the past four years, and further functionality is deferred to CSS4.
In particular, anyone even remotely familiar with the CSS WG's development process (e.g., by reading www-style) knows that it's very reluctant to change anything that's already interoperably implemented. Even if something is nominally a draft, any part that's been implemented is very likely to remain stable, with only adjustments to details and corner cases (and only then if implementers are okay with it). The entire Selectors specification has been interoperably implemented by multiple browsers for a long time now.
The people writing these standards are mostly the implementers (i.e., browser authors). They aren't going to implement a feature and then screw themselves over by gratuitously changing it after the fact.