Inventing on Principle - amazing video!

Started by
65 comments, last by ddn3 12 years, 1 month ago

I wouldn't personally actually be concerned about security in the domains where I'd find this useful.

I think this in itself is an the heart of the issue.

Consider a LISP machine (designed from the ground up to give maximum flexibility to the developer), versus iOS (designed from ground up for end user experience). Each serves it's own purpose well, but the purposes are entirely distinct.

In the context of a modern consumer device, we have to surrender flexibility in certain areas in order to ensure end-user experience. Third party apps must be sandboxed, so they cannot disrupt battery life, network stack, or monopolise user interface, etc.

That doesn't imply that certain LISP machine concepts aren't useful in user-space. Increased introspection and debugging support all to the good.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Advertisement


Yes, for the fifth time in this thread, one needs to go to extreme measures to gain sufficient insight, because most widely available platforms (aka cheapest and ubiquitous) no longer provide it.



When did they ever provide this level of development? LISP machines? I don't think LISP machines provided anywhere near the level of interactive execution and procedural programming we're discussing ( nothing I've found on the Internet or from reading Wikipedia anyways). Nothing like this have been developed yet, only glimpses here and there. If this is to be a reality the hard work has to be done and it's fully possible as I laid out, there are no hardware or software barriers. It would be nice to leverage existing technology but nothing has been developed like this, well maybe Haskel and their advance functional programming models comes close..

-ddn

[quote name='Antheus' timestamp='1331166859' post='4920255']
Yes, for the fifth time in this thread, one needs to go to extreme measures to gain sufficient insight, because most widely available platforms (aka cheapest and ubiquitous) no longer provide it.



When did they ever provide this level of development? LISP machines? I don't think LISP machines provided anywhere near the level of interactive execution and procedural programming we're discussing ( nothing I've found on the Internet or from reading Wikipedia anyways). Nothing like this have been developed yet, only glimpses here and there. If this is to be a reality the hard work has to be done and it's fully possible as I laid out, there are no hardware or software barriers. It would be nice to leverage existing technology but nothing has been developed like this, well maybe Haskel and their advance functional programming models comes close..

-ddn
[/quote]
Take a running process that you didn't write, say your filesystem browser. You can point to that, stop its execution, be directed to its source code, modify bits of it and interact with it without ever relaunching anything. To a deep extent, you can dive into system calls as well. That was implemented. It is implemented in a smaller way (for obvious reasons) in Allegro CL and LispWorks. Probably also the Mac Clozure IDE, though I have minimal experience with that.

Take a running process that you didn't write, say your filesystem browser. You can point to that, stop its execution, be directed to its source code, modify bits of it and interact with it without ever relaunching anything. To a deep extent, you can dive into system calls as well. That was implemented. It is implemented in a smaller way (for obvious reasons) in Allegro CL and LispWorks. Probably also the Mac Clozure IDE, though I have minimal experience with that.


Sure glimpses and pieces have been done, VM sandboxing, in memory modification, runtime configuration, state dumping, etc.. all the pieces are in themselves not super difficulty, its combining all the pieces into a cohesive system built around a unified theory of programming ( in this case procedural programming centered around reversible execution and state splitting ). More to Antheus point, that's at the software level, to get the nitty gritty u would have to support this at the OS level and my point is there is no OS nor there ever was one which allowed this, you'd have to write a whole new one.. imo.



-ddn


Third party apps must be sandboxed, so they cannot disrupt battery life, network stack, or monopolise user interface, etc.


Solving the wrong problem. Battery life? Just peg the CPU. Network stack? Max the traffic. Sandboxes don't help.

If anything, both of these raise questions which are currently not being addressed by sandboxes, nor are they all that relevant.

Aside from a little fun for script kiddies, there is no money in draining the battery. Important questions deal with data, not hardware. Is there a way for some piece of my personal knowledge (bank account, email password, ...) to be shared with people I didn't intend to. That's a very hard question to define since it's hard to define exact relations between those pieces.

Why is iOS perceived as safe? Sandbox? The approval process, semi-automated "many eyes".

We have static analyzers, but hardware is a bit too complex and software not even remotely structured enough to allow automated proof preventing above issues. Instead of trusting some external gatekeeper, just prove that downloaded code doesn't violate any of given constraints (obvious complexity problems arise).

Web shows both sides of sandboxing. On one hand, if you take enough things away, sandbox becomes fairly secure. At same time, HTML5 has the ability to crash the OS (driver and JS VM related bugs through JS or canvas or WebGL).

Or, look at recent DNS block incident in a fully web-based form software. Some people decided to use the service for phishing by faking forms from banks.

Hardware/kernel exploits may sound attractive, but really aren't all that interesting. They definitely limit certain attack vectors, but still rely on user to make a judgement call - someone who roots their phone or perhaps installs untested software is just at same risk.

Sanboxes and other technologies are abstractions. Abstraction is a means, it doesn't need to hide or obscure underlying layers. That may mean different things in different context, sometimes allowing access to lower levels, or perhaps just having full access to source is enough. In some cases, hiding underlying layers may be beneficial, but just about all of the barriers today are for commercial reasons, not for sake of security or improvement of user's experience.

Process is all that matters. Phones are safe because of process, not because of tech. Similar to web, where security/safety depends on credibility of company. Despite one of most robust sandboxes, web remains one of least secure platforms for stuff that matters.

Another interesting aspect is game theory and determining how trust works and how risks are mitigated, which does answer why magic sandboxing is very viable solution - but unfortunately one that many take for granted: "How could this happen, I did ....".

u would have to support this at the OS level and my point is there is no OS nor there ever was one which allowed this, you'd have to write a whole new one.. imo.

There was/is something that did exactly what I was describing, though to say "is" I have to concede that while you can buy it and get it to run, it is extremely dated, if not "dead". It is Genera OS.
We'll i stand corrected, Genera OS does seem like it might fit the bill, being a Lisp machine driven by low level Lisp code, OS coded in Lisp itself and drivers, if it allows you to hack its execution and roll back and permutate the state, then it would be perfect for exploring this programming paradigm (other than being written in Lisp :) )..

-ddn

This topic is closed to new replies.

Advertisement