| 01:57 | <MikeSmith> | annevk: systeam updated https://lists.w3.org/Archives/Public/public-whatwg-archive/ to include complete links back to April 2004 |
| 01:57 | <MikeSmith> | zcorpan: systeam updated https://lists.w3.org/Archives/Public/public-whatwg-archive/ to include complete links back to April 2004 |
| 01:58 | <MikeSmith> | oh cool, first message ever posted to the liast was from bratell I guess |
| 02:58 | <MikeSmith> | hoping gal is actually saying something different than what it sounds like he's saying in http://andreasgal.com/2015/03/30/data-is-at-the-heart-of-search-but-who-has-access-to-it/ |
| 03:00 | <Domenic> | wow that is an .... interesting ... post |
| 03:03 | <MikeSmith> | yeah when I read I thought at first there must be something I was misunderstanding myself |
| 03:05 | <MikeSmith> | I think he meant to say, In the long run this is bad for users |
| 03:06 | <MikeSmith> | I think that's what he's implying |
| 03:08 | <MikeSmith> | that if one search engine dominates, it's ultimately worse for users because their choices have been limited for them |
| 03:08 | <MikeSmith> | hopefully maybe he's clarify it to say something like that |
| 03:09 | <caitp-> | do users really care which search engine they use |
| 03:21 | <MikeSmith> | caitp-: point taken but they do care about the quality and relevance of the results they get |
| 03:21 | <MikeSmith> | and there are other imaginable ways that search engines can innovate |
| 03:22 | <MikeSmith> | if there's competition |
| 03:22 | <MikeSmith> | https://twitter.com/andreasgal/status/587682899895263232 |
| 03:22 | <MikeSmith> | "What's good for privacy is good for Google and bad for competition which is bad for privacy." |
| 03:22 | <caitp-> | quite honest, google doesn't really do any better than altavista when I search for stuff that's not super-mainstream |
| 03:22 | <caitp-> | and when you search for stuff that's super mainstream you know what you're gonna find anyways |
| 03:23 | <MikeSmith> | sure |
| 03:23 | <MikeSmith> | that's the other thing |
| 03:23 | <MikeSmith> | it's hard to notice differences like that if you don't have multiple search engines to evaluate results from |
| 03:24 | <MikeSmith> | anyway that quote above from gal also seems like a pretty big stretch |
| 07:18 | <annevk> | MikeSmith: I didn't really get it either |
| 07:19 | <annevk> | MikeSmith: the other search engines, e.g. DuckDuckGo, also use HTTPS |
| 07:19 | <MikeSmith> | yeah |
| 07:19 | <annevk> | MikeSmith: and advocating MitM attacks on users seems rather weird |
| 07:20 | <MikeSmith> | yeah it sure seems at odds with where everything else his headed |
| 07:20 | <MikeSmith> | but I think the part about Referer obfuscation is worth discussing |
| 07:21 | <annevk> | MikeSmith: there's control over Referer through the Referrer Policy |
| 07:21 | <MikeSmith> | not user control, right? |
| 07:22 | <MikeSmith> | ah can a site override the Google munging? |
| 07:22 | <karlcow> | can someone translate that sentence in Simple English (TM Wikipedia) -> "What's good for privacy is good for Google and bad for competition which is bad for privacy." |
| 07:23 | <annevk> | No, but I actually believe that Google should be allowed to control what they leak |
| 07:23 | <karlcow> | because I don't get the conclusion or logical statement of it |
| 07:23 | <annevk> | It's part of the user's privacy experience on Google |
| 07:23 | <MikeSmith> | annevk: ok |
| 07:25 | <karlcow> | Maybe I should read http://andreasgal.com/2015/03/30/data-is-at-the-heart-of-search-but-who-has-access-to-it/ |
| 07:25 | <MikeSmith> | karlcow: I suspect he meant something more like, "What's good for privacy is good for Google. But [practically speaking in terms of the search-engine market] what's good for Google is bad for competition, which [in the long run] is bad for privacy." |
| 07:25 | <karlcow> | MikeSmith: ah understood. |
| 07:25 | <karlcow> | thanks |
| 07:26 | <karlcow> | Yes it's a stretch. |
| 07:26 | <karlcow> | It frames Google instead of framing ads industry |
| 07:27 | <karlcow> | > For some 90% of searches, a modern search engine analyzes and learns from past queries, rather than searching the Web itself, to deliver the most relevant results. |
| 07:27 | <karlcow> | this assertion bothers me a lot |
| 07:29 | <karlcow> | I disagree with "most relevant results", or more exactly it is "sport stadium intelligence type". Relevant == Mass here. |
| 08:30 | <karlcow> | http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-01 |
| 08:31 | <karlcow> | The file URI Scheme |
| 08:32 | <MikeSmith> | yeah that guy's been working on that for a while I think |
| 09:09 | <jgraham> | I think I disagree. It's not just "the ads industry". My feeling is that giving any private institution uncontrolled access to enough private data is bad irrespective of their revenue stream. |
| 09:11 | <jgraham> | I think Andreas' point is that the search industry is heading in that direction and, ironically, that efforts to increase the privacy of individual searches set up a catch-22 scenario where disruption becomes impossible and all the data ends up in the hands of a small number of companies |
| 09:11 | <jgraham> | I think taking it as a simplistic "https is bad" is missing the point |
| 09:13 | <jgraham> | It is very possible to have things that we agree are good at one scale have effects on a different scale that are not good |
| 09:16 | <annevk> | I think the problem is with suggesting that mitm would be acceptable disruption. |
| 09:20 | <MikeSmith> | jgraham: what annevk said |
| 09:21 | <MikeSmith> | I also think Andreas's point probably was that the search industry is heading in that direction and, ironically, that efforts to increase the privacy ofindividual searches set up a catch-22 scenario where disruption becomes impossible and all the data ends up in the hands of a small number of companies |
| 09:21 | <MikeSmith> | but that's not what he actually said |
| 09:22 | <jgraham> | He didn't say "MITM is acceptable" anywhere that I saw |
| 09:22 | <jgraham> | He said that it was a fact and that it helped keep the market competitive |
| 09:22 | <MikeSmith> | maybe not but he implied it |
| 09:22 | <MikeSmith> | he implies it's good |
| 09:23 | <annevk> | "Search engines with small user bases can acquire search traffic by working with large Internet Service providers (also called ISPs, think Comcast, Verizon, etc.) to capture searches that go from users’ browsers to competing search engines." |
| 09:23 | <MikeSmith> | as far as I can see |
| 09:23 | <jgraham> | He implies that a competitive market is acceptable |
| 09:23 | <jgraham> | s/acceptable/good/ |
| 09:23 | <jgraham> | He states that this was a technique that enabled one to exist |
| 09:24 | <jgraham> | there is no rule that says that mechanisms allowing things we like don't have side effects which we dislike |
| 09:28 | <MikeSmith> | I guess I would say that anybody who was doing business on the basis of relying on secret deep-packet-inspection of user data by ISPs was doing something bad and harmful to begin with, so they very much deserve for the businesses and revenue streams to end up being wrecked when they can't do that any longer |
| 09:29 | <annevk> | Yeah, I take issue with Andreas not taking issue with ISPs meddling with traffic |
| 09:35 | <jgraham> | Well I don't care a jot about their business, but I don't think that addresses the fundamental issue at all, which is that this is a case where your near term interests as a consumer are strongly misaligned with your long term interests |
| 09:35 | jgraham | -> train |
| 09:43 | <JakeA> | Stupid question that an HTTP expert will know the answer to straight away: With chunked encoding, is each chunk *independently* gzipped? Also, what's the benefit of chunking vs a stream of data? |
| 09:54 | <JakeA> | Ok, so the whole body is zipped before chunking. Still not sure on the benefit or reasons for chunking |
| 10:41 | <annevk> | JakeA: with chunked you can do trailers. And it allows for streaming content. I thought you needed either chunked or set Content-Length |
| 10:42 | <JakeA> | annevk: yeah, you need to use chunking if you don't set content-length. I guess I'm trying to work out the benefit of one large chunk vs many chunks |
| 10:42 | <annevk> | JakeA: well if you don't know exactly what you're sending back you'd use it |
| 10:42 | <annevk> | JakeA: if you do, you can set Content-Length |
| 10:45 | <JakeA> | annevk: yeah, so what's the benefit of each chunk having a local content-length, rather than just streaming the data & having a termination signal |
| 10:46 | <JakeA> | (I know the latter isn't possible with HTTP, just working out why it was designed that way) |
| 10:47 | <MikeSmith> | so it seems like some people who were involved with the System Apps work where the effort come up with a non-Web different security & runtime model for apps are not proposing that the APIs that would have needed that are instead adding *Permission methods that require users to opt into a higher trust level to grant to particular apps |
| 10:47 | <annevk> | JakeA: that's probably for integrity |
| 10:48 | <MikeSmith> | I mean what's discussed in https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0092.html (about the *Permission thing) |
| 10:48 | <MikeSmith> | and in, e.g., the http://www.w3.org/2012/sysapps/tcp-udp-sockets/ spec |
| 10:49 | <MikeSmith> | TCPPermission interface, the allow users to grant an app permission to open a real TCP socket interface |
| 10:50 | <MikeSmith> | *TCP socket connection |
| 10:50 | <annevk> | JakeA: also, a delimiter would make it impossible to transfer arbitrary data |
| 10:50 | <annevk> | JakeA: that is probably the main reason |
| 10:50 | <annevk> | I'm really enjoying https://twitter.com/hsivonen/status/587928397881421824 |
| 10:51 | <MikeSmith> | my question about that permission stuff is, has this been discussed somewhere else (other than just among the SysApps people); e.g., in the WebAppSec group or TAG or somewhere |
| 10:51 | MikeSmith | is way behind on e-mail |
| 10:51 | <JakeA> | annevk: is arbitrary data a bad thing? Can you not do that with content-length? |
| 10:51 | <annevk> | MikeSmith: there was a discussion in one group for a bit |
| 10:52 | <annevk> | JakeA: it's not a bad thing, it's a requirement |
| 10:52 | <MikeSmith> | annevk: |
| 10:52 | <MikeSmith> | ok |
| 10:52 | <annevk> | MikeSmith: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/thread.html#msg1 |
| 10:53 | <annevk> | MikeSmith: that 0092 email you pointed to was the follow up |
| 10:54 | <annevk> | MikeSmith: that whole permission model stinks though, I don't think that would ever ship outside of walled gardens such as the Chrome Store or Firefox OS Store |
| 10:54 | <annevk> | MikeSmith: and they already have their own proprietary APIs they probably don't want to replace due to the effort that would require that's better invested elsewhere |
| 11:08 | <_1_hozi> | hiii |
| 12:01 | <MikeSmith> | annevk: ok I hadn't yet read the part where you'd responded earlier to Claes |
| 12:03 | <MikeSmith> | annevk: I have to say that as far as the list of use cases at https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0001.html most of those don't seem to require a TCP socket interface |
| 12:04 | <MikeSmith> | e.g., "An email client which communicates with SMTP, POP3 and IMAP servers" |
| 12:05 | <MikeSmith> | clearly we already have Web-based e-mail clients that work just fine without needing to implement per-app SMTP, POP3 and IMAP protocol support on the client side |
| 12:07 | <MikeSmith> | and "An irc client which communicates with irc servers", we already have Web-based IRC clients and regardless I think going forward we don't really want to do IRC over the Web anyway; instead we want to be creating Web-first ways to do many-to-many real-time chat that takes advantage of the richer features you can have when you do that instead of limiting yourself to what you can do with IRC |
| 12:08 | <MikeSmith> | and "Peer-to-peer applications", we have DataConnection in WebRTC |
| 12:08 | <MikeSmith> | etc etc |
| 12:09 | <MikeSmith> | I thought the original proposal for a TCP socket interface was motivated by the idea that people would be writing system-level apps (as opposed to just userland apps) using Web-platform technologies |
| 12:10 | <MikeSmith> | for stuff like FirefoxOS or ChromeOS |
| 12:11 | <MikeSmith> | I don't think anybody started out on that with the idea of a way to expose raw TCP connections to apps running on the real Web |
| 12:12 | <MikeSmith> | so it kind of seems like some use-case creep has happened here |
| 12:18 | <annevk> | MikeSmith: given that to this day we're still connecting to IRC and various other services through native apps there's something to be said for being compatible with "legacy" interfaces |
| 12:19 | <annevk> | MikeSmith: however, if a solution does not address the security problems it's obviously not going to get any traction outside walled gardens |
| 12:22 | <MikeSmith> | annevk: yeah, sure |
| 12:23 | <MikeSmith> | but more and more I'm being really skeptical of use cases of the "this allows connecting to some legacy thing over some legacy protocol" variety |
| 12:25 | <MikeSmith> | people should instead by focusing their energy on coming up with new Web-first ways of solving the same problems the legacy application protocols did, but doing it Web-natively |
| 12:26 | <MikeSmith> | I really believe in this idea of Tim's that the Web wants to be "the information space that contains all other information spaces" |
| 12:28 | jgraham | thinks of the web more as "the space where we thought information might be, only to find cat pictures" |
| 12:28 | <MikeSmith> | heh |
| 12:28 | <MikeSmith> | anyway an information space like the IRC space isn't something bound to the IRC protocol or whatever other that was developed a couple dozen years ago before there was a Web |
| 12:30 | <MikeSmith> | jgraham: rightly you should just be able to post cat picture right here into this channel where we can all see it |
| 12:31 | <MikeSmith> | but you can't because we're our apps are using some protocol here that was invented before the Internet ever had any idea what to do with actual images |
| 12:33 | <jgraham> | Well if you were using irccloud and I was the sort of person who posted cat pictures into a channel, I could |
| 12:33 | <jgraham> | (other web-based irc clients are available) |
| 12:33 | <jgraham> | In fact it doesn't even have to be web-based |
| 12:35 | <jgraham> | In general my worry about the web compared to other protocols is that the requirement for a server side strongly encourages the creation of walled gardens, and intermediaries |
| 12:36 | <MikeSmith> | jgraham: WebRTC DataConnection doesn't rely on any server side |
| 12:36 | <jgraham> | I understand that there are more P2P things coming, but if you compare irc to facebook messanger or whatever it's not clear that the latter's really better for anyone. |
| 12:36 | <MikeSmith> | oh, granted that |
| 12:37 | <jgraham> | And even with irccloud, it seems like you are adding an extra party who is privy to all your conversations for no real advantage |
| 12:37 | <MikeSmith> | but as far as IRC specifically there are things like Slack and Gitter that provide a very good, rich user experience |
| 12:37 | <MikeSmith> | yeah, agreed on that |
| 12:37 | <jgraham> | Well for the advantage of a nicer UI |
| 12:39 | <MikeSmith> | er, btw I guess DataChannel is what the WebRTC thing is called (not DataConnection) |
| 12:42 | <annevk> | MikeSmith: be careful now, that's what the XHTML 2.0 guys thought too |
| 12:43 | <Ms2ger> | Weren't you one of the XHTML2 guys? :) |
| 12:43 | <annevk> | Ms2ger: I was cheering them on, but I guess that's semantics |
| 12:44 | <annevk> | Ms2ger: but I did realize at some point that gradual evolution works better |
| 12:47 | <MikeSmith> | I'm the guy who thinks it should be pretty obvious that over the long run the Web is going to evolve to assimilate all these things and let people do them better than they did before with the old systems |
| 12:56 | <annevk> | Agreed, it's just easier to assimilate if we can remove the friction |
| 14:00 | <MikeSmith> | annevk: btw if you find any remaining oddities in https://lists.w3.org/Archives/Public/public-whatwg-archive/ please lemme know |
| 14:01 | <MikeSmith> | systeam said that part of the problem was that the mboxes they were given to start from where whacked in various ways |
| 14:01 | <MikeSmith> | missing or misplaced stuff |
| 14:02 | <MikeSmith> | I think they had to write or revise some scripts of coercing them into some form the archive system could consume as expcted |
| 14:22 | <annevk> | Bah |
| 14:22 | <annevk> | Please thank them :-) |
| 15:36 | <annevk> | JakeA: could you reply to https://github.com/whatwg/fetch/issues/27#issuecomment-92905683 perhaps? |
| 15:37 | <annevk> | JakeA: would you mind if I assign that issue to you? |
| 15:37 | <JakeA> | annevk: Go for it |
| 18:13 | <TabAtkins> | terinjokes: If you *do* want to do something that lets unrelated websites coordinate, publish a vocab and use Microdata. |
| 19:22 | <wanderview> | jsbell: ping |
| 19:44 | <jsbell> | wanderview: yo? |
| 19:44 | <wanderview> | jsbell: so thanks to jgraham we now have the blink cache tests in wpt and gecko! |
| 19:44 | <wanderview> | which is awesome |
| 19:45 | <jsbell> | wanderview: w00t! |
| 19:45 | <wanderview> | jsbell: however, I believe there are some spec issues with the tests... wondering where you want me to post those? in wpt? |
| 19:45 | <jsbell> | wanderview: sure |
| 19:45 | <wanderview> | for example, the spec prohibits putting a POST request in the Cache: https://dxr.mozilla.org/mozilla-central/source/testing/web-platform/tests/service-workers/cache-storage/script-tests/cache-add.js#30 |
| 19:45 | <wanderview> | and think some things I wrote blink issues on in the past |
| 19:45 | <wanderview> | like requiring object equivalence for subsequent calls to caches.open(), etc |
| 19:45 | <wanderview> | jsbell: thanks! |
| 19:46 | <jsbell> | wanderview: Cool. I think for POST we have a failing expectation file in chrome, but yeah the test should be updated. so wpt is great |
| 19:46 | <wanderview> | yea, the spec changed there |
| 21:22 | <jgraham> | jsbell: If we fix test issues in wpt will you be able to merge those fixes to blink? |
| 21:30 | <jsbell> | jgraham: yep |
| 21:31 | <jsbell> | jgraham: slowly, painfully, and manually if need be, but yep. :) |
| 21:31 | <xtrm0> | Hasta lá vista |
| 21:38 | <jgraham> | jsbell: Awesome! |
| 21:42 | <gsnedders> | jgraham: I presume you'll support getting xfail stuff merged into html5lib ASAP? |