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?
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?
First day of Spring 2015
#IndieWebCamp @MIT wrapped. Snow in Cambridge.
Free wifi & power @Tosci. And ice cream.
But that’s not free. Except for the samples.
to MIT for @W3C Social Web WG, @IndieWebCamp!
Let’s focus on live user-centric demos only, no architecture astronomy plumbing demos, no video playback. Live demos with real websites with real content (no Lorem Ipsum) and real URLs / permalinks that anyone can load, browse, verify for themselves.
See Also: http://tantek.com/2015/069/t1/js-dr-javascript-required-dead
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.
https://instagram.com/p/0Nm00jA9XW/
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.
“amplifications of lesser heard voices are vital to a free society.”
— @acegiak #indiewebcamp.
Continued:
“Solidarity with minorities you're not a part of prevents authorities from dividing people and conquering”
http://indiewebcamp.com/irc/2015-03-11/line/1426064607414
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:
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?
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.
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.
More: https://en.wikipedia.org/wiki/Ellipsis
Specifically:
“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).
Mozilla formally objected when it was a Proposed Recommendation, agreeing with Apple’s research and reasoning.
Both formal objections were overruled.
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.
This morning: legs too tired to sprint, did a deck instead.
33 cards of
♣ leglift
♦ sideplank
♥ pushup
♠ sergeant lunge
2-10 J=11 Q=12 K=13 A=14
For the sideplank and lunges, I did the count from the card on both sides/legs. Took a photo with the rest of the Trackish Tuesday crew and then watched the sunrise in Golden Gate Park afterwards on my way home.
https://instagram.com/p/zfSACaA9b7
