[01:10] attente: Hrm ok, but it may be because the yakkety system is relatively fresh, i.e last week. [01:10] attente: i.e that other system worked fine. === maclin1 is now known as maclin === hikiko_ is now known as hikiko [05:00] hello === duflu_ is now known as duflu [06:44] morning! [06:44] somone to lend a hand with yakkety? [06:46] What's up? [06:48] I'm trying to install daily build of yakkety but it is crashing every time I try [06:48] toshiba portege with SSD hd [06:48] you happen to know if the installation is buggy or crashy= [06:49] I've got even the bug report [06:49] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1611010 [06:49] Launchpad bug 1611010 in ubiquity (Ubuntu) "yakkety installation failure" [Undecided,New] [06:51] I'm doing the installation through a USB bootable stick [06:53] Looks like the installer *is* buggy :) [06:53] I'm trying now with xenial iso to confirm =) [06:56] You're right RAOF =) on xenial works perfect [06:57] you buggy installer thanks! [07:17] is anyone else not having a proper scrollbar in firefox in yakkety? [07:17] the scrollbar space is there, but not the handle/knob [07:20] word up, d-tops [07:34] The bird, I believe, is the word. [07:47] good morning desktopers [07:47] hey desrt RAOF [07:48] good morning [07:48] tsdgeos, could be a gtk 3.20 fallout, what firefox version do you have? yakkety has 46 but proposed has 48 and it might be worth trying that one [07:48] hey Trevinho! [07:48] hi seb128, how are you? [07:48] hey seb [07:48] Trevinho, I'm good thanks! you? [07:48] seb128: 47 [07:48] try 48 just in case [07:48] allright, another sunny day... This summer is as it as to be :-) [07:48] seb128: yeah the internet seems to agre with you it's because of gtk 3.20 [07:49] i've installed some extension that gives me blue colored scrollbars for the moment [07:49] it's something [07:49] can you try 48? [07:50] I've a yakkety vm, let me boot that [08:03] Wow... This last yakkety landing is taking soooo long... :-/ [08:03] sup [08:03] Morning. [08:04] I have a spare hour or so today. Laney, I'll be uploading artwork later. [08:04] morning all [08:04] hey Laney [08:04] & flexiondotorg [08:04] & willcooke [08:05] how is u.k today? [08:05] sunny! [08:05] Yep, that ^ [08:07] lie! [08:07] it suuuuuuuuure is [08:07] what's going on?! [08:08] can you please send us our european sun back [08:08] kthxbye [08:09] meh [08:09] meh meh [08:10] that naive patch for theming doesnt work against 3.20. in fact everything is different in 3.20. [08:13] welcome to GTK fun world, you got a free ticket to play another round! [08:21] *cough* [08:22] The following NEW packages will be installed: ... gcc-6 ... [08:23] cool [08:29] Sweet5hark1: heh, yeah, what seb128 said ;) if you need help and link me to the code i can take a look later today probably [08:29] hey ochosi, how are you? [08:30] good good :) you? [08:31] ochosi: thanks, I think I first need to recompile an unpatched version against 3.20 to see if/how stuff is broken there at all. [08:31] Sweet5hark1: hm, not sure that's true, but go ahead :] [08:36] I'm good thanks [08:38] how's the whole gtk3.20 transition going for y? [08:38] it's in [08:38] nice [08:38] congrats [08:39] firefox needs a rebuild and to get out of proposed [08:39] been stuck there for a while [08:40] ochosi: well, https://cgit.freedesktop.org/libreoffice/core/commit/?id=03c33a2521421415c4fcbbe1491dc92a1943269b looks like stuff is quite different for 3.20 vs. 3.19 [08:42] chrisccoulson, hey, ^ do you plan to look at the firefox build on ppc/s390x or do you need help with that? [08:42] Laney, I've a feeling it's not going to be easy to find somebody wanting to fix the firefox build on ppc [08:43] I don't plan to do anything with ppc [08:43] so what then? [08:45] well, chrisccoulson's position iirc is that we should stop to claim we support firefox on those archs and stop building in there [08:45] but infinity disagrees with that iirc and said he would be happy to help fixing build issues so we keep having it available on those archs [08:45] Yeah, we should stop pretending that firefox is supported on powerpc [08:46] infinity, xnox hey, do you think you would have any cycles to help sorting out firefox on powerpc/s390x? if not we are suggesting removing it from those archs [08:46] chrisccoulson, what about s390x? [08:47] I get the position, but it requires some execution to become reality [08:47] you mean? [08:47] well, I just pinged them [08:47] let's give them some time to reply [08:48] if they don't/don't have slots we just stop building on those arch/delete [08:48] but it wouldn't be nice to just do it now before they reply? [08:49] I'm personally +1 to stop building it on powerpc, there are probably like 10 users for it and it's not worth the work it put on us to keep it working [08:50] Sweet5hark1: right, but while for the theming side of things the changes might seem invasive, it's not *that* bad [08:51] I mainly mean that it has reverse dependencies [08:51] Hopefully most of those are OR-ed to any web browser [08:53] seems they do [08:53] but yeah if we decide to go this way it needs some work [08:53] but I don't think too much [09:01] I'll use chromium for a bit :-) [09:02] does anyone still use firefox? ;) [09:03] o/ [09:03] I did until 2 minutes ago [09:04] I don't like the new look of the awesome bar in firefox 48 :-/ [09:04] it's way harder to read/parse for me [09:04] let's see if I get used to it [09:05] desrt, oh, reminding you to look at that glib gerexp test issue from friday [09:05] oh ya. yay. [09:05] * desrt loves gregex [09:06] link me? [09:06] desrt, also do you know if having xdg-open as a fallback for urls handling in glib when there are no registered handler was ever discussed? [09:06] didrocks, ^ [09:06] what is your usecase here? [09:06] i think it doesn't make sense, since xdg-open is really only supposed to be doing what glib would be doing anyway [09:06] desrt, ERROR:/build/glib2.0-4NbKb8/glib2.0-2.49.2/./glib/tests/regex.c:82:test_new: assertion failed (g_regex_get_compile_flags (regex) == data->real_compile_opts): (0x00000000 == 0x00000001) [09:06] but i guess this is in the case that xdg-open has been replaced by our helper? [09:06] https://bugzilla.gnome.org/show_bug.cgi?id=767240 [09:06] Gnome bug 767240 in gregex "Regex failures with pcre 8.38" [Normal,New] [09:07] desrt, yeah, it's in the snappy case, we have a fake "xdg-open" that sends a dbus call to the real env which has a service handling the url [09:07] i think we should consider a different approach here, in fact [09:07] but for the "click on url" to work in gtk apps we need to have the mimetypes defined in the env [09:07] why not ship upstream xdg-open inside of the snap [09:07] and then create a .desktop file for our forwarding service [09:07] and? [09:07] and set it up as the default http and https handler (and whatever else) [09:08] then xdg-open will do its normal job, and then so will glib [09:08] how would that help? [09:08] it would make upstream xdg-open work, and it would eliminate the need for weird non-op fallbacks in glib [09:08] the issue there is that the in-snap .desktop needs to list all known handlers [09:08] no. it only needs to know about the forwarding service [09:08] like x-scheme-handler/skype [09:09] oh. [09:09] i thought this was only for http and https [09:09] http/https works [09:09] on account of security concerns... [09:09] but it forces us to create a mimeapps.list [09:09] right [09:09] mimeapps.list is a trivial text file [09:09] right [09:09] but it needs to be edited to add mimetypes on our end then [09:10] like if skype claims x-scheme-handler in their snapd [09:10] we need to edit our os snap to list the mimetype [09:10] so xdg-open knows it's a type it can handle [09:10] i thought we discussed handling of arbitrary schemes and decided that it represents a security hole [09:10] well some people did [09:10] but I was not in this discussion [09:10] and now I'm hitting the issue than for e.g yelp to work be need to add help: [09:11] and then next somebody is going to say than clicking on an hangout:url in telegram doesn't work [09:11] so we add hangout [09:11] etc [09:11] telegram works by url [09:11] which seems to be the future here, in fact [09:11] you mean? [09:11] like telegram.me/desrt [09:12] well, if I send on a text saying "join me on hangout:seb-and-desrt" [09:12] ie: matching http url prefixes [09:12] what happens to the hangout:<...> part? [09:12] but does hangouts actually work that way? hangouts are by http URL too [09:12] dunno [09:13] but [09:13] /usr/share/applications/mimeinfo.cache:x-scheme-handler/skype=skype.desktop; [09:13] ya... skype is dumb and old [09:13] so it means skype supports "skype:" [09:13] i bet it has a more modern approach as well [09:13] /usr/share/applications/mimeinfo.cache:x-scheme-handler/steam=steam.desktop; [09:13] /usr/share/applications/mimeinfo.cache:x-scheme-handler/spice=remote-viewer.desktop; [09:13] /usr/share/applications/mimeinfo.cache:x-scheme-handler/vnc=vinagre.desktop; [09:13] I meant there is a stack of those [09:14] or "you should install appstream:evolution" [09:14] ...and it's probably not generally safe to allow confined apps to arbitrarily open them [09:14] they don't open [09:14] they send a dbus call to the system with the url [09:14] ...and then? [09:14] and the helper decide if it's safe to open or not [09:14] right. exactly. [09:14] and afaik, the helper currently decides "http and https? yes. else? no." [09:15] and mailto: also iirc [09:15] right [09:15] I wanted to restart that discussion with the snappy team because I was not part of the previous one and don't understand the rational [09:15] ie: we want only very specific handlers here.... as a matter of security policy... opening it to arbitrary handlers being dispatched from confined apps is a bad idea [09:15] what's the security risk of saying to the system "open that skype url with the handle you have for it"? [09:15] talk to attente when he wakes us... [09:15] opening skype can join you to a conversation, for example [09:16] k, I was planning to [09:16] that's much more active than simply viewing a webpage in a browser (which is an entire program designed to security-isolate you from the URLs you visit) [09:16] in any case...... i guess it might make sense to provide some sort of override mechanism in glib for this kind of thing, but it probably won't work as well as you think it will [09:17] is the issue there than we currently don't have a prompt to make you pick the app you want to use? [09:17] because e.g android do that [09:17] click on files or url trigger the system to ask you with what you want to open [09:17] and that list includes random app [09:17] I'm sure you can open skype from messanger on android [09:17] the issue is that applications, as we know them, are generally designed to assume that the thing passing them a (e.g.) skype: url are operating at a similar trust level [09:18] Laney, hey, I still need a review for the plugins-bad MP :) [09:18] on android it's different.. their URL dispatching mechanism has different trust-assumptions baked in to it [09:18] and it's not just about some "are you good with this? [x]don't bother me again" prompt [09:18] abeato: I know, it's open right now [09:18] I guess I don't see what security issue it could be to see "yes I want to open that url in " if it's a decision I explicitly ack/deny [09:19] abeato: I had to fix libhybris yesterday to make gst-bad even build [09:19] which was step zero in reviewing it [09:19] :/ [09:19] because (a) if there is a security dialog every time, that's really really poor design [09:19] Laney, oh, I see [09:19] and (b) if there is not a security dialog every time, it's potentially dangerous [09:19] (a) is what android does right? [09:19] and (c) allowing the user to select "don't show me this anymore" is not really providing them with enough information to make an informed choice [09:19] abeato: so ya, doing this in a minute - now need to make MPs for those fixes [09:20] Laney, cool, thanks [09:20] no. first of all, android only asks if there is a question of what to do. [09:20] if there is only one possible app to handle an action, it just does it [09:20] ie: the android dialog is not about security at all. it is about selecting an app, in the purest sense. [09:20] k [09:21] and i repeat, the most important aspect here: android apps have been designed such that dispatched URLs are assumed to come from potentially untrusted sources [09:21] apps as we have them on our systems are not. they assume that the thing that is feeding them the command line arguments is operating at the same level of trust [09:21] which was never true though [09:21] like you could call "program url:I-typed" for ever [09:22] yes. of course. the key being "i-typed" [09:22] ie: the user doing it themselves [09:22] so programs have to deal with potentially receiving random input aimed at made them bug [09:22] or the webpage you visit [09:22] and the argument there is, "if the user can type this commandline, then of course they could also just type rm -rf /... so no security concern..." [09:22] web browsers are VERY cautious about opening 3rd-party handlers [09:23] i just did a telegram request, for example, and am getting a rather large lecture about it from chrome [09:23] well if you click on appstream: url it's going to call gnome-software [09:23] "If you did not initiate this request, it may represent an attempted attack on your system. Unless you took an explicit action to initiate this request, you should press «Do Nothing»" [09:23] interesting [09:24] (and imho, this is bad UI) [09:24] I think it's enough discussion for telling me it's not a simple matter of waving the whitelist thing then [09:24] hope they agree to add a few other selected handlers though [09:24] but the point stands: nobody thinks it's a good idea to let untrusted things open arbitrary url schemes with arbitrary handlers [09:24] meh. [09:24] I want "help:" in there so GNOME documentation works [09:24] to be honest, you have a point [09:25] it may make sense to allow this to be expanded in the future [09:25] and at some point we will probably want to add some mechanism to glib to allow for opening url handlers working with arbitrary URLs (and have them rejected on the system side) [09:25] well I guess it's fine for selected ones where we set a default handler [09:26] like help ;-) [09:26] that's a real feature to discuss... but (a) we can't "just do it", and (b) it won't look like fork()/exec() xdg-open [09:26] right [09:26] well my "fallback on xdg-open" was because xdg-open is that wrapper than do a dbus call for it [09:26] ya... of course [09:26] but it doesn't get to that point in there is no .desktop installed to claim the mimetype [09:26] but that only makes sense if xdg-open is not ... *ahem* xdg-open [09:26] so I need to create a fake mimeapps.list which has [09:27] x-scheme-handler/http=xdg-open.desktop [09:27] x-scheme-handler/https=xdg-open.desktop [09:27] x-scheme-handler/mailto=xdg-open.desktop [09:27] and it's a bit annoying [09:27] well, even if it was the real xdg-open [09:27] to get to the point it's being called you need it to have a .desktop which claims the mimetypes [09:28] i wonder if we could do x-scheme-handler/* somehow [09:28] like, we have mimetype inheritance [09:28] that would be nice [09:28] we could make a x-scheme-handler/fallback that is the parent type of all the other scheme handlers [09:29] qt apparently just fallback to calling xdg-open (from what didrocks said) so was wondering if that would make sense for gio [09:29] to be discussed with the mime maintainers, perhaps [09:29] right [09:29] desrt, thanks for the discussion! [09:29] i seriously doubt we will ever do this [09:29] k, fair enough [09:29] glib is trying hard to reduce the amount of fork()/exec() it does [09:29] do you know how flatpak handles urls? [09:29] i think it doesn't :) [09:29] at least not last i heard of it [09:30] k, so eventually we all need to figure out something [09:30] ya. and i will insist on it being the same thing for everyone :) [09:30] +1 [09:31] thanks desrt [09:31] desrt, going back to the other topic, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/g/glib2.0/20160806_091504@/log.gz [09:31] desrt, the error matches what is in https://bugzilla.gnome.org/show_bug.cgi?id=767240 [09:31] Gnome bug 767240 in gregex "Regex failures with pcre 8.38" [Normal,New] [09:31] which I think meant 8.39 [09:32] i'm starting to wonder about the value of testing GRegex [09:32] that's the pcre3 8.38->8.39 that triggers the test regression [09:32] i think pretty much 100% of people are using it only for non-obscure features [09:32] and the testcase is brutally heavy on testing every weird edge case [09:32] Morning [09:33] well it's important to not regress/change behaviour, even on edge cases no? [09:33] hey andyrock, having nice holidays? ;-) [09:34] seb128: not if nobody cares :p [09:34] at some point you start testing the implementation more than the interface [09:35] okay. in this case, it seems quite bad, indeed, though. [09:35] since the documentation specifically mentions these features... [09:35] wtf... [09:37] interesting to notice that the last several cases of this have been addressed by fixing the tests :p [09:41] :-) [09:50] seb128: yes firefox 48 from proposed fixes the scrollbar problem (and other issues i had with checkboxes and stuff) === hikiko is now known as hikiko|ln === doko_ is now known as doko [10:25] seb128, infinity, chrisccoulson - possibly related https://bugzilla.mozilla.org/show_bug.cgi?id=1271748 based on pattern matching. The fact that it affects big-endian only is suspicious. [10:25] Mozilla bug 1271748 in JavaScript Engine "Crashes on start: ABORT: JS_InitWithFailureDiagnostic: u_init() failed" [Major,Unconfirmed] [10:25] does anyone at all run nightly builds and/or any way to bisect as to when this has started to happen? [10:26] xnox, that issue was caused by us not bundling the ICU data file. That's fixed now [10:26] chrisccoulson, ack, thanks. [10:29] chrisccoulson, is our packaging of firefox at all bisectable, or am I better off building / running bisect against upstream tree? to spot when s390x stopped building between firefox 46 & 48? [10:29] xnox, you'd need to do it against upstream [10:30] ack [10:36] seb128: you'll never guess what i'm going to do to fix this bug :D [10:36] pcre broke behaviour upstream, intentionally... [10:36] chrisccoulson, ... and it needs gazzilion disk space right? [10:36] and i sort of agree that it doesn't really matter [10:37] xnox, I can't remember - I don't recall the last time that I did a firefox build locally :) [10:37] I don't think it's that bad [10:37] compared to what I usually work on [10:41] chrisccoulson, xnox, better adding s390x support to the firefox-next ppa ;) [10:41] Does anyone use firefox on s390x? [10:42] I guess not, so simply blacklisting the ppc and s390x seems the best way [10:45] ricotz, there is community port to lubuntu for powerpc, i'm pretty sure it's like the only browser working there. [10:45] no, nobody uses graphical things on s390x. [10:45] .... or at least they should not. [10:45] but failure of _all_ big endian architectures we have, indicates an endianess bug =) [10:47] xnox, ok === jibel_ is now known as jibel [10:51] seb128: patch in the bug to test, if you like [10:51] ricotz, is firefox-next canonical-only ppa? [10:52] xnox, no [10:52] no powerpc/s390x for that, for now, then =( [11:01] xnox, see the comment here - https://hg.mozilla.org/mozilla-central/file/tip/build/autoconf/icu.m4#l81 [11:02] hmmm, apt-get build-dep libreoffice finished with exactly 0 bytes of disc space in a VM. it claims to be successful. [11:02] should save you time bisecting ;) [11:02] <- living on the edge [11:02] chrisccoulson, ah [11:02] chrisccoulson, so... how is that generate? and why a system one is not used? [11:03] * xnox ponders how to generate it. [11:10] xnox, we don't use system libraries in firefox [11:12] i think their update script does build both little and big endian, and then just ignores the bigendian one =( === hikiko|ln is now known as hikiko [11:28] chrisccoulson, re-running icu_sources_data.py after patching it to keep bigendian icudata. [11:31] then i'll need to patch build machineray to use that. and hopefully everything will be good. [11:32] seb128: it's raining now [11:32] you'll be happy to know [11:34] xnox: thanks for looking! [12:03] Laney, sorry about that, sun is back there... [12:04] desrt, thanks, going to try that in a bit === DanChapman_ is now known as DanChapman [12:05] pretty sure it should work fine.... it basically just comments out the problem :p [12:05] feels like cheating! [12:10] the problem is well-understood, and the change was intentional by upstream [12:10] it just so happens that our tests are more pedantic than theirs are [12:17] xnox: Nobody attaches graphical heads on s390x, it seems to be a very common use case to run x clients on s390x though. [12:18] chrisccoulson: You use some system libraries... [12:19] chrisccoulson: System libicu might be a good candidate. [12:19] Though, this should be fixed upstream regardless. [12:28] I cannot start gnome terminal in yakkety and I've this crash bug 1611358, is it known? [12:28] bug 1611358 in gnome-terminal (Ubuntu) "/usr/lib/gnome-terminal/gnome-terminal-server:6:g_assertion_message:g_assertion_message_expr:VteTerminalPrivate::set_background_alpha:vte_terminal_set_colors:update_color_scheme" [Undecided,New] https://launchpad.net/bugs/1611358 [12:37] jibel: No, but if you go into dconf-editor and browse to /org/gnome/terminal/legacy/profiles: and look at background-transparency-percent, what are the values? [12:38] I can make it happen if I put a value > 100 in there [12:39] Laney, -89 [12:40] Probably fix that to like 10 [12:40] no idea how that would happen [12:41] Laney, it works with 10 [12:41] and breaks with any value <0 [12:42] ok [12:42] I can put some sanity checking in there, but I wonder how that happens [12:43] there are already 3 reports in errors.u.c [12:43] I see that [12:50] jibel: ok, I uploaded something to make it not crash [12:50] thx for reporting [12:50] Laney, thx for fixing [13:09] chrisccoulson, i hate icu [13:09] so the build that firefox does doesn't support byteswapping in the icupkg tool. [13:09] argh [13:14] seb128: hey, just following up on the discussion you had with desrt. is the xdg-open whitelist ok? or did you want to do something else? === JanC is now known as Guest75507 === JanC_ is now known as JanC [13:25] attente, I was wondering how much it was discussed to restrict, like where do we draw the line on what is ok and not [13:26] attente, I'm unsure to see what security issue it is but d_esrt convinced me some people think it's desirable to keep it restricted, which is fair enough [13:26] attente, oh and hey btw ;-) [13:29] hey to you too :) [13:30] yeah, i guess we were trying to play it safe [13:30] there wasn't that much discussion, but niemeyer wanted it restricted too iirc [13:31] maybe there's some way we can make updating the whitelist less painful though? [13:33] is having a dialog asking the user to open a url really that bad design though? it sounds ok to me tbh... [13:33] do you have any clever idea there? [13:33] I don't know [13:33] but do you know who should take the decision if it's ok to add more url types to the whitelist? [13:34] is that gustavo? [13:35] * didrocks missed that discussion, got some Internet outage for 10 minutes [13:35] yeah, gustavo, but it might be good to ask #security too [13:35] (or less, but time to go to the cave, see nothing happened, coming back…) [13:37] k [13:37] desrt: ricotz: any idea on how to fix the gjs autopkgtest? it's blocking gnome-shell 3.20 from yakkety https://bugzilla.gnome.org/769447 [13:37] Gnome bug 769447 in general "TypeError: o.emit_sig_with_foreign_struct is not a function" [Major,New] [13:37] didrocks, you didn't miss much but I copied it in /msg for you [13:38] thanks seb128! [13:39] jbicha: gjs is not my strong suit, sorry [13:40] yw! [13:41] oh, Laney didn't like my gedit patch ;-) [13:41] desrt: hey, don't want to sound sense, but what exactly is the problem with a dialog asking the user what they want to do with the url? [13:44] desrt: yeah, it's annoying that the tests work fine on my computer… :( [13:47] jbicha, did you try with the lxc thing? [13:49] I used autopkgtest-buildvm-ubuntu-cloud and autopkgtest -- qemu [13:51] let's try autopkgtest-build-lxc [14:17] attente: because, if the system is working properly, the user already expressed their intent [14:18] if i select "Help" from the menu, i don't want to see a dialog asking "Are you sure you want to see the help?" [14:18] "Are you sure you want to allow ______?" dialogs are awful. we need to avoid them as far as it is possible to do so. [14:19] as discussed during the gtk hackfest, the best way to do this is to make the receiving app do something "safe", in response to the incoming request, and that's the nature of what we're debating here [14:19] for opening help, the safe thing is opening help [14:20] for joining a video chat or capturing an image, though, a better example would be to open a "adjust your hair" screen or so, giving the user a chance to either proceed or cancel, before anything actually happens [14:23] desrt, that regex patch fixes the test with .39 (and they still work with .38) [14:25] cool! [14:26] attente: we have to perform an interesting trick... we have to assume that the apps that the user are using are malicious, without revealing to the user that we think this... [14:27] If the next step is obvious and costless and not sensitive to time, just do it and make it easy for the user to back out when they decide. [14:27] from the user's point of view, everything should flow just as well as it did before... if they start being asked "are you sure that this thing that you did is what you really want to do?" then they are going to start feeling that the experience isn't as smooth as it was before [14:28] so we need to find ways to turn "are you sure you want to do that thing you told me to do?" type questions into "...and in what way do you want me to do that for you?" type questions [14:28] (always being careful to put a convenient "no. i don't want this at all!" button there) === jdstrand_ is now known as jdstrand [14:30] isn't there some assumption that snaps are confined because they could potentially be dangerous? [14:32] from our point of view, of course we have to think about that [14:32] but the user shouldn't have to [14:33] when i click on a link in telegram i don't want to think about the interaction as a potentially dangerous exchange between two mutually-untrusting agents [14:33] i just want the link to open... [14:34] ditto for when i tell meetup that i want to select a new profile picture from my photo album [14:34] "this app might be attacking me" is the farthest thing from my mind at that point, because i just told it, please _take_ this picture [14:36]