Posted by
CmdrTaco
on from the from-the-research-center-that-brought-us-everything-else dept.
Sandeep writes " PARC announces a new software architecture , named Obje, to establish a device-independent networking system. Essentially, it allows two devices to teach each other how to talk amongst themselves. It does this by sending actual code over the network."
Keep in mind I have only SkimmedTFA... This seems like it would be useful for forming ad hoc networks, for example in a disaster or emergency scenario. But for frequent daily use, it seems like it might be a particularly vulnerable protocol.
Are the benefits of high quality and reliable communication in a disaster/terrorism situation worth the potential risks of insecurity in that situation?
if you're sending code over the network in order to communicate, why have a traditional network at all? Why not just synchronize all the files between all the machines, or just have terminals? It seems like a mistake to send code for anything as a part of initiating network communication. PC 1: "here's how to hack me." PC 2: "OK! sending hack." PC 1: "thanks! Now I'm hosed." PC 2: "no prob. see you in hell! ha ha ha!"
heh - The infinite IS possible with Obje
by
Wingchild
·
· Score: 5, Insightful
From the article:
The Obje platform works with all standards, including those that have not yet been defined. It requires no central coordination, pre-configuring, or special set-up, and can be easily used by people with no technical expertise.
It provides users a way to combine devices to build simple solutions for hundreds of problems - easily assembling their particular applications from available devices and services. It offers manufacturers a simple, fast, and timely solution to the increasing requirement to connect products.
The Obje platform works with devices of all kinds - including cell phones, computers, personal digital assistants (PDAs), printers, set-top boxes, bar-code scanners, video displays, and others - from any manufacturer.
It works with everything, everywhere - because rather than being some kind of new l33t tech, or even a new technical standard, it's a self-described "meta standard".
In that respect, it reminds me a lot of Microsoft's DNA (Distributed Network Architecture), which I'm not sure anyone remembers. I only do because I built the Mid-Atlantic DNA labs, having worked for one of their Premiere Partners. Basically DNA wasn't new tech of any kind so much as a way of thinking and realignment of existing technologies. Instead of coming up with something really neat and whizbang to sell, Microsoft instead tried selling the process of how to think about how to get work done. Instead of creating apps that are live in the net, say, add a layer of firewalling and some abstraction between the user and the app itself, centralize all of your data in searchable SQL databases, and do other really common stuff!
And they charged people for it, too.:) Obje reminds me of this - standards about standards about actual work.
Re:Sounds Like Sun's JINI
by
Anonymous Coward
·
· Score: 5, Informative
Q. How is the Obje interoperability platform different from UPnP? Jini? A. The key difference between the Obje technology and other approaches to interoperability is that Obje does not require prior agreement on domain specific interfaces--the protocols, encodings, and standards used to communicate with specific types of devices. Other technologies, including UPnP, Jini, HAVi and Bluetooth, each define specialized interfaces for each new type of device: Bluetooth defines "profiles" for phones, headsets and printers; Jini defines APIs for printers and cameras; the UPnP consortium defines interfaces for audio/visual devices, scanners and home appliances; HAVi defines APIs for DVD and CD players, printers, cameras and TVs.
The problem with such approaches is that software must be recoded to address each specific type of device that it is expected to work with. For example, an application written to use UPnP media servers will not be able to use UPnP scanners (much less devices implemented under other standards) without re-implementation.
With Obje, devices and applications are written once, against a small, fixed set of meta-interfaces, which allow them to acquire any needed communication capabilities at runtime. These meta-interfaces abstract the protocols and communication standards used by specific devices so that, at runtime, a device can provide its communication specifics to the entity that wants to use it, with no reprogramming of existing services. This allows users and manufacturers to "recombine" devices and services at will, without waiting for slow-moving standards bodies. This ability is unique to Obje.
Re:Whats wrong with generated code?
by
NSash
·
· Score: 5, Funny
Code can be a very concise way to express an algorithm.
And to think that all this time, I was expressing my algorithms in pictograms!
Parc = Real PnP
by
SunCrushr
·
· Score: 5, Interesting
So from what I've read in the article, this looks to be Plug'n'play as it was meant to be:
Devices which use simple initial aggreed upon standard to extend their various servcies to each other without all the protocols having to be aggreed upon ahead of time, just a few simple initial protocols which are used to communicate and extend the other protocols and services between the devices. If this is applied correctly by the industry, it could change computing a lot, opening more complex systems to users with less experience and requiring less support resources. I'll be watching this closely.
Re:Parent should be "Insightful," not "Funny"
by
drinkypoo
·
· Score: 5, Insightful
Simply enough, you don't trust the other end, and all code is run in a sandbox. If the code does anything strange the session is terminated, if the other system (or peripheral) hands you strange code too many times you just stop listening. I don't think it's really necessary to send code, it would be just as well to send a list of capabilities (shades of my HVAC discussion) and then the sytem decides what you are based on your capabilities and treats you accordingly.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:Parent should be "Insightful," not "Funny"
by
jilles
·
· Score: 5, Interesting
With Java you can do this. Just run the code in a sandbox. Alternatively you can use some trusted third party and signatures. Or you can do both (authenticate other party and allow verified and validated code to do whatever it is authorized to do). The JINI architecture works along these lines (although it seems rather dead nowadays). It can be very secure if you set it up properly.
--
Jilles
Re:Parent should be "Insightful," not "Funny"
by
BlueTooth
·
· Score: 5, Interesting
and then the sytem decides what you are based on your capabilities and treats you accordingly.
This assumes that the system already knows about all possible capabilities and that it knows how to talk to everyone else.
I think the idea is that devices teach each other of their existence. It would be like if I bought a USB device (say a camera) that Windows didn't support, the camera would be able to bootstrap Windows with some drivers from its own firmware. The only thing that has to be prearanged is a protocol for this transaction. I don't need to maintain an extensive driver library for this to work.
-- SPAM
Re:Parent should be "Insightful," not "Funny"
by
goatwhip
·
· Score: 5, Interesting
What portion of detecting whether code sent to you over the network is doing something 'strange', do you find simple?
I hate it when people preface comments with "Simply enough" or "Obviously". It automatically makes anyone who doesn't understand what the person is talking about, feel stupid.
This sounds very much like PARC wants to teach machines how to interact more on "human" terms than on strict "computer" terms.
The most useful systems of tomorrow can't simply assume that peripherals/devices conform to their world view in order to work together. Instead, they must spend some time up front talking, listening, communicating, then eventually, cooperating.
Heading in this direction will prevent a technological monoculture from appearing, which wedges itself into a hole dug from its own presuppositions. Instead, I think this would foster a hardware equivalent of Open Source, where anyone who knew how to talk the fundamental protocol could build something interesting and introduce it into a system.
Of course, that's a pretty far-off idea, but I think it is worth pursuing.
Slashdot Mirror
Personal Firewall and Anti-Virus coders everywhere today announced that "You've got to be kidding me".
This MUST either result in such intractable security issues that it will be worthless . . .
. . . or the machines will become sentient and use us (along with a form of fusion) as a plentiful power source.
Damn.
-Peter
Keep in mind I have only SkimmedTFA... This seems like it would be useful for forming ad hoc networks, for example in a disaster or emergency scenario. But for frequent daily use, it seems like it might be a particularly vulnerable protocol.
Are the benefits of high quality and reliable communication in a disaster/terrorism situation worth the potential risks of insecurity in that situation?
if you're sending code over the network in order to communicate, why have a traditional network at all? Why not just synchronize all the files between all the machines, or just have terminals? It seems like a mistake to send code for anything as a part of initiating network communication.
PC 1: "here's how to hack me."
PC 2: "OK! sending hack."
PC 1: "thanks! Now I'm hosed."
PC 2: "no prob. see you in hell! ha ha ha!"
stuff |
From the article:
:) Obje reminds me of this - standards about standards about actual work.
The Obje platform works with all standards, including those that have not yet been defined. It requires no central coordination, pre-configuring, or special set-up, and can be easily used by people with no technical expertise.
It provides users a way to combine devices to build simple solutions for hundreds of problems - easily assembling their particular applications from available devices and services. It offers manufacturers a simple, fast, and timely solution to the increasing requirement to connect products.
The Obje platform works with devices of all kinds - including cell phones, computers, personal digital assistants (PDAs), printers, set-top boxes, bar-code scanners, video displays, and others - from any manufacturer.
It works with everything, everywhere - because rather than being some kind of new l33t tech, or even a new technical standard, it's a self-described "meta standard".
In that respect, it reminds me a lot of Microsoft's DNA (Distributed Network Architecture), which I'm not sure anyone remembers. I only do because I built the Mid-Atlantic DNA labs, having worked for one of their Premiere Partners. Basically DNA wasn't new tech of any kind so much as a way of thinking and realignment of existing technologies. Instead of coming up with something really neat and whizbang to sell, Microsoft instead tried selling the process of how to think about how to get work done. Instead of creating apps that are live in the net, say, add a layer of firewalling and some abstraction between the user and the app itself, centralize all of your data in searchable SQL databases, and do other really common stuff!
And they charged people for it, too.
Q. How is the Obje interoperability platform different from UPnP? Jini?
A. The key difference between the Obje technology and other approaches to interoperability is that Obje does not require prior agreement on domain specific interfaces--the protocols, encodings, and standards used to communicate with specific types of devices. Other technologies, including UPnP, Jini, HAVi and Bluetooth, each define specialized interfaces for each new type of device: Bluetooth defines "profiles" for phones, headsets and printers; Jini defines APIs for printers and cameras; the UPnP consortium defines interfaces for audio/visual devices, scanners and home appliances; HAVi defines APIs for DVD and CD players, printers, cameras and TVs.
The problem with such approaches is that software must be recoded to address each specific type of device that it is expected to work with. For example, an application written to use UPnP media servers will not be able to use UPnP scanners (much less devices implemented under other standards) without re-implementation.
With Obje, devices and applications are written once, against a small, fixed set of meta-interfaces, which allow them to acquire any needed communication capabilities at runtime. These meta-interfaces abstract the protocols and communication standards used by specific devices so that, at runtime, a device can provide its communication specifics to the entity that wants to use it, with no reprogramming of existing services. This allows users and manufacturers to "recombine" devices and services at will, without waiting for slow-moving standards bodies. This ability is unique to Obje.
And to think that all this time, I was expressing my algorithms in pictograms!
So from what I've read in the article, this looks to be Plug'n'play as it was meant to be:
Devices which use simple initial aggreed upon standard to extend their various servcies to each other without all the protocols having to be aggreed upon ahead of time, just a few simple initial protocols which are used to communicate and extend the other protocols and services between the devices. If this is applied correctly by the industry, it could change computing a lot, opening more complex systems to users with less experience and requiring less support resources. I'll be watching this closely.
Simply enough, you don't trust the other end, and all code is run in a sandbox. If the code does anything strange the session is terminated, if the other system (or peripheral) hands you strange code too many times you just stop listening. I don't think it's really necessary to send code, it would be just as well to send a list of capabilities (shades of my HVAC discussion) and then the sytem decides what you are based on your capabilities and treats you accordingly.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
With Java you can do this. Just run the code in a sandbox. Alternatively you can use some trusted third party and signatures. Or you can do both (authenticate other party and allow verified and validated code to do whatever it is authorized to do). The JINI architecture works along these lines (although it seems rather dead nowadays). It can be very secure if you set it up properly.
Jilles
and then the sytem decides what you are based on your capabilities and treats you accordingly.
This assumes that the system already knows about all possible capabilities and that it knows how to talk to everyone else.
I think the idea is that devices teach each other of their existence. It would be like if I bought a USB device (say a camera) that Windows didn't support, the camera would be able to bootstrap Windows with some drivers from its own firmware. The only thing that has to be prearanged is a protocol for this transaction. I don't need to maintain an extensive driver library for this to work.
SPAM
What portion of detecting whether code sent to you over the network is doing something 'strange', do you find simple? I hate it when people preface comments with "Simply enough" or "Obviously". It automatically makes anyone who doesn't understand what the person is talking about, feel stupid.
This sounds very much like PARC wants to teach machines how to interact more on "human" terms than on strict "computer" terms.
The most useful systems of tomorrow can't simply assume that peripherals/devices conform to their world view in order to work together. Instead, they must spend some time up front talking, listening, communicating, then eventually, cooperating.
Heading in this direction will prevent a technological monoculture from appearing, which wedges itself into a hole dug from its own presuppositions. Instead, I think this would foster a hardware equivalent of Open Source, where anyone who knew how to talk the fundamental protocol could build something interesting and introduce it into a system.
Of course, that's a pretty far-off idea, but I think it is worth pursuing.