[00:00] It should be on all pages relating to the project, really. [00:00] But yes, particularly a big warning on the code pages. [00:00] I could do as bugs has done (though correctly) to ensure apps do not work until someone enables them and state clearly who they represent [00:00] But branches are useful regardless. [00:01] They just need to be clearly unofficial. [00:01] Since We have competing communities, I feel pretty powerless to make everyone happy. [00:01] So the code team could make the code pages clear [00:01] LP is the only project hosting site that I know of that requires placeholder registration. It needs to go out of its way to do it right. [00:02] I know. I feel it is wrong that I am working on this [00:03] I an need to go thought 100s (and I really wish that number was an exaggeration) of bugs in all the apps to see what services users are trying to enable or configure, how every step fails. And these bugs are ancient [00:03] Launchpad already gives lots of projects enough reasons not to use it. [00:04] Let's not get people angry with it before they even start using it. [00:04] please help me then. where will people *see* this message? [00:05] code.launchpad.net/gedit, at least. [00:05] What is the message? what does it mean by not official? [00:05] launchpad.net/gedit needs it to be obvious too. [00:05] But ideally it should be in the header. [00:05] Those are code teams pages [00:05] Yes, and this is a Launchpad-wide problem. [00:05] it seems reasonable to me to show a header across all those pages saying "gedit's real home page is at http://blah (tell me more)" [00:06] Right, something like that. [00:06] And the name in the header could be something like "gedit in Launchpad" [00:06] With poolie's suggestion. [00:06] To indicate that this isn't really it. [00:07] But, well, this is probably why we have UI designers. [00:07] AI approved the reuse of the Involvement portlet so that code was always used. I could put text back on the overview page, but where? what message? The user is trying to take an action and I do not know where he is looking on to inform him this project officially uses lp hosting [00:08] sinzui, i think probably every page under that project [00:08] On every page, yes, but probably also an obvious warning in an extra portlet at the top of the project index. [00:08] also the "tell me more" gives us a chance to explain [00:08] why we have this page here at all [00:08] and what you can do with it [00:08] Actually, I think the issue is really about the reverse situation as you suggested. The page should state *where the code is officially hosted*. This is the same stupid problem with bugs, where I can tell Lp where bugs are tracked, but LP will never tell anyone else what I said [00:09] This sound related to the "let me point the app tabs to other URLs" suggestion that pops up every so often. [00:09] The home page is a poor argument. Lp does not want to host any project's home page. There are all hosted some where else. [00:11] s/home page/official site [00:11] wgrant, I think it is. I think for example I can have two community doing support. With using Lp Answers, and the upstream community using a mailing list. For the good off all other users/communities, Lp should state the situation and the someone make a choice [00:11] ah [00:12] sinzui: Who is someone? [00:12] it's a bit like the way facebook has pages about people who don't use facebook [00:12] famous people at least [00:12] some find it a bit creepy [00:12] I should be able to choose how I want support and the community I contact [00:12] they may be doing better than launchpad at at least making it clear the actual person isn't there [00:13] sinzui: The user shouldn't able to; the project owner should. [00:14] I am not sure any owner has more authority than any other community. [00:14] The owner must be able to tell Launchpad what to do. [00:15] poolie, I do believe no service should be enabled until someone states they are using it. [00:16] it depends what you mean [00:16] So I cannot use answers to support a project? Why can I not have Lp branches because a project uses gnome git? [00:17] ah [00:17] i think we should just make the context clear [00:17] sinzui: You can't use Answers to support a project if you are some random, no. [00:17] I do not think there is a on/off. There is several states (hence my suggestion of an enum) that allows Lp to help multiple communities share projects [00:18] Well I can be an answer contact for any project [00:20] You can't be. [00:20] LP exists to serve the project. [00:20] No it does not [00:20] If the project's owners do not want LP to do something, it should not do it. [00:20] that is a common mist conception. Lp could never host all the project that produce code that make up Ubuntu [00:21] Lp exists to help communities share information, and to lower the barrier of controbution [00:22] wgrant: Why is it an issue for Launchpad but not for e.g. sites like ohloh that also just track projects? [00:22] jelmer: Does Ohloh provide services like this? [00:23] GNOME should not need to require zeitgeist to abandon Lp merge proposals. GNOME should be happy to know that Lp can help them with their own project dependencies. Lp should provide GNOME with excellent data about bugs and fixes. [00:23] wgrant: yes, it allows users to post reviews of projects as well as mirroring the downloads for projects, project description, vcs locations [00:23] jelmer: It allows one to link to external download pages, and just displays the real VCS location. That sounds reasonable enough. [00:24] And presumably the owner can tell it not to link to an external download page. [00:24] I would be happier if it were easier to see real VCS information. I have more than a 1000 projects that need love [00:24] Whereas they can't tell Launchpad to not accept questions from people. [00:26] wgrant: I think the main problem is the perception that Launchpad is a project-endorsed resource [00:26] jelmer: Right. [00:27] Ohloh exists solely as a secondary resource. [00:27] right, and everybody regards it as that, wheras most people seem to think of Launchpad as a hosting site, not as a free software project tracker [00:28] Well, most people think of Launchpad as the site that hosts Ubuntu. [00:28] if we can make it clearer when a project is just tracked by lp and not hosted on lp I think this would be less of a problem. [00:28] Exactly! [00:29] It is bot binary though [00:29] not [00:29] a project can use git hub for hosting, but still use Lp MPs [00:30] That's a very strange use case. [00:30] or be on gnome.org and use mps :P [00:30] wgrant: not at all [00:30] lifeless' case sounds more reasonable. [00:31] folk are doing it in fact [00:31] But I guess they are similar. [00:31] thumper: hi [00:31] If a little concerning. [00:31] maxb: hi [00:31] maxb: I've updated the vcs-imports celeb permissions [00:32] maxb: are you interested in helping qa? [00:32] maxb: I could add you to the team, and you could make sure you can't do non-import related bits [00:32] maxb: as long as you don't use production :) [00:32] heh [00:33] did you want to do it now? i can grab a computer [00:34] (i'm on an android phone at prrsent) [00:34] sinzui: btw, the "Configure project branch" link is really nice [00:34] jelmer, sinzui: my frustration with that is that it isn't used consistently [00:35] maxb: I could add you to the team and you could look tomorrow if you like [00:35] sinzui: it saves quite a few roundtrips when registering a new upstream project [00:35] although I tried to import a subversion branch as a bazaar branch by mistake [00:36] thumper: there being multiple forms for setting up a project branch you mean? [00:36] * thumper nods [00:36] I'd like to take the guts of that same page and have a single page for registering a new branch [00:37] thumper: i can have a quick look now and explore more exhaustively tomorrow [00:37] it also doesn't use the same permissions / widget checks as the official import page [00:37] laptop is booting [00:39] thumper: we also have all the infrastructure to just detect what type of vcs is present at a remote URL, it'd be nice to simplify the UI [00:39] jelmer: that would be nice [00:40] maxb: you should be in the team now [00:42] IIRC the key things to look at were the new-project workflow, and the code import machines. [00:42] something like that [00:43] maxb: actually I should have just added you on staging :) [00:43] maxb: as you could at least try to tweak the machine settings there [00:44] maxb: you are now in the vcs-imports team on staging [00:44] * thumper checks that the right revno is on staging [00:45] maxb: staging should be good to play with [00:45] maxb: you can try anything there :) [00:48] or rather, on staging I can't try to tweak the machine settings, so I infer your branches have landed there already === matsubara-afk is now known as matsubara [00:49] It all looks as expected - the one thing I haven't done yet is verify that I don't have any boxes I shouldn't in the new project workflow [00:55] and I've now done that on staging [00:57] Modulo the essential trickyness of QA-ing a negative, I'd say it's all fine [00:59] Erm, pear's /home/importd/.bazaar/subversion.conf is apparently broken: http://launchpadlibrarian.net/49455906/maxb-guice-trunk.log [01:00] the same failure is apparent in other branches when imported on pear [01:00] Yeah, it does that sometimes. [01:00] Happens sometimes with concurrent bzr-svn imports. [01:04] Do we need act-of-losa to get it fixed? [01:04] yes [01:09] thumper: OK, I'd say QA complete - did you want to deactivate me from ~vcs-imports pending an official ratification of it being ready for community members, or shall I start reviewing imports from time to time? [01:40] maxb: if you're on staging, then you're not activated on prod anyway [01:43] lifeless: I added him on prod too :) [02:29] hey [02:29] Hello [02:30] first off, thanks for commenting [02:30] BTW, it would be nice if non-developers could subscribe to LP wiki pages. [02:30] there had been a bit of silence aside from vague 'that sounds nice' [02:30] ah is this the 'action not allowed'? [02:30] that's a bug [02:30] lifeless: did you end up testing those merge proposal changes you did early in the cycle? [02:30] poolie: Yes. action not allowed. [02:30] lifeless: I'd just like to sign off the qa [02:30] * poolie looks [02:31] scottk, https://bugs.launchpad.net/bugs/586601 has a workaround too [02:31] poolie: In any case, what I read in the bug and the wiki page is very concerning. [02:31] Bug #586601: dev wiki toolbar has 'subscribe user' but not plain 'subscribe' [02:31] OK. Thanks. [02:32] so [02:32] Subscribed now. Thanks. [02:32] poolie: https://lp-oops.canonical.com/oops.py/?oopsid=1612BM1 [02:33] poolie: that is (one of) the branch mail job that had memory issues [02:33] Also, I'm somewhat laggy at the moment, so if I don't reply, it's not because I'm ignoring you. [02:33] poolie: it is the kernel [02:33] poolie: lp:~vcs-imports/linux/trunk [02:33] scottk, let's try to unpack "to mean anything positive" [02:34] i don't assume it means the user specifically authenticated that message [02:34] in the sense that typing a gpg passphrase could mean "yes really" [02:34] If you allow the message to do anything that requires authentication, you have. [02:34] i do think it means we can be incrementally more sure that the message comes from who it claims to come from [02:34] would you agree? [02:34] No. [02:35] It means you can be sure it came from the domain it purports to come from, but it tells you nothing about the user. [02:35] thumper: sign off on it [02:35] lifeless: ok [02:35] thumper: it doesn't matter if its right or wrong, until we do the other things you wanted, we're not using the queue stuff anyhow [02:35] thumper: at your request :) [02:35] * thumper nods [02:35] :) [02:36] The only way to believe it says anything about the user is to believe in implementation details of proprietary webmail services that you really have no insight into and even if they actually do what you think, could change without warning. [02:36] no, nothing about this is specific to proprietary webmail [02:36] thumper: that said, I'm entirely confident of my changes anyway, as they a) have tests and b) weren't at the UI layer. [02:37] lifeless: ok [02:37] ok, so are you talking about a case like this: [02:37] poolie: Implementation details of the sender. The ones mentioned are proprietary (mostly) webmail providers. [02:37] thumper: its not in the risk sector for me [02:37] they're just examples [02:37] OK. [02:38] anyhow, so a case like this: smtp.canonical.com lets employees connect over port 529 authenticate and send mail; but it doesn't check that the mail they send is from the user they authenticated as [02:38] Right. That's pretty typical. [02:38] therefore i can get a mail signed that claims to be from joe@canonical.com [02:39] All you really know is that it passed through smtp.canonical.com and they signed it. [02:39] ok, interesting [02:39] DKIM very explicitly makes no assurance that the From address is in any way valid or correct. [02:39] Just that since the header is signed, it didn't get modified in transit. [02:40] hm [02:40] i understand that this is up to their local policy [02:40] it would be a bit weird for them to just sign all outgoing mail [02:41] but perhaps that really is a typical deployment [02:41] especially if it's just stuck in front of an existing server [02:41] Now you may do a security analysis and determine that for some actions (maybe bug status), that is sufficient status. The action is reversable and doesn't really hurt, but you have to recognize that you don't really know who sent the mail. [02:41] Yes. [02:41] ScottK: I don't think we want to do that type of check [02:41] ScottK: in fact we do allow that for unsigned email [02:41] so there are hints in the rfc [02:41] ScottK: things like general comments [02:42] and i'll refrain from quoting it, but it does say that they would authenticate the submitter before signing it [02:42] In fact, if you get a dkim signed mail d=kitterman.com and From scott@kitterman.com, I really did send it or I have a bad bug, but I've gone beyond what is typical and there's no way to know I've done it. [02:42] Yes, but what does authenticate the sender mean? [02:42] Typically it means that the sender is an authorized user of the MTA. [02:42] i assume that means username/password or similar authentication of the smtp submission [02:42] thumper: we do ?! [02:42] poolie: Yes. [02:42] lifeless: yes [02:43] thumper: I get mail rejected when I try to do status changes without signing it.. [02:43] commenting doesn't require signed email [02:43] lifeless: status changes do require signing [02:43] a plain comment doesn't [02:43] yes, as does filing a new bug [02:44] thumper: so the thing you replied two was about bug status [02:44] thumper: you can see my confusion [02:44] what I was referring to was: we already have a distinction [02:44] thumper, that oops would be good to file a bug about [02:44] between trusted and weakly authenticated [02:45] I don't think we want another in the middle [02:45] me either [02:45] the question here is whether dkim-signed mail can be treated as 'adequately authenticated' [02:45] for things like changing bug statuses etc [02:46] well... [02:46] if there are a non-negligible number of domains that will sign any mail sent through them [02:46] then it may not wokr [02:47] I can set up any number of identites with fastmail [02:47] will it sign all of them? [02:47] So you can see the concern I expressed in the bug? [02:47] the question is will fastmail let me send mail that pretends to be tim? [02:47] that would be pretty damn weird if it did [02:47] ScottK, is that the only concern? [02:47] That's the most important one. [02:48] that is the sort of answer we should get before enabling it [02:48] so we could have a whitelist [02:48] I think an implementation that depends on polling commercial email services and asking the internals of their implementation details is not a really great idea. [02:49] or we could get this from adsp, though i haven't looked into that much [02:49] why do you say 'internals'? [02:49] it doesn't really matter how it's implemented [02:49] You need to know if they allow cross user forgery. [02:49] right [02:49] That restriction is an internal implementation issue for them. [02:49] There's no protocol basis for discovering it. [02:50] I can tell you from experience with SPF and DKIM deployments that senders routinely deploy this stuff and barely understand it. [02:50] if somebody decided to turn on dkim signing in ubuntu, would it be likely to allow cross-user forgery? [02:51] Currently Ubuntu developers have the ability to send mail through fiordland at least to Launchpad. I don't know what checks they have in place. [02:52] At least you've got the data in Launchpad accounts to know what users should use what email addresses, but how you link that up to an SMTP time user authentication, I'm not sure. [02:52] i think you have a really good point that this will probably be deployed badly [02:52] but ... if cross- [02:52] cross-user forgery is common, it seems to substantially defeat the point of dkim [02:52] It depends. [02:52] for example they talk a lot about showing a signed From address to the user as authentic [02:52] or trustwotrhy [02:52] In the case of webmail providers, you arguably need to know if they have if they have CSRF flaws etc. Or more simply you need to know the user hasn't leaked their password accidentally... you can't require absolute trust, because nothing is absolutely trustworthy. [02:53] The more common use is to use the d= domain as an input token to a reputation system. [02:53] So over time you can measure which domains tend to send good mail and which one tend to send bad mail so you can treat them differently. [02:53] spiv: But if you can't trust the webmail providers, they can already reset your Launchpad password. [02:54] In that case, you don't really care about cross-user forgery. [02:54] You only really care if you try to believe the from address is somehow validated. [02:54] It may be, it may not, but it's no part of DKIM to say. [02:54] ah [02:55] All DKIM can tell you about the from address is it wasn't altered in transit. [02:57] It was, in fact, contentious in the working group whether or not to require from be signed. [02:57] For this exact reason, people would read too much into it. [02:57] i see it is required [02:57] In the end, it's required to be signed only because it's a required part of the message body. [02:58] The fact that it's signed, is helpful for the policy component, ADSP, that was developed after the base DKIM signing spec. [02:58] proposition: a signature by kitterman.com on "From: scott@kitterman.com" indicates kittermain.com asserts this message is from scott@kitterman.com [02:58] you don't think that's true? [02:58] No. [02:58] It asserts it's signed by kitterman.com and kitterman.com takes responsibility for it. [02:59] If it verifies, you can also trust the signed parts of the message were not modified in transit. === matsubara is now known as matsubara-afk [03:02] but "takes responsibility for it" only in the sense of "takes responsibility for it not being spam" not "takes responsibility for it not being forged"? [03:05] Takes responsibility so that you can blame it (in a reputation sense) if it's "bad". [03:06] ok, so i see your point [03:06] but the rfc really does seem to allude to a larger scope than that [03:06] It is of two minds about it. [03:06] mm, i understand it may be contentious [03:07] In the end, that's all it really does, but there are lots of entities that want to use the DKIM domain as an input to secret sauce reputation systems. [03:07] there are specific examples saying that a from field signed by the relevant domain may be trusted [03:07] it may be the deployment is so bad this doesn't work [03:07] which would be kind of sad considering how long this has been in coming and how new it now is [03:13] I think for applications where domain level information is sufficient, it has a lot of potential. [03:13] ok [03:13] Unfortunately, in the LP case, you need more granularity than it can provide. [03:13] can't they sign the From: field? [03:14] The difficulty is that most implementations do not verify that the authenticated sender is authorized to send using a particular address. [03:14] well, citation needed for 'most' [03:15] but it's certainly possible some don't [03:15] The common documented Ubuntu setups don't. [03:15] wgrant: do they claim that they do though? [03:15] lifeless: Signing From just means it wasn't modified in transit. [03:15] lifeless: How do we tell? [03:16] wgrant: is From signed, no ? [03:16] lifeless: Heh, no. [03:16] Actually you can't actually tell if they claim it's valid. [03:16] lets assume we could tell, what header would we use in launchpad to associate the mail with the account [03:19] ? [03:19] If you're talking DKIM, you're talking body From. [03:19] DKIM is silent on envelope identities. [03:20] and do servers routinely sign body From without sender verification ? [03:20] There's no requirement in the RFC for it. [03:20] Or to put it slightly differently .... [03:21] The senders are verified, but generally they are verified to be authorized users of the MTA, not generally that they are specificaly authorized to use the From they are using. [03:21] are they able to sign the mail as being from their domain *without* signing body From ? [03:21] No. Signing from is required because it's a mandatory part of the message. [03:21] ok [03:21] so we're screwed [03:22] well [03:22] I think DKIM verification is not suitable for applications where you need to have some assurance that you have mail from a specific user. [03:22] anyone doing DKIM as a 'this isn't spam' effort is indistinguishable from someone doing DKIM with user granularity [03:22] Well, someone could define another standard for a signed header that verifies From. But surely such a thing already exists. [03:22] The D in DKIM stands for Domain for a reason. [03:22] ScottK: some domains may be good enough to use [03:22] wgrant: Yes, for this application you use GPG or S/MIME. [03:22] i thought this was part of the point of DKIM beyond SPF [03:22] well [03:22] lifeless: How would you know? [03:22] given there is an exposure [03:23] ScottK: we could ask them [03:23] does this actually matter [03:23] ScottK: they could tell us [03:23] how many important users send mail from servers that allow spoofing [03:23] lifeless: My experience is a lot of providers wouldn't give you an answer you can rely on. [03:23] and how bad is it if their mail is spoofed [03:23] one could already cause a lot of trouble by forging unsigned mail [03:24] Status changes are reasonably trusted at the moment. [03:24] And used for workflow things in Ubuntu. [03:24] poolie: I don't think DKIM 'goes beyond' SPF, it tells you a similar thing about a different identity. [03:25] If you have a message where Mail From and From are the same (this is the 80% case) then an SPF pass and a valid DKIM signature tell you about the same thing. [03:25] The difference between what they tell you is for most purposes not important. [03:27] wgrant: so, if we turned on DKIM for providers that say 'we do per-user authentication on our submission port' [03:28] wgrant: would that really decrease the workflow trust? [03:28] lifeless: You need to be very careful and specific about how you ask that question. [03:28] ScottK: agreed [03:28] Also I'm reasonably certain a significant fraction of the Yes answers you get would be wrong somehow. [03:28] ScottK: 'the body from header in mail from our servers is restricted to addresses the sender can receive at by submission-time authentication' [03:29] I'm continually stunned at how shallow people's understanding of these technologies they are deploying is. [03:29] ScottK: where they are wrong, we disable DKIM for that domain again. [03:29] lifeless: To the extent you know. [03:29] ScottK: that is also a limitation on gpg [03:29] Less so. [03:29] ScottK: I don't see that it is knowable in either case. [03:30] and in both cases, when we have reason to doubt, we can disable it. [03:30] So let's say you go down this path .... [03:30] I'm kitterman.com and I want you to trust my DKIM signature. How do I sign up? [03:31] Are you going to allow anyone to play that makes the correct assertions or is this just for the big boys? [03:31] first cut, lets say there is a DKIM page on dev.launchpad.net, it could say 'file a ticket in answers' [03:31] ScottK: Myself, I'd let anyone that comes along, makes [minor] personal contact and asserts that they do the right thing. [03:32] So there is an admin cost here. [03:32] and have a CHR accessible list to enable.disable folk [03:32] ScottK: as a start [03:32] ScottK: if it works well, make signup straight forward, with admins to disable and re-enable disabled domains. [03:32] Then there's the case of a provider (like say yahoo.com) that doesn't really care about LP and DKIM, but may have a small fraction of their users that do. [03:32] but thats more up front dev when we don't know if it will be a) popular b) work well c) not be a screaming mess [03:33] mm [03:33] ScottK: so, if we believe they dtrt (e.g. by testing ourselves), we could turn it on. [03:33] You won't get a Yahoo dev filing tickets on launchpad. [03:33] ScottK: or we could say 'really please tell us' - and I'm positive we can track the right person at yahoo down. [03:33] so this doesn't seem that different in principle from a mail domain that allows any user to read any other user's mailbox [03:34] poolie: Except it's a lot more common. [03:34] exactly [03:34] Historically "is an authorized user" was enough of a check. [03:34] well [03:34] probably signing messages at all is still uncommon [03:34] commercial domain providers have a vested interest in avoiding forgery sent through their servers [03:34] i don't know what fraction of deployed instances are borken [03:35] but i should probably believe you if you say it's high [03:35] Now you also want people to check is an authorized user of the MTA and that they are using an identity they are authorized to use. [03:35] home and small business less so, because its not representing multiple entities [03:35] ISP's may be a very grey area. [03:35] one would think that isps probably block outgoing forgeries [03:35] but probably not all do [03:36] Part of the problem was that before email authentication, there was very little value in doing cross-user forger, so it doesn't happen much. [03:36] As soon as DKIM or SPF pass starts to mean something, then it's an attack that has value. [03:36] so how about deploying this and not trusting the results, just logging them [03:36] right [03:36] but it's an attack that can potentially be fixed reasonably easily [03:36] i thought the main thrust of this work was aimed at a particular domain that starts with 'g' [03:37] If you're in a position to know about it. [03:37] yeah, and that's the other thing [03:37] whitelisting about 5 domains will help a lot of people [03:37] mwhudson: its a particular provider that we know does DKIM, and supplies some vast fraction of LP user accoun email addresses [03:37] lifeless: right [03:37] then we can consider kitterman.com etc case by case [03:37] mwhudson: but its not the only very popular one ;) [03:38] poolie: I'd also consider SPF pass for a domain the same as a DKIM signature. [03:38] and the largest senders are probably reasonably likely to get it right [03:38] Eventually. [03:38] lifeless: it's by far the most popular though [03:38] SPF is an interesting thought experiment [03:38] i guess there's the apps-for-domains issue too, that kinds of messes things [03:39] mwhudson, do you mean mwhudson.com being hosted by google? [03:39] poolie: Fundamentally a DKIM signature just tells you that the message passed through an MTA authorized by the domain owner and that it hasn't been modified in transit. [03:39] poolie: right [03:39] this can be accommodated by dkim, but it's not done at the moment [03:39] SPF tells you the first part, but not the second. [03:40] In transit modification is not a major risk on direct point to point transmissions. [03:40] there's another difference which is that dkim seems just easier to implement later in the pipeline [03:40] when we're examining a queued mail [03:40] mwhudson: yes, I want apps-for-domains too [03:40] perhaps not substantially, but parsing the headers to work out when it went into our trusted network seems a bit messy [03:40] You'd want to implement SPF checking in the border MTA and then consume with the SPF recieved or Authentication Results header later. [03:40] right [03:41] Spamassassin does this quite well. [03:41] so in principle, if i sent mail direct from my ip to launchpad i think it would be ok to trust it for, say, voting on merge proposals [03:41] It's far more reliable than trying to grovel the connecting IP address out of the recieved headers later. [03:41] by analogy i would be pretty happy to do that over http and it's just a bug that's not supported at the moment [03:42] now eventually you could say there are some operations which should require really strong authentication [03:42] but i think that's a different issue [03:42] Merging code is not something that requires strong authentication? [03:43]