Network neutrality isn't actually about not charging you more in that case. It's about not trying to charge Netflix to avoid degraded service but more about not deliberately degrading Netflix's traffic just because Netflix won't pay to reach the ISP's customers (as opposed to throttling all high-data-volume streams coming across a network connection point from all sources equally and only when congestion across that point exceeds a certain threshold, which is what you'd expect when throttling was used for traffic management and not revenue enhancement).
The telecomms already are charging companies for access, and the big companies like Google and NetFlix are fine with it because the cost for them isn't prohibitively high. That still leaves the small companies facing having to pay for access to end users, and it'll be harder for them because the precedent's already there that having to pay for access to your customers is OK.
I much prefer a compiler or code analyzer that simply flags an assignment where a condition is expected as an error or at least a warning. Then it doesn't matter which form you use, you get told about the problem either way. And personally I find the yoda-talk form much harder to decipher when I'm trying to parse or construct compound conditions.
I think this is the wrong thing for Twitter to do. They ought to reinforce the idea that verification is just that: verification of identity. It's no more an endorsement of the person than a driver's license is an endorsement of them by the DMV. Personally I like a flag that tells me whether an account really belongs to the person in question or a troll trying to get them in trouble. In the case of white supremacists and their ilk, I consider the verified checkmark to be a target selection aid. It helps me insure I'm taking offense at and responding to someone who deserves it, not someone who's gotten the MAGA folks annoyed.
Simple solution: make tickets sold on-line non-transferable and marked with the name of the person they're for. When you buy tickets through a retail channel they have to collect a name for each ticket, which shouldn't be a problem for someone buying for a group of friends. At the door the ticket gets checked against identification and if the name doesn't match the ticket's no good.
If the primary outlet wants to allow resellers to buy for other people, they'd have to implement a reservation system where they can reserve (but not purchase yet) the number of tickets they expect to sell that day. They collect the credit-card information and names from the buyer, submit an order to the vendor against their reservation and send the tickets to the buyer when the purchase is confirmed. The reseller's profit would be the difference between the retail price of the tickets and what the reseller was charging buyers for them. Their daily reservation would be limited and the limit adjusted based on the average number of orders they submitted a day, with the reservation expiring at the end of the day. The primary vendor could also impose limits such as no more than 50% of the event's tickets being available to resellers.
Doesn't directly regulate the pricing, but now no one reseller can "lock up" the entire inventory for an event and control the price that way. If a reseller prices tickets too high, buyers will go somewhere else. And if someone gets the bright idea of setting up a network of reseller entities, they run into the problem of keeping the sales for each entity high enough to earn a big enough reservation block while simultaneously spreading the sales out enough to keep from having reservation blocks reduced for lack of sales on some entities.
Maybe not. One of the big reasons Google stopped the fiber roll-out was because of the constant stonewalling of companies like AT&T when it came to letting Google run cable on the utility poles. If municipalities are able to push back against the incumbent telecomms and cable companies and make it easier and faster for new companies to get fiber on the poles, Google may get back in the game. Wireless had some advantages, but it's also got some major disadvantages in built-up areas where spectrum and tower space are at a premium and fiber's needed for transceiver backhaul anyway.
Why mention the registrar at all? DANE is built on DNS, so other than delegation of nameservers your registrar is out of the picture (unless they're also your DNS provider). The only trust relationship needed is between you and your DNS provider, and you can change your DNS provider if you don't trust your current one. Or if you're truly paranoid you can run your own nameservers.
CAs are also out of the picture if you want them to be, using DANE you can use either self-signed certificates for your server or create your own local issuing authority for your certificates. End of problem with not trusting CAs, you only have to trust yourself.
I'd prefer, rather than key pinning, DANE and TLSA were adopted widely. That'd allow not only attaching a specific certificate to a site but running a site without needing to go to a third party for certificates. Combined with DNSSEC to prevent forgery of the DNS records involved it's more secure than the CA chain-of-trust because the site owner/operator's unlikely to issue his own certificates to malicious parties through error or negligence.
Unfortunately that HSM only stores 1024 keys. That's nowhere near sufficient for large-scale use. And Yubico makes PKCS 2FA dongles that can interface directly with the browser to make the whole thing seamless.
One thing: the big TOTP-key database isn't on your phone or computer or RSA fob/dongle. It's on a server run by whatever service you're authenticating with. And it's that database that's most likely to be compromised. That's true even for the RSA dongles, the host still has to have a database of all the keys so they can validate the code you entered against what your dongle should've generated.
A better solution would be USB hardware-based 2FA using public-key cryptography, and those aren't too expensive. It's just that there's no big money to be made there, by their nature the dongles can't be a locked-in part of a proprietary system so the big vendors and their salespeople have little reason to push for them.
Why would LibreOffice need integration with Confluence? Confluence is a wiki-type web application. You pull it up in any browser. You can put links to pages into any ODF document. You can attach ODF documents to Confluence pages, or link to them if they're stored on any Web server. Exactly what integration are you asking for?
Yes, it's free speech, just as it's free speech to deliberately mislead people in print or when speaking. But just as with in-print or speaking, deliberately making false statements opens you to the backlash when you're fact-checked and proven to be knowingly lying to people, along with the possibility of being sued for libel or slander (since you're talking about deliberate untruths, the public-figure exception will be exceptionally hard to hide behind).
Failing to apply the patch would be the failure of that one person to order the patch applied, plus the failure of his superior to notice that an action item hadn't been handled, plus a failure of the security team to notice that a ticket hadn't been completed, plus the failure of the head of the security team to notice his subordinates had uncompleted tickets sitting there. All this stuff should be tracked, and where I work it is and we have daily status meetings where stuff like this gets asked about, and development team managers and product managers have weekly status meetings where lack of progress on tickets and what needs done about it is a standard agenda item.
Accountability means managers and executives are just as accountable for work getting done or not getting done as low-level employees are expected to be.
They probably did quantify the risk. In terms of it's effect on their revenue, of course, since that's what's at risk for them. And that risk is close to zero, since consumers can't block reporting of their data to Equifax and there are only 2 competitors Equifax has to worry about and the majority of them already use all 3 bureaus. So why expend money mitigating something that poses negligible risk to your business? It poses no risk to the executives either, their future income doesn't depend on Equifax continuing in business. At worst they'll collect a hefty severance package and spend a few weeks relaxing until they get picked up at another company. This is what I refer to as the difference between a businessman and an MBA: the businessman's livelihood is at stake, whereas the MBA is just a glorified W-2 employee.
Risk to consumers? Equifax doesn't do business with consumers, why would anything that happens to those consumers bother it? At most Equifax will spend a few years arguing with regulators and maybe some fines will be levied, but odds on the cost of the fines will be less than the cost of good security. More likely they'll be able to claim they were following all the recommended practices (shoddy as those are) and it's Apache's fault for having left the bug in the version of Struts in question, which (especially given the current administration) will be enough for them to skate even though everybody reasonable knows it's BS.
Sure. If I could make one small edit I would make that a single key operation.
Why not use the Alt-SysRq key that was on the original PC keyboard? It even had the advantage of being tied to a dedicated interrupt so a locked-up keyboard driver wouldn't block the key. Can't argue that the key wasn't there, it was there from the very start and intended for just this use (secure attention signal).
I'd even go so far as to question whether it's a problem. Logging on or unlocking a computer are things done relatively infrequently compared to everything else you use the keyboard for. Dedicating a single key to this one task seems like a waste of a perfectly good key's worth of keyboard layout real-estate, not to mention making it far too easy to accidentally hit the key that'll disconnect your session or lock your computer while you're in the middle of something. Sure you can say you don't want it to be a secure attention key if you're logged in, but that defeats the whole purpose and you might as well just uncheck the box requiring C-A-D to log in.
Answer: third parties. Do you want anyone who can see the traffic to be able to insert themselves into the traffic flow and alter what you're receiving? Because that's what can happen with unencrypted traffic. And while it might not be easy to do that at the level of say the backbone routers, it's really easy for someone to hack the WiFi router at a coffee shop and install a transparent proxy to hijack downloads and replace them with malware. In fact, if you make regular use of public WiFi access, the hijacker may be the router's owner for all you know.
I've long suspected that more than a few patent trolls have paid off the defendants to get out of a suit gone wrong, but always the "settlement" comes with the condition that the defendants not talk about it. What's game-changing about this one is that there's no non-disclosure agreement, Kaspersky's free to publicize exactly who had to pay how much to make the suit disappear. That opens the door for other defendants to counter patent trolls' record of "settlements" (used as evidence of the strength of their claims) with "Show how those "settlements" aren't just like the one with Kaspersky.".
You start by teaching the kids critical thinking and logical problem-solving. Including things like inductive reasoning so they can develop general approaches to solving classes of problems based on the patterns found in a collection of solutions to specific problems. You teach them to trust their own reasoning unless and until someone explains exactly where and how their reasoning is wrong. You teach them that there are usually multiple solutions to any given problem, how to recognize the trade-offs made in the different solutions and how to select the best set of trade-offs for their situation.
Once they've learned that, then you introduce the idea of formal languages for expressing how to solve a problem and how to use those languages to write computer programs.
Unfortunately this'll never happen, because it'll mean raising a generation of children who'll think for themselves and question authority and that's the last thing the professional educators (which is completely distinct from "teacher") want to have to deal with. Ditto the Powers That Be in the various levels of government. Which means we might as well discard the whole idea of teaching computer programming to everyone.
That or if Google supported CERT records in DNS properly. Then sites could publish their own issuing certs and, as long as they use DNSSEC, you could at least verify that the certificates belong to the entity that owns the domain (which is all that's needed for most purposes).
Problem: permitting unencrypted traffic in the general case pretty much breaks all encryption since it permits intermediate nodes to force a state where encrypted connections are "not supported". Since unencrypted connections are supported, that gives ISPs et. al. the ability to tell you to just use a supported (unencrypted) connection. The goal is to force a situation where no intermediate node can legitimately assert that no encryption stronger than some level is allowed, which requires making encryption of some level or another mandatory across the board. See the removal of null encryption from SSL/TLS for a detailed analysis. It's acceptable to permit null (identity) encryption as an option, but only by implementing the whole system such that both client and server have to be expecting null encryption and agree to it for it to be effective and if either end won't agree to go that low the network is still required to support that.
SSL/TLS allowed a situation where only a maximum strength was specified and any node could force a maximum no higher than the minimum and the system would still work. What's needed is a system where the endpoints specify both the maximum they can support and the minimum they'll agree to, and any attempt to set a maximum lower than either end's minimum not only causes the connection to fail but is a clear violation of the standard (leaving ISPs without an excuse for not supporting a minimum equal to the maximum strength in the standard).
It's strange, but it's the only way to operate in a universe where you never know if you're being too paranoid, only if you weren't paranoid enough.
The problem with embedding security protocols in the network itself is the same one we've seen with network capacity: the providers have little incentive to upgrade once they've invested in the initial roll-out. If we embed security at the level of the ISPs and backbone providers, we'll have a massive problem when that security is inevitably broken (whether by malicious action or simply advances in computing power making the algorithms it uses obsolete). We'd also likely see major abuses, either by laziness (your Linux OS isn't supported, we won't allow it to connect) or greed (good-bye routers, you'll have to connect computers directly for security to work and that means paying per computer to connect them). Good-bye having your own domain, for security all email has to be routed through your ISP's mail servers which only support your ISP's email addresses or you'll have to use webmail interfaces which also put you at the mercy of a mail provider (eg. no S/MIME signed/encrypted email unless your mail provider supports it and you give them your private key). And in general I distrust any claims that ISPs and backbone carriers will implement any kind of security correctly, they won't even implement current security measures like spoofed-address filtering.
And what kind of security would we gain? This idea can't protect us from malicious actors gaining network access, ISPs can still sign up customers and there'll always be ISPs who can be fooled by false IDs or who won't look too closely at the background of a customer offering them money. It can't protect us from false identity claims, see above. It can't protect us from malicious content, we've already seen that in the way new exploits get past software designed for the sole purpose of detecting malicious content.
I'm fine with the network enforcing things like default encryption of traffic, but it should be a case of IP-level protocols requiring endpoints to encrypt traffic (eg. all IPv6 traffic requires AH and ESP or the routers will reject it). Authentication should be done directly between the parties that need to authenticate, eg. your email provider issues x.509 certificates for it's users certifying they're who they claim to be (or at least own the address they're using), DNS registries issue certificates certifying that an email provider or mail server operator controls the domain name they're using to send email and so on. Example: if I'm operating my own mailserver for silverglass.org, I'd create my own master issuing certificate and get it signed by either my domain registrar (who'd be using a certificate signed by the registry) or the.org registry saying that my certificate is good for issuing certificates within the silverglass.org domain. Then part of turning on a new mail user would be me issuing them a certificate valid for the email addresses they've asked for. I'd also be issuing the server certificates for my own mailservers. During email handling (receiving a message from my server or delivering a message to it) one check would be "Is this server's certificate valid for the relevant domain for the message?". When you signed or encrypted email messages, you'd do so using a certificate I'd issued to you (saying "This is the true owner of the email address sending this message.") or another one issued by a party who knows your identity (eg. one from your employer saying "This is really our employee and he's shown us ID proving he's really X."). And as far as malicious content goes, well, we already have AV software in use but I've found that the only people who don't have a problem with malware are the ones who refuse to directly handle content from outside or unknown/unexpected sources. The only solutions I have are a) use less complex formats that don't require hairy error-prone code to parse and b) run programs that access that content in a VM that doesn't have unmediated system access (most OSes now are capable of running lightweight VMs or containers). No, languages won't solve the problem of vulnerabi
OK, so where's the bandwidth going to come from to connect say Reno NV to anywhere? Or El Paso TX, or Des Moines IA? There's a lot of nowhere around those cities and no phones to relay signals through.
Slashdot Mirror
Network neutrality isn't actually about not charging you more in that case. It's about not trying to charge Netflix to avoid degraded service but more about not deliberately degrading Netflix's traffic just because Netflix won't pay to reach the ISP's customers (as opposed to throttling all high-data-volume streams coming across a network connection point from all sources equally and only when congestion across that point exceeds a certain threshold, which is what you'd expect when throttling was used for traffic management and not revenue enhancement).
The telecomms already are charging companies for access, and the big companies like Google and NetFlix are fine with it because the cost for them isn't prohibitively high. That still leaves the small companies facing having to pay for access to end users, and it'll be harder for them because the precedent's already there that having to pay for access to your customers is OK.
I much prefer a compiler or code analyzer that simply flags an assignment where a condition is expected as an error or at least a warning. Then it doesn't matter which form you use, you get told about the problem either way. And personally I find the yoda-talk form much harder to decipher when I'm trying to parse or construct compound conditions.
I think this is the wrong thing for Twitter to do. They ought to reinforce the idea that verification is just that: verification of identity. It's no more an endorsement of the person than a driver's license is an endorsement of them by the DMV. Personally I like a flag that tells me whether an account really belongs to the person in question or a troll trying to get them in trouble. In the case of white supremacists and their ilk, I consider the verified checkmark to be a target selection aid. It helps me insure I'm taking offense at and responding to someone who deserves it, not someone who's gotten the MAGA folks annoyed.
Simple solution: make tickets sold on-line non-transferable and marked with the name of the person they're for. When you buy tickets through a retail channel they have to collect a name for each ticket, which shouldn't be a problem for someone buying for a group of friends. At the door the ticket gets checked against identification and if the name doesn't match the ticket's no good.
If the primary outlet wants to allow resellers to buy for other people, they'd have to implement a reservation system where they can reserve (but not purchase yet) the number of tickets they expect to sell that day. They collect the credit-card information and names from the buyer, submit an order to the vendor against their reservation and send the tickets to the buyer when the purchase is confirmed. The reseller's profit would be the difference between the retail price of the tickets and what the reseller was charging buyers for them. Their daily reservation would be limited and the limit adjusted based on the average number of orders they submitted a day, with the reservation expiring at the end of the day. The primary vendor could also impose limits such as no more than 50% of the event's tickets being available to resellers.
Doesn't directly regulate the pricing, but now no one reseller can "lock up" the entire inventory for an event and control the price that way. If a reseller prices tickets too high, buyers will go somewhere else. And if someone gets the bright idea of setting up a network of reseller entities, they run into the problem of keeping the sales for each entity high enough to earn a big enough reservation block while simultaneously spreading the sales out enough to keep from having reservation blocks reduced for lack of sales on some entities.
Maybe not. One of the big reasons Google stopped the fiber roll-out was because of the constant stonewalling of companies like AT&T when it came to letting Google run cable on the utility poles. If municipalities are able to push back against the incumbent telecomms and cable companies and make it easier and faster for new companies to get fiber on the poles, Google may get back in the game. Wireless had some advantages, but it's also got some major disadvantages in built-up areas where spectrum and tower space are at a premium and fiber's needed for transceiver backhaul anyway.
Why mention the registrar at all? DANE is built on DNS, so other than delegation of nameservers your registrar is out of the picture (unless they're also your DNS provider). The only trust relationship needed is between you and your DNS provider, and you can change your DNS provider if you don't trust your current one. Or if you're truly paranoid you can run your own nameservers.
CAs are also out of the picture if you want them to be, using DANE you can use either self-signed certificates for your server or create your own local issuing authority for your certificates. End of problem with not trusting CAs, you only have to trust yourself.
I'd prefer, rather than key pinning, DANE and TLSA were adopted widely. That'd allow not only attaching a specific certificate to a site but running a site without needing to go to a third party for certificates. Combined with DNSSEC to prevent forgery of the DNS records involved it's more secure than the CA chain-of-trust because the site owner/operator's unlikely to issue his own certificates to malicious parties through error or negligence.
Unfortunately that HSM only stores 1024 keys. That's nowhere near sufficient for large-scale use. And Yubico makes PKCS 2FA dongles that can interface directly with the browser to make the whole thing seamless.
One thing: the big TOTP-key database isn't on your phone or computer or RSA fob/dongle. It's on a server run by whatever service you're authenticating with. And it's that database that's most likely to be compromised. That's true even for the RSA dongles, the host still has to have a database of all the keys so they can validate the code you entered against what your dongle should've generated.
A better solution would be USB hardware-based 2FA using public-key cryptography, and those aren't too expensive. It's just that there's no big money to be made there, by their nature the dongles can't be a locked-in part of a proprietary system so the big vendors and their salespeople have little reason to push for them.
Why would LibreOffice need integration with Confluence? Confluence is a wiki-type web application. You pull it up in any browser. You can put links to pages into any ODF document. You can attach ODF documents to Confluence pages, or link to them if they're stored on any Web server. Exactly what integration are you asking for?
Yes, it's free speech, just as it's free speech to deliberately mislead people in print or when speaking. But just as with in-print or speaking, deliberately making false statements opens you to the backlash when you're fact-checked and proven to be knowingly lying to people, along with the possibility of being sued for libel or slander (since you're talking about deliberate untruths, the public-figure exception will be exceptionally hard to hide behind).
Failing to apply the patch would be the failure of that one person to order the patch applied, plus the failure of his superior to notice that an action item hadn't been handled, plus a failure of the security team to notice that a ticket hadn't been completed, plus the failure of the head of the security team to notice his subordinates had uncompleted tickets sitting there. All this stuff should be tracked, and where I work it is and we have daily status meetings where stuff like this gets asked about, and development team managers and product managers have weekly status meetings where lack of progress on tickets and what needs done about it is a standard agenda item.
Accountability means managers and executives are just as accountable for work getting done or not getting done as low-level employees are expected to be.
They probably did quantify the risk. In terms of it's effect on their revenue, of course, since that's what's at risk for them. And that risk is close to zero, since consumers can't block reporting of their data to Equifax and there are only 2 competitors Equifax has to worry about and the majority of them already use all 3 bureaus. So why expend money mitigating something that poses negligible risk to your business? It poses no risk to the executives either, their future income doesn't depend on Equifax continuing in business. At worst they'll collect a hefty severance package and spend a few weeks relaxing until they get picked up at another company. This is what I refer to as the difference between a businessman and an MBA: the businessman's livelihood is at stake, whereas the MBA is just a glorified W-2 employee.
Risk to consumers? Equifax doesn't do business with consumers, why would anything that happens to those consumers bother it? At most Equifax will spend a few years arguing with regulators and maybe some fines will be levied, but odds on the cost of the fines will be less than the cost of good security. More likely they'll be able to claim they were following all the recommended practices (shoddy as those are) and it's Apache's fault for having left the bug in the version of Struts in question, which (especially given the current administration) will be enough for them to skate even though everybody reasonable knows it's BS.
Answer: third parties. Do you want anyone who can see the traffic to be able to insert themselves into the traffic flow and alter what you're receiving? Because that's what can happen with unencrypted traffic. And while it might not be easy to do that at the level of say the backbone routers, it's really easy for someone to hack the WiFi router at a coffee shop and install a transparent proxy to hijack downloads and replace them with malware. In fact, if you make regular use of public WiFi access, the hijacker may be the router's owner for all you know.
I've long suspected that more than a few patent trolls have paid off the defendants to get out of a suit gone wrong, but always the "settlement" comes with the condition that the defendants not talk about it. What's game-changing about this one is that there's no non-disclosure agreement, Kaspersky's free to publicize exactly who had to pay how much to make the suit disappear. That opens the door for other defendants to counter patent trolls' record of "settlements" (used as evidence of the strength of their claims) with "Show how those "settlements" aren't just like the one with Kaspersky.".
How about the companies use the Reply-To header to direct replies to automated notifications to the correct place to handle them?
You start by teaching the kids critical thinking and logical problem-solving. Including things like inductive reasoning so they can develop general approaches to solving classes of problems based on the patterns found in a collection of solutions to specific problems. You teach them to trust their own reasoning unless and until someone explains exactly where and how their reasoning is wrong. You teach them that there are usually multiple solutions to any given problem, how to recognize the trade-offs made in the different solutions and how to select the best set of trade-offs for their situation.
Once they've learned that, then you introduce the idea of formal languages for expressing how to solve a problem and how to use those languages to write computer programs.
Unfortunately this'll never happen, because it'll mean raising a generation of children who'll think for themselves and question authority and that's the last thing the professional educators (which is completely distinct from "teacher") want to have to deal with. Ditto the Powers That Be in the various levels of government. Which means we might as well discard the whole idea of teaching computer programming to everyone.
That or if Google supported CERT records in DNS properly. Then sites could publish their own issuing certs and, as long as they use DNSSEC, you could at least verify that the certificates belong to the entity that owns the domain (which is all that's needed for most purposes).
Problem: permitting unencrypted traffic in the general case pretty much breaks all encryption since it permits intermediate nodes to force a state where encrypted connections are "not supported". Since unencrypted connections are supported, that gives ISPs et. al. the ability to tell you to just use a supported (unencrypted) connection. The goal is to force a situation where no intermediate node can legitimately assert that no encryption stronger than some level is allowed, which requires making encryption of some level or another mandatory across the board. See the removal of null encryption from SSL/TLS for a detailed analysis. It's acceptable to permit null (identity) encryption as an option, but only by implementing the whole system such that both client and server have to be expecting null encryption and agree to it for it to be effective and if either end won't agree to go that low the network is still required to support that.
SSL/TLS allowed a situation where only a maximum strength was specified and any node could force a maximum no higher than the minimum and the system would still work. What's needed is a system where the endpoints specify both the maximum they can support and the minimum they'll agree to, and any attempt to set a maximum lower than either end's minimum not only causes the connection to fail but is a clear violation of the standard (leaving ISPs without an excuse for not supporting a minimum equal to the maximum strength in the standard).
It's strange, but it's the only way to operate in a universe where you never know if you're being too paranoid, only if you weren't paranoid enough.
The problem with embedding security protocols in the network itself is the same one we've seen with network capacity: the providers have little incentive to upgrade once they've invested in the initial roll-out. If we embed security at the level of the ISPs and backbone providers, we'll have a massive problem when that security is inevitably broken (whether by malicious action or simply advances in computing power making the algorithms it uses obsolete). We'd also likely see major abuses, either by laziness (your Linux OS isn't supported, we won't allow it to connect) or greed (good-bye routers, you'll have to connect computers directly for security to work and that means paying per computer to connect them). Good-bye having your own domain, for security all email has to be routed through your ISP's mail servers which only support your ISP's email addresses or you'll have to use webmail interfaces which also put you at the mercy of a mail provider (eg. no S/MIME signed/encrypted email unless your mail provider supports it and you give them your private key). And in general I distrust any claims that ISPs and backbone carriers will implement any kind of security correctly, they won't even implement current security measures like spoofed-address filtering.
And what kind of security would we gain? This idea can't protect us from malicious actors gaining network access, ISPs can still sign up customers and there'll always be ISPs who can be fooled by false IDs or who won't look too closely at the background of a customer offering them money. It can't protect us from false identity claims, see above. It can't protect us from malicious content, we've already seen that in the way new exploits get past software designed for the sole purpose of detecting malicious content.
I'm fine with the network enforcing things like default encryption of traffic, but it should be a case of IP-level protocols requiring endpoints to encrypt traffic (eg. all IPv6 traffic requires AH and ESP or the routers will reject it). Authentication should be done directly between the parties that need to authenticate, eg. your email provider issues x.509 certificates for it's users certifying they're who they claim to be (or at least own the address they're using), DNS registries issue certificates certifying that an email provider or mail server operator controls the domain name they're using to send email and so on. Example: if I'm operating my own mailserver for silverglass.org, I'd create my own master issuing certificate and get it signed by either my domain registrar (who'd be using a certificate signed by the registry) or the .org registry saying that my certificate is good for issuing certificates within the silverglass.org domain. Then part of turning on a new mail user would be me issuing them a certificate valid for the email addresses they've asked for. I'd also be issuing the server certificates for my own mailservers. During email handling (receiving a message from my server or delivering a message to it) one check would be "Is this server's certificate valid for the relevant domain for the message?". When you signed or encrypted email messages, you'd do so using a certificate I'd issued to you (saying "This is the true owner of the email address sending this message.") or another one issued by a party who knows your identity (eg. one from your employer saying "This is really our employee and he's shown us ID proving he's really X."). And as far as malicious content goes, well, we already have AV software in use but I've found that the only people who don't have a problem with malware are the ones who refuse to directly handle content from outside or unknown/unexpected sources. The only solutions I have are a) use less complex formats that don't require hairy error-prone code to parse and b) run programs that access that content in a VM that doesn't have unmediated system access (most OSes now are capable of running lightweight VMs or containers). No, languages won't solve the problem of vulnerabi
Anyone still falling for this, in this day and age, should seriously be banned from ever coming within 10 feet of any computer ever again.
Yes, that includes the ones in their car.
And who's going to pay for (and own) the satellites?
OK, so where's the bandwidth going to come from to connect say Reno NV to anywhere? Or El Paso TX, or Des Moines IA? There's a lot of nowhere around those cities and no phones to relay signals through.