There is a way to add a guest onto the room without it invalidating the previously issued cards for that room. However, it seems like all front desk staff have a hard time remembering that the sequence for adding a guest to the room is (like, one keypress) different for the one that replaces the current set of guests. The guest stay can be extended as well.
The new card disables the old card. The new card can also be programmed with the earliest date and time at which it will be accepted by the lock. The old card will not be disabled if use of the new card is attempted prior to the new card's enable time.
Another neat thing is that the lock stores key usage information, a reader device (a keycard interface to a handheld device) can be used to recall this information. This allows the hotel to find out definitively what key was used to gain entry to a room and at what time this occurred.
The information is encoded on the key, it's much more cost-effective to do it this way than to try to have "networked" door locks. Although I'd imagine that the information is not the room number but instead the lock id.
This is NOT new, cat engines have been around since the early 1900s. An example from cat.com: "The Cat Engines used in our generator sets are designed for long life before overhaul."
This system's sole use has to be crowd control. If you are trying to broadcast information to people a mile away, how loud would the information be to other people only 1/4 mile away?
They need to be sending fresh water and buses into new orleans, not this kind of useless "technology".
What walmart actually wants to do with this is have ownership of the store product remain with the manufacturer until the product is purchased by the consumer. Walmart is always working to minimize their inventory risks and this would be the ultimate reduction in that risk - the situation where Walmart owns no inventory. In order to strongarm manufacturers into accepting this scenario, Walmart must first prove that they can track the movement of inventory in and out of the store with absolute reliability.
I don't understand the labels' position. At the labels' wholesale price of 60 cents a song, that's somewhere between $7 and $10 per album. Walmart pays $7 wholesale for a physical CD. So in the case of iTunes, the labels are making the same or more than what they make on the sale of a physical CD, only they don't have the associated manufacturing costs? Am I missing something here?
Payola has been around for many, many years and will certainly be around for many more. If small labels are so foolish as to think that the Sony case will increase their ability to gain radio airtime, it is no wonder that they are a small label.
It's even more than just private individuals now using the NWS data. My employer was paying tens of thousands of dollars a year for Accuweather forecast data that they FTPd to us daily. When the NWS started offering downloads of their GRIB US forecast files, we cancelled the Accuweather service and started using the GRIBs.
The funny thing is that it wasn't really a financially driven decision for us. We wanted the forecast information for every zipcode whereas Accuweather forced us to request the addition of new forecast zipcodes one by one from their sales rep. The sales rep would then insist on finding out what new customer of ours was using the data, and the sales rep would then contact +our+ customer to try to sell them additional weather services. We are not in the weather service business and it was very, very annoying.
The "RFID alternative" omits RF, it requires the device to be physically touched to the receiver. How the article's author would consider this an alternative to RFID is beyond me, as the device would be unsuitable for 99% of the situations where RFID can be used.
I see suggestions to use Java but I'd be hard pressed to come up with an example of a large scale web site that uses Java. Perl and PHP are all over the web. Amazon, Yahoo, Sportline - sites that get serious traffic.
I don't know about the rest, but on the dozen or so computers I've used, both at home and at work, over the last four years, the PDF reader has never worked reliably. As an example now, on all of our machines at work, if the PDF reader was invoked, shutting down windows generates an exception. At home, the reader locks up intermittently while loading PDFs.
Your reasoning as to why something cannot be secure is absurd. I have read the code, I even posted an example of issues with the code in this exact same comment thread, in response to someone else. You are arguing a line of reasoning, "no application can be acceptably secure", that has been disproven by prominent security researchers and software developers. Have you ever read the discussions concerning issues of this nature that have appeared in the bugtraq and webappsec mailing lists over the last five years? You seem to be at least partially uninformed as to what constitutes a well designed web application, from a security standpoint. It's as if you have created your own standard and are oblivious to the discussions that the top minds in the field have had and the conclusions that those discussions have yielded. That is what is seen time and time again in poorly written applications - a disregard for best practices. You have just furthered my example by offering an uninformed argument that erroneously justifies a failure to sanitize all input.
The specific issues indicate an underlying problem in the way Drupal handles input sanitization. Let's once again look at this one line of Drupal code:
Is $edit['subject'] considered safe to display after this mess of functions is called? Are you sure that the result of stripping tags and then subsequently decoding entities won't result in new tags appearing, created when decoding entities is called? Or is an author who later outputs $edit['subject'] supposed to remember that he needs to re-entity encode it before outputting it to the browser? Why isn't a wrapper function for decoding entities and allowing permissible characters through (versus the fundamentally flawed idea of stripping bad characters) contained in the core drupal code? Why is input sanity left up to the individual module authors to implement?
Slashdot Mirror
There is a way to add a guest onto the room without it invalidating the previously issued cards for that room. However, it seems like all front desk staff have a hard time remembering that the sequence for adding a guest to the room is (like, one keypress) different for the one that replaces the current set of guests. The guest stay can be extended as well.
The new card disables the old card. The new card can also be programmed with the earliest date and time at which it will be accepted by the lock. The old card will not be disabled if use of the new card is attempted prior to the new card's enable time.
Another neat thing is that the lock stores key usage information, a reader device (a keycard interface to a handheld device) can be used to recall this information. This allows the hotel to find out definitively what key was used to gain entry to a room and at what time this occurred.
Unless you had +just+ checked in, most decent hotels won't provide additional keys without verifying the photo ID of a person on the room's folio.
I worked IT at a large resort and this was my experience as well. I find the story questionable.
The information is encoded on the key, it's much more cost-effective to do it this way than to try to have "networked" door locks. Although I'd imagine that the information is not the room number but instead the lock id.
What is "real" security? Security is not a fixed state, it's a set of layers and processes. PG is one layer and it +is+ effective.
The 3rd party companies have names and IP spaces...
This is NOT new, cat engines have been around since the early 1900s. An example from cat.com: "The Cat Engines used in our generator sets are designed for long life before overhaul."
This system's sole use has to be crowd control. If you are trying to broadcast information to people a mile away, how loud would the information be to other people only 1/4 mile away?
They need to be sending fresh water and buses into new orleans, not this kind of useless "technology".
I don't know about satellite service elsewhere, but in South Florida, adverse weather frequently affects satellite reception.
They already have these (called COWs for Cell On Wheels) and the units are probably en-route.
What walmart actually wants to do with this is have ownership of the store product remain with the manufacturer until the product is purchased by the consumer. Walmart is always working to minimize their inventory risks and this would be the ultimate reduction in that risk - the situation where Walmart owns no inventory. In order to strongarm manufacturers into accepting this scenario, Walmart must first prove that they can track the movement of inventory in and out of the store with absolute reliability.
In a stark contrast to the warehouse's conveyor belt speed of 600 feet per minute, the store checkout speed is 6 customers per hour.
I don't understand the labels' position. At the labels' wholesale price of 60 cents a song, that's somewhere between $7 and $10 per album. Walmart pays $7 wholesale for a physical CD. So in the case of iTunes, the labels are making the same or more than what they make on the sale of a physical CD, only they don't have the associated manufacturing costs? Am I missing something here?
Payola has been around for many, many years and will certainly be around for many more. If small labels are so foolish as to think that the Sony case will increase their ability to gain radio airtime, it is no wonder that they are a small label.
It's even more than just private individuals now using the NWS data. My employer was paying tens of thousands of dollars a year for Accuweather forecast data that they FTPd to us daily. When the NWS started offering downloads of their GRIB US forecast files, we cancelled the Accuweather service and started using the GRIBs.
The funny thing is that it wasn't really a financially driven decision for us. We wanted the forecast information for every zipcode whereas Accuweather forced us to request the addition of new forecast zipcodes one by one from their sales rep. The sales rep would then insist on finding out what new customer of ours was using the data, and the sales rep would then contact +our+ customer to try to sell them additional weather services. We are not in the weather service business and it was very, very annoying.
I think it should be "pooh-poohs"...
You mean Powered by Bloxor!!
damn, if I only had mod points...
The "RFID alternative" omits RF, it requires the device to be physically touched to the receiver. How the article's author would consider this an alternative to RFID is beyond me, as the device would be unsuitable for 99% of the situations where RFID can be used.
I see suggestions to use Java but I'd be hard pressed to come up with an example of a large scale web site that uses Java. Perl and PHP are all over the web. Amazon, Yahoo, Sportline - sites that get serious traffic.
I don't know about the rest, but on the dozen or so computers I've used, both at home and at work, over the last four years, the PDF reader has never worked reliably. As an example now, on all of our machines at work, if the PDF reader was invoked, shutting down windows generates an exception. At home, the reader locks up intermittently while loading PDFs.
I'd imagine that your suggestion would cost considerably more to implement...
some?
Your post should be modded up.
Your reasoning as to why something cannot be secure is absurd. I have read the code, I even posted an example of issues with the code in this exact same comment thread, in response to someone else. You are arguing a line of reasoning, "no application can be acceptably secure", that has been disproven by prominent security researchers and software developers. Have you ever read the discussions concerning issues of this nature that have appeared in the bugtraq and webappsec mailing lists over the last five years? You seem to be at least partially uninformed as to what constitutes a well designed web application, from a security standpoint. It's as if you have created your own standard and are oblivious to the discussions that the top minds in the field have had and the conclusions that those discussions have yielded. That is what is seen time and time again in poorly written applications - a disregard for best practices. You have just furthered my example by offering an uninformed argument that erroneously justifies a failure to sanitize all input.
t put($edit['comment'], $edit['format']))), 29, TRUE);
The specific issues indicate an underlying problem in the way Drupal handles input sanitization. Let's once again look at this one line of Drupal code:
$edit['subject'] = truncate_utf8(decode_entities(strip_tags(check_ou
Is $edit['subject'] considered safe to display after this mess of functions is called? Are you sure that the result of stripping tags and then subsequently decoding entities won't result in new tags appearing, created when decoding entities is called? Or is an author who later outputs $edit['subject'] supposed to remember that he needs to re-entity encode it before outputting it to the browser? Why isn't a wrapper function for decoding entities and allowing permissible characters through (versus the fundamentally flawed idea of stripping bad characters) contained in the core drupal code? Why is input sanity left up to the individual module authors to implement?
Do you understand +yet+ what I am saying?