“As writers, we don’t need companies like Medium to tell us how to use the web. Or define openness and democracy. Or tell us what’s a ‘waste of [our] time’ and what’s not. Or determine how and where readers experience our work. We need to decide those things for ourselves.”
#trackattack is back!
did a 400 warmup 800 800 800 800 4x200, abs
workout: warmup 800 1600 800 1600 4x200, abs
Reopening of Kezar Stadium has definitely brought a bigger crowd. We had 29 people today.
Though I need to build back up to doing the full track workout, I did have a couple of minor personal achievements this morning.
During part of the second 1600, when I was starting my 800, I managed to draft Jeff drafting Andy Cochrane for 200m (half a lap). Though Andy is still in recovery mode he's still ridiculously fast from my perspective. Being able to "keep up" with Andy, even for just a half a lap, even when he was "taking it easy", and in the middle of a 1600, felt like doing the impossible, and emboldened me to push harder on average in my other runs, including...
On the second 200 I made sure to take-off exactly when Kate said go. As I exited the turn onto the back straight, I started kicking farther back & up, and managed to pass & finish that 200 ahead of a couple of people who are usually much faster than me. I could barely breathe afterwards.
Also my 1 year trackiversary was 2015-063 (20 days ago) tantek.com/2014/064/t2/yesterday-npsf-track-kezar-trackattack
Hard to believe I've been running track workouts (on & off, mostly on) for over a year.
* 2015-069 did Trackish Tuesday 2x600 4x400 2x300 4x200
* 2015-034 did Trackish Tuesday warmup of 2x600, 600, 2x200
* 2015-027 did Trackish Tuesday 5x600 3x300
* 2014-350 did Trackish Tuesday 6x600
* 2014-315 post-Berkeley Half recovery fast walk/jog at Tempo Tuesday
* 2014-294 did Tempo Tuesday ~16km 94:30 (10 mi at < 9:30min/mile)
* 2014-287 did Tempo Tuesday ~7km
* 2014-273 did Tempo Tuesday ~15.2km
* 2014-266 did Track Tuesday workout all but one 1600
IndieWebCamp Cambridge 2015 is over. Having finished their ice cream and sorbet while sitting on a couch at Toscanini’s watching it snow, the topics of sameAs, reuse, and general semantics leads to a mention of Dublin Core Application Profiles.
Is Replaced By: Not applicable, wait, isn’t that supposed to be an inverse relationship?
I’m used to this shit.
(nods, clicks forward, starts scrolling, reading)
We decide that the Library of Congress Subject Headings (LCSH) meet our needs. - I’m not sure the rest of the world would agree.
No surprises there.
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
Wait what? Not "given-name" and "family-name"? Nor "first-name" and "last-name" but "firstName" and "family_name"?!?
Clearly it wasn’t proofread.
But it’s in the following table too. foaf:firstName / foaf:family_name
At least it’s internally consistent.
Oh, this is really depressing.
Did they even read the FOAF spec or did they just hear a rumour?
A week ago I woke up at ~6:15 in Big Basin to @LaurBreu shouting “Time to get up for morning run!”. It was significantly colder than any recent morning in San Francisco. I put on three layers and joined about a half dozen other fellow #NPSF campers; I think we finally got going about 6:45. When I returned to camp I had completed my longest trail run to date, most of it solo.
We ran down to the park headquarters, checked out the trail options, and quickly decided on Berry Creek Falls, whick seemed about another 4.5 miles away. There was a brief debate about whether to do a full 9 mile loop or run back after a halfway point.
Everyone started down the trail at a fast clip. In less than half a mile I had lost sight of them. After about a mile, I saw one friend come back, she'd noted beforehand that she had to cut short for another engagement. Not long after I saw another friend walking back, apparently having twisted her ankle running. After that I didn’t see anyone else on the trail.
I kept running, stopping a few times to take photos. After making it about 3/4 of the way to Berry Creek Falls, I kept expecting to see the rest of the group running back. With just 1 mile to go I decided to keep going all the way to the falls. Made it to a bench with a beautiful view of the falls, yet it looked like I could get closer.
The trail meandered downhill closer to the creek eventually to a large fallen tree. To my right was a large boulder embedded in the ground that looked too slippery to descend down to the flowing water.
I crossed the creek with the fallen tree as bridge. On the other side I had to jump down to another fallen tree, then down to the creekbank where the path continued back towards the falls. Hiking up I finally got close enough for a better view.
At this point I had no idea where everyone else had gone. Last I had heard the plan was to run to the falls and run back. Since I was on my own, and after all the wandering about 5 miles away from the park headquarters, I decided the best option was to run back the way I came.
I ran back to the fallen tree. But this time I crossed the rocks in the stream to the large boulder on the other side. At about a 60 degree incline, with plenty of ridges to grab, and chips to dig my feet into, I climbed up the boulder without difficulty.
On the run back the layers came off until I was running in a tshirt and sweatpants, the rest tied around my waist.
I’d never run this far by myself, in a new place, miles away from help or other resources. No headphones, no network contact. A lot of time to just think, run, and focus. Focus on running, on keeping a good pace, and regular breathing.
It was good to see landmarks that I had passed on the way in. I’d counted three trail markers, and as I passed each one on the way back I sipped just that much from the remaining water bottle strapped to my waist.
About halfway back I finally started to see people coming the other way. Hikers. With jackets, backpacks, and hats.
As we exchanged good mornings and they stopped to stand back as I ran by, I couldn't help but think, I used to be you, now I'm this.
I reached the trail head at park headquarters, checked a map for the road back to the camp, and ran uphill the rest of the way.
The trail was estimated to take ~6 hours. I ran ~11 miles from camp to the waterfall and back in under 2.5 hours.
At some point in the last few months apparently I changed from a hiker to a trail runner. It felt more comfortable, and was more fun, to run the trail than walk it.
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.
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) as a pull request.
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?
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.
Ghosts in the machine: open tabs and auto-completed-from-history posts from deceased friends. Considering creating or adding to memorial pages for them in the communities we knew each other in, beyond just citing their work. Seems about all we can do sometimes, remember them for their good work, and their positive contributions.
@kylewm2 hence I replied to the source for context.
The brackets […] indicate removal from a quote.
“If an ellipsis is meant to represent an omission, square brackets must surround the ellipsis to make it clear that there was no pause in the original quote: [ . . . ]. Currently, the MLA has removed the requirement of brackets in its style handbooks. However, some maintain that the use of brackets is still correct because it clears confusion.”
Since we often use ellipses to truncate POSSE tweets, it’s better to always use […] when elliding inside a quote, to disambiguate that the ellipsis was not in the original. And square brackets are also the convention for indicating quoter edits to the content of a quotation, such as insertion of implied words, substitutions for pronouns etc.
W3C has advanced the longdesc attribute to a Recommendation, overruling objections from browser makers.
Not a single browser vendor supported advancing this specification to recommendation.
Apple formally objected when it was a Candidate Recommendation and provided lengthy research and documentation (better than anyone has before or since) on why longdesc is bad technology (in practice has not and does not solve the problems it claims to).
For all the detailed reasons noted in Apple’s formal objection, I also recommend avoid using longdesc, and instead:
Always provide good alt (text alternative) attributes for images, that read well inline if and when the image does not load. Or if there’s no semantic loss without the image, use an empty alt="".
For particularly rich or complex images, either provide longer descriptions of images in normal visible markup, or linked from a image caption or other visible affordance. See accessibility expert James Craig’s excellent Longdesc alternatives in HTML5 resource for even more and better techniques.
Perhaps the real tragedy is that many years have been wasted on a broken technology that could have been spent on actually improving accessibility of open web technologies. Not to mention the harrassment that’s occurred in the name of longdesc.
Sometimes web standards go wrong. This is one of those times.