disarming malware

The problem with bad software isn't that it gets made. It will get made, and no matter how easy we make the tools for specification and testing of software, there will be people who use unsafe production methods to make unreliable and exploitable software. However, I would hope that a secure system can exist. In the same vein as modern cryptography, I acknowledge that perfect security in the general case is unlikely, but suggest that strong security-- in some specific, provable sense-- can exist in the software systems that humans subject themselves to.

My main goals:

1. make the economic benefits of releasing exploitable software less than the costs of producing good software.
2. minimize the effects of unavoidable exploits, eliminate avoidable exploits, provide tools for realizing these goals in software production systems.
3. make more accessible tools which can formally exclude the possibility of certain classes of exploits existing.
4. spread more knowledge about safe software practices to those who make software

~~~~

Treating software as biology

Not techinical at all, but I was just thinking about how sometimes software does things that don't make sense to us and which have no easy solution from a first guess at what's going on. It would be useful to have a integrative view of piece of running software. What I mean is, we want to be able to see what the features are of a system over time, how they change, but we want to see all of these things at the same time. That, I really hope, isn't too hard. From there I would like to see how we can take the state of the program and relate it to the activity of the system it works in.

This idea isn't entirely my own. There was a paper I read a while back about treating a peice of malware as a virus which has certain system call profile. For a single architecture and operating system, this should be statistically stable across machines and serve as a sort of marker. That idea comes, very loosely I'm afraid, from the immune system, which can identify antigens by interacting with them.

~~~~

A video of Michael Rabin discussing second-price auctions:
https://video.ias.edu/csdm/1213/0429-MichaelRabin

Concerns collusion resistance and zero-knowledge. The bidders want to hide their bids from everyone auctioneer (evaluator-prover), but they also want to know that their bids were calculated correctly. There is danger of collusion so that bidders can get a lower price (to the detriment of the auctioneer).

More from Micali (collaborated with Rabin on this topic): http://cacm.acm.org/magazines/2014/2/171688-cryptography-miracles-secure-auctions-matching-problem-verification/fulltext

~~~~

Something that would be useful: a running list of abbreviations and definitions on the side of a document reader. The listing depends on which abbreviations had been used up to that point in the paper -- so they appear and disappear as you go down and up the document. The definitions can be attached to the document as metadata, and that data can be modified by the user through the reader to include their own definitions.

A companion to this is a tool which will give abbreviations, synonyms, and definitions for certain terms on mouse-over.

~~~~

Book sculpture

~~~~

It is possible to change the patterns of thought and shift into "flow" intentionally and without rituals, etc. The difficulty is the delay between the decision and the onset of the mental state. Patience and experience bridge the gap.

~~~~

Should all of the constraints use sets?

I'm considering making all constraints use sets. This change would be contained to the connector class since every value that didn't use sets already could have all of its values implicitly wrapped into Singletons and then unwrapped on getValue calls. The problem there is, of course, that then the constraints which do make use of sets will have to form their own singletons whenever they request a value. Obviously, this is annoying. Part of the usage of sets that I'm thinking of is with inequalities. I want to be able to specify that a whole range of values could satisfy an inequality where previously, I had to settle for just not setting anything on that connector. In this context, singleton values don't make sense because they need to be dereferenced to the exact value anyway.

The main thing is that when we set a single value on top of a set, we have to test membership, but when we set another set on top of a set, we have to test the intersection is non-null (and possibly another value).
This gives something like:

(define (consistent? newval v)
...
(match (list newval v)
       [`(,(? Set? x) ,(? Set? y))
        (intersect x y)]
       [(or `(,(? Set? x) ,(? (negate Set?) y))
            `(,(? (negate Set?) y) ,(? Set? x)))
        (member? x y)]) ; member? returns y or (gensym)
...)

to get the value to set. Note that this also changes the meaning of consistent? to what might be called makeConsistent. An operator that takes two values of some type and returns an value that is consistent with both of them. This can be achieved by way of generics. The various set functions can be used with any values that they need and Connector only needs to know about the generic function makeConsistent. This allows for us to make any number of types and give them a their own definition of makeConsistent, but also to not require any changes to Connector -- the two concerns are completely separated. Going back to the original point of this post, we still have to change the use of consistent? Connector to makeConsistent and change the semantics of the constraint solver such that any constraint can set values on the connector (this was the case before), but may not be the setter anymore since the value that is finally set doesn't belong to any of them. However, assuming the makeConsistent functions are correctly implemented, we have to notify neither the setter of the old value nor the setter of the new one since the result will be consistent with them both. This may make the logic slightly more complicated, but the advantage of allowing extension of types by users outweighs that concern.

~~~~