I sort of think this command is bad enough from a "pure" security perspective that it shouldn't come upstream -- the only "legitimate" use is getting around VPNs, which defeats some of the point of having a VPN. We could possibly bring the transaction support upstream (which I think is fine) and say "drop the command in as an extension if it's politically expedient".

I'm not really sure how to balance this. This is pretty clearly never the right technical fix, I think. I think a better technical fix is available for any conceivable ruleset or set of constraints, even "C-level execs are just too important to deal with VPNs but everyone else has to", which could be implemented with selective account-level access permissions. And stuff like "read-only access is fine off VPN" or "no access to Diffusion off-VPN" or whatever are also realistic to implement.

But I think this comes out of an internal struggle between IT (who own the VPN / corporate network but either don't have the skillset to make them work well or maybe it's actually impossible to implement a good VPN for some legitimately hard technical reason) with Legal/Security backing them up, and everyone else who hates the VPN and just wants to get around it, and ultimately can easily do so with proxies/"!history"/etc, and IT is more or less powerless to stop any of this.

Ideally, I think an organization should either take the VPN seriously or not implement it (which I think is completely reasonable given the cost and hassle that VPNs impose, and the ease and frequency with which users punch holes in them); and important execs should bear a greater security burden than everyone else, not a lesser one. But none of this can realistically be changed either politically or technically.

So I kind of lean toward providing "!history" support but not shipping the command, and maybe putting it in some "subversive extensions for getting around your org's dumb badly thought out policies which you can't fix" extension that we discourage in a "sometimes this is the lesser of several evils" way after T5055.

One VPN anecdote is that Facebook's guest WiFi network was on corpnet for a long time (maybe the entire time we were at 1601 California?) so anyone could park in the parking lot, connect to guest WiFi, and hit production hosts directly. Maybe this is still better than nothing, but pretty much the entirety of my personal experience with VPNs is broadly consistent with a relatively extreme framing like "VPNs are mostly security theater that harm employees more than they discourage attackers".

I'm not sure I see the underlying security concern (assuming we respect the "must encrypt" flag). If the policy settings allow the user to view the content, and we already send content via email all the time, what's the risk in sending all the content at once on demand? Using !history as an attack seems like a slightly streamlined version of "create a herald rule that adds me, a nefarious exfiltrator, as a subscriber to every task that gets created", or just making a bunch of Conduit calls to fetch every visible object's transaction history. We already have lots of tooling in place to support "browserless" workflows, and this just feels like another convenience for users who like to organize their lives around their email clients.

How would you feel about this feature if the request never mentioned VPNs, and came in as "George R. R. Martin wants to interact with his publisher's Maniphest tasks on his computer, but he doesn't have access to a web browser"? I think the whole "sneaking around the VPN" issue is secondary to just fleshing out the "all email, all the time" product experience.

Even if you want to focus on the VPN issue, I have a little more sympathy for users stuck with mobile VPN clients, which tend to exist in a significantly deeper circle of hell than their desktop counterparts. I also think that installs that are actually worried about exfiltration via email already have the "must encrypt" flag to force their users to go through whatever browser/VPN hoops they see fit.

In D19372#238553, @epriestley wrote:

One VPN anecdote is that Facebook's guest WiFi network was on corpnet for a long time (maybe the entire time we were at 1601 California?) so anyone could park in the parking lot, connect to guest WiFi, and hit production hosts directly.

As an ex-SRE at Facebook, I can assure you that this state of affairs (which I don't recall ever existing) couldn't possibly have existed for very long. Also, production hosts weren't even accessible from corpnet: you needed to go through a dev instance or a jump host. And if I recall correctly, at some point corpnet access was locked down via 802.1x certificates, which made it impossible to just give someone the corpnet WiFi password.

Maybe this is still better than nothing, but pretty much the entirety of my personal experience with VPNs is broadly consistent with a relatively extreme framing like "VPNs are mostly security theater that harm employees more than they discourage attackers".

To get a little more philosophical, my objection to VPNs is that they encourage the lazy deployment of 3rd party software. Instead of exhaustively auditing something for attack surface, ops can just spin up a server and not worry about it, "because it's behind the VPN." Of course, it's also an extreme framing to say "no one should ever deploy internal software that they wouldn't want exposed to the public internet", so using a VPN boils down to a tradeoff between security in the abstract and practicality in finishing the weekly sprint. To make another example out of Facebook, I can't find the link, but there was a story in the last few years about an internal FB travel reimbursement portal or something that had a remote execution vulnerability and was able to connect to production. I'd easily believe someone deployed that thing assuming it was protected by some level of network access control, and a "no VPN" policy might have made them think twice before standing up that service.

Anyway this is not a hill I'm ready to die on; I just want to make sure I understand where your security concerns are coming from, since if I was handling this support request I would have implemented it without a second thought.

How would you feel about this feature if the request never mentioned VPNs, and came in as "George R. R. Martin wants to interact with his publisher's Maniphest tasks on his computer, but he doesn't have access to a web browser"?

Generally, "no". This already comes up sometimes, mostly in the context of "our users like mailing lists, so can you make the email have a lot more information in it, like the entire comment thread for every inline?". PHI143 is one recent-ish example.

We have a lot of features to make email more useful, but I try to focus on making email more useful as email, not as a replacement for the web workflow.

The "perfect" implementation which some of these requests are asking for is basically for us to take a screenshot of the webpage and email it to you every time. This is better in two concrete ways that I'm aware of:

1. If you don't have a reliable connection to the internet, you can download your email and then go through it offline (although you can't leave comments, grab the patches, etc).
2. It makes it easy to bypass VPNs.

It's also better in some ephemeral ways which I think mostly amount to "users don't like new things". I'm sympathetic to this since I also hate new things, but I don't think we're asking too much to expect users to be comfortable visiting a web page in 2018.

(The webpage is better than the email screenshot in approximately 9 million billion ways, one of which is that it takes us zero additional work to implement.)

On (1), I basically think this just isn't worth building for. US tech employees can get access pretty much anywhere via mobile tether at a reasonable price nowadays. If you're a student trying to contribute to an open source project and commuting to University in the rural Czech Republic on a tandem bicycle or riding a cow or something then maybe there's no realistic way to get an uplink, but this certainly isn't our core market. There may be some things we can do to improve Phabricator's behavior on spotty/unreliable uplinks which makes cost/benefit sense, but I think the world is generally moving toward ubiquitous connectivity and this isn't a super valuable long-term project. If we really wanted to push offline access, we'd probably be better off building a desktop app.

On (2), great, but I'm not sure if we should be shipping a feature which only works to subvert security policies.

I think I'd generally agree that this isn't a big deal if there was a pretty good "legitimate" reason for this feature to exist (e.g., Trump watches Ready Player One and then shuts down the internet on Tuesdays and Thursdays, so offline access becomes way more important) and the feature also happened to enable some subversive VPN bypassing. But my gut is that 99%+ of the time someone uses !history, it will be to bypass VPN restrictions, and that this feature is effectively only a VPN bypass feature. There's also basically no world in which replying !history and then waiting for Phabricator to email you back is ever better than clicking the huge button in the header to instantly load the page, I think, unless you're trying to bypass a VPN? So maybe this is more like 100% of the time than 99% of the time.

I don't think this particular bypass is even necessarily bad (although it amounts to full read access and mixed read/write access to everything the user can access on the install with some less-secure combinations of metamta.one-mail-per-recipient, metamta.insecure-auth-with-reply-to, and metamta.public-replies), but it clearly subverts the policy, which is "no access to this resource from off the VPN". If the desired policy is "access to Maniphest is OK off the VPN", or "access to everything is OK off the VPN", it would be better to just implement that policy in Phabricator/the VPN and moot this by letting the links in the email work.

Maybe a point of comparison is a hypothetical !browse <url>, which takes a screenshot of that URL (Phabricator URLs only) and emails it to you.

This feature has no conceivable purpose except bypassing VPNs (no reasonable user would prefer it over clicking a link), and essentially makes Phabricator un-VPN'able by building in a VPN-subverting feature.

This might be a net positive for some users, but I don't think it's a feature we should ship with and enable by default.

I think !history is much closer to !browse than it is to other email commands like !claim, !subscribe @user, !project, etc., which have a mixture of good user-facing and bot-facing use cases even if they're sometimes effectively used as a VPN bypass.

The more extreme version of this would be to make Phabricator tunnel out of the VPN by default and give every install an automatic proxy on the public internet at your.full.domain.vpn-bypass.phacility.com. This is obviously a feature we shouldn't build or ship, but I I think the scale is something like:

SUBVERSIVE FEATURES THAT ARE
PURELY FOR BYPASSING VPNS

 * <-- Automatic Public Tunnel
 | 
 * <-- !browse
 |
 * <-- !history
 |
 |
 |
 .
 . <-- a vast distance
 .
 |
 |
 |
 * <-- !accept (Which is configurable and off by default!)
 |
 * <-- !claim, !subscribe, etc.
 |
 * <-- Email notifications

REASONABLE FEATURES WITH
VARIED USE CASES WHICH CAN
ALSO BYPASS VPNS

So the current bar is somewhere between !accept and all other email actions (where !accept is part of the upstream, but off by default and must be configured to enable it) and I think !history is way at the other end of the range.

I'd also be sort of OK with shipping this off-by-default with a config option, but I really hate adding upstream options (T8227) and am optimistic about "install extensions" representing a better approach for managing this kind of niche stuff after T5055.