See also: IRC log
<DanC> trackbot, start meeting
<trackbot> Date: 04 March 2010
<ht> As signalled in email, I will be joining after I get off a transition call
<noah> Right, Henry, I got that in the agenda
<noah> I'm having some Zakim problems at the moment...trying again
Scribe me up.
<scribe> Scribe: DKA
<scribe> ScribeNick: DKA
<scribe> Chair: noah
<DanC> +1 approve http://www.w3.org/2001/tag/2010/02/25-minutes.html
+1
RESOLUTION: Minutes of the 25th are approved.
Noah: TAG status report. HTML working group has made a few small comments. I have made small updates to reflect their contributions.
... I will publish this tomorrow or monday.
http://www.w3.org/2001/tag/2010/sum03.html
Noah: It's member-only currently.
Larry: I wondered - I scanned for a reference to the versioning work.
Noah: Can you draft a few sentences and send them to me? I'll put them in.
Larry: Ok.
Noah: Just email me "change request for the status report." I want to have it out so people can review it before the AC meeting.
... Two teleconferences between now and the f2f. One on the 11th and one on the 18th. Neither I nor Tim will be available on the 18th. Can we cancel?
+1 to cancel the 18th.
RESOLUTION: Cancel the telecon on the 18th.
Noah: On the 11th, Tim will be unavailable.
I will also be unavailable next week BTW as I will be on a plane.
Noah: We may cancel it but let's leave it for now.
Noah: Quick update. We did a good job asking each of you what you're doing. Anything related to the f2f agenda to discuss?
<DanC> re http://www.w3.org/2001/tag/2010/03/actionsbyshepherd.html
DanC: You sent out a list - I looked at Mine and Tim's and a bunch of stuff got assigned to him. I tweaked some of those.
Noah: Fine.
... I ran a little script to list all the issues open/pending by shepherd. By Monday please alert me to any of your issues that need attention in the f2f that do not have actions.
<DanC> (I think I'll be sending something about ISSUE-56: (abbreviatedURIs-56), where I sent a proposal ages ago...)
Noah: Part of the role of the shepherd is to keep thinking about things we don't have actions associated with.
... Questions?
<timbl> Wonders if what is a WebID
ACTION-396?
<trackbot> ACTION-396 -- Henry S. Thompson to henry to draft emails for NM to send to HTML WG chairs and to Liam+MS authors encouraging a change proposal wrt distr. extensibility by 23 March -- due 2010-03-04 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/396
Noah: We want to send emails on behalf of the TAG...
<masinter> we were saying two things: (a) we'd reviewed the documents and think they're interesting, and (b) we're encouarging certain people to engage in the HTML WG process and offering our help in doing that.
Noah: two notes Henry was asked to send. One to HTML chairs and one to Liam Q. and MS authors and one to Henry himself...
<masinter> just though the message should make the two things clear
<noah> Did Larry's mail ever show up in the archive?
Noah: Let's look specifically at the notes that Henry has drafted ...
... Let's bless Henry's notes or fix them.
Larry: I think the fixing is just minor.
<masinter> use your discression, that's fine with me
Noah: We need text I can mail.
DanC: What should we do?
Noah: Henry and Larry should go off-line and do this or we should do this now [in the call].
... I'm happy with Henry's text but if Larry is concerned then we have to work through that.
Larry: That's OK.
Noah: We can go with Henry's text?
Larry: Yes.
:)
<masinter> just consider in future, i think, is fine with me
RESOLUTION: Noah to send both of henry's ACTION-396 emails.
<DanC> action-396?
<trackbot> ACTION-396 -- Noah Mendelsohn to henry to draft emails for NM to send to HTML WG chairs and to Liam+MS authors encouraging a change proposal wrt distr. extensibility by 23 March -- due 2010-03-05 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/396
<noah> Noah assigns himself as owner of ACTION-396
<DanC> action-395?
<trackbot> ACTION-395 -- Noah Mendelsohn to guide TAG to a response on HTML decentralized extensibility (self-assigned) -- due 2010-03-23 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/395
<noah> ACTION-395?
<trackbot> ACTION-395 -- Noah Mendelsohn to guide TAG to a response on HTML decentralized extensibility (self-assigned) -- due 2010-03-23 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/395
Noah: I would like to have permission to close ACTION-395 when I send that note.
... Anyone have a problem with that?
... OK I am going to do that.
<DanC> close action-395
<noah> close ACTION-395
<trackbot> ACTION-395 Guide TAG to a response on HTML decentralized extensibility (self-assigned) closed
<trackbot> ACTION-395 Guide TAG to a response on HTML decentralized extensibility (self-assigned) closed
<DanC> action-395: see action-396 for follow-up
<trackbot> ACTION-395 Guide TAG to a response on HTML decentralized extensibility (self-assigned) notes added
jar: Before I joined the TAG there was an open issue-57. I got assigned an action to close up one of these sub-issues.
<noah> FWIW, there's still an open ISSUE-57
jar: question is: why is it that even though direction of HTTP spec says address should be retained on a temp redirect that none of the browsers do this?
... couldn't find much material. A mozilla bug report and a wikipedia article.
... I drafted a memo of what I know about this issue. http://www.w3.org/2001/tag/2010/02/redirects-and-address-bar.txt
Noah: Any thoughts?
<noah> Noah: What, if anything, should TAG do next on this?
jar: I looked at Mozilla [bug database] but didn't look at other bug database. Should I look at others?
DanC: you found the relevant bug...
Larry: Obscure wrinkle with IRIs in the address bar...
<DanC> "I would *not* like to see this wontfixed." -- David Wood 2010-02-10 10:15:02 PST https://bugzilla.mozilla.org/show_bug.cgi?id=68423
<DanC> (I think "broadcast more widely" is consistent with posting a blog item)
Tim: This is interesting - next step I suggest is to mail the browser vendors. We've got them in the HTML working group. We need to broadcast more widely with what we've got. And if they still don't know why - it may well be that nobody's ever coded it because nobody's ever got round to it.
<Zakim> timbl, you wanted to suggest that that the next step is to email the browser vendoers engineers
<Zakim> masinter, you wanted to note that location & content-location are difficult for IRIs, since the HTTP headers are URIs but what is presented should probably be translated back, but
<Zakim> noah, you wanted to say that this seems broken, but I have a sinking feeling that this train has long since left, that there might be compatibility issues, etc.
Tim: Could we make a patch in the Mozilla codebase? Or a firefox plug-in that fixes it?
Larry: IRI document - this has more serious security problems when you allow unicode than ascii-only to the point that we [re]moving the requirement in the IRI document that human-...
<DanC> (yeah... I was thinking it's orthogonal, but maybe not...)
Noah: I'm less convinced that spoofing is relevant - copy-paste - copy-paste is usually not vunerable to spoofing.
<Zakim> jar, you wanted to say they probably will consider it a security bug
Noah: this seems like an obvious thing that browser vendors would have fixed it. Are there other barriers than getting the code written?
jar: It's worth while to try to contact the browser people. My bet is that every one of them would say that this is a spoofing or phishing risk.
... the compromise option would be to have some alternative UI control that could give you access to the original URI.
<DanC> ("david wood and I were suggesting" refers to what, I wonder?)
<noah> I don't think we can do UI design at the level of particular new dialogs, we can just encourage exploration of ways of making two URIs available....I'm suspicous that users will just be confused.
jar: the thing about the address bar - users are going to look at the address bar - even if it's not meant to provide a particular info or endorsement, users will use it in this way.
... claim is that users are looking at the address bar to assess the trustworthiness of the content they see on the page. Things can go wrong if the redirect happened in error.
<masinter> <t>There seems to be little hope of relying on either administrative or technical means to reduce the availability of spoofing exploits. For this reason, user agents SHOULD NOT relying on humans doing visual or perceptual comparison or verification of IRIs as any means of validating or assuring safety, correctness or appropriateness of an IRI. Other means of presenting users with the validity, safety, or appropriateness of visited sites
<masinter> are being developed in the browser community as an alternative means of avoiding these difficulties.</t>
Tim: you've got to convince me. A trustworthy site won't redirect you to an untrustworthy site.
jar: I think the claim is it will.
<noah> Is the concern that the "trustworthy" site might have been compromised?
<masinter> above is proposed wording for IRIBIS
Tim: The definition of the a trustworthy site is that it won't.
... You could provide the effect of hiding the URI of something using frames - to retain the right to be linked to.
... I want to see an attack scenario.
<masinter> wonder if conneg should refer to more specific URI
<Zakim> DanC, you wanted to swap in a comment that boris endorses: "if I could get bigCorp.com to redirect me to mysite.com, then I could make it look as if the data was from their site"
Noah: DanC can you explain what the threat is?
<DanC> https://bugzilla.mozilla.org/show_bug.cgi?id=68423
DanC: Got to the bottom of this page with the more modern comments. Comment from Boris Zbarsky.
... In comment 20 - he says comment 12 seems right on the the prospect of money. https://bugzilla.mozilla.org/show_bug.cgi?id=68423#c12
... I don't find this persuasive.
... [but others do]
<masinter> convention is that temporary redirection doesn't imply delegation of speaks for
<masinter> and that the address bar should match what you got and not what you asked for
<jar> "if I could get bigCorp.com to redirect me to
<jar> mysite.com, then I could make it look as if the data was from their site."
Tim: If I can get bigcorp.com to redirect to mysite.com, I own bigcorp.com.
<DanC> ("the transitive property of insecurity" was a paper by tchrist@convex, but it seems to have disappeared from the net)
Noah: You can make the case that you could own a bit of bigcorp.com but you don't own the whole site.
Tim: If I can get bank of america to redirect to my site...
Noah: ...these guys are saying that the protection is that the address bar will then say "Tim's bank". [The IRI issue is not addressed.]
DanC: if you can keep the BofA logo up there [in the address bar] then that's quite a bit less secure.
<timbl> Line 1 Bank of America .. as served by akamai.com
<timbl> in line 2.
Noah: UI design and security are in tension.
<timbl> The "Permalink:"
<DanC> "I'm fine with having a way to retrieve the original URL the user tried to resolve... I just don't think it should be in the url bar." -- Boris https://bugzilla.mozilla.org/show_bug.cgi?id=68423#c22
<timbl> word
Noah: two addresses and a complex relationship between them as to what's trusted. What's the chances that this will actually help my mother notice that she's been phished.
DanC: The point of moving forward is not to stop phishing...
Noah: I'm afraid that a collareral damage from this effort is to make it less obvious when they've been phished.
<Zakim> masinter, you wanted to note that
I wonder if secure browsing and site certificates and UI around these play into this?
Larry: [reading requirements around human verification of IRIs]
<Zakim> DanC, you wanted to say this flies in the face of trademark use
Larry: Additional annotation of the IRI int he address bar as to how safe it is - like is it likely to be a spoof.
<noah> That's next up on our agenda, FWIW
DanC: So people should not rely on looking at names?
Larry: Right.
[some discussion on this point]
Noah: This is Agenda Item 7 - shall we leave the floor open for discussion on both?
... Can you introduce your proposal on spoofing?
<noah> Larry's proposal on spoofing: http://lists.w3.org/Archives/Public/www-tag/2010Feb/0175.html
<noah> =============draft============
<noah> There are serious difficulties with relying on a human to verify that
<noah> a presentation of an IRI to them (whether visually or read out loud)
<noah> is the same as another identifier or is the one intended. These
<noah> problems exist with ASCII-only URIs (bl00mberg.com vs. bloomberg.com)
<noah> but are enormously exacerbated when using the larger character
<noah> repertoire of Unicode; these problems are elaborated in [UTR#36].
<DanC> (that was bcc'd... I wonder if the thread is only in public-iri)
<noah> There seems to be little hope of relying on either administrative or
<noah> technical means to reduce the availability of such exploits, to the
<noah> extent that user agents SHOULD NOT relying on visual or perceptual
<noah> comparison or verification of IRIs as any means of validating or
<noah> assuring safety, correctness or appropriateness of an IRI.
<noah> [UTR#36] also identifies additional security considerations that are
<noah> applicable to IRIs.
<noah> ======draft============
Larry: copy-paste is still an interesting use case. .. I can see the advantage of both - having the actual URI you got to and the one you started with. That the thing you see in the address bar corresponds to what you're looking at is compelling.
DanC: But people want to bookmark the right URI.
Larry: So maybe the operation of bookmarking should be where we push.
jar: That's my suggestion.
<DanC> (bookmarking and in general making links)
<masinter> there are several URIs IRIs available, and which you want depends
<masinter> there's also the URI vs. the IRI
<timbl> 12 https://bugzilla.mozilla.org/token.cgi?t=ZXbZHfzCvo&a=cfmpw
<DanC> (the http spec is pretty clear on which you want in the case in question, larry; don't muddy the waters)
<masinter> since "location:" and "content-location:" are URI only, and yet your bookmark and copy/paste should be IRI
Tim: People bookmark things in lots of ways. I drag the icon to the left of the URI onto the desktop. You can drag that into different places [email messages, IRC channels, etc..] to do different things. My assumption is that it matches the URI I see next to it when I do that.
<noah> I agree with what Tim's saying. I very often copy/paste from URI bar into email
<masinter> HTTP spec doesn't account for IRIs
<noah> Bookmarking is just one UI gesture. There are many others.
Tim: I think it's a serious bug if when I bookmark it's not what's in the URI bar.
... I'm happy to be a "perm bar" with its own icon...
<noah> I think this happens
Tim: How often would the permalink button come up?
Many: a lot
<Zakim> noah, you wanted to wonder about hooking copy/paste?
Larry: What you want to present to the user is a IRI but what [they often get] is a URI...
<DanC> (when there's an HTTP redirect, do the browsers map back from uri to iri before displaying in the address bar?)
<masinter> the HTTP headers here are URIs, not IRIs. But the address bar, the user visual display, as well as the bookmark, should be unicode, not ASCII hex or punicoded hostnames
Noah: What if the guideline is - whenever the UA performs an operation that copies or processes a URI, at that point the user should be given a choice and make informed consent as to which one would be copied.
... Could agents buy into that?
<masinter> so if you redirect, you redirect to a URI, but the view should be IRI
<jar> (TimBL above was saying he likes to drag from the favicon in the location bar onto desktop or into email etc)
<Zakim> DanC, you wanted to agree that designing the UI here isn't useful, but...
DanC: Jar - Please do post a blog item - that is a way to encourage UI design in this space.
Larry: I think it's worth going down the URI / IRI transition route as well.
<DanC> "Dear Lazyweb, can I have a browser that knows how to bookmark the right address?" <- suggested blog title
Larry: I actually don't think that if you redirect to something that was an IRI, the address bar doesn't seem to show a URI it shows a presentation of the IRI that undoes the unicoding of the hostname for example.
jar: I'm happy to do this as a blog post.
<timbl> s/https://bugzilla.mozilla.org/token.cgi?t=ZXbZHfzCvo&a=cfmpw//
<timbl> s?https://bugzilla.mozilla.org/token.cgi?t=ZXbZHfzCvo&a=cfmpw??
Noah: Either let's close action-348 or put it in another state and let's go on to the spoofing stuff.
<masinter> blog posting and then other TAG members commenting on it sounds like a good way of TAG action
jar: I'm happy to close it. I will make a couple of changes based on what Dan and Tim have said.
<noah> close ACTION-348
<trackbot> ACTION-348 Research reasons why browser providers (e.g. Mozilla) aren't willing to meet requests (e.g. from purl) to retain address bar URL following successful redirect closed
<masinter> +1 to doing that more often... use the web rather than email to post results
Noah: So we will have no option actions on the address bar thread.
Noah: We've had some discussion already... Anything else?
<noah> FWIW, email I see because of the push model. Web I tend to miss.
<noah> Email linking the Web is fine.
Larry: There is active discussion on the IRI mailing list. There's a unicode technical report that [explores] a number of the issues which I think is good.
Noah: Close the action?
<DanC> fwiw, the thread: http://lists.w3.org/Archives/Public/public-iri/2010Mar/thread.html#msg0
Larry: Yes I think it's under control and the relevant parties are engaged.
<noah> close ACTION-343
<trackbot> ACTION-343 Discuss petname application to IRI spoofing in public-iri and www-tag closed
Noah: any objections to close action-343?
[none heard]
DanC: How does public-IRI relate to the new working group?
Larry: it's now the official mailing list.
<DanC> (http://lists.w3.org/Archives/Public/public-iri/ should be updated )
DanC: Can we move to item 10?
<DanC> ACTION-354: defer to ftf
<trackbot> ACTION-354 Review client side storage apis (web simple storage etc.), looking for architectural issues or other critical problems... or interesting design features the TAG should know about notes added
Noah: Defer ACTION-354 o the face-2-face.
<DanC> ACTION-354 due 8 March
<trackbot> ACTION-354 Review client side storage apis (web simple storage etc.), looking for architectural issues or other critical problems... or interesting design features the TAG should know about due date now 8 March
jar: gave a summary of what's going on with link header and "well known".
... semantic web coordination group meeting a week or two ago...
<DanC> (email to where?)
Jar: I was thinking of composing a short email - writing to them - copying www-tag - with recommendations.
... no actions were assigned at sw-cg.
Noah: What do you propose for state of ACTION-363?
DanC: Leave it open...
<noah> DC: ACTION-363 should stay open as umbrella for JAR to send email to www-tag and Ivan(?)
<DanC> ACTION-363: looks like next step is for jar to mail Ivan H. with copy to www-tag
<trackbot> ACTION-363 Inform SemWeb CG about market developments around webfinger and metadata access, and investigate relationship to RDFa and linked data notes added
Ashok: It would work better if you guys proposed what you would like standardized.
Noah: What's WebFinger?
<DanC> (have we all completely forgotten what we discussed at at our last f2f? ;-)
<noah> JAR: uses .wellknown at the host
Jar: WebFinger is a way to get a little bit of XML associated with an email address. It uses a well known URI at the host that gives a rule that tells you how to turn the username into another URI that you fetch to get [e.g.] public key or whatever you want.
<DanC> "Personal Web Discovery, making email addresses readable again" -- http://code.google.com/p/webfinger/
Tim: smtp protocol originally had this but it was designed out due to security issues...
DanC: The TAG has said "identify things with URIs" and the experience in this community of people managing accounts is that URIs are unusable but name@domainame is usable. So this is a way to use email addresses as URIs.
<masinter> mailto: is a URI scheme, being updated to deal with I18N issues
<Zakim> DKA, you wanted to note similarities to XMPP <-> HTTP community issues.
DanC: what I meant was that the change from the email address the URI is a local function.
<masinter> prepend "mailto:" turns email address into URI
<timbl> Global convention for a local function
Tim: It's a globally agreed locally executed function.
<noah> DKA: XMPP community also found URI's to be inconvenient for users
<jar> I think there's a level of indirection... http://x/.well-known/host-meta contains a rewrite rule that will transform user@x into an arbitrary URI (presumably containing the user name)
<DanC> action-363?
<trackbot> ACTION-363 -- Jonathan Rees to inform SemWeb CG about market developments around webfinger and metadata access, and investigate relationship to RDFa and linked data -- due 2010-02-24 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/363
<DanC> action-363 due +2 weeks
<trackbot> ACTION-363 Inform SemWeb CG about market developments around webfinger and metadata access, and investigate relationship to RDFa and linked data due date now +2 weeks
<DanC> (feel free to make a better guess at due date, jar)
ACTION-380?
<trackbot> ACTION-380 -- Daniel Appelquist to draft response to Fredrick, short and to the point. Larry to review. -- due 2010-03-04 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/380
Noah: Along the way I had a to-do to respond to Frederick. Why is 380 there and why is it different to what I already did?
<noah> DKA: So, I'm a new guy...
<noah> DKA: This was to be a response from the TAG.
<masinter> http://lists.w3.org/Archives/Public/public-ietf-w3c/2010Mar/0002.html
<masinter> yesterday
<noah> http://www.w3.org/2001/tag/group/track/actions/318
<noah> Send note to Device APIs and Policy (DAP) Working Group on behalf of the TAG
<noah> The note I sent ends with:
<noah> Thank you very much.
<noah> Noah Mendelsohn
<noah> For the W3C Technical Architecture Group
<masinter> Thomas R. reported there Thomas: TAG feedback was that this wasn't necessarily a good approach
<noah> This action got opened at: http://www.w3.org/2001/tag/2010/01/28-minutes
<Zakim> masinter, you wanted to note DAP issue on W3C/IETF coordination call
<Zakim> DanC, you wanted to borrow some TAG time to do team business about geolocation news... and to note http://lists.w3.org/Archives/Public/public-geolocation/2010Mar/0007.html
Larry: The topic of this was the subject of the W3C-IETF coordination call. Thomas R. reported that the TAG was concerned. The message has been received [by the IETF].
... Topic 5 on security.
<masinter> if there were assurances, they weren't in the minutes
DanC: There is a 3-march message from John Morris of CDT. Long message giving all the ingredients of a formal objection but not objecting [to Geo going to CR] and in particular to the API should include privacy.
<DanC> (he's not affiliated with the IETF, but he holds a similar position)
Ashok: this is part of the action I took on last week.
<noah> From John Morris' note:
<noah> Thus, to be clear, we think that the W3C should proceed to finalize
<noah> the 1.0 version of the specification. But – and here is where we hope
<noah> the W3C Team will accommodate a variation on the normal process – we
<noah> believe that the W3C Director should ALSO carefully review and
<noah> evaluate the objections we have raised.
<noah> Our goal is not to delay the
<noah> specification, but instead is to seek guidance from the W3C as to
<noah> whether both the process and substantive output of this WG meet the
<noah> current standards of the W3C. If they do – and they may well – then
<noah> that guidance would factor into my organization’s evaluation of its
<noah> continued involvement in the W3C.
DanC: John Morris is representing CDT in this case.
<noah> Minutes of 1-28 TAG meeting are: Our goal is not to delay the
<noah> specification, but instead is to seek guidance from the W3C as to
<noah> whether both the process and substantive output of this WG meet the
<noah> current standards of the W3C. If they do – and they may well – then
<noah> that guidance would factor into my organization’s evaluation of its
<noah> continued involvement in the W3C.
<noah> argh!!!
<noah> http://www.w3.org/2001/tag/2010/01/28-minutes#item04
Tim: We [the TAG] looked at whether there was a serious technical problem. After our involvement, the working group did make a more thorough job of going over the input even though they didn't change their course.
<noah> http://www.w3.org/2001/tag/2010/01/28-minutes#item04 is the telcon where ACTION-380 got assigned to DKA
<noah> F2F session with TLR: http://www.w3.org/2001/tag/2009/12/08-tagmem-minutes.html#item03
<DanC> tx
Tim: The architectural issue here - the architecture of including privacy information with other information. Should we encourage the consortium to have a consistent architecture across different APIs [for privacy]. Should this be designed independent of Geo and other things? There are lots of APIs for different sorts of things many of which are sensitive.
... geo has some specific issues [but] should we be looking for a consistent way of packaging information with the privacy information around it?
<noah> I still like my idea of mandating the right extensibility hooks; have heard of objections from implementors, but I don't yet understand what those objections are
<Zakim> noah, you wanted to look a bit at Jan 28 minutes
<noah> http://www.w3.org/2001/tag/2010/01/28-minutes#item04 is the telcon where ACTION-380 got assigned to DKA
<timbl> Should we be building systems so that whenever they expect data X they can also accept package of X and the social metadata about X?
http://www.escholarship.org/uc/item/0rp834wf is a good article on this BTW
<masinter> to enable quality "X" protocols must accompodate transmission of auxiliary information and representation to preserve X. For I18N, it's ability to do unicode and including "lang" annotations in cases where the language context. For security, it's being clear about authority of information and a way of accessing that. For privacy there has to be a channel, and use cases of using the channel. etc.
<DanC> (380 and 371 are don't to my satisfaction, regardless of their history)
Noah: I mentioned interest in extensibility mechanisms and how they play here.
<masinter> because these qualities (privacy, security, internationalization, accessibility) are often not enforced merely by market forces
Noah: wrt "ACTION-380" what is "this"?
... So you did send a note.
Dan: Yes:
<DanC> he sent http://lists.w3.org/Archives/Public/www-tag/2010Feb/0044.html
<noah> DKA sent: http://lists.w3.org/Archives/Public/www-tag/2010Feb/0044.html
Noah: I propose we agree to close ACTION-380 then. Any objections?
Larry: It's fine.
[no objections]
close ACTION-380
<trackbot> ACTION-380 Draft response to Fredrick, short and to the point. Larry to review. closed
<DanC> action-397?
<trackbot> ACTION-397 -- Ashok Malhotra to frame F2F discussion on geolocation and geopriv, with help from DKA -- due 2010-03-10 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/397
<noah> ack next\
Larry: I just was wondering if there's a way this can cover other kinds of issues we've addressed in the past having to do with i18n, security... some things that are not what customers are asking for but are for the greater good. E.g. use of UNICODE.
<noah> I take Larry's point in principle; I don't immediately see how to use it to frame an effective set of next steps for the TAG.
<DanC> (I think the unicode stuff got worked out by market forces, in the end. it took FOREVER. how old is the utf-8 RFC?)
Larry: Similar kinds of policies around accessibility.
<Zakim> masinter, you wanted to try to generalize privacy with security, internationalization, accessibility issues
<Zakim> noah, you wanted to ask Larry what to do
Larry: A general piece of direction that we need to look a the higher level policy issues - needs beyond the market forces.
Noah: So what would the TAG do?
Larry: We have some architectural statements around accessibility. We should have a concrete position [on privacy].
Noah: Not sure what to do concretely ...
<masinter> longer-term economic benefit, even if it doesn't meet short-term market needs
DanC: people are motivated by money or hard-earned experience...
we did
<DanC> action-380?
<trackbot> ACTION-380 -- Daniel Appelquist to draft response to Fredrick, short and to the point. Larry to review. -- due 2010-03-04 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/380
<timbl> t-3
<DanC> action-371?
<trackbot> ACTION-371 -- Noah Mendelsohn to schedule TAG discussion of DAP WG query on policy (self-assigned) -- due 2010-01-26 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/371
<noah> DKA: Is there a concrete, technical point about packaging privacy with data?
<timbl> re here around privacy data packaged with other data that we could / should say something about? ... you need to sat "q+ to ...."
<noah> DKA: At the first geo meetings, I was not happy with the notion that privacy should go with APIs, now starting to doubt based on UC Berkeley paper.
<noah> t-1
The Berkeley Paper: http://www.escholarship.org/uc/item/0rp834wf
<DanC> action-397: perhaps take a look at http://www.escholarship.org/uc/item/0rp834wf
<trackbot> ACTION-397 Frame F2F discussion on geolocation and geopriv, with help from DKA notes added
Noah: Dan A, Ashok is to propose help from you (ACTION-397) what we will discuss on the f2f.
... Adjourned.
<timbl> How can we take advice on privacy from someone who uses frames and flash and and
<timbl> javascript:dynamicLink("0rp834wf.pdf",%20true,%20"action=transientDownload;expire=72h;from=2010-03-04:11:30;key=1fe20ca9476a51e2f01d1d65ae2f4f31")
<noah> Abstract:
<noah> <p>The W3C's Geolocation API may rapidly standardize the transmission of location information
<noah> on the Web, but, in dealing with such sensitive information, it also raises serious privacy
<noah> concerns. We analyze the manner and extent to which the current W3C Geolocation API provides
<noah> mechanisms to support privacy. We propose a privacy framework for the consideration of location
<noah> information and use it to evaluate the W3C Geolocation API, both the specification and its use in
<noah> the wild, and recommend some modifications to the API as a result of our analysis.</p>
<timbl> <p>The W3C's Geolocatio
<timbl> Cool URIs never change theu just expire
<timbl> Thank you for chairing Noah
<masinter> i promised to do something today and now i don't remember what
<DanC> thanks for taking the ball on updating the public-iri archive homepage, larry.