"STEREOTACTIC IMAGE GUIDED IMPLANTATION OF BILATERAL GPi DEEP BRAIN STIMULATION ELECTRODES WITH VOLUMETRIC ANALYSIS USING MAZOR ROBOT AND IMPLANTATION OF RIGHT INFRACLAVICULAR PULSE GENERATOR"
was on all the forms I had to sign, describing what was done to me...
"Stereotactic image" (the 3D result of an MRI scan on Tuesday and a CT scan Friday morning)
"... guided" (the team looked at the 3D image to plan the route of the wires into my brain)
"Implantation" (skewering)
"of bilateral" (both sides)
"GPi" (globus pallidus interna -- the part of my brain they were targeting)
"deep brain" (well, it was pretty deep in there, and hard to get to)
"stimulation electrodes" (two thin cables with 8 strands each leading to 8 points within the GPi)
"with volumetric analysis" (checking the path so they don't skewer something important)
"using Mazor robot" (a device they attached to a 'platform' that was screwed into my skull first thing Friday morning after first making me a numb-skull, then drilling pilot holes and screwing in; the Mazor robot then guides the surgery exactly)
"and implantation" (this one goes in a little pocket they cut in my chest)
"of right" (only one)
"infraclavicular" (under my collar bone, the electrode leads pushed under scalp, neck skin, down chest)
"pulse generator" (the thing that will send pulses to the electrodes)
Right now my brain is recovering from the trauma of this disturbance... my Parkinson's symptoms are mainly worse than usual -- both hands shaking, having trouble standing, using a walker to scoot around the house, speech soft and distorted enough that Alexa doesn't understand me, mild headache, among other indignities.
Today I get to shower! Yay!
My appointment for having the whole thing turned on and to start tuning the pulses to my body is February 16th. Happy Birthday!
The process of fine tuning can take 6 months of appointments every two weeks. Each of 8 leads on each side, with their own pulse intensity, frequency and width ... I'm assuming there's some method to it, will let you know.
February 7, 2018
January 25, 2018
Going Bionic
I hadn't talked about it publicly, but it's pretty obvious now if you see me in person: my hands (often) shake, my foot (often) drags. I have Parkinson's disease -- first diagnosed 12 years ago, its a slowly progressive condition. There are whole books about all the horrible potential symptoms, but I've been fortunate (among the millions with it) that my symptoms have been relatively mild. Medications, exercise and determination mainly controlled the worst.
But progressive diseases progress, and interfere with getting on with life.
I'm mainly risk-averse, but (after declining 5 years ago) I'm now scheduled next week for a surgical treatment called "Deep Brain Stimulation": like a pacemaker, but for the brain rather than the heart, and more of a pace-disruptor than -maker.
The procedure is described as "minimally invasive" and "reversible" and it's been done 100,000 times (300 by my surgeon). But still, it requires MRI and CAT scan to place wires to the exact spot without hitting good brain or blood vessels. (I got a Rift VR tour of some patient's anonymized brain as part of the explanation.)
Besides the wires in my brain ("Will I be able to listen to the radio without a radio?"), there will be wires under skin from scalp down to a not-so-tiny controller implanted -- wirelessly charged and programmed, battery rated to last 15 years. The "programming" usually takes months of adjustment.
I remember ~40 years ago admiring someone's programming skills, to the point I told people "he's so good I'd let him program my pacemaker". I'm not going to ask Boston Scientific to review their source code, but I do hope they aspire to better than "five nines".
Wish me luck...
1/31 added: for all the good wishes, expressed and felt: thank you, its meant a lot...
But progressive diseases progress, and interfere with getting on with life.
I'm mainly risk-averse, but (after declining 5 years ago) I'm now scheduled next week for a surgical treatment called "Deep Brain Stimulation": like a pacemaker, but for the brain rather than the heart, and more of a pace-disruptor than -maker.
The procedure is described as "minimally invasive" and "reversible" and it's been done 100,000 times (300 by my surgeon). But still, it requires MRI and CAT scan to place wires to the exact spot without hitting good brain or blood vessels. (I got a Rift VR tour of some patient's anonymized brain as part of the explanation.)
Besides the wires in my brain ("Will I be able to listen to the radio without a radio?"), there will be wires under skin from scalp down to a not-so-tiny controller implanted -- wirelessly charged and programmed, battery rated to last 15 years. The "programming" usually takes months of adjustment.
I remember ~40 years ago admiring someone's programming skills, to the point I told people "he's so good I'd let him program my pacemaker". I'm not going to ask Boston Scientific to review their source code, but I do hope they aspire to better than "five nines".
Wish me luck...
1/31 added: for all the good wishes, expressed and felt: thank you, its meant a lot...
October 22, 2017
Mea Culpa
I hate Twitter. It amplifies the emotional content of what should be a rational discussion.
I was dismayed to see a twitterstorm of complaints about the ODI report on PDF and data.
I was dismayed to see a twitterstorm of complaints about the ODI report on PDF and data.
I'm especially embarrassed that I asserted (too convincingly) anything about stars. The 5-star evaluation of file formats was a nice idea, but shouldn't apply to formats at all.
Whether something is "open" depends on the tools you have, as I explore in Open Data and Documents, the scale doesn't match what people actually value.
I love Twitter. I think the twitter responses have been useful in at least reaching the user community. Thanks.
Join in on the discussion.
Whether something is "open" depends on the tools you have, as I explore in Open Data and Documents, the scale doesn't match what people actually value.
I love Twitter. I think the twitter responses have been useful in at least reaching the user community. Thanks.
Join in on the discussion.
October 21, 2017
September 10, 2016
IETF "Security Considerations" and PDF
One of the things I've been doing lately is trying to dampen some of the misconceptions and misdirections concerning the Portable Document Format (PDF). I'm not sure why, except people seem to forget what was good about it and what wasn't (isn't).
PDF is over 20 years old ... "as old as the Web"-- I first heard about it at GopherCon '93. Has it run its course, time for something new? But PDF supplies a unique solution for an application that spans the work between paper documents and electronic, and assurances of fidelity: if I send you a document, and you say you got it and read it (using a conforming reader) then I know what you saw.
There's an official list of media types managed by IANA (in the news lately for other reasons, another blog post). IANA, Internet Assigned Numbers[sic] Auhority, is in charge of maintaining the
registries, as directed by the IETF.
IETF has a different decision-making process than other standards groups. However, as usual, the process involves creating and distributing a draft, and asking for comments. Comments need to be responded to, even if you don't make changes because of the comment. Different kinds of documents have different criteria for advancement, and it's sometimes hard to figure out what rules apply.
There were lots of comments during the review period, and I responded to most of them last week, in a single email.
But which rules apply? RFC 6838 Section 3.1 for types "registered by a recognized standards-related organization using the 'Specification Required' IANA registration policy [RFC5226]"? Or do we follow Section 6.1, "in cases where the original definition of the scheme is contained in an IESG-approved document, updates of the specification also requires IESG approval."?
And does the "DISCUSS" laid on the document's approval meet any of the criteria of the rules for a DISCUSS?
But I'd like to accommodate the common request that the document say more about security of PDF software. It's well-known that PDF has been a vector for several infamous exploits... why can't we say more?
I'm sure we could say more. And if this were a new registration or the PDF spec itself I'd try. But application/pdf has been around over 20 years, the exploits and their prevention publicized.
But there is no single valid account of software vulnerabilities; the paper suggested (in a COMMENT, not a DISCUSS) isn't anything I could cite; I disagree with too many parts.
I’ll go back to the question of the purpose of “Security Considerations” in MIME registrations; for whom should it be written? For a novice, it is not enough. For an expert, you wind up enumerating the exploits that are understood and can be explained. The situation is fluid because the deployment of browser-based PDF interpreters is changing for desktop and mobile, and PDF is just another part of the web.
I agreed with the reasoning behind the requirement, that requiring everyone to write about Security might make them think a little more about security.
But I think there’s another view, that Security is a feature of the implementation. It’s the implementation’s job to mitigate vulnerabilities. So any security problems, blame the implementation, not the protocol. And the implementors need to worry about not writing buggy code, not just about security per se.
And there is no point of saying “write your implementations carefully”, because there are so many ways to write software badly. Talking about the obvious easy-to-describe exploits isn’t really useful, because we know how to avoid those.
Now perhaps this is just "don't set a bad precedent". So maybe the clue is to follow text/html, and suggest that "entire novels" have been written about PDF security, but not here in the Internet Media Type registration.
Some background about PDF
Everyone has heard of PDF, but I'm not sure there's widespread understanding of its role and history. Wikipedia PDF isn't too bad; page independent data structures but based on Postscript, a way of getting licenses to embed fonts, first released in 1993. Originally a "distill" of a printed page, over the years, features were added: forms, 3D, compression, reflow, accessibility.PDF is over 20 years old ... "as old as the Web"-- I first heard about it at GopherCon '93. Has it run its course, time for something new? But PDF supplies a unique solution for an application that spans the work between paper documents and electronic, and assurances of fidelity: if I send you a document, and you say you got it and read it (using a conforming reader) then I know what you saw.
MIME types
In email and web, file types are labeled by a two part label, like text/html, image/jpeg, application/pdf. This "Internet Media Type" is (supposed to be) used in content-type headers in email and web as a way for the sender to say how a receiver should interpret the content (except for "sniffing" but that's another blog post).There's an official list of media types managed by IANA (in the news lately for other reasons, another blog post). IANA, Internet Assigned Numbers[sic] Auhority, is in charge of maintaining the
registries, as directed by the IETF.
IETF has a different decision-making process than other standards groups. However, as usual, the process involves creating and distributing a draft, and asking for comments. Comments need to be responded to, even if you don't make changes because of the comment. Different kinds of documents have different criteria for advancement, and it's sometimes hard to figure out what rules apply.
Getting draft-hardy-pdf-mime to RFC
I got into updating the registration of PDF a while back, while working on "PDF for RFCs", and, after consultation, took the path of revising the RFC which authorized the current registration, RFC 3778, in the form of a document that replaced 3778, including the registration template for application/pdf . That's the document I'm trying to get passed.There were lots of comments during the review period, and I responded to most of them last week, in a single email.
Which process?
I won't go into the detailed rules, but the path we chose involved getting IESG approval for an Informational specification, one of the paths laid out in RFC 6838, which lays out the rules for the IANA media type registry.But which rules apply? RFC 6838 Section 3.1 for types "registered by a recognized standards-related organization using the 'Specification Required' IANA registration policy [RFC5226]"? Or do we follow Section 6.1, "in cases where the original definition of the scheme is contained in an IESG-approved document, updates of the specification also requires IESG approval."?
And does the "DISCUSS" laid on the document's approval meet any of the criteria of the rules for a DISCUSS?
But I'd like to accommodate the common request that the document say more about security of PDF software. It's well-known that PDF has been a vector for several infamous exploits... why can't we say more?
"Security Considerations"
IETF has an unusual policy of requiring ALL documents (https://tools.ietf.org/html/rfc3552 Section 5) to consider security and document threats and possible mitigations. ISO has no such rule; security is considered the responsibility of the implementation. W3C nominally does through TAG review, I think, but WHATWG is more haphazard. The question remains: does a conforming implementation require that the implementation expose the user to security risks.I'm sure we could say more. And if this were a new registration or the PDF spec itself I'd try. But application/pdf has been around over 20 years, the exploits and their prevention publicized.
But there is no single valid account of software vulnerabilities; the paper suggested (in a COMMENT, not a DISCUSS) isn't anything I could cite; I disagree with too many parts.
I’ll go back to the question of the purpose of “Security Considerations” in MIME registrations; for whom should it be written? For a novice, it is not enough. For an expert, you wind up enumerating the exploits that are understood and can be explained. The situation is fluid because the deployment of browser-based PDF interpreters is changing for desktop and mobile, and PDF is just another part of the web.
I agreed with the reasoning behind the requirement, that requiring everyone to write about Security might make them think a little more about security.
But I think there’s another view, that Security is a feature of the implementation. It’s the implementation’s job to mitigate vulnerabilities. So any security problems, blame the implementation, not the protocol. And the implementors need to worry about not writing buggy code, not just about security per se.
And there is no point of saying “write your implementations carefully”, because there are so many ways to write software badly. Talking about the obvious easy-to-describe exploits isn’t really useful, because we know how to avoid those.
Now perhaps this is just "don't set a bad precedent". So maybe the clue is to follow text/html, and suggest that "entire novels" have been written about PDF security, but not here in the Internet Media Type registration.
February 15, 2015
Birthday greetings, Packed committees, community, standards
Today is my birthday. I woke to find many birthday greetings on Facebook, and more roll in throughout the day. It's hard to admit how pleasing it is, embarrassing. I haven't asked for birthday greetings and don't usually give them. Maybe I'll change my mind.
Perhaps I'm late to the party but I'm still trying to understand the 'why' of social networking -- why does Facebook encourage birthday greetings? What human pleasure does getting 11 "happy birthday" notes trigger?But it fits into the need to have and build community, and the mechanism for community requires periodic acknowledgement. We engage in sharing our humanity (everyone has a birthday) by greeting. Hello, goodbye, I'm here, poke. But not too often, once a year is enough.
I wrote about standards and community yesterday on the IETF list, but people didn't get it.
Explaining that message and its relationship to birthday greetings is hard.
The topic of discussion was "Updating BCP 10 -- NomCom ELEGIBILITY".
- IETF : group that does Internet Standards
- BCP10: the unique process for how IETF recruits and picks leadership
- NOMCOM: the "Nominating Committee" which picks leadership amongst volunteers
- elegibility: qualifications for getting on the NOMCOM
I think BCP10 is a remarkable piece of social engineering, at the center of the question of governance of the Internet: how to make hard decisions, who has final authority, who gets to choose them, and how to choose the choosers. Most standards groups get their authority from governments and treaties or are consortia. But IETF developed a complex algorithm for trying to create structure without any other final authority to resolve disputes.
But it looks like this complex algorithm is buggy, and the IETF is trying to debug the process without being too open about the problem. The idea was to let people volunteer, and choose randomly among qualified volunteers. But what qualifications? There's been some concern about the latest round of nomcom volunteers, that's what started this thread.
During the long email thread on the topic, the discussion turned to the tradeoffs between attending a meeting in person vs. using new Internet tools for virtual meetings or more support for remote participation. Various people noted that the advantage of meeting in person is the ability to have conversations in the hallways outside the formal, minuted meetings.
I thought people were too focused on their personal preferences rather than the needs of the community. What are we trying to accomplish, and how do meetings help with that? How would we satisfy the requirements for effective work.
A few more bits: I mention some of the conflicts between IETF and other standards groups over URLs and JSON because W3C, WHATWG, ECMA are different tribes, different communities.
Creating effective standards is a community activity to avoid the Tragedy of the Commons that would result if individuals and organizations all went their own way. The common good is “the Internet works consistently for everyone” which needs to compete against “enough of the Internet works ok for my friends” where everyone has different friends.
For voluntary standards to happen, you need rough consensus — enough people agree to force the remainder to go along.
It’s a community activity, and for that to work there has to be a sense of community. And video links with remote participation aren’t enough to create a sense of community.
There are groups that purport to manage with minimal face-to-face meetings, but I think those are mainly narrow scope and a small number of relevant players, or an already established community, and they regularly rely heavily on 24/7 online chat, social media, open source tools, wikis which are requirements for full participation.
The “hallway conversations” are not a nice-to-have, they’re how the IETF preserves community with open participation.
One negative aspect of IETF “culture” (loosely, the way in which the IETF community interacts) is that it isn’t friendly or easy to match and negotiate with other SDOs, so we see the WHATWG / W3C / IETF unnecessary forking of URL / URI / IRI, encodings, MIME sniffing, and the RFC7159-JSON competing specs based at least partly on cultural misunderstandings.
The main thing nomcom needs to select for is technical leadership (the skill of getting people to follow) in service of the common good). And nomcom members should have enough experience to have witnessed successful leadership. One hopes there might be some chance of that just by attending 3 meetings, although the most effective leadership is often exercised in those private hallway conversations where compromises are made.
November 20, 2014
Ambiguity, Semantic web, speech acts, truth and beauty
(I think this post is pretty academic for the web dev crowd, oh well)
When talking about URLs and URNs or semantic web or linked data, I keep on returning to a topic. Carl Hewitt gave me a paper about inconsistency which this post reacts to.
The traditional AI model of semantics and meaning don't work well for the web.
Maybe this is old-hat somewhere but if you know any writings on this topic, send me references.
In the traditional model (from Bobrow's essay in Representation and Understanding), the real world has objects and people and places and facts; there is a KRL Knowledge Representation Language in which statements about the world are written, using terms that refer to the objects in the real world. Experts use their expertise to write additional statements about the world, and an "Inference Engine" processes those statements together to derive new statements of facts.
This is like classic deduction "Socrates is a man, all men are mortal, thus Socrates is mortal" or arithmetic (37+53) by adding 7+3, write 0 carry 1 plus 3 plus 5 write 9, giving 90.
And to a first approximation, the semantic web was based on the idea of using URLs as the terms to refer to real world, and relationships, and RDF as an underlying KRL where statements consisted of triples.
Now we get to the great and horrible debate over "what is the range of the http function" which has so many untenable presumptions that it's almost impossible to discuss. That the question makes sense.
That you can talk about two resources being "the same". That URLs are 'unambiguous enough', and the only question is to deal with some niggly ambiguity problems, with a proposal for new HTTP result codes.
So does http://larry.masinter.net refer to me or my web page? To my web page now or for all history, to just the HTML of the home page or does it include the images loaded, or maybe the whole site?
"http://larry.masinter.net" "looks" "good".
So I keep on coming back to the fundamental assumption, the model for the model.
Coupled with my concern that we're struggling with identity (what is a customer, what is a visitor) in every field, and phishing and fraud on another front.
Another influence has been thinking about "speech acts". It's one thing to say "Socrates is a man" and completely different thing to say "Wow!". "Wow!" isn't an assertion (by itself), so what is it? It's a "speech act" and you distinguish between assertions and questions and speech acts.
A different model for models, with some different properties:
Every speech is a speech act.
There are no categories into assertion, question, speech act. Each message passed is just some message intending to cause a reaction, on receipt. And information theory applies: you can't supply more than the bits sent will carry. "http://larry.masinter.net" doesn't intrinsically carry any more than the entropy of the string can hold. You can't tell by any process whether it was intended to refer to me or to my web page.
Truth is too simple, make belief fundamental.
So in this model, individuals do not 'know' assertions, they only 'believe' to a degree. Some things are believed so strongly that they are treated as if they were known. Some things we don't believe at all. A speech act accomplishes its mission if the belief of the recipient changes in the way the sender wanted. Trust is a measure of influence: your speech acts that look like statements influence my beliefs about the world insofar as I trust you. The web page telling me my account balance influences my beliefs about how much I owe.
Changing the model helps think about security
Part of the problem with security and authorization is we don't have a good model for reasoning about it. Usually we divide the world into "Good guys" and "bad guys": Good guys make true statements ("this web page comes from bank trustme") while bad guys lie. (Let's block the bad guys.) By putting trust and ambiguity at the base of the model and not as an after-patch we have a much better way of describing what we're trying to accomplish.Inference, induction, intuition are just different kinds of processing
In this model, you would like influence of belief to resemble logic in the cases where there is trust and those communicating have some agreement about what the terms used refer to. But inference is subject to its own flaws ("Which Socrates? What do you mean by mortal? Or 'all men'").
Every identifier is intrinsically ambiguous
Among all of the meanings the speaker might have meant, there is no inbound right way to disambiguate. Other context, out of band, might give the receiver of the message with a URL more information about what the sender might have meant. But part of the inference, part of the assessment of trust, would have to take into account belief about the sender's model as to what the sender might have meant. Precision of terms is not absolute.
URNs are not 'permanent' nor 'unambiguous', they're just terms with a registrar
I've written more on this which i'll expand elsewhere. But URNs aren't exempt from ambiguity, they're generally just URLs with different assigned organizations to disambiguate if called on.
Metadata, linked data, are speech acts too.
When you look in or around an object on the net, you can often find additional data, trying to tell you things about the object. This is the metadata. But it isn't "truth", metadata is also a communication act, just one where one of the terms used is the object.
There's more but I think I'll stop here. What do you think?
Subscribe to:
Posts (Atom)
Medley Interlisp Project, by Larry Masinter et al.
I haven't been blogging -- most of my focus has been on Medley Interlisp. Tell me what you think!
-
HTML5 If there are 300 implementations of a specification, all different, but you take the 4 "important implementations" and...
-
I hadn't talked about it publicly, but it's pretty obvious now if you see me in person: my hands (often) shake, my foot (often) drag...
-
w3c , html5 , representation , resource , angels , pins , uri , url ,iri Everyone knows what a URL is, right? It's just a simple...