ROS conceptually runs on the web, not in a single computer. Its job mainly is to make sure all data is instantly available to whoever has permission to see it using a predictive caching scheme. It is not up to the provider of the information to serve it or deliver it, merely to maintain the master copy. You never again need fear being SlashDotted. The closest thing we have to the decentralised file/message distribution system I envision is Napster.
Almost all programming can be viewed as an exercise in caching.ROS spends much of its time ensuring that no one else can pry on that data or modify it. Everything is encrypted and digitally signed. ROS spends the rest of its time pretending to be a computer-friendly search engine, finding and retrieving information from the web, filtering the tidal wave of information down to a manageable stream.
~ Terje Mathisen
Like the JVM (Java Virtual Machine), the ROS runs on a simulated highly evolved computer that has intelligent peripherals only, somewhat cleverer that today’s device drivers. They don’t need device drivers. This simplifies ROS and makes it more robust and secure. Various real OS (Operating System) ’s will host it (e.g. you can logically install an SQL (Standard Query Language) engine peripheral). Eventually ROS might develop some native iron to host it directly.
Many of my student projects are designed to be protypes for parts of this future operating system. It builds on top of the platform independence of Java, moving it from the language to the OS level. Have a look in particular at the following student projects:
The catch is, you don’t really want the ROS terminal seeing your keystrokes, your screen displays, or your unencrypted data. Perhaps the smart card could be powerful enough to act as CPU (Central Processing Unit) and dark room, so that at least the ROS terminal never saw unencrypted data even if it saw the other two.
Perhaps you need a government certification on ROS terminals to ensure they don’t cheat, that they forget everything once you pull your smart card. Perhaps brand names on ROS terminals attesting to tamper proofing will be sufficient.
Anthony Yen wrote: What is to prevent a hostile computer from compromising your migrated sessions’ authentication tokens? Instead of a smart card inserted into the new desktop, and the new desktop can attempt to break the smart card without the user’s knowledge or have a keylogger that pulls passwords entered at the keyboard, what if you could assume the availability of a cellular phone that is in the physical possession of the user? Then password challenges are negotiated through a device trusted and possessed by the user.
If you go to a hotel in Switzerland, there will be a computer in your hotel room. You sit down at it, and your cellphone automatically receives a locater code (IP (Internet Protocol) address or something more generic for NAT’d devices) from the computer via Bluetooth. You identify yourself with a passphrase on your cellphone, which makes a secure connection to your backup server, and instructs it to open a secure connection to the computer in the hotel at the given locater code. You acknowledge a question from you backup server on your cellphone that you see the session so that no hijacked sessions are possible by passing incorrect locator codes. At that point all your files and applications appear on the desktop, just as you left them at home.
Using this technique, no access passphrases are ever negotiated across hardware that is not personally trusted, possessed and verified by the individual user. Using one time pads, the final authorization step prevents hijack and replay attacks. The only attacks that remain are mirrored sessions, where someone installs hardware on the compromised system that shows what you see on the display. But if your data is so sensitive that you are worried about mirrored sessions, you probably would be using your own system all the time.
Perhaps you will not use ROS in the early stages of evolution for anything highly confidential.
available on the web at:
optional Replicator mirror
Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : . If you want your message, your name or email kept confidential, not considered for public posting, please explicitly specify that. Unless you state otherwise, I will treat your message as a letter to the editor that I may or may not publish in the feedback section. After that, it will be too late to retract it. If you disagree with something I said, especially when sending an ad-hominem attack, a rant composed mainly of obscenities or a death threat, please quote the offending passage and cite the web page where you found it, tell me why you think it is wrong, and, if possible, provide some supporting evidence. I can’t very well fix erroneous or ambiguous text if I can’t find it.
Your face IP:[18.104.22.168]
|Feedback||You are visitor number 11,059.|