Sure we can build a new Internet. Where are the long-haul links that connect cities going to come from, though? Let alone the intercontinental links. Or local distribution when you want aggregate bandwidth greater than WiFi provides? The logistical problems with those things are what the current control issues stem from.
And do we really need a new Internet? IPv6 itself seems pretty sane, and it's possible to build new protocols on top of it (in fact if you look for a file named "protocols" (even Windows machines have it) you'll find tons of them listed). Or even just start building application protocols that require the use of IPSec encryption/authentication.
Completely redo your infrastructure? Dude, we're not talking about Windows here. If you upgrade servers from something as old as 14.04 up to 17.04 (most current release available) you'll need to change approximately 0% of your configuration. You'll want to update a lot of it to take advantage of new features available, but you do that sort of thing over time if you've any sense at all. You don't even upgrade every machine in one session, you upgrade them in groups so the downtime won't shut down your business. This ain't rocket science, rolling upgrades have been SOP everywhere except in Redmond since the late 60s.
If you decided to run a business based on a short-lived release that was stated to be such (eg. 16.10), then I'd argue that you are a kindergarten. You should've based it on one of the LTS releases like 14.04 (supported until 4/2019) or 16.04 (supported until 4/2021). But then you aren't running a business, you're just a troll.
And yet the creditors here would cheerfully argue (and have argued) that contracts entered into in good faith aren't enforceable because they were verbal and the debtor can't show any proof they existed, when that contract consisted of the creditor's rep giving assurances to the debtor about leniency. You and they can't have it both ways. The big financial institutions have been at the forefront of advocating that if you can't produce a signed written agreement then it didn't happen and isn't legally enforceable, well the individual debtor's equally entitled to demand the same standard apply when it goes the other direction.
Figuring out how to solve traffic congestion, that's the easy part. There's lots of ways, mostly in two categories: reducing the volume of traffic needed to move a given number of people, and optimizing the flow of traffic.
The hard part is getting people to actually let the solutions do their job. Everyone wants better traffic flow, but they don't want to change their own driving patterns to ones that optimize traffic flow (especially if it means giving up even a second's advantage over anyone else).
I've never had a problem with credit cards used for online payments. Sure, they'll get compromised, but half the times my cards were compromised it was through brick-and-mortar merchants whose point-of-sale systems were compromised so online use doesn't look to be any more risky that in-person use. Just make sure to check the charges daily (I use a finance program that automatically downloads new charges every morning, plus it gives an alert on the first charge by a new merchant which is convenient). Consumer protection laws in the US keep you from being liable for pretty much all unauthorized activity (at worst you're on the hook for the first $50).
Just don't trust debit cards online, except if they're tied to a bank account that's funded only as needed and doesn't have excess money in it to be absconded with.
If you have any such URLs, the problem is that they exist. If they shouldn't be accessible from outside your network then they should either require authentication restricted to your network or the perimeter firewall should block access to that host from outside. If there's sensitive information in the URL itself, there shouldn't be. URLs can leak too easily (eg. in Referer headers) to be considered safe for confidential/sensitive bits of information.
I'm not surprised, because I've occasionally gotten a look at the resumes and candidates who didn't get to the hiring manager (discarded by HR as not meeting the qualifications). I've found more better-qualified candidates in the discard pile than in the list we got to do phone interviews with, and the consistent pattern is that the HR screening systems put too much emphasis on strong matches with too-specific keywords and not enough emphasis on "knows the subject and has a proven ability to learn the tools". Even with the improvements in AI and expert systems, the screening's still subject to the same old problems.
Software courses are in my book really field-specific. If you're doing operating-system development or embedded-hardware programming then the classes are useful, but outside of those fields that kind of course isn't really helpful and the university computer-science and computer-engineering programs seem to deliberately avoid teaching the things that are useful (eg. how to understand and use standard frameworks (not a specific framework either, the concepts needed to pick up any framework and work with it), how to figure out which design patterns are most applicable and when you're dealing with an anti-pattern that has to be removed, the common idioms in different categories of software architectures, that sort of thing).
It's sad that after 35 years at this I'm still seeing the same malfunctions and watching the same kind of job-shop schmo mishandle things in the same old ways. WiPro or Andersen, plus ça change...
And you set yourself up here. Take your "alicebob" password example. If you allow all-lower-case passwords an attacker trying concatenations of obvious words needs to try 4 possibilities to crack that password. OTOH if he knows you prohibit all-lower-case he only needs to try 3 since "alicebob" is illegal. You've just decreased the amount of time he needs by 25. That's significant. The fact that "alicebob" couldn't be used as a password is exactly why the attack is faster, it's a vulnerability and not a feature.
As far as passwords being replaced by "something better", I doubt there's anything better for the obvious reasons (eg. biometrics are unchangeable if breached and even more predictable than passwords since there's (in theory) only one possibility for a given user and knowing the user an attacker can determine what that sole possibility is). We'd be better-off sticking with passwords and looking at ways to remove the need to commit them to fallible human memory and enter them in error-prone ways like typing, which are probably the two greatest contributors to password vulnerability. #3 is very probably transmitting the password itself over the connection in order for the remote end to validate it, and we've had the methods to eliminate that for decades (all browsers support challenge-response authentication for instance, the only reason it wasn't used was because of IE6's brain-dead rules about which method to use if more than one was available).
Hello ActiveX, its been a while! And you never had any security issues did you, noooo, perfectly safe. Thats why its still around today... err, oh, wait...
Yup. We've been this route before. Not to mention compiling native code for multiple versions of multiple operating systems on multiple CPU architectures. Avoiding that's one of the attractions of browser-based applications. Look, a security and development nightmare in the same package!
Mandatory character classes never increase the search space, they can only decrease it. In your example, if based on your rules I know that all-lower-case passwords aren't legal because they lack a mandatory character class then I can immediately exclude all all-lower-case possibilities from my search. That can only speed up my search for passwords compared to having to check those possibilities even if users aren't using them (as an attacker I don't know if they are or not unless you tell me in your rules that your system won't let them).
It also complicates things for anyone using any password generator because they've got to check their policies and make sure they're using the one that matches your particular set of mandatory character classes. Remember that users don't have to create passwords just for your system, they have to create them for every system they use. The fewer variations they have to deal with, the less likely they are to do something stupid setting up for any particular variation.
Before it hurt them, though, they'd file suit objecting to the penalty. It'd be a decade or more before it all got sorted out, and in the meantime it'd be business as usual for them.
The cable companies in fact can do something about such competition. They gave the municipalities Hobson's Choice: give them monopoly access to the rights-of-way, or do without cable TV. Shopping around doesn't help the municipality, all the big cable companies are demanding the same thing and the smaller ones can't get licenses for the content so they don't have anything to put on the air. I lived through that period, and there really wasn't much the cities could do about it. Now it just gives the telecoms another point of leverage so even if you get officials in place who'll fight they just end up tied up in court trying to break the contracts.
This sort of lawsuit won't do much, even if the state wins. What would do something about the problem is for the state or the municipalities to take the position that the cable companies have breached the contracts that give them monopoly access to public right-of-way for their wiring, then open the access up to other companies under terms that'd prevent any company from blocking or interfering with use by others. That'd still leave some roadblocks, but it'd remove one of the most important ways the telecoms maintain their monopoly position.
This wouldn't involve the ISP, it'd be entirely within the router. The router could access any DNS server, but hosts on the internal side could only access the router's caching DNS server unless the user authorized an exception for them. It wouldn't entirely prevent attacks like this one, but it'd prevent direct attacks and forcing the attacks through multiple levels of caching would blunt the attack to a degree and make it easier to throttle the sources of the malicious requests.
Ultimately, it's the groups that initiated the DDoS who are to blame. But others have to take some responsibility for failing to do what they could to mitigate the opportunities to initiate attacks:
1. ISPs could implement measures based on RFCs 3704 and 2827 that would make spoofed traffic difficult to impossible to generate.
2. Router makers could implement RFC 3704 and 2827 rules in their firewalls by default, could implement default rules that blocked access to external DNS to everything except the router (with the option for the user to allow some or all access), could provide a separate network for IoT devices that defaults to no Internet access and the user has to specifically authorize access per device, and could make randomized default passwords the standard for factory-default configurations.
3. IoT manufacturers could make randomized default passwords standard and design their devices to not require Internet access to configure.
4. Consumers could acknowledge that they're responsible for their own networks and routinely make use of the available tools to check on the health of their networks and the status of the devices on it.
"We can't create a culture that says it cares about diversity and then excludes almost half the country because they back a political candidate," Zuckerberg wrote. "There are many reasons a person might support Trump that do not involve racism, sexism, xenophobia, or accepting sexual assault."
Certainly there are reasons, but that's not the point and not why Project Include won't work with Y Combinator. Support of Trump involves considering sexual assault, racism, sexism and xenophobia to be acceptable. That holds regardless of the reasons you have for supporting him. Project Include is saying "No, those things that Trump loudly and proudly stands for are not acceptable, period. We don't care why you think they're acceptable because we don't believe there's any reason you could give us that could make them acceptable.". And this isn't just the candidate's supporters espousing those positions, it's the candidate himself making his enthusiastic support of those positions the centerpiece of his speeches and campaign.
There'll be plenty of jobs. What there won't be will be employee positions. Companies will increasingly replace employees with robotics and software. Work will shift to self-employment. A contract software engineer will contract with an accountant to handle accounting, with an advertising firm to handle ad placement, with their hosting services to handle routine administration of their servers and so on. An author would contract with someone to screen calls and mail and act as a secretary/receptionist, with someone else to proofread and edit their manuscripts and so on, and would publish directly through distribution channels like Amazon's Kindle Store. A seamstress would contract for advertising services and for janitorial services for the store. Lots of work, but no employees.
My argument in favor of basic income is that starting all of that requires a certain stability. You can't start a contract software consulting business, or start writing full-time, or start a dressmaking store, if you're scrambling to keep food on the table and a roof over your family's head. You can't get a full-time job to cover the bills because those full-time jobs won't exist. So what's the alternative to a basic income if you want people to work? If it's not there they won't be able to afford to spare the concentrated effort needed to get a successful business off the ground, it'll all be sucked up by the scramble to get enough cash this week to buy groceries. If they put in the effort, their family'll be out on the streets and starving in the time it takes for the effort to start producing results.
There's no one single way, but there are several much more useful ways such that files created through Windows have the expected permissions in Cygwin (user read/write) and files created through Cygwin are accessible in Windows (user can read and write them). There's no excuse for the Linux subsystem not being able to do something reasonable. And yes I've dealt with Cygwin files in Windows and Windows files in Cygwin. It works because Cygwin understands Windows ACLs (see POSIX accounts, permission, and security). Amusingly the mapping system Cygwin uses was based on Microsoft's own mapping system from Services for Unix. So not only does Microsoft have the code for an example of a working method available (Cygwin's code), they wrote the code for a working method (SFU).
So basically MS's Linux subsystem can't even do the job Cygwin does quite nicely? I think MS ought to go and read the code, learn some lessons and carry it back. It's not like you can't translate Unix permissions to Windows' permissions system and vice-versa, the code's even right there to read.
Using a straight hosting service like Linode involves owning your own domain name, controlling the DNS and having your own SMTP and IMAP server running. That's all stuff that isn't specific to Linode, the same setup'll work on any service that offers virtual machine hosting. If Linode disconnects you you can drop your setup onto a host on Rackspace or any other service, update your DNS records to point to the new host's addresses and you're back in business. That's much easier than if you've no control over the domain, the DNS or the server software.
Was the "editing to conceal evidence of illegality" perchance what agent Fitchner described in this statement?
In May 2015, I created another BACKPAGE "Escort" ad with the goal of trying to post an ad containing sexual verbiage indicative of a prostitution ad. I used the words "cum" and "quickie" in the ad, but when I tried to post it, I received a message that told me those words were "forbidden in this category." I had to change the words to "come" and "quick session" in order for the ad to be accepted.
If that's what you're talking about, it's rather a strained reading to interpret rejecting ads that contain language indicating they might be for prostitution with editing those ads.
Would that "editing" be related to this statement by agent Fitchtner?
In May 2015, I created another BACKPAGE "Escort" ad with the goal of trying to post an ad containing sexual verbiage indicative of a prostitution ad. I used the words "cum" and "quickie" in the ad, but when I tried to post it, I received a message that told me those words were "forbidden in this category." I had to change the words to "come" and "quick session" in order for the ad to be accepted.
The statement that indicates that Backpage tries to reject ads containing language indicating they involve prostitution? That one isn't going to fly, Backpage will simply point to precedent that Section 230 explicitly bars holding them liable for the content just because of such blocking. They're also going to point to a long string of demands from law-enforcement agencies that sites do just such blocking.
One advantage of planning for remote work is that it makes it easier to get people on-line and working in an emergency. If production goes down unexpectedly on a weekend, if the company's already set up for remote work they can make phone calls and get engineers on-line and working on the problem in a matter of 5-15 minutes. If the company isn't, engineers are going to have to get dressed and get in to the office before they can even start looking at the problem and that can take a half-hour to an hour (or more depending on how far away the engineer lives). It also makes it easier for employees to turn what would've been a day taken off to deal with appointments into a half-day or less of time away from the keyboard, which helps get more work done. I've always felt that those benefits more than outweigh the costs of setting the company up for remote work, and that having people working remotely on a regular basis makes sure all that infrastructure's working properly and gives confidence that it'll be there and working when things go pear-shaped and you really need to get people on the problem quickly. To me that justifies telling the HR people and the managers "The company needs this. If you don't know how to run things this way, go start learning.".
Slashdot Mirror
Sure we can build a new Internet. Where are the long-haul links that connect cities going to come from, though? Let alone the intercontinental links. Or local distribution when you want aggregate bandwidth greater than WiFi provides? The logistical problems with those things are what the current control issues stem from.
And do we really need a new Internet? IPv6 itself seems pretty sane, and it's possible to build new protocols on top of it (in fact if you look for a file named "protocols" (even Windows machines have it) you'll find tons of them listed). Or even just start building application protocols that require the use of IPSec encryption/authentication.
Plus it appears the code's been backed out: https://github.com/atom-minima...
Completely redo your infrastructure? Dude, we're not talking about Windows here. If you upgrade servers from something as old as 14.04 up to 17.04 (most current release available) you'll need to change approximately 0% of your configuration. You'll want to update a lot of it to take advantage of new features available, but you do that sort of thing over time if you've any sense at all. You don't even upgrade every machine in one session, you upgrade them in groups so the downtime won't shut down your business. This ain't rocket science, rolling upgrades have been SOP everywhere except in Redmond since the late 60s.
If you decided to run a business based on a short-lived release that was stated to be such (eg. 16.10), then I'd argue that you are a kindergarten. You should've based it on one of the LTS releases like 14.04 (supported until 4/2019) or 16.04 (supported until 4/2021). But then you aren't running a business, you're just a troll.
And yet the creditors here would cheerfully argue (and have argued) that contracts entered into in good faith aren't enforceable because they were verbal and the debtor can't show any proof they existed, when that contract consisted of the creditor's rep giving assurances to the debtor about leniency. You and they can't have it both ways. The big financial institutions have been at the forefront of advocating that if you can't produce a signed written agreement then it didn't happen and isn't legally enforceable, well the individual debtor's equally entitled to demand the same standard apply when it goes the other direction.
Figuring out how to solve traffic congestion, that's the easy part. There's lots of ways, mostly in two categories: reducing the volume of traffic needed to move a given number of people, and optimizing the flow of traffic.
The hard part is getting people to actually let the solutions do their job. Everyone wants better traffic flow, but they don't want to change their own driving patterns to ones that optimize traffic flow (especially if it means giving up even a second's advantage over anyone else).
I've never had a problem with credit cards used for online payments. Sure, they'll get compromised, but half the times my cards were compromised it was through brick-and-mortar merchants whose point-of-sale systems were compromised so online use doesn't look to be any more risky that in-person use. Just make sure to check the charges daily (I use a finance program that automatically downloads new charges every morning, plus it gives an alert on the first charge by a new merchant which is convenient). Consumer protection laws in the US keep you from being liable for pretty much all unauthorized activity (at worst you're on the hook for the first $50).
Just don't trust debit cards online, except if they're tied to a bank account that's funded only as needed and doesn't have excess money in it to be absconded with.
If you have any such URLs, the problem is that they exist. If they shouldn't be accessible from outside your network then they should either require authentication restricted to your network or the perimeter firewall should block access to that host from outside. If there's sensitive information in the URL itself, there shouldn't be. URLs can leak too easily (eg. in Referer headers) to be considered safe for confidential/sensitive bits of information.
I'm not surprised, because I've occasionally gotten a look at the resumes and candidates who didn't get to the hiring manager (discarded by HR as not meeting the qualifications). I've found more better-qualified candidates in the discard pile than in the list we got to do phone interviews with, and the consistent pattern is that the HR screening systems put too much emphasis on strong matches with too-specific keywords and not enough emphasis on "knows the subject and has a proven ability to learn the tools". Even with the improvements in AI and expert systems, the screening's still subject to the same old problems.
Software courses are in my book really field-specific. If you're doing operating-system development or embedded-hardware programming then the classes are useful, but outside of those fields that kind of course isn't really helpful and the university computer-science and computer-engineering programs seem to deliberately avoid teaching the things that are useful (eg. how to understand and use standard frameworks (not a specific framework either, the concepts needed to pick up any framework and work with it), how to figure out which design patterns are most applicable and when you're dealing with an anti-pattern that has to be removed, the common idioms in different categories of software architectures, that sort of thing).
It's sad that after 35 years at this I'm still seeing the same malfunctions and watching the same kind of job-shop schmo mishandle things in the same old ways. WiPro or Andersen, plus ça change...
And you set yourself up here. Take your "alicebob" password example. If you allow all-lower-case passwords an attacker trying concatenations of obvious words needs to try 4 possibilities to crack that password. OTOH if he knows you prohibit all-lower-case he only needs to try 3 since "alicebob" is illegal. You've just decreased the amount of time he needs by 25. That's significant. The fact that "alicebob" couldn't be used as a password is exactly why the attack is faster, it's a vulnerability and not a feature.
As far as passwords being replaced by "something better", I doubt there's anything better for the obvious reasons (eg. biometrics are unchangeable if breached and even more predictable than passwords since there's (in theory) only one possibility for a given user and knowing the user an attacker can determine what that sole possibility is). We'd be better-off sticking with passwords and looking at ways to remove the need to commit them to fallible human memory and enter them in error-prone ways like typing, which are probably the two greatest contributors to password vulnerability. #3 is very probably transmitting the password itself over the connection in order for the remote end to validate it, and we've had the methods to eliminate that for decades (all browsers support challenge-response authentication for instance, the only reason it wasn't used was because of IE6's brain-dead rules about which method to use if more than one was available).
Hello ActiveX, its been a while! And you never had any security issues did you, noooo, perfectly safe. Thats why its still around today... err, oh, wait...
Yup. We've been this route before. Not to mention compiling native code for multiple versions of multiple operating systems on multiple CPU architectures. Avoiding that's one of the attractions of browser-based applications. Look, a security and development nightmare in the same package!
Mandatory character classes never increase the search space, they can only decrease it. In your example, if based on your rules I know that all-lower-case passwords aren't legal because they lack a mandatory character class then I can immediately exclude all all-lower-case possibilities from my search. That can only speed up my search for passwords compared to having to check those possibilities even if users aren't using them (as an attacker I don't know if they are or not unless you tell me in your rules that your system won't let them).
It also complicates things for anyone using any password generator because they've got to check their policies and make sure they're using the one that matches your particular set of mandatory character classes. Remember that users don't have to create passwords just for your system, they have to create them for every system they use. The fewer variations they have to deal with, the less likely they are to do something stupid setting up for any particular variation.
Before it hurt them, though, they'd file suit objecting to the penalty. It'd be a decade or more before it all got sorted out, and in the meantime it'd be business as usual for them.
The cable companies in fact can do something about such competition. They gave the municipalities Hobson's Choice: give them monopoly access to the rights-of-way, or do without cable TV. Shopping around doesn't help the municipality, all the big cable companies are demanding the same thing and the smaller ones can't get licenses for the content so they don't have anything to put on the air. I lived through that period, and there really wasn't much the cities could do about it. Now it just gives the telecoms another point of leverage so even if you get officials in place who'll fight they just end up tied up in court trying to break the contracts.
This sort of lawsuit won't do much, even if the state wins. What would do something about the problem is for the state or the municipalities to take the position that the cable companies have breached the contracts that give them monopoly access to public right-of-way for their wiring, then open the access up to other companies under terms that'd prevent any company from blocking or interfering with use by others. That'd still leave some roadblocks, but it'd remove one of the most important ways the telecoms maintain their monopoly position.
This wouldn't involve the ISP, it'd be entirely within the router. The router could access any DNS server, but hosts on the internal side could only access the router's caching DNS server unless the user authorized an exception for them. It wouldn't entirely prevent attacks like this one, but it'd prevent direct attacks and forcing the attacks through multiple levels of caching would blunt the attack to a degree and make it easier to throttle the sources of the malicious requests.
Ultimately, it's the groups that initiated the DDoS who are to blame. But others have to take some responsibility for failing to do what they could to mitigate the opportunities to initiate attacks:
1. ISPs could implement measures based on RFCs 3704 and 2827 that would make spoofed traffic difficult to impossible to generate.
2. Router makers could implement RFC 3704 and 2827 rules in their firewalls by default, could implement default rules that blocked access to external DNS to everything except the router (with the option for the user to allow some or all access), could provide a separate network for IoT devices that defaults to no Internet access and the user has to specifically authorize access per device, and could make randomized default passwords the standard for factory-default configurations.
3. IoT manufacturers could make randomized default passwords standard and design their devices to not require Internet access to configure.
4. Consumers could acknowledge that they're responsible for their own networks and routinely make use of the available tools to check on the health of their networks and the status of the devices on it.
Certainly there are reasons, but that's not the point and not why Project Include won't work with Y Combinator. Support of Trump involves considering sexual assault, racism, sexism and xenophobia to be acceptable. That holds regardless of the reasons you have for supporting him. Project Include is saying "No, those things that Trump loudly and proudly stands for are not acceptable, period. We don't care why you think they're acceptable because we don't believe there's any reason you could give us that could make them acceptable.". And this isn't just the candidate's supporters espousing those positions, it's the candidate himself making his enthusiastic support of those positions the centerpiece of his speeches and campaign.
There'll be plenty of jobs. What there won't be will be employee positions. Companies will increasingly replace employees with robotics and software. Work will shift to self-employment. A contract software engineer will contract with an accountant to handle accounting, with an advertising firm to handle ad placement, with their hosting services to handle routine administration of their servers and so on. An author would contract with someone to screen calls and mail and act as a secretary/receptionist, with someone else to proofread and edit their manuscripts and so on, and would publish directly through distribution channels like Amazon's Kindle Store. A seamstress would contract for advertising services and for janitorial services for the store. Lots of work, but no employees.
My argument in favor of basic income is that starting all of that requires a certain stability. You can't start a contract software consulting business, or start writing full-time, or start a dressmaking store, if you're scrambling to keep food on the table and a roof over your family's head. You can't get a full-time job to cover the bills because those full-time jobs won't exist. So what's the alternative to a basic income if you want people to work? If it's not there they won't be able to afford to spare the concentrated effort needed to get a successful business off the ground, it'll all be sucked up by the scramble to get enough cash this week to buy groceries. If they put in the effort, their family'll be out on the streets and starving in the time it takes for the effort to start producing results.
There's no one single way, but there are several much more useful ways such that files created through Windows have the expected permissions in Cygwin (user read/write) and files created through Cygwin are accessible in Windows (user can read and write them). There's no excuse for the Linux subsystem not being able to do something reasonable. And yes I've dealt with Cygwin files in Windows and Windows files in Cygwin. It works because Cygwin understands Windows ACLs (see POSIX accounts, permission, and security). Amusingly the mapping system Cygwin uses was based on Microsoft's own mapping system from Services for Unix. So not only does Microsoft have the code for an example of a working method available (Cygwin's code), they wrote the code for a working method (SFU).
So basically MS's Linux subsystem can't even do the job Cygwin does quite nicely? I think MS ought to go and read the code, learn some lessons and carry it back. It's not like you can't translate Unix permissions to Windows' permissions system and vice-versa, the code's even right there to read.
Using a straight hosting service like Linode involves owning your own domain name, controlling the DNS and having your own SMTP and IMAP server running. That's all stuff that isn't specific to Linode, the same setup'll work on any service that offers virtual machine hosting. If Linode disconnects you you can drop your setup onto a host on Rackspace or any other service, update your DNS records to point to the new host's addresses and you're back in business. That's much easier than if you've no control over the domain, the DNS or the server software.
Was the "editing to conceal evidence of illegality" perchance what agent Fitchner described in this statement?
If that's what you're talking about, it's rather a strained reading to interpret rejecting ads that contain language indicating they might be for prostitution with editing those ads.
Would that "editing" be related to this statement by agent Fitchtner?
The statement that indicates that Backpage tries to reject ads containing language indicating they involve prostitution? That one isn't going to fly, Backpage will simply point to precedent that Section 230 explicitly bars holding them liable for the content just because of such blocking. They're also going to point to a long string of demands from law-enforcement agencies that sites do just such blocking.
One advantage of planning for remote work is that it makes it easier to get people on-line and working in an emergency. If production goes down unexpectedly on a weekend, if the company's already set up for remote work they can make phone calls and get engineers on-line and working on the problem in a matter of 5-15 minutes. If the company isn't, engineers are going to have to get dressed and get in to the office before they can even start looking at the problem and that can take a half-hour to an hour (or more depending on how far away the engineer lives). It also makes it easier for employees to turn what would've been a day taken off to deal with appointments into a half-day or less of time away from the keyboard, which helps get more work done. I've always felt that those benefits more than outweigh the costs of setting the company up for remote work, and that having people working remotely on a regular basis makes sure all that infrastructure's working properly and gives confidence that it'll be there and working when things go pear-shaped and you really need to get people on the problem quickly. To me that justifies telling the HR people and the managers "The company needs this. If you don't know how to run things this way, go start learning.".