Toslink isn't high end. It's on almost everything one might hook up to a stereo receiver. Many computers have it, including just about all Macs. The Xbox/Xbox 360 and PS2/PS3 have it. Digital cable and satellite receivers have it. Cheap DVD players have it.
Cat6 is suitable for gigabit ethernet, and the money spent on fiber could be better spent on just about anything. And Cat6a is suitable for 10GBaseT up to 100 m.
Poor UI - what he is talking about? Windows CE is a mess. Yes, Windows Mobile 5 was kinda Teletubies land as Windows XP, but still, it's a huge mess stiched together
Although Windows Mobile is based on Windows CE, they are not the same thing. Windows Mobile is a specific set of applications on top of Windows CE with a single (visible) application - a PDA or phone. Windows CE itself can be used with a keyboard and mouse and has the ability to act as a standard desktop system (with multiple windows visible, a method to switch between windows, etc.)
Poor line quality is not a problem that can be solved solely by planning. In some cases, high latency can only be avoided by rewiring. If there are problems within a building, it can be fixed at the customer's expense. If there are distance limitations, customers might be able to choose between low latency and low throughput or higher lantency and higher throughput.
Latency is (in part) influenced by distance. Those far away from major cities can expect more latency. The latency within an ISP's own network can vary significantly depending on where their own network ends.
Residental ISPs generally do not sell a guaranteed service - they explicitly state that service may vary, and the technologies they use will intentionally introduce latency in order to incraese throughput and/or provide a more reliable connection. If you do want Internet service with certain guaranteed performance characteristics, you can get it - you'll just have to pay a lot for it.
I'd go even further, 50ms is the maximum latency, packet lost should be under 1% and the upload and download should never go below 80%.
Today's common broadband delivery technologies aren't necessarily well-suited to provide these kinds of guarantees. ADSL, DOCSIS, and wireless technologies have ways to handle poor singal conditions - usually by decreasing the transfer rate and increasing error correction, which often has the effect of increasing latency as well.
Some wireless systems work in such a way that getting round trip times under 50 ms is only possible in optimal conditions.
If ISPs were required to provide guarantees like this to residental customers, they might just stop offering service to those with poor line conditions.
MPEG4 ASP (that is, what's implemented by XviD) isn't that popular outside of the Internet, and it's rarely used for HD video.
H.264 (aka MPEG4 AVC) is used in: H.323 conferencing, most HD satellite, high-def HD broadcasts in some countries, IPTV services like U-verse, Apple's video store, AVCHD camcorders, newer Flash streaming videos, Blu-ray, more and more Internet pirated video (especially HD), and more. In many cases, H.264 replaced MPEG2 or H.263. IIRC, Apple was the main user of MPEG4 ASP out of this list.
You mean h263, and h263 has been used in videoconferencing since the 90s. It's a generation or two old.
H264 is a recent development; it was completed during the first half of this decade. It is used in new videoconferencing systems, includig HD equipment.
As I recall, it also took up a lot more CPU cycles, and portable music manufacturers didn't want to use it because of poor battery performance.
Some devices used specialized decoding hardware instead of using a general purpose CPU to perform decoding; even if the device's CPU was fast enough to decode MP3, a separate decoder was able to use less power.
Who the hell would want to use DRM on a fully open format? It doesn't make sense. The only thing that makes DRM work is the fact it's closed.
DRM is a way of controlling access to an encrypted bitstream. It doesn't matter so much what the format is inside. The main difference between something like AAC and Vorbis is that Vorbis is believed to be unencumbered by any known patents and has an easily found and freely available specification. AAC is an ISO/IEC standard and has open-source encoders and decoders available (although I'm not sure if the open-source encoders are as good as others.)
But AAC and WMA have DRM capabilities, I don't think Ogg can, or MP3, making AAC and WMA a higher standard for things that are sold.
If someone was interested in using Vorbis, they could implement their own DRM container or adapt another to work with Vorbis. I don't think AAC itself has DRM capability; Apple implemented it on their own.
Ogg Vorbis was better in quality than MP3 - back then (and even today) the most popular compression for music. However, AAC and WMA are also better than MP3 - and people actually sold music in AAC and WMA formats as well as MP3.
Theroa is not better than h264 (the new popular standard for video on the Internet, many Blu-ray discs, HD satellite, and HD broadcast in some parts of the world), so it's not a repeat of Vorbis at all. Theora just scores higher on a scoring algorithm when compared ot a single h264 encoder, the open-source x264.
$3-5/month for MMS will not deter many people, so it will probably translate to increased profits.
I am an iPhone customer, and I already pay for MMS - the messaging plan on the account includes unlimited MMS and SMS. AT&T actually blocks iPhone lines from accessing the MMS server, though.
Because its so hard to add 5556667777@mms.cellphone.com to a contact?
It is hard when you do not know the carrier, and can break when someone ports their phone number.
User friendly or not, it has always been incorrect to say that iPhone users cannot send pictures to MMS devices.
iPhone users (via email) can send pictures to MMS email gateways if they have an email account configured and they know which email gateway to use. A real MMS implementation would not require the sender to know the receiver's carrier, and will work if the receiver changes carriers.
Not saying you're wrong, but to be a bit pedantic, ALL standards are flawed and incomplete to some extent. The issue is how much those items matter and to whom.
I would say the lack of a standard spreadsheet formula syntax is a major flaw... This matters quite a bit to anyone who wants to implement a spreadsheet application with formulas.
If you take as a criteria for a "good standard for office documents" that it have a number of interoperable implementations and provides all generally-required functionality, ODF clearly meets that standard, MSOOXML as clearly fails it on lack of interoperable implementations.
Many of these implementations don't implement the standard as published, or add extensions. If most implementations (or the most widely used ones) deviate from or extend the published standard, the published standard is less useful and the de facto standard becomes "ODF as implemented by OpenOffice.org and a few others". And the most popular ODF implementation does not follow a published standard: OpenOffice.org 3 implements ODF according to a draft of ODF 1.2.
The old Word, Excel, and PowerPoint formats have a few interoperable implementations as well (OpenOffice.org, Office, iWork...)
If you think about it, telling someone "Fix this issue within xx days or I'll disclose it" is borderline blackmail. You're telling someone that if they don't do what you want, when you want it, you'll cause them grief.
But did the researchers demand that the flaws be fixed in a given timeframe? The vendor didn't even look at the vulnerabilities in the two week period. What can you do when the vendor doesn't take a problem seriously and when you don't have a business relationship with the vendor?
The lesson learned, use free/open source software or buy from vendors with an excellent track record of addressing these kinds of problems quickly and transparently.
Simply choosing free/open source software doesn't really prevent what happened here from happening again. Open source software is not magically more secure, and open source developers can ignore reported vulnerabilities. The main benefit is that anyone can fix the vulnerabilities.
And vendors with horribly insecure software can still do a great job of fixing flaws quickly... once they find out about them.
The latest published standard version of ODF (1.1) is flawed - perhaps the most frequently mentioned flaw is that it does not define a syntax for spreadsheet formulas. An ODF 1.1 compliant spreadsheet application can thus generate ODF 1.1 compliant spreadsheet documents that are incompatible with other ODF 1.1 spreadsheet applications.
When completed, ODF 1.2 will fix this flaw and others. But ODF 1.2 is not yet finished.
Someone sends a random, out-of-the-blue email saying "hey we hax0red your code, lol" and you expect the recipient to pop tall and check out their site immediately? Are you serious?
No one looked at the details of the vulnerabilities for two weeks, after they claimed they would look at it and after they claimed they would respond in a few hours.
And what contact information was needed? Obviously Milw0rm talked with someone at the company, so they already had contact information.
In a business context, it is customary for people to sign their emails with (at least) their name.
However, I am willing to state, without reservation, that Milw0rm are a bunch of asshats who deserve to be sued into oblivion over their callous disregard for the safety of the customers using this software.
If anyone callously disregarded the safety of LXLabs' customers, it was LXLabs. Milw0rm's disclosure aside, it's LXLabs who made a product with such severe security issues and LXLabs who made ridiculous claims about the security of their product.
Most of the people hurt by this had no control over the software getting fixed, had no idea there was a problem until it was too late to do anything about it, and were completely innocent of any mistakes.
LXLabs' customers chose the product to begin with! If the product is indeed this insecure, the customers are certainly not innocent, as they have failed to thoroughly evaluate the product.
And yet Milw0rm doesn't care one fig about those people and just releases code that sends their lives and businesses into a tailspin.
It is not milw0rm's responsibility to care for LXLabs' customers. That's LXLabs' job.
Two weeks is not nearly enough time to even decide if something like this is worth looking at, let alone find a fix, develop it, test it, implement it, and push it to all clients
Are you serious?
According to milw0rm, whoever responded didn't even access the details of the vulnerabilities - after two weeks. Nor did they provide any contact information. It would only take a few minutes to skim through the details, and it should have been immediately apparent that the vulnerabilities described could be serious. But they didn't read the details at all.
Assuming milw0rm did contact the correct person/people at LXLabs, they clearly has no interest in the security of their product(s).
No, you truly can. You can't blame it for 100% of the problem, but without doubt, people who make viruses are preying on others. What outcome to you expect, when those preyed upon are already struggling just to get through the day and raise their kids or whatever?
You might expect someone selling a product to not lie about security.
Lxlabs has really been preying upon their customers all along: they've been selling an extremely poor product and lying about their product's security design.
I have very mixed feelings on security firms releasing exploits to the public just to try and get results. In my (admittedly limited) experience, more bad has come from releasing exploits publicly than good.
These vulnerabilities are so simple - and many lead to root access. I'd be surprised if these vulnerabilities haven't been found in the past by others; it's likely that people who found them have been exploiting the application for some time. See the exploits - the application is clearly flawed and was designed with little regard to security. With a security failure of this magnitude, I think it's best that everyone know about the exploits. If I used this product, I wouldn't trust the vendor's ability to write a secure product at all; I'd switch to a more secure product ASAP.
Slashdot Mirror
Are you posting from 1999?
Toslink isn't high end. It's on almost everything one might hook up to a stereo receiver. Many computers have it, including just about all Macs. The Xbox/Xbox 360 and PS2/PS3 have it. Digital cable and satellite receivers have it. Cheap DVD players have it.
Cat6 is suitable for gigabit ethernet, and the money spent on fiber could be better spent on just about anything. And Cat6a is suitable for 10GBaseT up to 100 m.
Although Windows Mobile is based on Windows CE, they are not the same thing. Windows Mobile is a specific set of applications on top of Windows CE with a single (visible) application - a PDA or phone. Windows CE itself can be used with a keyboard and mouse and has the ability to act as a standard desktop system (with multiple windows visible, a method to switch between windows, etc.)
Poor line quality is not a problem that can be solved solely by planning. In some cases, high latency can only be avoided by rewiring. If there are problems within a building, it can be fixed at the customer's expense. If there are distance limitations, customers might be able to choose between low latency and low throughput or higher lantency and higher throughput.
Latency is (in part) influenced by distance. Those far away from major cities can expect more latency. The latency within an ISP's own network can vary significantly depending on where their own network ends.
Residental ISPs generally do not sell a guaranteed service - they explicitly state that service may vary, and the technologies they use will intentionally introduce latency in order to incraese throughput and/or provide a more reliable connection. If you do want Internet service with certain guaranteed performance characteristics, you can get it - you'll just have to pay a lot for it.
Today's common broadband delivery technologies aren't necessarily well-suited to provide these kinds of guarantees. ADSL, DOCSIS, and wireless technologies have ways to handle poor singal conditions - usually by decreasing the transfer rate and increasing error correction, which often has the effect of increasing latency as well.
Some wireless systems work in such a way that getting round trip times under 50 ms is only possible in optimal conditions.
If ISPs were required to provide guarantees like this to residental customers, they might just stop offering service to those with poor line conditions.
MPEG4 ASP (that is, what's implemented by XviD) isn't that popular outside of the Internet, and it's rarely used for HD video.
H.264 (aka MPEG4 AVC) is used in: H.323 conferencing, most HD satellite, high-def HD broadcasts in some countries, IPTV services like U-verse, Apple's video store, AVCHD camcorders, newer Flash streaming videos, Blu-ray, more and more Internet pirated video (especially HD), and more. In many cases, H.264 replaced MPEG2 or H.263. IIRC, Apple was the main user of MPEG4 ASP out of this list.
You mean h263, and h263 has been used in videoconferencing since the 90s. It's a generation or two old.
H264 is a recent development; it was completed during the first half of this decade. It is used in new videoconferencing systems, includig HD equipment.
Some devices used specialized decoding hardware instead of using a general purpose CPU to perform decoding; even if the device's CPU was fast enough to decode MP3, a separate decoder was able to use less power.
DRM is a way of controlling access to an encrypted bitstream. It doesn't matter so much what the format is inside. The main difference between something like AAC and Vorbis is that Vorbis is believed to be unencumbered by any known patents and has an easily found and freely available specification. AAC is an ISO/IEC standard and has open-source encoders and decoders available (although I'm not sure if the open-source encoders are as good as others.)
If someone was interested in using Vorbis, they could implement their own DRM container or adapt another to work with Vorbis. I don't think AAC itself has DRM capability; Apple implemented it on their own.
Ogg Vorbis was better in quality than MP3 - back then (and even today) the most popular compression for music. However, AAC and WMA are also better than MP3 - and people actually sold music in AAC and WMA formats as well as MP3.
Theroa is not better than h264 (the new popular standard for video on the Internet, many Blu-ray discs, HD satellite, and HD broadcast in some parts of the world), so it's not a repeat of Vorbis at all. Theora just scores higher on a scoring algorithm when compared ot a single h264 encoder, the open-source x264.
And something that would normally take 10 seconds now takes much longer. This is inconvenient.
It is a burden. MMS is convenient and easy. Sending email to an MMS email gateway is not.
People usually tell others when they change their phone number, if they want to keep in touch.
With MMS disabled, an email to MMS gateway won't work either.
I am an iPhone customer, and I already pay for MMS - the messaging plan on the account includes unlimited MMS and SMS. AT&T actually blocks iPhone lines from accessing the MMS server, though.
Someone gives you their phone number. What's their carrier's email to MMS gateway?
They just switched carriers and kept the same phone number. What's their carrier's email to MMS gateway now?
It is hard when you do not know the carrier, and can break when someone ports their phone number.
iPhone users (via email) can send pictures to MMS email gateways if they have an email account configured and they know which email gateway to use. A real MMS implementation would not require the sender to know the receiver's carrier, and will work if the receiver changes carriers.
There is no yet: ODF 1.1 is already a published standard, and support for the ODF standard is mandated by some governments.
I would say the lack of a standard spreadsheet formula syntax is a major flaw... This matters quite a bit to anyone who wants to implement a spreadsheet application with formulas.
Many of these implementations don't implement the standard as published, or add extensions. If most implementations (or the most widely used ones) deviate from or extend the published standard, the published standard is less useful and the de facto standard becomes "ODF as implemented by OpenOffice.org and a few others". And the most popular ODF implementation does not follow a published standard: OpenOffice.org 3 implements ODF according to a draft of ODF 1.2.
The old Word, Excel, and PowerPoint formats have a few interoperable implementations as well (OpenOffice.org, Office, iWork...)
But did the researchers demand that the flaws be fixed in a given timeframe? The vendor didn't even look at the vulnerabilities in the two week period. What can you do when the vendor doesn't take a problem seriously and when you don't have a business relationship with the vendor?
Simply choosing free/open source software doesn't really prevent what happened here from happening again. Open source software is not magically more secure, and open source developers can ignore reported vulnerabilities. The main benefit is that anyone can fix the vulnerabilities.
And vendors with horribly insecure software can still do a great job of fixing flaws quickly... once they find out about them.
The latest published standard version of ODF (1.1) is flawed - perhaps the most frequently mentioned flaw is that it does not define a syntax for spreadsheet formulas. An ODF 1.1 compliant spreadsheet application can thus generate ODF 1.1 compliant spreadsheet documents that are incompatible with other ODF 1.1 spreadsheet applications.
When completed, ODF 1.2 will fix this flaw and others. But ODF 1.2 is not yet finished.
No one looked at the details of the vulnerabilities for two weeks, after they claimed they would look at it and after they claimed they would respond in a few hours.
In a business context, it is customary for people to sign their emails with (at least) their name.
If anyone callously disregarded the safety of LXLabs' customers, it was LXLabs. Milw0rm's disclosure aside, it's LXLabs who made a product with such severe security issues and LXLabs who made ridiculous claims about the security of their product.
LXLabs' customers chose the product to begin with! If the product is indeed this insecure, the customers are certainly not innocent, as they have failed to thoroughly evaluate the product.
It is not milw0rm's responsibility to care for LXLabs' customers. That's LXLabs' job.
Are you serious?
According to milw0rm, whoever responded didn't even access the details of the vulnerabilities - after two weeks. Nor did they provide any contact information. It would only take a few minutes to skim through the details, and it should have been immediately apparent that the vulnerabilities described could be serious. But they didn't read the details at all.
Assuming milw0rm did contact the correct person/people at LXLabs, they clearly has no interest in the security of their product(s).
You might expect someone selling a product to not lie about security.
You might expect someone selling a product with completely false security marketing to at least read the information regarding any published vulnerabilities - note that the vendor apparently did acknowledge the notification, but did not read the details.
Lxlabs has really been preying upon their customers all along: they've been selling an extremely poor product and lying about their product's security design.
These vulnerabilities are so simple - and many lead to root access. I'd be surprised if these vulnerabilities haven't been found in the past by others; it's likely that people who found them have been exploiting the application for some time. See the exploits - the application is clearly flawed and was designed with little regard to security. With a security failure of this magnitude, I think it's best that everyone know about the exploits. If I used this product, I wouldn't trust the vendor's ability to write a secure product at all; I'd switch to a more secure product ASAP.