Looks like decent specs, and ASUS phones are always reasonably priced. I'm surprised they didn't go full 4K resolution on the screen though, given it's supposed to be an "augmented reality" device.
No, but that's not the point. Nuget packages have Powershell install scripts. Nuget packages can be created by anyone. Ergo, if you're really so paranoid about security that you plan to audit every script or program you run, then you should be auditing these too.
No they aren't. All modern pathways look promising until they tried to scale them up. And both of these are subject to the non-equilibrium braking radiation problem, which appears insurmountable.
Citation needed. Polywell certainly has theoretical losses due to Bremsstrahlung radiation, but they also have a theoretical argument suggesting this should be surmountable, an argument that hasn't been definitively refuted, and requires experimental validation. The money poured into other approaches is orders of magnitude more than that required to validate Polywell.
Focus fusion has no known theoretical limitation, and they're operating with even less money.
The problem is not actually physics, its economics, and we already know fusion is not competitive.
Well that's pure bull. The economics of fusion are purely driven by the physics of fusion. Of course it looks expensive when you still don't know how to do it efficiently. This is true of every technology until the first few breakthroughs.
Are you for real? You can decompile executables and see what they're going to do too, so do you seriously expect people to audit every program they're going to run?
Just because scripts are one or two orders of magnitude smaller than executables, why should the burden suddenly fall on end users to audit when a properly designed system wouldn't need such auditing for either programs or scripts.
So here's an idea: don't design insecure systems so people don't have to do unnecessary, stupid and laborious work.
Do you read all of the Excel macros in a spreadsheet before allowing them to run? Do you read the NPM or nuget install scripts for every package before you download it so you can get your actual work done? How about for every update to every package?
You seriously underestimate the number of scripts that are automatically run during normal, every day activity. You'll be fired for low productivity if you seriously think you can audit every script or program you need to run.
Don't you use nuget if you're a.NET developer? NPM or Grunt if you do front-end web development? They all use scripts that run with your full authority, and these are used daily by tens of thousands of software developers. People who manage popular NPM packages could probably do a lot of damage if they wanted to, just by uploading a new version that does something nefarious. It's like a road runner cartoon, and we've all walked off a cliff and just keep reassuring ourselves that everything will be fine as long as we don't look down.
Even non-developers use software they download from the internet, like browsers, e-mail clients, photo apps, and even office documents with macros that can trash their systems. It has nothing to do with time-crunches, it's just a reality in our world that people use programs for just about everything; that most of these programs come from sources most people wouldn't even begin to know how to verify, even with code signing; that, even if they did know how to verify a code signature, chances are this verification step would be meaningless because they probably don't know the person or entity who signed it; that even if they did know the person(s) who signed it, they have no idea if those persons themselves were somehow vulnerable to some attack which compromised their product.
The ultimate solution can only be found in ensuring that running programs that you know nothing about is inherently safe. Verifying the source of these programs is just a very poor proxy for that property. Fortunately, it's been proven to be achievable.
There is no difference between scripts and programs. Everything I said applies equally to any software you download from the internet (browsers, e-mail clients, Office documents with macros), any packages you install via a package manager to do your development (npm, grunt, etc), etc. I think you can see that everyone downloads programs from the internet, and they face the choice of "run this and do my job or don't do my job" every day.
And it's only going to become more pervasive. All of these scripts and programs run with all of your authority, with access to all of your files.
Code signing solves one very small aspect of the security problem quite well, and then people bafflingly try to use it everywhere like a hammer thinking it will solve other problems.
This means two things: 1. the executable wasn't modified since it left the publisher's build farm, and 2. you know whom to sue if there are problems (especially in jurisdictions that don't allow a blanket disclaimer of all liability).
Which a) just costs you more time and money, b) doesn't recover your lost data, and c) plenty of people with certificates aren't in your jurisdiction. Furthermore, you overestimate how difficult it is to obtain a valid certificate. All I need to do is own a domain. Anyone can purchase a domain.
I think the idea is that when faced with an unsigned script and a competitor's signed script, users will choose the signed script because of the guarantees of an OV certificate.
Certificates don't guarantee safety, which is really all the user wants to know, right after the question of whether the script does the job they need it to do.
Furthermore, given how easy it is to obtain a domain-validated cert, your scenario isn't realistic. Users are actually faced with the choice of running two programs both of which are signed with certificates. Now how do they choose?
Some of them, like the encrypting ransomware requires no special privileges at all, but simply access to user files, and to network files that the user has read/write access to.
Those are special privileges. I don't think you truly appreciate the meaning of POLA. When you run a program with a POLA shell, it literally has access to nothing except the memory in its own address space and any parameters it's passed via the command line. Here's a simple example of copying a file in a traditional Unix shell: $ cp foo.txt foo.bak To implement the desired copy functionality, the cp command must have access to the entire local environment, including the entire file system since it can lookup an arbitrary path. This is an absurd amount of authority for a program that merely copies bytes from a source to a sink. Now here's a POLA version of the same command: $ cp < foo.txt > foo.bak Notice that the only permissions cp needs are explicitly specified in the command. They are then opened by the trusted shell and passed in as file descriptors, a read-only one and a write-only one, to the untrusted program. The explicit permission grants are obvious, and POLA shells generalize this type of pattern to compartmentalize all programs.
For whatever reason, Outlook allowed it to be executed, and the user clicked the dialog that might have prevented it, and then the script went to town encrypting files on the user's own folders and the share.
A perfect failure of POLA. In a proper least authority environment, it would have been perfectly safe to run that program because it would have had to raise a request to the environment for a set of read/write file descriptors and your user would have been rightly suspicious of any program requesting access to so many files.
Famous last words. Developers and system administrators are high-value targets since they potentially have access to numerous systems with sensitive information.
However, powershell *puroports* to have security features like execution policies and signing, so it draws more scrutiny.
Both terrible "security" policies. What would a signature possibly mean to me as a user if I don't know you? With or without a signature, my choice is still: either I run this script I need to my job, or I don't and I can't do my job (or it gets much, much harder). So basically PowerShell's security is no better than any other shell that's come before it; it projects a false sense of security, and like UAC before it, it just gets in your way.
So given the fact that getting a job done is king, and running scripts or programs written by potentially malicious people is the only reasonable way to do your job, then running arbitrary scripts must be made safe. The means to achieve this is the Principle of Least Authority (POLA), and POLA environments can and have been done before, even within commodity POSIX and Windows systems.
The earliest secure POSIX shell that I recall was Plash. Now we also have Shill (requires a kernel module) and the Capsicum shell (also requires kernel modules). Windows can be made POLA secure out of the box as was demonstrated with Polaris.
It's just amazing that we fail to learn the mistakes of the past even when solutions are available.
No, experimental data simply has to be consistent or anomalous. Anomalous requires investigation into possible errors. "Making sense" is a matter of interpretation, which is part of theoretical research, not empirical research.
Obviously, the further back you go, the less able they would be able to cope.
I'm not sure that's true. People from the recent past have already formed opinions on many subjects of modern interest, like transgenderism. Someone from the 50s would probably be quite bigoted against homosexuals and transgendered people. Someone from ancient Greece not so much, particularly since homosexuality was more accepted then.
A person who has no experience with such things would at least be able to form their own opinions rather than conform to societal norms from their time. The further removed from their time they are, the more adaptable they will be to new social norms. I imagine the same will hold for people frozen now. They'll be able to adapt more readily if they wake up 500 years from now rather than 100 years from now.
He's more like a little boy who has no idea what to do or how to do it.
Little boys and girls are tyrants. Children are sociopaths who must be trained to be civilized human beings [1]. Sometimes training doesn't take, ergo, Trump.
[1] There's a quote around there that says this better than I could, so if anyone knows it please let me know!
It is even, we might say, unreasonable and without sufficient evidence... employing logic to consider the concept reveals that there could be no such thing... First, experts usually don't know nearly as much as they think they do. They often get it wrong, thanks to their inherently irrational brains that -- through overconfidence, bubbles of like-minded thinkers, or just wanting to believe their vision of the world can be true -- mislead us and misinterpret information...
Except politicians know even less, and mislead and misinterpret even more than scientists. So basically, the suggestion isn't to move to a system of perfect rationalism, which as you've said, doesn't actually exists. The proposal is instead to move towards more rationalism driven by empirical justification. It would almost certainly be better than what we have now.
"Whatever magic ingredient determines our sexuality was different for Sulu in our timeline. I like this idea because it suggests that in a hypothetical multiverse, across an infinite matrix of alternate realities, we are all LGBT somewhere."
Except this reinforces a false narrative that sexual orientation is a choice, when it's really not. The point of divergence for the new Trek verse is after Sulu was born, and he was almost fully grown. That's not how the "magic ingredient" that determines our sexuality works.
The fact remains that women do worse on interviews than men, and hence it's not surprising that companies hire them less.
I don't think that's what it's saying. It's saying that 1.4 times as many men get a job through their site because they stick with it longer, where 7x more women than men just leave after 1 or 2 failed attempts.
[...] we need to give women the same levels of false confidence that men have in the face of constant rejection.
I can certainly support the idea of instilling more confidence despite rejection because that's perfectly rational, but I don't think the insulting label of "false confidence" is warranted.
Otherwise two historical novels of same period would be derivative works of each other.
Now you're just being obtuse. Such historical novels didn't invent the history in which they're told. If one novel invented something which wasn't actually historical, like Sherlock Holmes, and the other novel included it, then the latter might indeed be a derivative work (depending on the extent of inclusion).
Which is all beside the point, because Star Trek is clearly an invented universe, and as such, any work taken place in that universe is derivative. Even creating a documentary about Star Trek would get into trouble if it weren't covered by fair use provisions of copyright law.
Slashdot Mirror
Looks like decent specs, and ASUS phones are always reasonably priced. I'm surprised they didn't go full 4K resolution on the screen though, given it's supposed to be an "augmented reality" device.
No, but that's not the point. Nuget packages have Powershell install scripts. Nuget packages can be created by anyone. Ergo, if you're really so paranoid about security that you plan to audit every script or program you run, then you should be auditing these too.
Citation needed. Polywell certainly has theoretical losses due to Bremsstrahlung radiation, but they also have a theoretical argument suggesting this should be surmountable, an argument that hasn't been definitively refuted, and requires experimental validation. The money poured into other approaches is orders of magnitude more than that required to validate Polywell.
Focus fusion has no known theoretical limitation, and they're operating with even less money.
Well that's pure bull. The economics of fusion are purely driven by the physics of fusion. Of course it looks expensive when you still don't know how to do it efficiently. This is true of every technology until the first few breakthroughs.
So basically, a classic, well known TOCTTOU vulnerability.
Focus fusion and Polywell are also promising, but underfunded.
Are you for real? You can decompile executables and see what they're going to do too, so do you seriously expect people to audit every program they're going to run?
Just because scripts are one or two orders of magnitude smaller than executables, why should the burden suddenly fall on end users to audit when a properly designed system wouldn't need such auditing for either programs or scripts.
So here's an idea: don't design insecure systems so people don't have to do unnecessary, stupid and laborious work.
Do you read all of the Excel macros in a spreadsheet before allowing them to run? Do you read the NPM or nuget install scripts for every package before you download it so you can get your actual work done? How about for every update to every package?
You seriously underestimate the number of scripts that are automatically run during normal, every day activity. You'll be fired for low productivity if you seriously think you can audit every script or program you need to run.
Don't you use nuget if you're a .NET developer? NPM or Grunt if you do front-end web development? They all use scripts that run with your full authority, and these are used daily by tens of thousands of software developers. People who manage popular NPM packages could probably do a lot of damage if they wanted to, just by uploading a new version that does something nefarious. It's like a road runner cartoon, and we've all walked off a cliff and just keep reassuring ourselves that everything will be fine as long as we don't look down.
Even non-developers use software they download from the internet, like browsers, e-mail clients, photo apps, and even office documents with macros that can trash their systems. It has nothing to do with time-crunches, it's just a reality in our world that people use programs for just about everything; that most of these programs come from sources most people wouldn't even begin to know how to verify, even with code signing; that, even if they did know how to verify a code signature, chances are this verification step would be meaningless because they probably don't know the person or entity who signed it; that even if they did know the person(s) who signed it, they have no idea if those persons themselves were somehow vulnerable to some attack which compromised their product.
The ultimate solution can only be found in ensuring that running programs that you know nothing about is inherently safe. Verifying the source of these programs is just a very poor proxy for that property. Fortunately, it's been proven to be achievable.
There is no difference between scripts and programs. Everything I said applies equally to any software you download from the internet (browsers, e-mail clients, Office documents with macros), any packages you install via a package manager to do your development (npm, grunt, etc), etc. I think you can see that everyone downloads programs from the internet, and they face the choice of "run this and do my job or don't do my job" every day.
And it's only going to become more pervasive. All of these scripts and programs run with all of your authority, with access to all of your files.
Code signing solves one very small aspect of the security problem quite well, and then people bafflingly try to use it everywhere like a hammer thinking it will solve other problems.
Which a) just costs you more time and money, b) doesn't recover your lost data, and c) plenty of people with certificates aren't in your jurisdiction. Furthermore, you overestimate how difficult it is to obtain a valid certificate. All I need to do is own a domain. Anyone can purchase a domain.
Certificates don't guarantee safety, which is really all the user wants to know, right after the question of whether the script does the job they need it to do.
Furthermore, given how easy it is to obtain a domain-validated cert, your scenario isn't realistic. Users are actually faced with the choice of running two programs both of which are signed with certificates. Now how do they choose?
Those are special privileges. I don't think you truly appreciate the meaning of POLA. When you run a program with a POLA shell, it literally has access to nothing except the memory in its own address space and any parameters it's passed via the command line. Here's a simple example of copying a file in a traditional Unix shell:
$ cp foo.txt foo.bak
To implement the desired copy functionality, the cp command must have access to the entire local environment, including the entire file system since it can lookup an arbitrary path. This is an absurd amount of authority for a program that merely copies bytes from a source to a sink. Now here's a POLA version of the same command:
$ cp < foo.txt > foo.bak
Notice that the only permissions cp needs are explicitly specified in the command. They are then opened by the trusted shell and passed in as file descriptors, a read-only one and a write-only one, to the untrusted program. The explicit permission grants are obvious, and POLA shells generalize this type of pattern to compartmentalize all programs.
A perfect failure of POLA. In a proper least authority environment, it would have been perfectly safe to run that program because it would have had to raise a request to the environment for a set of read/write file descriptors and your user would have been rightly suspicious of any program requesting access to so many files.
Famous last words. Developers and system administrators are high-value targets since they potentially have access to numerous systems with sensitive information.
Both terrible "security" policies. What would a signature possibly mean to me as a user if I don't know you? With or without a signature, my choice is still: either I run this script I need to my job, or I don't and I can't do my job (or it gets much, much harder). So basically PowerShell's security is no better than any other shell that's come before it; it projects a false sense of security, and like UAC before it, it just gets in your way.
So given the fact that getting a job done is king, and running scripts or programs written by potentially malicious people is the only reasonable way to do your job, then running arbitrary scripts must be made safe. The means to achieve this is the Principle of Least Authority (POLA), and POLA environments can and have been done before, even within commodity POSIX and Windows systems.
The earliest secure POSIX shell that I recall was Plash. Now we also have Shill (requires a kernel module) and the Capsicum shell (also requires kernel modules). Windows can be made POLA secure out of the box as was demonstrated with Polaris.
It's just amazing that we fail to learn the mistakes of the past even when solutions are available.
You mean those with decades more experience with a subject are more skilled, knowledgeable and adept? Colour me shocked.
No, experimental data simply has to be consistent or anomalous. Anomalous requires investigation into possible errors. "Making sense" is a matter of interpretation, which is part of theoretical research, not empirical research.
I'm not sure that's true. People from the recent past have already formed opinions on many subjects of modern interest, like transgenderism. Someone from the 50s would probably be quite bigoted against homosexuals and transgendered people. Someone from ancient Greece not so much, particularly since homosexuality was more accepted then.
A person who has no experience with such things would at least be able to form their own opinions rather than conform to societal norms from their time. The further removed from their time they are, the more adaptable they will be to new social norms. I imagine the same will hold for people frozen now. They'll be able to adapt more readily if they wake up 500 years from now rather than 100 years from now.
I hope you realize you just agreed with my point.
Little boys and girls are tyrants. Children are sociopaths who must be trained to be civilized human beings [1]. Sometimes training doesn't take, ergo, Trump.
[1] There's a quote around there that says this better than I could, so if anyone knows it please let me know!
Except politicians know even less, and mislead and misinterpret even more than scientists. So basically, the suggestion isn't to move to a system of perfect rationalism, which as you've said, doesn't actually exists. The proposal is instead to move towards more rationalism driven by empirical justification. It would almost certainly be better than what we have now.
Except this reinforces a false narrative that sexual orientation is a choice, when it's really not. The point of divergence for the new Trek verse is after Sulu was born, and he was almost fully grown. That's not how the "magic ingredient" that determines our sexuality works.
I don't think that's what it's saying. It's saying that 1.4 times as many men get a job through their site because they stick with it longer, where 7x more women than men just leave after 1 or 2 failed attempts.
I can certainly support the idea of instilling more confidence despite rejection because that's perfectly rational, but I don't think the insulting label of "false confidence" is warranted.
Evidence? Specifically, what evidence exists that whatever dysfunction may exist in the common office/team/company directly follow from gender?
What happened to the party of small government and suspicion of government interfering with people's personal lives?
Now you're just being obtuse. Such historical novels didn't invent the history in which they're told. If one novel invented something which wasn't actually historical, like Sherlock Holmes, and the other novel included it, then the latter might indeed be a derivative work (depending on the extent of inclusion).
Which is all beside the point, because Star Trek is clearly an invented universe, and as such, any work taken place in that universe is derivative. Even creating a documentary about Star Trek would get into trouble if it weren't covered by fair use provisions of copyright law.