14:59:06 <pili> #startmeeting S27 03/03
14:59:06 <MeetBot> Meeting started Tue Mar  3 14:59:06 2020 UTC.  The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:06 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:13 <asn> hello!!!
14:59:16 <brade> o/
14:59:18 <pili> hello hello
14:59:21 <mcs> hi
14:59:23 <pili> who else is around today? :)
14:59:39 <T0_7_> hello pili, nice meeting up again
14:59:39 <pili> here's the pad while everyone else shows up: https://pad.riseup.net/p/s27-meeting-keep
14:59:44 <acat> hi
14:59:51 <antonela> h
14:59:52 <antonela> i
14:59:54 <sysrqb> o/
15:00:01 <pili> please add your updates :)
15:06:00 <pili> ok
15:06:12 <pili> let's get started
15:06:25 <pili> I'll move my discussion point until the end
15:06:27 <asn> oh we reapplied to learning lab? :)
15:07:04 <pili> asn: yeah, I did
15:07:05 <pili> this will be a smaller thing
15:07:06 <pili> more like a blog post
15:07:16 <asn> i see
15:07:17 <pili> they were offering help to showcase our work here, so we'll see how that goes :)
15:08:17 <pili> asn: I think the first discussion point is yours?
15:08:26 * antonela added jenn's questions so we can talk about each of them together
15:08:28 <asn> yes
15:08:38 <asn> i mainly have thoughts about (1)
15:08:56 <asn> i think so far we've been commiting to .tor.onion as our pseudo-tld
15:09:08 <asn> i wanted to make sure that we all think it's a sensible thing to do
15:09:26 <asn> im mostly worried that if in the future we find the best superior name system, and we have already used .tor.onion for HTTPS-E
15:09:31 <asn> we wont be able to use it for the best superior system
15:09:33 <asn> perhaps
15:09:50 <pili> what are the alternatives? .tor?
15:10:14 <asn> people dont like .tor because it's not an official tld, and if people try to use it with chrome it will leak to the DNS servers
15:10:23 <asn> so securedrop people were not comfortable with it at all
15:10:27 <antonela> but .tor can be an official tld
15:10:27 <pili> ok
15:10:37 <asn> antonela: it could, but we would need lobbying work
15:10:48 <antonela> yes
15:10:51 <asn> people have said that it's gonna be quite hard to get it
15:10:55 <asn> but we havent really tried yet
15:10:58 <antonela> yes
15:10:59 <antonela> yes
15:11:05 <antonela> we can have whatever we want in .tor, now is https-e but in the future could be another resolver tech stack
15:11:17 <asn> right
15:11:20 <asn> u mean .tor.onion?
15:11:21 <asn> or .tor?
15:11:33 <antonela> and the medium term plan could be making .tor a tld
15:11:40 <asn> right
15:11:41 <pili> so, another way of looking at it, why do we think .tor.onion is not the best?
15:11:52 <antonela> well, everything can be better pili
15:11:57 <asn> .tor.onion is the best pseudo-tld we have given the constraints of the problem
15:12:08 <mcs> The problem I see is that if we encourgage use of foo.tor.onion then users will expect foo.tor.onion to always take them to the same foo.
15:12:26 <mcs> and if we switch to a different name provider that may not be true
15:12:46 <mcs> but I am not sure how to avoid this problem
15:12:49 <asn> right, or even if we allow custom rulesets in https-e
15:12:55 <asn> then the naming won't be global
15:13:04 <pili> well, if people want to use namecoin they'd be using .bit for example
15:13:08 <pili> seems to me like the name depends on the mechanism you're using
15:13:15 <antonela> i really dream with a blogpost that says: "Now, Tor Browser gives you .onion domains that you can remember. Read about .tor"
15:13:20 <mcs> maybe we need to make it clear that this experiment is not a global name system
15:13:24 <pili> so I don't see the problem of coupling .tor.onion to HTTPSE
15:13:42 <asn> syverson_: sysrqb: thoughts?
15:13:46 <sysrqb> with the current situation, we are only adding name mappings for domains we know will be stable
15:14:00 <pili> I don't see how you can have global naming without centralization :)
15:14:03 <sysrqb> there should never be a conflict with nytimes.com.tor.onion
15:14:03 <antonela> and that is the point of jenn's question: should we say news outlets to publish this name? is something we can see running in the medium/long term?
15:14:09 <pili> happy to be educated though :)
15:14:23 <sysrqb> regardless of moving to another naming scheme/system
15:14:30 <syverson_> Trying to formulate any answer that is short and responsive.
15:15:04 <pili> hey syverson_ good to have you here
15:15:23 <sysrqb> pili: yes, we must have centralization *somewhere*
15:15:33 <syverson_> This definitely sounds like a shortterm stopgap suggestion IMO, which seem consistent with the goals of S27.
15:15:52 <sysrqb> and if we use the current dns as that centralization/conflict resolution then we should never a problem
15:16:27 <syverson_> By dns, you mean the naming not the lookup, yes?
15:16:59 <sysrqb> especially because securedrop would scope these names within the company's existing dns name
15:17:02 <sysrqb> syverson_: yes
15:17:04 <pili> I think part of the problem with trying to make these decisions is that we're still only experimenting and this is only a proof of concept
15:17:05 <sysrqb> sorry, that wasn't clear
15:17:49 <asn> syverson_: what is securedrops suggested naming scheme?
15:17:54 <asn> like what did jenn make in the ruleset?
15:17:57 <syverson_> pili: True. But our intended experiment is completely backwards compatible.
15:17:59 <asn> is it nytimes.com.tor.onion ?
15:18:13 <antonela> pili: true, but we can reach stable with this
15:18:15 <asn> or nytimes.securedrop.tor.onion ?
15:19:35 <asn> "from":"^https://www\\.2600\\.com\\.securedrop\\.onion","to":"http://lxa4rh3xy2s7cvfy.onion"
15:19:47 <asn> www.2600.com.securedrop.onion -> http://lxa4rh3xy2s7cvfy.onion
15:19:53 <asn> there you have it
15:20:20 <asn> she didnt use .tor.onion i think
15:20:21 <antonela> i dont think nytimes.com.tor.onion is a real escenario if we have headers working properly and/or becoming standard
15:20:29 <syverson_> asn: no lxa4rh3xy2s7cvfy.onion.securedrop.com
15:20:59 <sysrqb> https://github.com/redshiftzero/securedrop-httpse/blob/master/rulesets/2600-hacker-quarterly-securedrop-ruleset.xml
15:21:28 <syverson_> or securedrop.onion/?onion=lxa4rh3xy2s7cvfy
15:21:29 <sysrqb> <ruleset name="2600: The Hacker Quarterly">
15:21:29 <sysrqb> <target host="www.2600.com.securedrop.tor.onion" />
15:21:29 <sysrqb> <rule from="^http[s]?://www.2600.com.securedrop.tor.onion"
15:21:29 <sysrqb> to="http://lxa4rh3xy2s7cvfy.onion" />
15:21:29 <acat> asn: i thinks he did use .tor.onion, did you check https://redshiftzero.github.io/securedrop-httpse/default.rulesets.1582940785.gz?
15:21:30 <sysrqb> </ruleset>
15:21:35 <acat> *she
15:21:41 <asn> syverson_: ah thanks for this
15:21:57 <asn> acat: hmm perhaps i checked the wrong thing. i just gunzipped default.rulesets.1567398063 and lessed it
15:22:03 <asn> from here https://redshiftzero.github.io/securedrop-httpse/
15:22:06 <syverson_> arggh securedrop.com/?onion=lxa4rh3xy2s7cvfy
15:22:15 <sysrqb> this seems fine to me
15:22:26 <sysrqb> she even uses the securedrop.tor.onion namespace
15:22:30 <asn> right i like that
15:22:35 <asn> i like the namespacing
15:22:43 <asn> it's important!
15:22:49 <sysrqb> :)
15:22:50 <antonela> is the core idea of all this
15:23:14 <asn> ok so we all think this is worth and not destructive enough to go forward?
15:23:18 <pili> +1
15:23:21 <asn> with das experiment?
15:23:22 <acat> with the current rules only www.nytimes.com.securedrop.tor.onion will work (not nytimes.com.securedrop.tor.onion)
15:23:37 <sysrqb> yeah, i was (kinda) expecting securedrop.2600.com.tor.onion
15:23:44 <sysrqb> but i like her scoping more
15:23:56 <asn> acat: but that's a "bug" not a design issue, right?
15:24:21 <sysrqb> acat: yeah, i think that should be changed
15:24:25 <acat> yeah, not sure if she did it for some reason, but i guess it can be changed
15:24:26 <kushal> asn, bug as in missing for without www. part?
15:24:27 <antonela> do we need the .com?
15:24:37 <asn> kushal: o/
15:24:44 <sysrqb> antonela: yeah
15:24:45 <asn> kushal: yeah that perhaps it would be preferable to omit the www
15:24:53 <asn> but perhaps that's up to how securedrop do their UX analysis
15:24:56 <sysrqb> antonela: because of jen's example of ABC
15:25:05 <kushal> asn, understood, I think it is more as in the example.
15:25:06 <sysrqb> there are many organizations named ABC
15:25:10 <asn> kushal: right
15:25:35 <antonela> mmmm
15:26:51 <mcs> how does this work with multiple rulesets? does the securedrop ruleset only allow names under securedrop.tor.onion or could it have a rule for nytimes.tor.onion?
15:27:15 <kushal> mcs, only for securedrop.tor.onion ruleset
15:27:17 <sysrqb> it depends on how the ruleset is added
15:27:58 <mcs> I think limiting the scope for now is better for this experiment
15:28:02 <asn> agreed
15:28:12 <kushal> yes.
15:28:15 <asn> iiuc, the rulesets we add as tor browser will have a very specific scope
15:28:20 <syverson_> Yes. an added ruleset is completely trusted and a singlepoint.
15:28:21 <asn> now if we ever do custom rulesets, we will need to think how to do that
15:28:53 <mcs> I assume conflicts are resolved in a sane way, e.g., the rulesets must be ordered
15:29:13 <sysrqb> err. i wouldn't bet my life on that
15:29:32 <asn> :p
15:29:41 <syverson_> There is nothing current to make that so, AFAIK.
15:29:54 <sysrqb> but we would add this update channel with only scope of *.securedrop.tor.onion
15:30:26 <antonela> so, we take care about the trusted name space and the .tor and the .onion
15:30:36 <sysrqb> hrm
15:30:46 <sysrqb> i wonder if we can exclude this scope from the eff's update channel
15:30:46 <syverson_> sysrqb: what governs scoping?
15:31:03 <sysrqb> when you add an update channel the scope may be specified
15:31:15 <sysrqb> and then https-e filters rules based on that
15:31:18 <sysrqb> (based on my understanding)
15:31:23 <sysrqb> acat: do you remember more details?
15:31:30 <acat> yes, that's also my understanding :)
15:31:37 * antonela phew :)
15:31:50 <sysrqb> oh good :)
15:31:59 <asn> and the scope is specified locally right? it's not like the eff update channel can change its scope online, or something
15:32:13 <sysrqb> correct
15:32:16 <asn> or the securedrop update channel can override its scope
15:32:16 <asn> ok
15:32:32 <asn> and does the eff update channel have a scope right now? or its wildcard? that is, it can write on top of our rules?
15:32:39 <sysrqb> we'd need to set the scope when we compile the browser, somehow
15:32:45 <sysrqb> i don't know how we do that, yet
15:32:47 <asn> ack
15:32:57 <syverson_> How does the interface notify the user if a channel changes its scope?
15:32:58 <sysrqb> asn: i think it does not have a scope
15:33:00 <sysrqb> so *.*
15:33:05 <asn> fun
15:33:19 <sysrqb> syverson_: i have no idea
15:33:34 <syverson_> That could be an issue.
15:33:38 <sysrqb> maybe it doesn't, but the extension simply ignores entries
15:33:39 <asn> are we concerned about this? i remember in stockholm we were saying that perhaps update channels should be restricted onion-only or https-only, so that the eff update channel cannot rewrite our rules
15:33:58 <asn> concerned about the *.* i mean
15:34:45 <syverson_> sysrqb: you mean unless the user takes an action to accept the scope change?
15:34:50 <asn> we can also move on from this topic :)
15:34:58 <syverson_> asn: +1
15:35:06 <sysrqb> syverson_: ah, yes
15:35:16 <sysrqb> or adjusts the configured scope
15:35:26 <sysrqb> but i don't know if this information is presented to the user
15:35:28 <pili> ok, can we confirm what we have decided then? :)
15:35:32 <pili> if we're going to move on
15:35:35 <sysrqb> we should investigate this :)
15:35:54 <antonela> short comment, i dont think user needs to take action on accept the scope change - we don't have a ui for custom rulesets nor we are exposing this to users
15:36:01 <pili> I think regarding question (1) we can confirm to jen about .tor.onion, correct?
15:36:31 <asn> pili: yes thats my understanding!
15:36:48 <antonela> yes, and that move us to the next question
15:37:04 <pili> ok, everyone ok with moving on to question 2?
15:37:21 <sysrqb> sure :)
15:37:26 <pili> ok, for (2) this is a very good question and something we need to discuss today and agree on soon
15:37:43 <pili> (if not today... ;P )
15:37:46 <antonela> i hope we can reach stable with this
15:38:59 <sysrqb> i expect this will reach the stable release
15:39:22 <antonela> glad my hopes and your expectations are aligned sysrqb
15:39:23 <sysrqb> but only with limited name mappings
15:39:28 <mcs> I think we should treat it as an experiment for a while and not be in a hurry to take it to the stable release.
15:39:49 <mcs> But I am not sure how to evaluate success if we only release in alpha
15:39:51 <sysrqb> this will not be in the 9.5 stable release
15:40:05 <sysrqb> mcs: yes, i agree
15:40:10 <mcs> post-9.5 seems OK to me.
15:40:17 <pili> ok, so we're aiming for 10.0 stable then
15:40:28 <mcs> Jenn wants to know for server load purposes, right?
15:40:28 <antonela> so, the plan is go alpha for 9.5 and then X will be stable
15:40:41 <asn> what does this mean in terms of timing, if i may ask?
15:40:46 <sysrqb> hmmm
15:40:47 <asn> like in terms of human months
15:40:58 <sysrqb> asn: yeah, that is the question
15:41:03 <antonela> 9.5 june, X end of the year?
15:41:13 <sysrqb> because with our migration to the rapid releases
15:41:31 <sysrqb> our stable/alpha/nightly channels will be very different
15:41:45 <sysrqb> we can let this bake on alpha (beta?) for a while
15:41:55 <sysrqb> whatever we end up calling it
15:42:10 <sysrqb> and we can consider releasing it in stable later this year
15:42:35 <sysrqb> but if we want more UI/UX changes, like the .onion to .tor.onion mapping
15:42:40 <sysrqb> and Learn More link
15:42:45 <sysrqb> which require browser changes
15:43:02 <antonela> oh
15:43:03 <sysrqb> then this is not something we can release in the next few months
15:43:03 <pili> I have 9.5 stable due mid April, so we could release on 10.0a1 then?
15:43:31 <pili> I mean, we don't have to do it then, but that's what we had discussed for 9.5 stable previously :)
15:43:39 <pili> (which can change also)
15:43:46 <antonela> right
15:43:46 <sysrqb> yeah
15:43:49 <dgoulet> "release early release often" ? :D
15:43:51 <asn> if this requires more browser changes we hope that these are gonna happen outside of s27?
15:43:53 <sysrqb> we can keep this as alpha-only for a while
15:44:04 <sysrqb> asn:  yes
15:44:13 <asn> i would love this feature to be out on alphas soon so that people can try it out. i think it's a kick ass feature.
15:44:22 <sysrqb> dgoulet: only if the feature is ready :)
15:44:47 <sysrqb> but yes, i would like this to be in an alpha release soon
15:44:53 <antonela> releasing in alpha is a not public release
15:44:59 <asn> are we afraid that because more work needs to happen out of s27 this will go stale when s27 ends?
15:45:09 <pili> ok, so to answer jen, we can tell her it will be in an alpha around mid april?
15:45:32 <antonela> i mean, the main question from trusted parties is: should nytimes make this url public?
15:45:32 <pili> asn: I don't think so, it may need to wait until after june though
15:45:48 <antonela> if we release in alpha, that doesn't make sense
15:45:59 <asn> right
15:46:12 <asn> if we release only in alpha they cant make that url public, until it gets to stable
15:46:21 <asn> beacuse we need to assume that all users have access to the feature
15:47:10 <sysrqb> this depends on when a version of https-e is released with the modifications we need
15:47:31 <sysrqb> hrm!
15:47:36 <pili> what are the risks with releasing this with 9.5 stable?
15:47:39 <sysrqb> hmm
15:47:48 <pili> I understand we don't want to rush things
15:47:52 <sysrqb> htis is an https-e only features right now
15:48:02 <pili> do we have any specific issues in mind though?
15:48:03 <sysrqb> so when stable picks up the version that includes this functionality
15:48:13 <sysrqb> we can't control whether it is available on stbale
15:48:16 <sysrqb> stable
15:48:39 <sysrqb> we should think about this
15:48:44 <sysrqb> i don't want this in stable immediately
15:49:03 <sysrqb> acat: can we pref this? somehow?
15:49:03 <pili> ok, so the issue is the dependency on httpse? :)
15:49:06 <pili> I wouldn't want it to go straight to stable either
15:49:26 <sysrqb> pili: yes, dependency on https-e
15:49:36 <pili> maybe we can think about what's the next alpha we could get it in and see how much time that gives us for testing it out before it will make it to stable?
15:49:41 <sysrqb> and how comfortable we are with it, after some testing
15:49:41 <antonela> well, but this was something we already knew
15:50:02 <mcs> I thought acat’s patches do not require a new HTTPS-E (but maybe I am confused)
15:50:15 <acat> sysrqb: ok, i can revise the patch to put it behind a pref
15:50:29 <acat> mcs: correct, they do not
15:50:36 <sysrqb> oh
15:50:42 <asn> hehe
15:50:44 <sysrqb> then i am confused. one moment
15:50:53 * asn gives sysrqb a moment
15:51:04 <pili> another way to look at it is, is it worth delaying 9.5 stable a month or so to give us more time to get confident with this in alpha?
15:51:08 <pili> what was the issue that legind created in httpse then? :S
15:51:25 * pili needs a moment to double check her email also :P
15:51:32 <acat> pili: that's to implement .onion -> .tor.onion urlbar rewrites
15:51:40 <pili> thanks acat
15:51:49 <sysrqb> okay, i see
15:52:19 <sysrqb> i was confused. good.
15:52:39 <sysrqb> we can get this into an alpha this month
15:52:52 <sysrqb> but we probably won't include it in 9.5-stable
15:53:04 <pili> ok
15:53:13 <antonela> :S
15:53:31 <sysrqb> we can discuss when it will be included in a stable release
15:53:37 <antonela> maybe we need a to-do list to make it stable before anything
15:53:39 <sysrqb> most likely after the migration
15:53:48 <pili> ok, let's move that discussion to email possibly
15:53:58 <pili> we have 5 minutes and 1 more question to answer :)
15:54:03 <sysrqb> antonela: yes, we should decide what a "stable" version looks like
15:54:05 <pili> (and another discussion item)
15:54:15 <antonela> sysrqb: i thought we were in that phase now :(
15:54:29 <pili> I will start a thread after this meeting
15:54:47 <sysrqb> antonela: let's discuss
15:54:57 <antonela> yep
15:55:14 <pili> ok, question 3- I guess is asking about when this would make it to android
15:55:31 <pili> which would not happen until after fenix migration
15:55:55 <sysrqb> i wonder how the https-e ruleset will interact with tor browser on android without the other UI changes
15:55:55 <pili> so we're looking at mid- late 2020?
15:56:27 <sysrqb> i guess the .tor.onoin will be rewirtten to the .onion?
15:56:32 <antonela> the interesting thing about the chromium client is that brave already ships https-e
15:56:38 <mcs> acat: any thoughts about Android support? will some things “just work?"
15:56:51 <antonela> so browsers shipping https-e and tor can get this feature like automagically
15:57:05 <sysrqb> pili: yeah, probably late 2020?
15:57:11 <pili> ok
15:57:12 <sysrqb> hard to know now, really
15:57:12 <acat> mcs: we would have to implement it for Fenix I guess, although we could share some parts of it
15:57:19 <sysrqb> pili: definitely after the fenix migration
15:57:28 <syverson_> sysrqb: right, i was confused by acat's earlier saying the rewrite was in the other direction.
15:57:50 <mcs> acat: thanks; sounds like a post-fenix thing then as sysrqb said
15:57:54 <acat> mcs: ideally just the changes in browser.js would have to be ported to Fenix
15:58:33 <acat> but who knows, as i also had to change some copy-paste logic
15:59:09 <sysrqb> syverson_: we are considering both directions
15:59:19 <syverson_> ?
15:59:58 <syverson_> sysrqb: maybe you can explain to me later today.
15:59:58 <sysrqb> but i assume if the ruleset is used as-is on android, then the url will be rewritten to the .onion
15:59:59 <pili> (we're at the hour, I don't think there's anyone in here next so we can continue the discussion for a short while)
16:00:04 <sysrqb> acat: does that make sense?
16:00:10 <pili> I will need to drop in about ~15 minutes though :)
16:00:27 <sysrqb> acat: without the browser changes? only applying the ruleset
16:00:31 <sysrqb> syverson_: sure
16:00:53 <acat> sysrqb: ah yes yes, sorry i misunderstood
16:00:56 <acat> you're right
16:01:22 <sysrqb> okay, cool. good, good
16:01:30 <pili> I think we have answered question 3 from jen in any case :)
16:01:33 <sysrqb> i think we can wrap up this meeting
16:01:49 <pili> asn: did you want to briefly discuss community portal updates?
16:01:56 <pili> for onion services section?
16:01:57 <antonela> whoever replies jenn please add sysrqb to the thread
16:01:59 <asn> nah it's fine
16:02:01 <asn> nothign important there
16:02:04 <asn> let's keep it for next week
16:02:09 <pili> ok, we'll defer to next week
16:02:12 <pili> thanks everyone!
16:02:15 <mcs> thx
16:02:15 <antonela> thanks!
16:02:22 <pili> #endmeeting