Technical Architecture Group Teleconference -- 02 Oct 2013

<trackbot> Date: 02 October 2013

<dka> UN Declaration on Human Rights, article 19: http://www.un.org/en/documents/udhr/index.shtml#a19

<wycats> https://gist.github.com/wycats/220039304b053b3eedd0

<annevk> http://tools.ietf.org/html/rfc5785#section-3 describes the /.well-known/ scheme

<wycats> my doubts are off the charts

<annevk> scribe: annevk

Publishing and Linking

SK: [missed] It is said in law that sites should provide a way to block a URL in a service.
... Most Russian service providers don't do deep packet inspection so they block the entire domain.

<wycats> He said that people can file copyright objections with a court, and the court can require that the copyright material be blocked on a URL level

<wycats> but most ISPs block on a domain-level because of technical limitations

SK: The law went into effect two months ago.
... Not much noticeable effect thus far.

DA: Is there a registry?

SK: There are registries. Each was created prior to this law. They consist mostly of extremist sites and [missed] sites.
... Every URL that is blocked by court decision is added and must be blocked by service providers.
... Providers are inconsistent with respect to which URLs they block.
... The procedure does not work well at the moment.
... There is no visible impact of the law. Some sites were blocked. Mostly torrent-related websites. One site which claims to do link tracking was blocked/unblocked/blocked.

DA: This is being used on websites providing links?

SK: Most sites claim they just provide links.

YK: Presumably they actually just provide links.
... They are not just magnet links?

SK: ...

DA: Piratebay is blocked in the UK
... Everything you said is true for the UK too, there's a list too

PL: The US government seizes domain names

YK: That's very different from a blocklist

DA: Are they doing anything at the domain level?

SK: They just block IP addresses

YK: It's distinctly different from using a registry vs changing things at the infrastructure level

Chinese firewall

SK: The Chinese firewall blocks IP addresses, URLs, search phrases, ... The main thought about this is that censorship in China is not technical.
... They block services outside of China and force them to relocate and have servers/services in China.
... Chinese government is not concerned with individuals publishing their opinion or using VPN.
... When there's a large public outcry, companies operating inside China (e.g. on social networks) will do the censorship.

DA: What are the rules around censorship?

YK: I think it's reasonable to assume it's similar to 1984

SK: The problem is the government having control over companies who will do the censorship.

DA: Thanks for the background. Not sure there's much we can do about this given that the W3C has indicated they're not doing legal activities around this.

WS: Yeah, I don't think there's anything right now we want to take action on.

DA: Two have come up: 1) Censorship due to commercial concerns and 2) censorship due to state concerns.
... We can close this topic, but it's useful to keep in mind

YK: We're losing the argument over how the internet resolves.

TBL: Sorry, UK?
... Which countries do DNS spoofing?

YK: Is only one vector. Telling ISPs to redirect URLs is another mechanism.

TBL: I know US messes with the DNS.

YK: That's different. They do it that the DNS level whereas UK for instance does man-in-the-middle.

TBL: I think the US does man-in-the-middle.

WS: No, US takes down US-registered domains and might cooperate with other countries for records outside their reach.

YK: The way the US does censorship is going to the authoritative source. What everyone else is doing is going to intermediaries and forcing them to violate the routing rules. I assert the latter is worse as it violates the architecture of the Internet.
... If man-in-the-middle becomes the normal state of affairs users will see more browser-UI-level warnings and become less receptive to them, as we were discussing yesterday.

SK: Some illegal activity in Russia has moved into the "shadow internet".

DA: darknet

AR: No surprise, with the distributed architecture control just moves elsewhere

YK: I would not be surprised if they found a way to shut down Tor

SK: A F2F darknet cannot be blocked

AR: It's possible to make things very difficult, even for that case.
... When outside the local subset.

DA: Is there anything the TAG wants to do here?
... People consider fragmentation of DNS to be an issue. DNS working the same everywhere has large benefits.
... If we get to a place where a group of people has a different DNS we start to balkanize the internet.

YK: Does DNSSEC help there?

PL: All it does is give verification.

YK: If it doesn't protect against malicious actors, I wonder what it helps against?

PL: It helps with ordinary man-in-the-middle attacks.
... The government can still mess things up.

AR: Protects against kids. Not against kids with guns.

<Zakim> wseltzer, you wanted to say "Internet governance"

WS: This intersects with Internet governance. Governments will try to control behavior they deem illegal. We can either work with them to do this in line with Internet architecture, or they will just do whatever...

YK: It seems hard to measure all the evils as it depends on what may happen in the future. My high-order bit is messing with the architecture, but maybe there are worse things.
... We might not have enough diversity of opinion here to tackle this.

AR: I doubt we'd even get consensus within this room.

YK: I think the decentralized position is that it's been a mistake to put centralized subsystems in. This would make the government fire, but the position is that one can outpace the government.

DA: A decentralized web has been discussed in the TAG before. E.g. URLs would still resolve if the internet is "turned off".
... I think we all agreed, "great idea", but the specifics were not entirely clear, nor what the TAG could do about it.

AR: What do you do about a local replacement for DNS? Do you do local resolving?
... That might not make the web less centralized. It allows for a new decentralized web, but the existing one would still be heavily centralized.

PL: We talked about sites being taken down with some kind of fallback. You'd ask the server where you got the link from if he knows any other location, etc.

YK: Someone could write something like this on top of WebRTC.
... With AppWorker (neeh ServiceWorker?) you could pull it from the caches...

<Yves> http://www.ccnx.org/

<wseltzer> https://en.wikipedia.org/wiki/Content-centric_networking

JSON

<noah> See http://www.parc.com/work/focus-area/content-centric-networking/

<slightlyoff_> wseltzer: thanks! The tech talk I as remember was: http://www.ccnx.org/395/1/van-jacobsen-at-google/

<wseltzer> [wseltzer leaves]

YK: Until recently two things were JSON specs: IETF RFC that includes MIME type registration and ECMAScript that defines parsing and serialization
... As a practical matter compatibility with the latter is important

<slightlyoff_> http://www.ecma-international.org/ecma-262/5.1/#sec-A.8

<slightlyoff> note that the Annexes are an intresting beast

YK: There was a desire to update the IETF RFC; initially the notion would be to correct some mistakes
... Now they want to outlaw duplicate keys; however that is used for comments today and it would break content if that were made a syntax error
... There were some loopholes that could be used, but TC39 was not okay with taking them

AVK: There is another difference, the RFC allows less top-level items than ECMAScript does

YK: After that Douglas Crockford went back and became our representative for the IETF. Multiple people from TC39 participated in this process.
... Some people from the IETF wanted to expand the set of technical changes, such as defining the semantics of numbers and strings.
... The IETF did not consider ECMAScript as the high-order bit, but simply one of multiple inputs.

<ht> Current application/json draft at IETF, Tim Bray editor, aka 4627bis, is at http://trac.tools.ietf.org/html/draft-ietf-json-rfc4627bis-04

YK: Even though semantics of JSON are not defined, the de facto semantics are those of ECMAScript.

<slightlyoff> March TC39 meeting notes on this topic: https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-03/mar-12.md#49-json-ietf-changes

YK: In response to demand for having a stable reference outside of ECMAScript, TC39 created a stable standalone draft.
... People on the IETF side felt blindsided by that...

<slightlyoff> July Day 1 JSON notes: https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-23.md#9-json

<slightlyoff> July Day 2 JSON notes: https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-24.md#9-json-continued

<slightlyoff> July Day 3 JSON notes: https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-25.md#json

HT: For the benefit of everyone, have someone from TC39 on the JSON WG.
... They're lightweight, just join the mailing list.

YK: I'm not excited about the language, feels like committee thing

AVK: yeah, it's a copout

YK: Using words like interoperable and MUST etc. is bad

DA: Is there anything the TAG should do?

AVK: I think web standards should reference ECMAScript
... XMLHttpRequest references ECMAScript

YK: Agreed

HT: TC39 could just include the MIME type registration in ECMAScript
... And then you own it

YK: That's good advice. We should go back to TC39 and own the MIME type.

<Yves> https://www.rfc-editor.org/rfc/rfc4329.txt

YK: There might be problems with the lax rules of JSON as drafted originally in the RFC vs how it's drafted in ECMAScript.

AR: In a closed JSON system there could be other types of JSON that are not compatible with ECMAScript

<dka> NM: If you have something that's purpoting to be a first class data publishing format on the web then it should be set down normatively [what to do with out of bounds nunbers]

<dka> YK: Concrete example -twitter was written in ruby - used an integer which was legal in ruby but when deserialized in ecmascript became NaN.

<dka> YK: It would be good if the spec said "numbers that lack ieee float precision should not be emitted from a json parser" must not would be a breaking change.

<dka> TBL: Wait a moment - you're defining two types of json...

AVK: If Ruby JSON cannot be parsed by ECMAScript, it's different and we should just have two standards

NM: JSON should continue to work with JavaScript, but it's also used independently

<wycats> I strongly object to this line of reasoning as being context-less

NM: Having a format, this represents any integer is a low bar, if it can also represent any floating point, fine
... From an interoperability point of view, it's only guaranteed for things in the following ranges...

<wycats> the historical details here are being ignored and we're waaaay down a rathole here

PL: CSS does not specify limits, but does specify minimum values and behavior when implementation limits are exceeded

YK: Quirks in JSON have survived. E.g. still does not have comments.

TBL: I heard you say the JSON specification ought to use SHOULD, I think it ought to use MUST

YK: It's "interoperable" now...

TBL: But SHOULD is no good

YK: I think TC39 does not accept MUST, as there are some exceptions
... around other languages

<noah> My proposal was NOT to introduce an integer type. There should be no change to having a single number type.

DA: What are the takeaways?

YK: TC39 should have a conversation on what numbers mean in JSON
... and whether the specification should have that as semantics

AVK: the other one is taking ownership of the MIME type

<noah> What I was proposing was that the mapping from >certain< serializations, such as the numbers that happen to be representations of integers (I.e. arbitrarily long sequence of integers with optional sign prefix) should be unambiguous, exactly as it is for XML schema datatypes and most bignums. There should rather be a statement that implementations are only required to handle such representations

<noah> as map to integers within certain bounds. I don't see this as an incompatibility or breaking change.

<dka> DA: …And is there anything we can do procedurally- e.g. inviting Tim Bray to join us as a guest for a future TAG call?

YK: Inviting Tim Bray seems fine

AR: I'd prefer Douglas Crockford to also be on the call

<scribe> ACTION: Dan to invite Tim and Doug to join a TAG call [recorded in http://www.w3.org/2013/10/02-tagmem-minutes.html#action01]

<trackbot> Created ACTION-836 - Invite tim and doug to join a tag call [on Daniel Appelquist - due 2013-10-09].

<BR\>

Web Audio

AR: The chairs of the group have not changed, but the editor has. Chris Rogers has left the group.
... Chris Wilson is the new editor, who will not be an author per se.
... They are working out of GitHub now.
... They are fixing the things we have raised. The most difficult one is addressing the issue around observable data races.

[crazy discussion]

[tl;dl: web is little endian]

AR: Audio executes primarily on a separate high-priority thread on which you cannot run script.
... However, this thread may mutate buffers you pass it, including those from JavaScript.
... This gives you data races.

[this was discussed to death on the list]

[tl;dl: data races are bad, the web doesn't have them at the moment]

AR: Our advice to Web Audio has been to fix this; they are fixing it

[no applause, but I think it's appreciated]

AR: Robert O'Collahan proposes to transfer the objects

AVK: currently you cannot transfer things back

AR: they are changing the API

AVK: [compat??? mind blown]

AR: Apple had performance concerns, but the group is going ahead with this approach
... The group has agreed, largely thanks to Jer Noble from Apple, to remove the duplication in the specification

AVK: Are implementations removing it?

AR: Maybe

YK: Doesn't matter

AVK: __proto__, String.prototype.blink(), does

[waaaa]

AR: We'll have to see with data

<wycats> I am going to go through MDN and start submitting spec bugs for every non-interoperable property that hasn't been removed

<wycats> will you back my effort?

wycats: you should file browser bugs first

<wycats> it's already in Mozilla

wycats: only if they are WONTFIX does it make sense to file spec bugs

<wycats> which is allegedly enough to standardize

<wycats> https://developer.mozilla.org/en-US/docs/Web/API/HTMLScriptElement

<wycats> script.event

<wycats> I will submit a spec bug to HTML5?

<wycats> you will back this effort with Hixie?

wycats: that's already in HTML

<wycats> let's make this an agenda item

wycats: http://www.whatwg.org/specs/web-apps/current-work/#dom-script-event

[scribe is missing a lot while arguing with wycats]

<wycats> let's put it on the stack

AVK: Is there anything we need to do?

AR: There's no scripting context on the audio thread yet

YK: It's not clear how to do concurrency yet
... The point is that if you want to do that, it should be done in TC39, not in a WG

AR: The tl;dl is that things are trending in the right direction

[too long, didn't listen]

<dka> ACTION on alex to write up something to send to Web Audio working group.

<scribe> ACTION: alex to write up something to send to Web Audio working group [recorded in http://www.w3.org/2013/10/02-tagmem-minutes.html#action02]

<trackbot> Created ACTION-837 - Write up something to send to web audio working group [on Alex Russell - due 2013-10-09].

Platform API constraints

YK: New platform APIs should be described in terms of ECMAScript semantics, preferable without the need of proxies

AVK: What about workers?

<wycats> Proposal: First try data properties, then try accessors, then try proxies

YK: They're fine, they don't change the invariants of the observable bits

<wycats> Use Object.observe on top of data properties if you can

AR: The audio thread could be described as an Audio worker
... If they started out with describing their world in JavaScript, they might have ended up with a different solution

AVK: currently we use accessors only

YK: I think that's a mistake
... One problem with accessors is that they're extremely observable, you can extract the function and do something with it

AVK: What are the cases where would we change the APIs?

YK: TC39 doesn't think you can change accessors to data properties or vice versa

AVK: I think proxies are bad is generally considered bad

AR: We could help out with constructors. Not generally accepted for platform APIs yet.

YK: We should tell people about @@create

AVK: It's not there yet

YK: The point is about having a pattern
... createElement() does things that include allocation; does things like @@create

[Summary: WebIDL needs updating to support ES6-style classes, as already requested in various bugs, then platform APIs need to be updated to be described in terms of that.]

AR: Another problem is that Web Audio and <audio> are not connected.

YK: I think it should be Web Audio's job to define <audio>.

AR: They consider networking and decoding out of scope.

YK: Sounds like it's the problem of the TAG then. We should make it not our problem.

AR: Need to do some matchmaking.

YK: Could try to start from a web components <fancy-audio> element and see what we need.

[YK and AR agree.]

<dka> People need to take a look at this: http://www.w3.org/2001/tag/group/track/actions/open which records open actions - and make it reflect reality.

DA: We are going to break for lunch.
... But first...

[tl;dl: clean up your open actions!]

@@break

<twirl> Scribe: twirl

<slightlyoff> speaking of the darknet...: http://www.theverge.com/2013/10/2/4794780/fbi-seizes-underground-drug-market-silk-road-owner-indicted-in-new

There are many "darknets" which are much darker than TOR networks

I2P for example

Perfect Dark

Upcoming meetings

Whiteboard image

DKA: We agreed on Jan 7-9 last time
... It should be in a Europe
... London?

[ discussion ]

TBL: We need Jeni

DKA: Let's say London Jan 7-9 for now
... We have an invitation for Yandex by September meeting

HT: It's time for me to move on

<timbl> ACTION noah to fix the tracker system so it can handle alumni names as well as current members

<trackbot> Created ACTION-838 - Fix the tracker system so it can handle alumni names as well as current members [on Noah Mendelsohn - due 2013-10-09].

<JeniT> Jan 7-9 fine for me. Do you want me to see if we can host at ODI?

DKA: How many meetings do we want to have in Feb-Sep?

<timbl> JeniT, if you promise not to be distracted ;-) yes please look

DKA: The first week of April for our next meeting?
... And early July for next one?

[ discussion on July meetings ]

DKA: We have no solution on where to host March-April meeting

[ discussion on San-Diego ]

DKA: San-Francisco?

<slightlyoff> thanks for minuting this, twirl

DKA: I think we should stick on London for January
... West Coast in Apr and Europe in Jul?

[ TPAC Nov 2014 discussion ]

Agreed: Jan 7-9 London, March 31 - Apr 2 West Coast, Jun 30 - Jul 2 Europe, Sep 29 - Oct 3 Moscow

TBL: I'm not sure about July

DKA: Let's mark Jul meeting "at risk"
... Mar-Apr in San-Francisco

TPAC 2013

DKA: We'll meet WebApps, sysApps (Dan), WebRTC (Anne)
... HTML (Anne?, Alex)
... WebCrypto (Alex)
... [something] (Dan)

Web Performance (Alex)

DKA: Should we (TAG) have a room?

[ agreed]

DKA: TAG sync up on Monday morning

<scribe> ACTION: Dan to talk to Wendy and Philippe about TPAC Meetings [recorded in http://www.w3.org/2013/10/02-tagmem-minutes.html#action03]

<trackbot> Created ACTION-839 - Talk to wendy and philippe about tpac meetings [on Daniel Appelquist - due 2013-10-09].

PL: Do we need to talk about spec reviews?

DKA: Yes

[ discussion on elections ]

Spec Reviews

Whiteboard image

DKA: We have WebRTC, WebAudio, Push, Web Animations, HTTP 2.0, Network Discovery, Compositing and Blending, WebCrypto
... WebAudio: \o/
... WebRTC: Need to write something

AR: Okay

DKA: WebCrypto

AR: Many issues with WebCrypto

[ discussion on WebCrypto problems ]

DKA: meet them at TPAC
... Push

SK: I wrote a review, waiting for TAG to give a feedback
... In general, too many unclear concepts

DKA: Web Animations

SK: I'm trying to finish WA review

DKA: Screen orientation
... HTTP2 is for Yves
... WebComponents

YK: I'll take it

DKA: Network Discovery

AVK: Not our highest priority

YL: Marcos has already reviewed Orientation

<Yves> https://github.com/w3ctag/spec-reviews/blob/master/2013/07/OrientationLock.md

DKA: We should review Orientation and Push drafts
... Compositing and Blending
... PL to review
... Should TAG write a review for HTTP2?
... I think YL should write a review and present it to TAG
... short break

<dka> [some on-break discussion on javascript performance on mobile devices relating to http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/]

DKA: Should TAG respond to this article?

<wycats> http://mbebenita.github.io/LLJS/

<wycats> http://asmjs.org/

<wycats> approaches to narrow the gap specifically around GC

<wycats> that run in today's browsers

<dka> [consensus is that the methodology employed by the author is flawed - in that the author compared c with javascript and ignored the fact that javascrpt apps leverage the underlying platform to do performance-demanding things]

Exotic Permissions

AR: There are permissions on using user data
... It's seams reasonable to ask user for permission on using data like e-mail or address
... For example, there is a dialog about geolocation permission
... But we can't just ask user "can I use filesystem", etc
... At present moment we just prohibit that
... We don't have a language for for that

DKA: Does sysapps work on it?

<dka> http://www.w3.org/TR/2013/WD-runtime-20130321/

<dka> http://www.w3.org/2012/sysapps/app-lifecycle/

YK: I think that's big architectural question

<slightlyoff> http://www.w3.org/2012/sysapps/runtime/

[ discussion on whether people care about permissions ]

YK: one real way to explain to people is to say what worst things could happen
... WebApps is not like regular apps
... By downloading and installing app you gave them some permissions
... That doesn't work with web apps

[ discussion on how could we trust websites ]

AR: We need just a manifest to describe permissions

DKA: So we need a security manager in OSes?

<dka> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html

[ discussion on APIs capable of working under different constraints ]

AR: You should be just sure that things won't do thing you don't want
... I like the idea that user may change his desicions at any time later

[ discussion whether we should trust apps displaying ads ]

YK: It's very easy to have, for example, your contact list leaked

<dka> tbl: [talks about the idea of "beneficent apps"]

<dka> dka: these would be vetted by a social system rather than a unitary authority?

<dka> tbl: yes -

<dka> tbl: putting nice apps and horrible apps into same box makes it too easy for the bad guys

<dka> YK: area of reasoning I favor: what distinguishes desktop apps from web apps - there is a conceptual step you're taking to "put it onto your desktop" - to keep it.

YK: difference between web apps and desktop apps is "installing" step

<dka> YK: we need users to go through a "solemn UI step"

YK: so user should make the same step with a "web app"

AR: One point: the list of permissions should be editable
... Maybe user disallowed some thing before but let app ask to ask again

<dka> HT: imagine the following world - in which the installation process and the launch process goes ahead without asking you permission for anything - and then the first time it needs a permission, it says "i need your permission x otherwise i cannot do y."

AR: we leave no ability to be wrong and that's bad

NM: asking 15 questions to accomplish just one task is bad too

DKA: what's the status of csp?

[ technical details on scripts ]

DKA: Should we put on the list of reviews?

YK: Alex and I reviewed this spec
... There are serious issues

DKA: does sysapps guys think on that?

AR: No

[ discussion on sysapps ]

[ agreed on sending feedback to sysapps ]

<slightlyoff> interesting :https://sslcheck.globalsign.com/en_US

<dka> ACTION: yehuda to document his recommendations to the sysapps wg regarding de-packagizng the specs [recorded in http://www.w3.org/2013/10/02-tagmem-minutes.html#action04]

<trackbot> Created ACTION-840 - Document his recommendations to the sysapps wg regarding de-packagizng the specs [on Yehuda Katz - due 2013-10-09].

[ break ]

<Yves> https://www.ssllabs.com/downloads/SSL_Threat_Model.png

HTML5 Authoring Spec

YK: I'm not happy with the results of using authoring mode

[ Noah tells the history of question ]

[ discussion on whether its normative or not ]

YK: Is a subset of a normative document normative too?

DKA: What should TAG do?

[ discussion on are we cdo about that ]

DKA: That's not an architectural thing but we are the voice of developers

NM: Originally it was

<dka> [disagreement on the need for an author-version of html and whether or not such a version should be normative]

HT: ECMAScript defines the language but doesn't define parser

[ more disagreement ]

<annevk> http://developers.whatwg.org/

<scribe> ACTION: dka to Ask Robin what's going on [recorded in http://www.w3.org/2013/10/02-tagmem-minutes.html#action05]

<trackbot> Created ACTION-841 - Ask robin what's going on [on Daniel Appelquist - due 2013-10-09].

TAG webpage redesign

PL: no progress at this moment
... should we make a brainstorm?

DKA: What do we need?

AR: Who are we, what are we doing, etc...

<annevk> TAG[@@create]

DKA: We need branding

<annevk> TAG[@@create] will take care of branding

DKA: I think we should combine our webpage content with blog content
... probably we should get some content away from main page, our minutes for example

<annevk> We're on the interwebs: https://www.youtube.com/watch?v=HueLJQTRiI4

<dka> http://www.w3.org/TR/fragid-best-practices/

<Yves> http://www.w3.org/TR/urls-in-data/

<ht> The core standards use URI, e.g. 3986 Uniform Resource Identifier (URI): Generic Syntax

<dka> ACTION Yves to check on status of Jeni's documents.

<trackbot> Created ACTION-842 - Check on status of jeni's documents. [on Yves Lafon - due 2013-10-09].

<annevk> The core standards use URL, e.g. HTML, CSS, URL (hah)

<dka> adjourned