I've read through the comments; I thought I would put in my 2 cents.
Several folks pointed out that you could get the midlet (the term for
the type of app sprint runs) on the phone by hosting it yourself or
downloading via a cable, and bypassing Sprint's site and the need for
a developer's certificate.
They are correct, but they are also missing part of the story.
They part they are missing is: in order to use some of the APIs on the
phone, your midlet must be "blessed" by the operator. Technically it
has to say the protected features it wants access to and be signed
by the manufacturer or operator. All this is covered in the
MIDP2.0 (JSR-118) spec.
I was a member of the committee that wrote that spec.
So, if you want to write a local game you don't need any of that magic: you
can do everything you want via the "untrusted" (that is: unsigned) profile.
But to do some of the more advanced features (like using GPS data, or
being able to be woken up when not running - push registry) you have to
be signed by the manufacturer or operator.
Anyone who's read to this point will probably have noticed that the folks
who make the phone or sell the phone (manufacturer or operator) are able
to bless applications, but the folks who bought the phone cannot.
This wasn't an accident.
When the committee was working out the details of the protection model
manufacturers and operators were
well represented. The only third party developers present were companies
that were beholden
to operators. There were no end users or corporations represented, so
their interests didn't get a lot of weight.
I don't think it was evil intent by any of the parties. Its just that
went these standard committees meet each representitive makes sure their
interests are protected, and those who aren't present don't get a voice.
This is a very common problem for most standard committees; its not unique
to the JCP or MIDP. But it does help to explain why you, an 3rd party developer
is a second class citizen even for your own phone, let alone your customer's
phones.
Bellsouth sees how it can extract fees by charging web sites for preferred access.
But they are clearly missing that they can suffer from the same effect too.
Imagine this:
What happens if Google (or any other site) starts charging Bell South
for preferred access for its customers? If Bell South wants its
network to not look very slow when accessing Google they
need to pay up.
Web sites could even take adds: tired of slow access via Bell South?
Switch to Earthlink for faster searching!
I bet it looks like less of a moneymaker if they consider that.
It's actually never legally allowed to require a social security number; "they" can request it, but not demand it, unless "they" are a government agency
This is somewhat true, but pretty misleading. Private companies cannot require a social security number, but they can make providing it a condition of doing business with you.
You could use ModVis to image a single data set across multiple monitors. They distribute the image across a cluster of hosts, each of which have a slightly different view. It might be overkill for just three screens, but works very well if you can't do it in hardware.
Don't think chess board: think infinite 2d matrix, with many, many parallel paths.
The chess move part just means three units away (two over and one up, or one of
the reflections of this move).
Use the formula for combining parallel resistances: 1/(1/R1 + 1/R2 +... + 1/RN)
So you have 1/(1/3 + 1/3 + 1/3 + 1/4 * (# of 4 -distance-paths) + 1/(# 5-distance paths)).
The denominator grows faster than the harmonic series (1/2 + 1/3 + 1/4 +...) which grows to infinity, so the total resistance (1/infinity) is zero.
I agree with your basic point: that the number gives retailers lots of rope
to have bad practices, and the last published specs gave no help on how
to administer the write-authorization field.
But it doesn't have to be that bad. If I was making a system I would
use PKI based on the manufacturer, customer, product id and item serial number; that way every item
would have a different write-authorized value. You would have to break
the underlying PKI on a per-item basis. This defeats any offline attack
capability (assuming the underlying PKI infrastructure is secure, which if
insecure is a bigger problem than reprogramming RFID tags...)
I guess I look at it as a business problem: the system doesn't have to
be bullet proof; it just has to be hard enough to crack to cost more than
several hundred dollars per item. I think that is achievable by the current
standard.
Unfortunately the standard doesn't help at all in this area. So we are very
likely to see many bad implementations, which will give the whole RFID space
a bad reputation.
This case was already covered in the older RFID specs that used
to appear at www.autoidcenter.org (they have since become viewable to membersonly
when they handed standards off to www.epcglobalinc.org several
months ago).
In order to write data to the tag you needed to know a 64bit
number that was programmed into the tag. The standard didn't say
how you set that number; that was policy reserved to the tag programmer.
But in order to have a write command accepted, you needed to match
the previously programmed number.
So if commercially deployed tags really are generally writeable
it is more of an administration problem (like leaving telnet
enabled on public facing servers) than a failure to consider
the problem at all.
Not only do the bulbs have a 2000 hour "rated" life, but that life
is defined as the bulb having at least 50% of the original brightness.
Most bulbs slowly decline in brightness over the span of its lifetime,
so your 1200 lumen projector (or whatever its starting spec was) will slowly get dimmer and dimmer before the
bulb fails completely.
Alas, SMS to phones just isn't as reliable as a pager; I found
that here in the SF bay area there were many, many times when
pages came through, but SMS messages did not.
SMS is nice to have, but if you absolutely, positively
have to get a hold of someone, they really need a pager.
Calling an 800 number bypasses the caller-id-blocking
system. An 800 number can always see your phone number
via a system called "ANI" (automatic number identification?)
The theory that I've heard for this is: since the callee is
paying for the call, they get to know your phone number.
Anyway, you have no privacy protection when you call
an 800 (or 888, or 877, or any of its friends) number.
For me, the
senate floor analysis
was the most interesting. According to that, the effect of the bill would be $21 Million, assuming that they get 5% more companies to pay. This strikes me as optimistic, but what can I say.
Federal law already says you can only demand taxes
from companies with a "nexus" in the state. This bill tries to "clarify" that a nexus includes service and support, as well as related companies that share a trademark name.
The legality of the law seems open to question, since some companies purposefully define their mail order and on line units as separate companies to avoid having a nexus in a state.
At most this bill will have a minor effect on a few companies. It is not a major change to sales taxes on internet companies.
They're only using the firewire protocol (to provide things like guaranteed bandwidth), not the actual
firewire physical layer.
So it doesn't matter whether or not firewire (aka ieee1394) lives or dies in the marketplace. Although, bridging from 802.15.3 to 1394 will be easier if they share a mac layer (and, for example, bridging to usb2.0)
Using the USB protocol might be a better market choice, but this is the IEEE, where leveraging an existing IEEE standard gets the inside track of consideration.
Actually, it *is* 3G, as defined by the 3rd Generation Partnership Project -- the folks who define what "3G" is.
They define 3G as anything over 144 kb/sec, and
Sprint's use of the 1xRTT CDMA protocol just makes the limit.
Of course, just like in 3G, that doesn't mean that
*you* will get that speed, just that it is technically possible to get that much bandwidth in a cell.
Or, as one wag I know put it: those 386kbit/sec (for Euro style 3G) or 150kbit/sec (for Sprint) are the guaranteed not-to-exceed speeds, never seen in the wild...
Everything you say is correct, but what really bothers me is: the interests of the end user (and the end user's enterprise) never seem to show up in the list.
If you are a mobile operator: the customer is not always right...
Sadly, even if it runs linux on the inside, there is no reason to believe that developers get any access to it (although that would be very nice if they did).
I've worked on the A720 and the A830 Motorola phones, and none of the underlying system was exposed.
The Symbian Quartz platforms are even worse. Even as owner of the phone you can't put anything on them; everything must be signed by either Motorola or the mobile operator. This is because there is no security model in the OS, so any code on the phone has to be completely trusted (like active-x), and they didn't want worms to be a problem.
Hopefully the design on a linux phone could be more nuanced...
Actually you (spRed) are wrong. FTP supports
a single connection (Passive, or PASV in the
actual protocol), which is what most web browsers
use by default. The "legacy" mode for FTP
is to open up a separate port for the data,
but many firewalls don't allow the separate
port to be successfully connected to (I won't
go into the reasons here...)
Also the data path uses TCP (not UDP as you state); it lives on
port 20 by default.
I looked at the site this story points to, but there just aren't any details. Everyone is exercised about "invoking the DCMA", but no one has any of the facts here at slashdot.
Just what did the letter say? Anyone can send a letter about anything, but there is no substance here, not even anything to get upset at.
The patent patent 4,698,672 actually refers to an earlier Compression Labs patent
patent 4,302,775
which seems much more relevant to JPEG. Patent '672 talks about interframe compression. Patent '775 talks about compression within the frame.
Luckily the '775 patent has already expired. JPEG seems safe, but motion JPEG might be exposed.
Slashdot Mirror
I didn't see anyone else mention this, so here's my understanding.
There are three common categories of employees are are exempt from standard overtime rules: supervisors, administrative, and professional.
A college degree (usually expressed as degree or equivalent experience) is evidence that the position has professional requirements, and can qualify for a Fair Labor Standards Act exemption from overtime rules.
Several folks pointed out that you could get the midlet (the term for the type of app sprint runs) on the phone by hosting it yourself or downloading via a cable, and bypassing Sprint's site and the need for a developer's certificate.
They are correct, but they are also missing part of the story.
They part they are missing is: in order to use some of the APIs on the phone, your midlet must be "blessed" by the operator. Technically it has to say the protected features it wants access to and be signed by the manufacturer or operator. All this is covered in the MIDP2.0 (JSR-118) spec. I was a member of the committee that wrote that spec.
So, if you want to write a local game you don't need any of that magic: you can do everything you want via the "untrusted" (that is: unsigned) profile. But to do some of the more advanced features (like using GPS data, or being able to be woken up when not running - push registry) you have to be signed by the manufacturer or operator.
Anyone who's read to this point will probably have noticed that the folks who make the phone or sell the phone (manufacturer or operator) are able to bless applications, but the folks who bought the phone cannot. This wasn't an accident.
When the committee was working out the details of the protection model manufacturers and operators were well represented. The only third party developers present were companies that were beholden to operators. There were no end users or corporations represented, so their interests didn't get a lot of weight.
I don't think it was evil intent by any of the parties. Its just that went these standard committees meet each representitive makes sure their interests are protected, and those who aren't present don't get a voice. This is a very common problem for most standard committees; its not unique to the JCP or MIDP. But it does help to explain why you, an 3rd party developer is a second class citizen even for your own phone, let alone your customer's phones.
But they are clearly missing that they can suffer from the same effect too. Imagine this:
Web sites could even take adds: tired of slow access via Bell South? Switch to Earthlink for faster searching!
I bet it looks like less of a moneymaker if they consider that.
For more info, see:
http://www.faqs.org/faqs/privacy/ssn-faq/a te.html
http://archive.cpsr.net/cpsr/privacy/ssn/SSN-Priv
You could use ModVis to image a single data set across multiple monitors. They distribute the image across a cluster of hosts, each of which have a slightly different view. It might be overkill for just three screens, but works very well if you can't do it in hardware.
You could try installing a Coraid box, which has a 10 disk chassis for $2500. You can load any disk you want, and attach it over the network.
I know they are working with other panel folks too, so you will probably see more of these type of sub-pixel displays soon.
Try googling harmonic series limit or just look at formula three on this page
This page gives an explanation why, and links to a strategy for a proof.
Wolfram has a fuller explanation
Use the formula for combining parallel resistances: 1/(1/R1 + 1/R2 + ... + 1/RN)
So you have 1/(1/3 + 1/3 + 1/3 + 1/4 * (# of 4 -distance-paths) + 1/(# 5-distance paths)).
The denominator grows faster than the harmonic series (1/2 + 1/3 + 1/4 + ...) which grows to infinity, so the total resistance (1/infinity) is zero.
But it doesn't have to be that bad. If I was making a system I would use PKI based on the manufacturer, customer, product id and item serial number; that way every item would have a different write-authorized value. You would have to break the underlying PKI on a per-item basis. This defeats any offline attack capability (assuming the underlying PKI infrastructure is secure, which if insecure is a bigger problem than reprogramming RFID tags...)
I guess I look at it as a business problem: the system doesn't have to be bullet proof; it just has to be hard enough to crack to cost more than several hundred dollars per item. I think that is achievable by the current standard.
Unfortunately the standard doesn't help at all in this area. So we are very likely to see many bad implementations, which will give the whole RFID space a bad reputation.
In order to write data to the tag you needed to know a 64bit number that was programmed into the tag. The standard didn't say how you set that number; that was policy reserved to the tag programmer. But in order to have a write command accepted, you needed to match the previously programmed number.
So if commercially deployed tags really are generally writeable it is more of an administration problem (like leaving telnet enabled on public facing servers) than a failure to consider the problem at all.
Most bulbs slowly decline in brightness over the span of its lifetime, so your 1200 lumen projector (or whatever its starting spec was) will slowly get dimmer and dimmer before the bulb fails completely.
The relay itself is a java applet, which makes scripting it pretty hard.
I got the feeling that the original poster wanted an automated way of calling for help...
SMS is nice to have, but if you absolutely, positively have to get a hold of someone, they really need a pager.
Calling an 800 number bypasses the caller-id-blocking system. An 800 number can always see your phone number via a system called "ANI" (automatic number identification?)
The theory that I've heard for this is: since the callee is paying for the call, they get to know your phone number.
Anyway, you have no privacy protection when you call an 800 (or 888, or 877, or any of its friends) number.
The Internet.com Story has a reference to the actual bill, but I doubt many folks followed it.
For me, the senate floor analysis was the most interesting. According to that, the effect of the bill would be $21 Million, assuming that they get 5% more companies to pay. This strikes me as optimistic, but what can I say.
Federal law already says you can only demand taxes from companies with a "nexus" in the state. This bill tries to "clarify" that a nexus includes service and support, as well as related companies that share a trademark name.
The legality of the law seems open to question, since some companies purposefully define their mail order and on line units as separate companies to avoid having a nexus in a state.
At most this bill will have a minor effect on a few companies. It is not a major change to sales taxes on internet companies.
So it doesn't matter whether or not firewire (aka ieee1394) lives or dies in the marketplace. Although, bridging from 802.15.3 to 1394 will be easier if they share a mac layer (and, for example, bridging to usb2.0)
Using the USB protocol might be a better market choice, but this is the IEEE, where leveraging an existing IEEE standard gets the inside track of consideration.
Of course, just like in 3G, that doesn't mean that *you* will get that speed, just that it is technically possible to get that much bandwidth in a cell.
Or, as one wag I know put it: those 386kbit/sec (for Euro style 3G) or 150kbit/sec (for Sprint) are the guaranteed not-to-exceed speeds, never seen in the wild...
If you are a mobile operator: the customer is not always right...
Sadly, even if it runs linux on the
inside, there is no reason to believe
that developers get any access to it
(although that would be very nice if
they did).
I've worked on the A720 and the A830
Motorola phones, and none of the underlying
system was exposed.
The Symbian Quartz platforms are even
worse. Even as owner of the phone you
can't put anything on them; everything
must be signed by either Motorola or
the mobile operator. This is because
there is no security model in the OS,
so any code on the phone has to be completely
trusted (like active-x), and they didn't
want worms to be a problem.
Hopefully the design on a linux phone
could be more nuanced...
I apologize; Edgewize is right and I'm wrong -- PASV doesn't use the same connection; it works just the way you said (I checked RFC 959).
I guess this can be the internet-tidbit-of-the-day that I learned...
Actually you (spRed) are wrong. FTP supports a single connection (Passive, or PASV in the actual protocol), which is what most web browsers use by default. The "legacy" mode for FTP is to open up a separate port for the data, but many firewalls don't allow the separate port to be successfully connected to (I won't go into the reasons here...)
Also the data path uses TCP (not UDP as you state); it lives on port 20 by default.
I looked at the site this story points to, but
there just aren't any details. Everyone is
exercised about "invoking the DCMA", but no
one has any of the facts here at slashdot.
Just what did the letter say? Anyone can send
a letter about anything, but there is no substance
here, not even anything to get upset at.
The Zaurus 5600 is 320x240 (1/4vga), not 640x480 as
stated in the slashback.
The C700 *is* 640x480.
Luckily the '775 patent has already expired. JPEG seems safe, but motion JPEG might be exposed.