I don't think (1) is as clear cut as you make it. Lots of smokers will tell you (simultaneously) that they want a cigarette and also want to quit smoking. Or pedantically, they want( ! want(smoke) ), which is odd in a kind of recursive wanting-about-wanting sort of way. You can model this in all sorts of fancy mathematical ways -- nested desires, temporal inconsistencies, hyperbolic discount factors, but intuitively, we all kind of grok the idea that human 'want' is not a self-consistent thing with a well-defined meaning. Heck, there are famous studies that show that if you let people chose freely from a list, there's a significant bias towards the first item, which ought to definitively resolve that human desires are sometimes ill-defined[1].
So far, I think that's just a matter of fact. Sometimes there's an idea batted around that if you believe this fact, you must accept the policy implications that it's "any of your business" as if it's an inexorable march from "people have inconsistent desires" to a paternalistic dystopia. I think that's a profoundly mistaken idea. At least for me personally, I believe "people want X" is an ill-defined concept while still believing (for the most part) in freedom and individual choice.
The scary thing to me is that if you go the Ayn Rand route and justify freedom on the basis that "people want X, therefore they did X", you are (IMHO) now greatly undermining the case for individual choice because you've made it contingent on all this baggage.
[1] As a side note: the fact that human desires are ill-defined in some cases doesn't make them entirely non-entities either. That's another extreme that says that if a thing is not platonically perfect then it must not exist. I think we all grok that human wants are really extant and that pointing out various inconsistencies or other oddities is entirely a different claim from claiming they don't exist.
Surely the OS is providing standard access to every FS
They are trying, and largely succeeding. Nevertheless, all non-trivial (and filesystems are highly nontrivial) abstractions are leaky
fopen() will still work, regardless, surely... no?
A service that offers background sync (i.e. changes are pushed to the cloud in the background) which doesn't just poll (polling is evil) needs an API much more complicated that fopen. Specifically, it needs a notification stream where it can create a 'watched' folder and be notified when:
A file in the watch was opened for writing was closed
A new file or directory entry was created
A file or directory was deleted
A file or directory was moved, either from outside the watch to inside, inside to outside or inside to inside. Note that this is essential to allow users to rename or reorganize their folders without retransmitting the entire file each time
Probably more I'm not thinking of . . .
This is a (somewhat) solved problem, in the sense that inotify exists within some limitations described on the wikipedia page (and further in the man page). One really obvious limitation is that the kernel will not do this recursively for you, meaning that the client has to manually add/remove folder watches. The other is that rename events are clunky, coming in two halves with a linking identify. Anyway, if you read the history, you'll note this is the third or so attempt at getting this right, which at least suggests that it's non-trivial enough that we had to can the original (dnotify) interface and start over once.
What was the point of this side-track into filesystem watching? Well, for one, we started with "how hard is fopen/fread" and now ended up with "holy crap, that's highly non-trivial to be async notified of changes within a directory tree (recursively!)". It also raises the question of whether the interface really is an airtight abstraction, or whether filesystem implementation details leak into the caller to be dealt with. Even answering that question for all supported Linux filesystems is non-trivial.
If you take nothing else away, just remember that this is a far more complicated problem than rsync;-)
None of the ARM CPUs in my tablets and smartphones incorporate speculative execution, and thus, are immune to these attacks.
Really? Then you must not have
Any ARM Cortex after A53, which was the first with branch prediction released in 2012 (if you are predicting a branch, then you are executing speculatively). The A57 then bumps this from just branch prediction to full OOO execution.
Any Samsung Exynos after M1. The Qualcomm ones are just warmed over ARMs anyway (with an LTE modem glued on) so nothing new there. Same for MediaTek.
Probably the Apple SOCs too, but they don't really give out slides.
Anyway, if you are running a ARM SOC with no branch predictor (let alone OOO) then you are on a phone/tablet from 2014 or earlier.
I guess if the sum-total is "I liked the UI in 7 more than 8 or 10", sure, I can accept that's your opinion on the UI. But an OS is much more then a UI, and saying it's "better" as an OS is mistaking that small part for the whole.
Also, I don't think an updated/maintained version of 7 would be better because there were architectural improvements (security/perf/reliability) since then and because doing so would siphon engineering and testing resources that could be put to use on modern version.
Considering the mess that most people are already just why would anyone not want the species to be altered? When you read our history books what you see is war, invasions, thefts. rapes and all manner of crime and depravity. And now we have a scientists that hopes to make a few adjustments.
What's more, many of great accomplishments came at a massive cost in lives. The ancient civilizations that set ventured onto the Mediterranean from Egypt, Carthage, Greece and Rome sent many sailors to their deaths. This continued well into the Age of Sail. The first aviators suffered the same, as did the first astronauts.
Those that venture into new areas are always stalked by death. To imagine that we can do so with no risk is foolish. Will CRISPR kill or maim? Most definitely. Should we abandon it? Most definitely not.
If Apple is going to deceive you in front of lawmakers. Why not release source without the offending code, and compile and send a different branch with it.
Indeed.
Most of us even hard core open source Linux fans, will not install their applications by compiling the source. make clean & make & make install
First, even those that do will not audit the entire source. I bet you could insert a function send_personal_data_to_kgb_and_nsa(void) and only a small number of people running./configure && make -j12 install would notice. If you obfuscated the functionality a bit better, no one would notice:-P
Anyway, even if you did audit the source, that is not sufficient to guarantee that the compiled binary faithfully represents the source files input. To do that, you have to audit the entire compiler/toolchain. And then you have to audit the compiler used to build the compiler.
If you want to verify what is happening, then you should monitor all the wireless traffic your phone sends. Compare it in a quiet environment and one with talking. See if the data sent from the device is enough for conversations.
But the phone has storage. And it has speech-to-text, part of which happens locally. Both of those features mean that, in theory, the phone could record and process the audit and then dribble it out over the network later when you are doing some other legitimate network activity.
So if you REALLY want to be certain, you have to fill up the storage (wait, there could be a secret reserve of a few GB that are not user-accessible) and also monitor the supply lines from the battery to ensure there is no heavy speech processing that might be transcribing it to text:-D
I agree with the sentiment of your post, just like showing that there is no way around having some level of trust in the hardware/software that you use.
Not sure why the editors didn't include the actual patch or technical details, but here's the thread. Click "Related" at the top to see the 5-part patch.
In short, looking at the patch, the DOS attacks the sequence/buffer for reordering TCP packets. Specifically, after sending lots of tiny packets with out of order sequence numbers, a couple things happen:
(1) There is an expensive operation to coalesce adjacent packets. This has to run through the entire out of order RB tree, and generally sucks. The fix avoids doing this until the OOO buffer is almost entirely full.
(2) When doing the collapse, keep track of how many 'tiny' packets there are and just bail out rather than continuing to do lots of operations/copies attempting to coalesce them.
(3) Once you've filled up the entire OOO buffer, Linux only drops just enough older packets to get under the boundary. This exacerbates the previous issues, as the attacker can keep the buffer entirely full. The patch changes this always drop in batches (1/8th of the memory) each time it's full.
Neat patch. Editors, next time can we get some real analysis?
The bond market wouldn't lend to him because of the combination of astronomical risk and no upside.
Think about it -- the bond lender gets, at most, the principal and interest they charge you. They don't share at all in the company success, no matter how much you make.
when programmers already canâ(TM)t write bug-free code, how the heck are they going to make up 100% guaranteed non-exploitable false bug
If you RTFA, you would see that the bugs are introduced by an automated source to source transformation tool at build time, not by the original programmer. So the question is, can the writer of the tool guarantee that the bugs it inserts are not exploitable. While I wouldn't sign off on it per-se, that does seem a whole lot easier than having each developer do so -- you've got to get the tool[1] exactly right, but only in one place.
Anyway, there's a lot to criticize in the paper. But the idea that they are asking programmers to make up non-exploitable bugs is based on a fundamental misreading of what they are actually proposing.
[1] In many ways, the tool is a lot lower in complexity than other transformation tools that are currently used on mission-critical software. Certainly lower complexity than an optimizing compiler at analyzing data flows and less intrusive than some of the binary obfuscating tools used to slow down reverse engineering.
That is still incorrect. We can keep it a secret that we requested X from the party that provides X,
Fair enough:-)
OK, that I can agree with. I'm not sure I'd call that "substituting" since the resolver is initiating the response, but it is true that you're still stuck trusting the resolver, unless you have a parallel authentication protocol...
Yeah, the interesting thing is that the resolver is not the authoritative source on the resolution.
Or to put it another way, we want to receive a particular piece of information X, we can't keep it a secret from the party that provides X that we requested X.
Agreed, fixed to address your concern.
Internal Tor nodes do not have the option of substituting their own responses. First, they don't even see the request or the response since both are encrypted, so they wouldn't have any idea what to substitute. Second, the response is authenticated with the service provider's private key, so no one else could generate a response the client would accept even if they somehow guessed what the request was.
I meant the endpoint that is actually doing the resolving is the one to substitute it. At some level, the DNS request has to be actually serviced by someone and that someone can maliciously substitute it.
You could say "well, the DNS service provider over Tor has some particular key", but that boils down to whether you trust that key is bound to a particular name (say: "Good guy DNS-SP"). Which is.. . the role of a CA system like we have in TLS to authoritatively map keys with common names.
DNSSec makes sense for other reasons (when you can't trust the resolver itself, or its communications with other nameservers), but that's separate from the problem of communicating anonymously with the resolver.
But that is indeed my point -- either you are talking about keeping the contents of the requests confidential from eavesdroppers (in which case, all you need is DNS-over-TLS) or you are talking about keeping it confidential from the resolver itself, which is flat out impossible.
TFA suggested that having the domain be shared to a "third party" was intrinsically a security problem. This is utterly nonsense -- to resolve a domain name you need to contact a resolver which intrinsically needs to know the domain to be resolved. This is always a third party, since it's neither the requester nor the provider.
Actually it is. Where else can an 18 year old kid with no experience, who has never had a job before, walk in and say "I want to be an aircraft mechanic. I want you to train me at your expense, and I want to be paid while I learn. I also demand free food and housing, and 30 days of vacation every year. Also, I plan to quit after 4 years, and then I want you to then pay my college tuition."
I don't know about you, but as a private employer I would gladly hire a ton of 18 year old kids for this deal, provided you also include the all important and the kid cannot quit until your 4 year term is up or else you will go to prison. Even with free food, housing and vacation, this is still an absolutely excellent deal for the employer, since training costs ebb out after 12-18 months (or, more likely, if you can't be even sort of useful after 18 months of training, it's not gonna happen).
More generally, it's a well-known coordination/defection problem with employers in a free market offering training programs -- which is that there is no credible way to guarantee that the trainee will not quit and join a competitor before the investment is repaid. There are a number of workarounds and other bad solutions to this problem:
** Make the trainee pay for the training up front (perhaps with loans) so the employer isn't in the red. Instead, pay increased wages to those with the training to compensate. This is most colleges, but also the civilian aviation industry, food industry and lots of other places where an employer-run-training program would just lead to poaching. Of course, this leads to massive advantages for family wealth and the profusion of expensive student loans. Also, there is a weaker feedback link, since students are getting loans to study what they think employers want, but often there is a mismatch. Certainly far more kids study video game design than could possibly be employed in that field.
** Make the trainee join an apprenticeship program as a condition for some kind of exclusionary credential. It's understood that the program is longer than educationally necessary and during the latter part of the apprenticeship, the trainee is already generating a surplus which pays back the training put into in the beginning. The trainee cannot leave halfway because they cannot practice the trade without the credential. Common in some technical European fields and in US medicine. This solves some problems, but often leaves an exclusionary cartel in charge of the credential and tends to under-produce it to extract higher rents. It can also lead to 'good-ole-boy' networks in which limited apprenticeship slots are allocated subjectively to those with political connections.
** Make the trainee sign a contract to fork over X% of wages for Y years up to $Z. This is a variant of the loan concept where repayment is scaled to success, newly popular in the Bay Area. It does lead to higher accessibility of the training at lower economic scales, but is quite expensive (there is an implicit interest rate here and it's high, very high). It's also questionable how enforceable these contracts are, and whether they are dischargeable in bankruptcy.
** The government directly pays for the training, not expecting an immediate return through labor but rather through lifetime taxes. This can work well, but often doesn't pay for itself. It also suffers the mismatch problem and cost inflation problem (public universities have ballooning per-student costs for no appreciable gain in output).
All in all, it's a gnarly problem without any clear and good solutions. More likely, we'll muddle along with some combination of mandatory-apprenticeship in areas where it makes sense and trainee-pays for the rest. Better solutions always welcome, but do keep the constraints in mind:-P
Because sharing data or information with any third party, which is Cloudflare in this case, is a security issue itself.
Exposing data to a particular party is an issue iff the security model treats that data as confidential and not intended for that party. In the current model of things, DNS queries are sent in the clear and so there is no confidentiality with respect to any party that happens to be eavesdropping.
So then thinking for a bit, we could have some transport layer security for DNS, this would provide confidentiality and integrity over the wire. We still have to share the domains we need with the service that resolves them though, so it literally cannot be kept confidential from that service. Or to put it another way, we want to receive a particular piece of information X, we can't keep it a secret that we requested X.
So then we are into distributed networks (aka TOR) and other sort of services where we accept that we cannot hide the nature of our request to the network (or else it wouldn't be able to return the requested resource) but we try to smear it out so that requests are all over the place. This would have major implications for authenticity though -- nodes in a 'mesh' DNS resolver could maliciously substitute their own resolutions.
To resolve that you need an authority like DNSSec, which means some root-level keys and that's a whole new mess.
There will need to be a massive cultural shift to actually get people in countries that used to export dirty plastic as "recyclable" to actually sort and wash their own plastic waste so it is actually recyclable at a reasonable cost.
My time is valuable to me. Unless your cultural shift somehow changes that, I can't see it.
Buying any stock entails *risk*. You're not entitled to the value of that stock to go up. If you buy a stock and it plummets because of shitty corporate policy, *you* invested in a company with shitty corporate policy. Eat your mistake.
This is only part-way true. A corporation still has substantial duties with regard to its shareholders. For instance, they can't just spend all the year's profit on hookers and blow for the board. Nor can they flat out lie.
Of course this case should be laughed out of court. But don't go so far as to say that companies have no duty whatsoever to their shareholders or that all shareholder cases are laughable.
I don't know about colloquially, but breaking to an occupied house has historically been considered a crime of violence, since it inherently carries with it the very real potential for a confrontation between the criminal and the occupants. Contrast with breaking into an unoccupied home, which is just a property crime.
Also, no one believes it would be better if the guy was shot. Any time a gun is used in anger is already very not good, the idea is to do so only when you are absolutely convinced that it's the best of a bunch of not-good options.
As for the 'second-most-gun-owners' claim, you're going to want to express this per-capita:-P
... balance between having situational awareness of what is going on in the network versus End User expectations of some privacy at work
I mean, the solution to expectations is to set expectations clearly, right? Whatever balance is chosen, the employees should be clearly informed about the policy, including what can be monitored/stored and whose approvals are necessary to read it.
You might be shocked to know that there is probably an IMAP server somewhere and if you compromise it, you get to read all the archived emails and impersonate email from anyone!
And a git server somewhere if you compromise it, you get all the source and the ability to impersonate commits from anyone.
Slashdot Mirror
[ Full disclosure: former cigarette smoker ]
I don't think (1) is as clear cut as you make it. Lots of smokers will tell you (simultaneously) that they want a cigarette and also want to quit smoking. Or pedantically, they want( ! want(smoke) ), which is odd in a kind of recursive wanting-about-wanting sort of way. You can model this in all sorts of fancy mathematical ways -- nested desires, temporal inconsistencies, hyperbolic discount factors, but intuitively, we all kind of grok the idea that human 'want' is not a self-consistent thing with a well-defined meaning. Heck, there are famous studies that show that if you let people chose freely from a list, there's a significant bias towards the first item, which ought to definitively resolve that human desires are sometimes ill-defined[1].
So far, I think that's just a matter of fact. Sometimes there's an idea batted around that if you believe this fact, you must accept the policy implications that it's "any of your business" as if it's an inexorable march from "people have inconsistent desires" to a paternalistic dystopia. I think that's a profoundly mistaken idea. At least for me personally, I believe "people want X" is an ill-defined concept while still believing (for the most part) in freedom and individual choice.
The scary thing to me is that if you go the Ayn Rand route and justify freedom on the basis that "people want X, therefore they did X", you are (IMHO) now greatly undermining the case for individual choice because you've made it contingent on all this baggage.
[1] As a side note: the fact that human desires are ill-defined in some cases doesn't make them entirely non-entities either. That's another extreme that says that if a thing is not platonically perfect then it must not exist. I think we all grok that human wants are really extant and that pointing out various inconsistencies or other oddities is entirely a different claim from claiming they don't exist.
It didn't IGNORE them, it speculatively executed past them and then ROLLED BACK all visible result.
The bug was not in executing over the boundary at all, it was that the roll-back did not also reverse the side effects to the cache.
They are trying, and largely succeeding. Nevertheless, all non-trivial (and filesystems are highly nontrivial) abstractions are leaky
A service that offers background sync (i.e. changes are pushed to the cloud in the background) which doesn't just poll (polling is evil) needs an API much more complicated that fopen. Specifically, it needs a notification stream where it can create a 'watched' folder and be notified when:
This is a (somewhat) solved problem, in the sense that inotify exists within some limitations described on the wikipedia page (and further in the man page). One really obvious limitation is that the kernel will not do this recursively for you, meaning that the client has to manually add/remove folder watches. The other is that rename events are clunky, coming in two halves with a linking identify. Anyway, if you read the history, you'll note this is the third or so attempt at getting this right, which at least suggests that it's non-trivial enough that we had to can the original (dnotify) interface and start over once.
What was the point of this side-track into filesystem watching? Well, for one, we started with "how hard is fopen/fread" and now ended up with "holy crap, that's highly non-trivial to be async notified of changes within a directory tree (recursively!)". It also raises the question of whether the interface really is an airtight abstraction, or whether filesystem implementation details leak into the caller to be dealt with. Even answering that question for all supported Linux filesystems is non-trivial.
If you take nothing else away, just remember that this is a far more complicated problem than rsync ;-)
Postscript: rsync is 50K LOC
Really? Then you must not have
Any ARM Cortex after A53, which was the first with branch prediction released in 2012 (if you are predicting a branch, then you are executing speculatively). The A57 then bumps this from just branch prediction to full OOO execution.
Any Samsung Exynos after M1. The Qualcomm ones are just warmed over ARMs anyway (with an LTE modem glued on) so nothing new there. Same for MediaTek.
Probably the Apple SOCs too, but they don't really give out slides.
Anyway, if you are running a ARM SOC with no branch predictor (let alone OOO) then you are on a phone/tablet from 2014 or earlier.
Crab mentality is real.
I guess if the sum-total is "I liked the UI in 7 more than 8 or 10", sure, I can accept that's your opinion on the UI. But an OS is much more then a UI, and saying it's "better" as an OS is mistaking that small part for the whole.
Also, I don't think an updated/maintained version of 7 would be better because there were architectural improvements (security/perf/reliability) since then and because doing so would siphon engineering and testing resources that could be put to use on modern version.
What's more, many of great accomplishments came at a massive cost in lives. The ancient civilizations that set ventured onto the Mediterranean from Egypt, Carthage, Greece and Rome sent many sailors to their deaths. This continued well into the Age of Sail. The first aviators suffered the same, as did the first astronauts.
Those that venture into new areas are always stalked by death. To imagine that we can do so with no risk is foolish. Will CRISPR kill or maim? Most definitely. Should we abandon it? Most definitely not.
You won't when you get pwned by a bug that's been fixed in more recent versions.
No one ever promised you that they would maintain software from 2009 past 2019.
Indeed.
First, even those that do will not audit the entire source. I bet you could insert a function send_personal_data_to_kgb_and_nsa(void) and only a small number of people running ./configure && make -j12 install would notice. If you obfuscated the functionality a bit better, no one would notice :-P
Anyway, even if you did audit the source, that is not sufficient to guarantee that the compiled binary faithfully represents the source files input. To do that, you have to audit the entire compiler/toolchain. And then you have to audit the compiler used to build the compiler.
But the phone has storage. And it has speech-to-text, part of which happens locally. Both of those features mean that, in theory, the phone could record and process the audit and then dribble it out over the network later when you are doing some other legitimate network activity.
So if you REALLY want to be certain, you have to fill up the storage (wait, there could be a secret reserve of a few GB that are not user-accessible) and also monitor the supply lines from the battery to ensure there is no heavy speech processing that might be transcribing it to text :-D
I agree with the sentiment of your post, just like showing that there is no way around having some level of trust in the hardware/software that you use.
Not sure why the editors didn't include the actual patch or technical details, but here's the thread. Click "Related" at the top to see the 5-part patch.
In short, looking at the patch, the DOS attacks the sequence/buffer for reordering TCP packets. Specifically, after sending lots of tiny packets with out of order sequence numbers, a couple things happen:
(1) There is an expensive operation to coalesce adjacent packets. This has to run through the entire out of order RB tree, and generally sucks. The fix avoids doing this until the OOO buffer is almost entirely full.
(2) When doing the collapse, keep track of how many 'tiny' packets there are and just bail out rather than continuing to do lots of operations/copies attempting to coalesce them.
(3) Once you've filled up the entire OOO buffer, Linux only drops just enough older packets to get under the boundary. This exacerbates the previous issues, as the attacker can keep the buffer entirely full. The patch changes this always drop in batches (1/8th of the memory) each time it's full.
Neat patch. Editors, next time can we get some real analysis?
Pretty sure the iOS client application source is pretty small compared to the backend source.
Not saying anything about market caps and justifications of course.
The bond market wouldn't lend to him because of the combination of astronomical risk and no upside.
Think about it -- the bond lender gets, at most, the principal and interest they charge you. They don't share at all in the company success, no matter how much you make.
If you RTFA, you would see that the bugs are introduced by an automated source to source transformation tool at build time, not by the original programmer. So the question is, can the writer of the tool guarantee that the bugs it inserts are not exploitable. While I wouldn't sign off on it per-se, that does seem a whole lot easier than having each developer do so -- you've got to get the tool[1] exactly right, but only in one place.
Anyway, there's a lot to criticize in the paper. But the idea that they are asking programmers to make up non-exploitable bugs is based on a fundamental misreading of what they are actually proposing.
[1] In many ways, the tool is a lot lower in complexity than other transformation tools that are currently used on mission-critical software. Certainly lower complexity than an optimizing compiler at analyzing data flows and less intrusive than some of the binary obfuscating tools used to slow down reverse engineering.
Fair enough :-)
Yeah, the interesting thing is that the resolver is not the authoritative source on the resolution.
Agreed with the rest of the post.
Agreed, fixed to address your concern.
I meant the endpoint that is actually doing the resolving is the one to substitute it. At some level, the DNS request has to be actually serviced by someone and that someone can maliciously substitute it. You could say "well, the DNS service provider over Tor has some particular key", but that boils down to whether you trust that key is bound to a particular name (say: "Good guy DNS-SP"). Which is .. . the role of a CA system like we have in TLS to authoritatively map keys with common names.
But that is indeed my point -- either you are talking about keeping the contents of the requests confidential from eavesdroppers (in which case, all you need is DNS-over-TLS) or you are talking about keeping it confidential from the resolver itself, which is flat out impossible. TFA suggested that having the domain be shared to a "third party" was intrinsically a security problem. This is utterly nonsense -- to resolve a domain name you need to contact a resolver which intrinsically needs to know the domain to be resolved. This is always a third party, since it's neither the requester nor the provider.
I don't know about you, but as a private employer I would gladly hire a ton of 18 year old kids for this deal, provided you also include the all important and the kid cannot quit until your 4 year term is up or else you will go to prison. Even with free food, housing and vacation, this is still an absolutely excellent deal for the employer, since training costs ebb out after 12-18 months (or, more likely, if you can't be even sort of useful after 18 months of training, it's not gonna happen). More generally, it's a well-known coordination/defection problem with employers in a free market offering training programs -- which is that there is no credible way to guarantee that the trainee will not quit and join a competitor before the investment is repaid. There are a number of workarounds and other bad solutions to this problem:
All in all, it's a gnarly problem without any clear and good solutions. More likely, we'll muddle along with some combination of mandatory-apprenticeship in areas where it makes sense and trainee-pays for the rest. Better solutions always welcome, but do keep the constraints in mind :-P
Exposing data to a particular party is an issue iff the security model treats that data as confidential and not intended for that party. In the current model of things, DNS queries are sent in the clear and so there is no confidentiality with respect to any party that happens to be eavesdropping.
So then thinking for a bit, we could have some transport layer security for DNS, this would provide confidentiality and integrity over the wire. We still have to share the domains we need with the service that resolves them though, so it literally cannot be kept confidential from that service. Or to put it another way, we want to receive a particular piece of information X, we can't keep it a secret that we requested X.
So then we are into distributed networks (aka TOR) and other sort of services where we accept that we cannot hide the nature of our request to the network (or else it wouldn't be able to return the requested resource) but we try to smear it out so that requests are all over the place. This would have major implications for authenticity though -- nodes in a 'mesh' DNS resolver could maliciously substitute their own resolutions.
To resolve that you need an authority like DNSSec, which means some root-level keys and that's a whole new mess.
My time is valuable to me. Unless your cultural shift somehow changes that, I can't see it.
This is only part-way true. A corporation still has substantial duties with regard to its shareholders. For instance, they can't just spend all the year's profit on hookers and blow for the board. Nor can they flat out lie.
Of course this case should be laughed out of court. But don't go so far as to say that companies have no duty whatsoever to their shareholders or that all shareholder cases are laughable.
I don't know about colloquially, but breaking to an occupied house has historically been considered a crime of violence, since it inherently carries with it the very real potential for a confrontation between the criminal and the occupants. Contrast with breaking into an unoccupied home, which is just a property crime.
Also, no one believes it would be better if the guy was shot. Any time a gun is used in anger is already very not good, the idea is to do so only when you are absolutely convinced that it's the best of a bunch of not-good options.
As for the 'second-most-gun-owners' claim, you're going to want to express this per-capita :-P
Depends on the industry. Healthcare, definitely. Law, definitely. Others: YMMV.
This whole thing is just a low-key slashvertisement to get employers in the Bay Area and Seattle to consider a branch office in NZ.
$150K is a bit over a starting salary these days.
I mean, the solution to expectations is to set expectations clearly, right? Whatever balance is chosen, the employees should be clearly informed about the policy, including what can be monitored/stored and whose approvals are necessary to read it.
If a CA inappropriately signs a leaf cert, they will be booted from the big browsers.
This is not conjectural, multiple CAs have been ejected.
Yes, that is the design tradeoff.
You might be shocked to know that there is probably an IMAP server somewhere and if you compromise it, you get to read all the archived emails and impersonate email from anyone!
And a git server somewhere if you compromise it, you get all the source and the ability to impersonate commits from anyone.