hAtom storage

Today I set a personal record at #NPSF PR-Wednesday. 33:55 — 2:07 faster. I don’t remember feeling this miserable during a PR-Wednesday workout in a long time. But first the times: * 2:07 faster than my previous PR-Wednesday record 36:02 (2015-02-25) * 1:30 faster than my course record 35:25 (2015-01-13, before the course became our PR-Wednesday workout) The previous two months I did both the 5:30 & 6:30 PR-Wednesday workouts as well as the “tweeners” in-between workout. Those times: tantek.com/2015/084/t1/npsf-double-pr-wednesday Feb: 36:02 & 36:15 Mar: 38:32 & 37:04 Since February of this year, the NPSF Alta Plaza PR-Wednesday workout has consisted of: 1. start at the bottom of the steps on Pierce. 2. run a clockwise lap around the park 3. run up steps to the flat area between the playground & tennis courts 4. 10 burpees 5. run back down the steps 6. repeat 2-5 two more times 7. repeat 2-3. For a total of 4 laps, 30 burpees, ??? steps, as fast as you can. Things I did differently beforehand for this morning: * Last night: iced my knees — no pain, just a little swollen from Tuesday track (ttk.me/t4at1) * 5:49 put on my newer racing ASICs instead of old training pair or Nike Structure 18s. * 5:50 rungang (warmup run ~2 miles) to 6:30 @Nov_Project_SF instead of driving to doubling-up 5:30 & 6:30. * ~6:15 downed a Starbucks single espresso on the run to Alta Plaza (having had nothing to eat at home but a couple of chewable vitamin Cs). During the PR workout this morning, there were three things that I distinctly remember doing differently, and feeling more mentally and physically miserable about. 1. Ran (no walking) up the entire West side hill (first time) on lap 1, legs shaking at the top, thinking, I'm not even half a lap in yet. 2. Second time up the steps, I raced them hard two at a time to the top (thanks to a serendipitous music boost), and then almost felt like throwing up while doing burpees after. Actually felt that during all subsequent burpees. 3. Third lap, on the North side downhill, sprinted to the point of losing my breath (was inspired to pass Gil and Jorge on the downhill, each on their fourth lap, who then passed me back on the East side downhill when I had trouble breathing & running at the same time). 4. Not what I did, but what a friend did for me: Fourth lap, my friend Matt Scharr ran with me (he’d finished his workout already), verbally encouraging me and anyone else nearby the whole way. I’ve said it before (ttk.me/b/4Yy2) and I’ll say it again (ttk.me/b/4_n1), this is an incredibly positive, inspiring, and supportive group to run and workout with. http://november-project.com/wp-content/uploads/2015/04/DSC_01331-768x515.jpg from fb.com/media/set/?set=a.632064620263368.1073742040.276430682493432 However, the entire workout I felt like I was going either slower or no faster than before. I felt like I was having an off day. A miserable off day. But stubbornly I wasn’t going to give up. Instead, I pushed harder to just get it over with. And ended up going faster. I should emphasize, none of this involved any kind of pain threshold (as far as I remember). No knee pain nor ankle pain. (Well maybe a bit of suppressing a lingering sidecramp from my Sunday 7 mile trail run). Apparently it was all about pushing myself further into both psychological and physical discomfort than I had before on a PR day. It’s going to be interesting facing that next month, when I know that that’s what it’s going to take to both go that fast, and to have even a chance of PRing again. Fortunately I have a different race focus before then: Just 18 days til Bay to Breakers (2015-05-17) - where I’ll have a different mental challenge. Last year I cut over 16 minutes (ttk.me/t4W81) from my B2B time (thanks to six months of NovemberProject). This year I've had twelve more months of NP and I honestly have no idea what is a reasonable expectation. I’ve had some thoughts, like cut five minutes, get a sub-1:10 but I’m trying hard to focus and concentrate on just beating last year’s time and giving it all I’ve got, finishing with the knowledge of having done so.

Dublin Core Application Profiles — A Brief Dialogue

IndieWebCamp Cambridge 2015 is over. Having finished their ice cream and sorbet while sitting on a couch at Toscanini's watching it snow, the topic of sameAs, reuse, general semantics leads to a mention of Dublin Core Application Profiles.

A:
Dublin Core Application Profiles could be useful for a conceptual basis for metadata interoperation.
T:
(Yahoos for dublin core application profiles, clicks first result)
T:
Dublin Core Application Profile Guidelines (SUPERSEDED, SEE Guidelines for Dublin Core Application Profiles)
T:
Kind of like how The Judean People’s Front was superseded by The People’s Front of Judea?
A:
(nervous laugh)
T:
Guidelines for Dublin Core Application Profiles
T:
Replaces: http://dublincore.org/documents/2008/11/03/profile-guidelines/
T:
Hmm. (clicks back)
T:
Dublin Core Application Profile Guidelines
T:
Is Replaced By: Not applicable, wait, isn’t that supposed to be an inverse relationship?
A:
I’m used to this shit.
T:
(nods, clicks forward, starts scrolling, reading)
T:
We decide that the Library of Congress Subject Headings (LCSH) meet our needs. - I’m not sure the rest of the world would agree.
A:
No surprises there.
T:
The person has a name, but we want to record the forename and family name separately rather than as a single string. DCMI Metadata Terms has no such properties, so we will take the properties foaf:firstName and foaf:family_name
T:
Wait what? Not "given-name" and "family-name"? Nor "first-name" and "last-name" but "firstName" and "family_name"?!?
A:
Clearly it wasn’t proofread.
T:
But it’s in the following table too. foaf:firstName / foaf:family_name
A:
At least it’s internally consistent.
A:
Oh, this is really depressing.
A:
Did they even read the FOAF spec or did they just hear a rumour?
T:
(opens text editor)

Twitter post 579080519930892288

Simplifying Standards & Reducing Their Security Surface: Towards A Minimum Viable Web Platform

At the start of this month, I posted a simple note and question:

Thoughts yesterday lunch w @bcrypt: @W3C specs too big/complex. How do we simplify WebAPIs to reduce security surface?

With follow-up:

And @W3C needs a Security (#s6y) group that reviews all specs, like #i18n & #a11y (WAI) groups do. cc: @bcrypt @W3CAB

Which kicked off quite a conversation on Twitter (18 replies shown on load, 53 more dynamically upon scrolling if various scripts are able to load & execute).

Security & Privacy Reviews

Buried among those replies was one particularly constructive, if understated, reply from Mike West:

[…] mikewest.github.io/spec-questionnaire/security-privacy/ is an initial strawman for security/privacy self-review.

A good set of questions (even if incomplete) to answer in a self-review of a specification is an excellent start towards building a culture of reviewing security & privacy features of web standards.

While self-reviews are a good start, and will hopefully catch (or indicate the unsureness about) some security and/or privacy issues, I do still think we need a security group, made up of those more experienced in web security and privacy concerns, to review all specifications before they advance to being standards.

Such expert reviews could also be done continuously for "living" specifications, where a security review of a specification could be published as of a certain revision (snapshot) of a living specification, which then hopefully could be incrementally updated along with updates to the spec itself.

Specification Section for Security & Privacy Considerations

In follow-up email Mike asked for feedback on specifics regarding the questionnaire which I provided as a braindump email reply, and offered to also submit as a pull request as well. After checking with Yan, who was also on the email, I decided to go ahead and do so. After non-trivially expanding a section, very likely beyond its original intent and scope (meta-ironically so), it seemed more appropriate to at least blog it in addition to a pull request.

The last question of the questionnaire asks:

Does this specification have a "Security Considerations" and "Privacy Considerations" section?

Rather than the brief two sentence paragraph starting with Not every feature has security or privacy impacts, which I think deserves a better reframing, I've submitted the below replacement text (after the heading).

Reducing Security Surface Towards Minimum Viability

Unless proven otherwise, every feature has potential security and/or privacy impacts.

Documenting the various concerns that have cropped up in one form or another is a good way to help implementers and authors understand the risks that a feature presents, and ensure that adequate mitigations are in place.

If it seems like a feature does not have security or privacy impacts, then say so inline in the spec section for that feature:

There are no known security or privacy impacts of this feature.

Saying so explicitly in the specification serves several purposes:

Shows that a spec author/editor has possibly considered (hopefully not just copy/pasted) whether there are such impacts.
Provides some sense of confidence that there are no such impacts.
Challenges security and privacy minded individuals to think of and find even the potential for such impacts.
Demonstrates the spec author/editor's receptivity to feedback about such impacts.

The easiest way to mitigate potential negative security or privacy impacts of a feature, and even discussing the possibility, is to drop the feature.

Every feature in a spec should be considered guilty (of harming security and/or privacy) until proven otherwise. Every specification should seek to be as small as possible, even if only for the reasons of reducing and minimizing security/privacy attack surface(s).

By doing so we can reduce the overall security (and privacy) attack surface of not only a particular feature, but of a module (related set of features), a specification, and the overall web platform. Ideally this is one of many motivations to reduce each of those to the minimum viable:

Minimum viable feature: cut/drop values, options, or optional aspects.
Minimum viable web format/protocol/API: cut/drop a module, or even just one feature.
Minimum viable web platform: Cut/drop/obsolete entire specification(s).

Questions and Challenges

The above text expresses a specific opinion and perspective about not only web security, web standards, but goals and ideals for the web platform as whole. In some ways it raises more questions than answers.

How do you determine minimum viability?

How do you incentivize (beyond security & privacy) the simplification and minimizing of web platform features?

How do we confront the various counter-incentives?

Or rather:

How do we document and cope with the numerous incentives for complexity and obfuscation that come from so many sources (some mentioned in that Twitter thread) that seem in total insurmountable?

No easy answers here. Perhaps material for more posts on the subject.

Twitter post 575144446519480321