Trackers

I am getting into trackers, as in Quantified Self.

But the tracking apps that you have to invoke manually are too high overhead.

I used to use a chess clock to track time working versus lost to IT bugs.

Idea: extend and adapt this for multiple trackers.

E.g. start off with an Android chess clock like tracker.  Big buttons saying working, lunch, hung, ...

Extend to scroll through a list of tracker/samplers. 

Find latest version of tool on path

Frustrated by systems where there isn't a single order of bin directories that can arrange for the most recent version of tools to be used, I wrote a tool to find the latest version of a tool on the path:


~/bin/path-version -latest -verbose --version -print -exec bash -c 'echo hi from bash $($SHELL -version)'
/home/glew/bin/bash: 3.2.25(1)-release
/usr/local/bin/bash: 2.05a.0(2)-release
/bin/bash: 3.2.25(1)-release
latest: /home/glew/bin/bash: 3.2.25(1)-release
exec /home/glew/bin/bash, -c echo hi from bash $($SHELL -version);
hello /bin/bash -c echo hi from bash $($SHELL -version)
hi from bash GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc.

--version (or -v, or -V, or -version) is the knob passed to the tool to query its version.

you can print all version, just the most recent, or just exec.

-- 

Based on a Perl library I just wrote, Version_Numbers.pm, that parses Version number strings of several syntaxes.  I.e. not just Perl's, and not just 1.2.3

I was surprised not to find such a library already existing.  Some were close, but not quite there.

Also compares.  Although the comparison rules are  a it two simplistic: strings are lexically sorted, whereas possibly

1.2rc should be less recent than 1.2, if the latter is what actually got released.

Capabilities created on the fly

I'm a fan of capabilities.

But a problem with capabilities systems is creating and maintaining the capabilities.

If somebody has to design the capabilitis, then you end up with a finite list for whatever the creator anticipated you might ask for.  Something like Android's app privileges: "This app requests full Internet access."

Hell, no: I only want it to access particular sites.  And I only want it to send data from certain files. ...

But what OS writer wants to code all of that up?

--

How about creating capabilities on the fly.

E.g. create capabilities automatically for all syscalls:

"open( function_or_regexp_to_be_applied_filename, function_to_be_applied_to_permissions)"

like

open
only files under such and such a directory
    owned by such and such a user
    after a scan has ben done on them
read-only


"* ... "

any syscall
with a filename argument that meets certain criteria ...
...



---

Since syscalls are rather low level, might apply this to any function call or library.

---

In general, want functions to be applied before the call, given the call, arguments.  Possibly caller...  (like "No socket opens from the user interaction facility".

Possibly evaluate on the raw call and args.
Better yet if can be evaluated on the canonicalized data that might be recorded in a log file - e.g. where filenames are made absolute, etc.

---

This doesn't eliminate the need to design coherent capabilties systems.

But it does mean that you can fairly create iron-clad invariants, such as only files in a particular place are accessed.

Aargh!! Out of date systems!!!

Aargh!!! I am sick and tired of working on out of date Linux boxes (that I am not sysadmin ion, that I cannot easily update.)

Today's trivial annoyance:

bash prompt \D{strftime format}

doesn't work on the bash 2.05a.0(2) copyright 2001
installed on the machine I am working on at work
works on a more recent ubuntu ...  4.1.5(1) - copyright 2009

---

Many pf my frioends just maintain their own virtual machines with whatever they depend on
- usually more recent than work - installed.
I must start doing that.

(Last time I tried, I ran out of disk space. Plus, the laptop I can install on is much slower than the workstations I can run on, even though they have old software.)

And then there's the risk that what works in my virtual box won't work on a standard work machine that somebody else is using...


--

These are trivial annoyances.  But finding failures like this wastes a trivial amount of time.  Many times in any given week.

Brackets - XML, and non

I like XML's "brackets":  <longname attributes="attributes"> ... </longname>.

Makes XML much less vulnerable to mismatches like dropping a paren:

<A> <B> <C> <D> ... </D> </B> </A> - the missing &lt/C> can be inferred, and possibly even repaired

(A: (B: (C: (D: .... ) ) )
which closing paren is missing? A, B, C, or D's?

But... sometimes I end up editing XML by hand. (Like on a wiki. (Or in blogger :-( )  And sometimes typing <longname>...</longname> is just too much.

Sometimes I would like the option of having a more compact, but less robust, bracket notation. Like the above mentioned (A: ... )

Or [A: ... ].  Or {B: ...}.  Or (although that latter is hard to tell from XML.)

Consider

<A> (B: {C: [D: ... ] ) </A>

it is still pretty easier to infer that the closing } for {C:  is missing.

Here's a thought: the matchingness of brackets is orthogonal to the actual name of the construct that uses the bracket - in XML parlance, the element.

LISP dialects that use only parens ( and ) exclusively are at one end of the spectrum.

XML, with arbitrary <tag> ... </tag> is at the other end.

And in between, we can have notations that use matching { and }, [ and ], < and >, << and >> - heck, Perl and regexps show that there don't even need to be matching pairs.  ' and '. " and ". Or ‘ and ’, etc.

These could be intermixed, as I have done before.

Indeed, the same entity, the same statement type, could use either bracketing form: &ltA> (A: ... ) </A>

I can imagine tools that translate between these forms.

From XML: &ltA> <A> ... </A> </A>

To strictly lisp-like parens: (A: (A: ... ) )

To forms that employ multiple bracket types for "clarity": (A: {A: ... } )

 ---

I guess that I am using (A: ...) as the compact representation of <A>...</A>.

Q: what about attributes? (A at1="at1" at2="at2" ... : ...)

 ---

There seems to be little lossage here. Except for the lost opportunity to place attributes on closing XML tags, <tag attributes>...</A closing-attributes> --- something that XML does not allow, but which I have supported in my own pseudo-XML dialects.

The HTML Mediawiki passes through

http://en.wikipedia.org/wiki/Help:HTML_in_wikitext

I've ranted before about quotification.

In the link is described the HTML that Mediawiki allows in wiki pages - i.e. the stuff it passes through.

Now, Mediawiki has to have a white list, because it cannot allow arbitrary HTML constructs that a maluser might use, e.g. to inject malware onto wiki pages.  E.g. all, or mostly all, user provided JavaScript must not be allowed. Even basic formatting may not be allowed - e.g. an attacker may be able to use CSS styles creatively to render invisble much text on a page, and thereby creating a phishing page with what remains. Plus the usual issues with tracking links, etc.

More basically, Mediawiki must not allow arbitrary user text. In particular, it must not allow text that would interfere with the HTML that Mediawiki is itself producing.

Now, that last is what my "modest proposal for quotification" specifically attacks: basically add a tag bit to every character that the user inserts, so that it can be distinguished from mediawiki added HTML.

But my "modest proposal" would disallow any user added HTML.  Except for the user added HTML that Mediawiki specifically whitelists, finds, filters, and explicitly removes the tag bit from. And, of course, any bugs in that procedure could lead to security holes...

At least HTML, XML, etc. is easy enough to parse that Mediawiki can filter out anything that isn't on the whitelist.  It does not have to worry TOO MUCH that new syntax will be added that it does not know about.  That's the joy about HTML/XML:  the syntax is (relatively) stable. Extensions can be added by adding new elements and attributes, but existing parsers can recognize such additions, and decide to pass them through or filter them out.

But, it would be nice if Mediawiki (or my own tools) could pass through much, much, more mediawiki.  If instead of having to whitelist specific constructs, they could say "Evaluate all HTML that does not consistute a security risk".  And especially Javascript.

E.g.

• do not evaluate any HTML or JavaScript that opens client files (without special permission)
• do not evaluate any HTML or Javascript that renders existing page elements invisible (except for 
• specially marked stuff.)  I.e. no switching to white on white zero size.

the above is a blacklist.  Or a whitelist:

• only evaluate HTML or JavaScript or CSS that changes colors in a likmited way, or fonts in a limited way, or text size in a limited way...

and so on.

I.e. it would be nice to be able to EVALUATE arbitrary HTML and Javascript, in a sandbox whose capabilities are explicitly circumscribed.

Whitelist the capabilities. 

Not necessarily the text.

Whitelist what the code does.  Not the input.

windows hang, android bitches

I hate it when Windows (7)
stops accepting keyboard input & must be rebooted.

but at least i can bitch about it using my android.