A Bitcoin 'wallet' is the private key which allows you to spend your the Bitcoin you own. A Multi-Signature wallet is a wallet for which you need 2 out of 3 keys to spend the Bitcoin.
How something like that could be used in a secure system in this case I'm not so sure about.
Have to admit I'm not a big fan of incremental improvements over an old less secure system, but they do improve things and fix things and it's stuff that actually can be deployed on the public Internet.
Judging by the discussions on the Mozilla mailinglists I wouldn't be surprised if Firefox will include a whilelist of currently certificates issues by CCNIC and make it so no new certificates issues by CCNIC will be valid.
At least as long as they CCNIC doesn't adhere to the proper rules. Maybe CCNIC will even get stricter rules applied to them.
seccomp: implement SECCOMP_FILTER_FLAG_TSYNC Applying restrictive seccomp filter programs to large or diverse codebases often requires handling threads which may be started early in the process lifetime (e.g., by code that is linked in). While it is possible to apply permissive programs prior to process start up, it is difficult to further restrict the kernel ABI to those threads after that point.
This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for synchronizing thread group seccomp filters at filter installation time.
When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, filter) an attempt will be made to synchronize all threads in current's threadgroup to its new seccomp filter program. This is possible iff all threads are using a filter that is an ancestor to the filter current is attempting to synchronize to. NULL filters (where the task is running as SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS,...) has been set on the calling thread, no_new_privs will be set for all synchronized threads too. On success, 0 is returned. On failure, the pid of one of the failing threads will be returned and no filters will have been applied.
The race conditions against another thread are: - requesting TSYNC (already handled by sighand lock) - performing a clone (already handled by sighand lock) - changing its filter (already handled by sighand lock) - calling exec (handled by cred_guard_mutex) The clone case is assisted by the fact that new threads will have their seccomp state duplicated from their parent before appearing on the tasklist.
Holding cred_guard_mutex means that seccomp filters cannot be assigned while in the middle of another thread's exec (potentially bypassing no_new_privs or similar). The call to de_thread() may kill threads waiting for the mutex.
Changes across threads to the filter pointer includes a barrier.
"The issue is that security features are hampering performance"
This is not always true (especially in this case).
OCSP stapeling is faster than normal OCSP.
(as a side note SPDY or HTTP/2 only works with HTTPS/TLS in practice and is faster than HTTP and in many cases faster than HTTPS. Obviously TLS and even TCP on the server need to be properly configured for that as they a large number of optimizations which might not be enabled by default: https://istlsfastyet.com/ )
The summary and many commenters here are also wrong/confused about what is going on.
OCSP is a protocol to ask the CA over HTTP the status of a certificate. The CA then creates a OCSP-response which is timestamped and signed by the CA.
Every time you visit a HTTPS-website and the browser hasn't done a recent check of the OCSP-status it will ask the CA for such a status. It will ask if the certificate the webserver uses is still valid.
This means extra TCP-connections, extra DNS-lookups, extra HTTP-request, time at the CA to create that response. And even some loss of privacy (the CA and any network between you and the CA obviously now can see the site you are visiting !). This also means the CA get a lot of requests to handle and the CA is becomes a single point of failure. Vulnerable to DOS-attacks
The solution to this problem is to have the webserver request an OCSP-response from the CA at a certain interval.
Now when your browser connects to the website the webserver can include the timestamped OCSP-response in the negotiation protocol. Thus the browser doesn't need to contact the CA itself.
Thus if all webservers do this, the CA will not only not be a single point of failure any more, but also not have to create that many OCSP-responses speeding up that operation for any remaining sites.
Now why do Firefox and Chrome include an extra blacklist ?
This is because pretty much every CA included in the browser uses 'intermediate certificates'.
The browser includes a copy of only the root certificate.
It doesn't know which intermediate certificates are valid. It needs to do a seperate OCSP-request for that.
And OCSP-stapling protocol sort of has an unfortunate 'flaw', it can only include a single OCSP-response when setting up a TLS-connection.
So what do the browser vendors do: - include the root-certiciate - include a automatically updating blacklist of revoked intermediate certificates - support OCSP-stapling so they know that website-certificate is still valid.
Now you know why this is done.
And now to get back to the performance: OCSP-stapling is faster than contacting the CA directly and including a blacklist of revoked intermediate certificates is also faster than contacting a CA directly.
They all made deals and changed the way their software worked instead of paying for the patent directly.
Do you know what they changed ? They are no longer peer2peer applications anymore.
And at least in the case of Skype, we know Microsoft can decrypt the calls. And we know they have at least automated systems which watch the text-messages you send over Skype because they have an anti-spam system in place.
WebRTC does real peer2peer for free, without patents, with standardized protocols. With probably-free codecs. At least the Opus audio codec is completely free. VP8 and VP9 probably don't have problems. But you might end up talking to an endpoint which only supports H.264 so you'll need something for that.
And there are libraries which you can use that use the same protocols and you can build your own desktop or smartphone app with that if you want.
I'm sorry, but I see WebRTC as something which solves real problems we thought we didn't have a couple of years ago.
Let me be clear: what applies to Azure as a foreigner applies also to Amazon/AWS, Google, Rackspace, IBM/SoftLayer, CenturyLink, DigitalOcean, Vultr, Linode, PeerOne or any other US-based company (even if they run the service in Europe for example).
I doubt it. They are in the business of selling products and services, they don't care what they can sell. They are a business trying to make money and stay relevant.
If running a porn streaming service wouldn't damage their image and was something they thought they knew how to run well and make good money on, I'm sure they would just add it to their list of services.
Now to be a bit more specific, of course they want your data. You see this happening especially on the consumer side.
For example: where can I get a copy of SkyDrive/OneDrive/whatever which I can run on my own systems ?
I read some companies have a policy that the people developing the microservice should also develop the client library for that microservice.
So in that case if you add more languages to an organization, you'll add a lot more overhead (every team would have to have at least one member that knows each language used in the origination, or at least the language of the other team which wants to talk to the microservice).
But I guess I was late with my comment, but I didn't get any extra points for it.;-)
You know, I don't always have time to keep an eye on what is going on the industry and lots of information/knowledge is spread around all over the place. But it only takes a few months to figure this stuff out.;-)
As I mentioned above, it's not so much about the language you use it's about applying it to the right task.
node.js might or might not apply to what you need.
You see some companies do: Node.js here because we got a good templating system, Go for this new part and Erlang for that other part because a really good open source system X already exists for that and Java for that other part because of open source library Y.
So it's very much about seperation of concerns and using the best tool (read: language and existing other libraries or databases) for the task.
The other part is: Deploying different services seperately (don't let deployment/update of one service depend on the deployment of an other). That is why different services don't share their databases. So they can be updated seperately.
In larger companies, like Netflix, they put a seperate team on every microservice. They are completely self-organising, like a little startup or something like that. They choose the best tools for the microservice they are supposed to build and develop further.
Slashdot Mirror
I believe I've seen Bitcoin Multi-Signature wallets use Shamir's algorithm:
https://en.wikipedia.org/wiki/...
A Bitcoin 'wallet' is the private key which allows you to spend your the Bitcoin you own.
A Multi-Signature wallet is a wallet for which you need 2 out of 3 keys to spend the Bitcoin.
How something like that could be used in a secure system in this case I'm not so sure about.
Have to admit I'm not a big fan of incremental improvements over an old less secure system, but they do improve things and fix things and it's stuff that actually can be deployed on the public Internet.
Examples are better revocation that actually works:
https://wiki.mozilla.org/CA:Im...
https://blog.mozilla.org/secur...
Making sure regular visitors on sites always use HTTPS and only allow for certain public keys (the last one fixed the CA system for regular visitors !):
http://en.wikipedia.org/wiki/H...
https://developer.mozilla.org/...
Maybe later we'll also see DNSSEC/DANE to fix the first time visit on a site:
http://en.wikipedia.org/wiki/D...
"people also like to possess it because it is rare"
That is what Bitcoin also garantees, it's rare.
You can precisely known how many Bitcoins there were, are or will be at a certain time.
The technical people are actually working on this problem:
1. make it super easy to encrypt all websites:
https://letsencrypt.org/
2. In the long run:
"Marking HTTP As Non-Secure"
https://www.chromium.org/Home/...
And many, many more improvements.
Steve Ballmer was talking about the GPL.
With open source they mean an open source license.
I really doubt they are talking about a free software license the GPL.
The reasons might end up being less important than the actions.
Here is the official announcement:
https://blog.mozilla.org/secur...
Here is a link to the latest Mozilla statement on the mailinglist/newsgroup:
https://groups.google.com/d/ms...
Judging by the discussions on the Mozilla mailinglists I wouldn't be surprised if Firefox will include a whilelist of currently certificates issues by CCNIC and make it so no new certificates issues by CCNIC will be valid.
At least as long as they CCNIC doesn't adhere to the proper rules. Maybe CCNIC will even get stricter rules applied to them.
Actually iDeal is exceptionally good in comparison to a whole lot of other countries.
Your bank still has an office you can go to ?
Mine doesn't anymore, they are busy getting rid of all their bank locations and clerks.
Automation is what they want.
And getting rid of cash seems to be a policy.
They are even reducing the number of ATMs.
This doesn't just apply to the my bank, but all banks in my country.
Even if they had an office I could go to, I doubt the clerk knows security procedures well enough to check if my ID is correct.
So, no, I don't think your idea will work. :-(
Here is the kernel commit message:
seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.
This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.
When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, ...) has been set on the calling thread, no_new_privs will be set for
filter) an attempt will be made to synchronize all threads in current's
threadgroup to its new seccomp filter program. This is possible iff all
threads are using a filter that is an ancestor to the filter current is
attempting to synchronize to. NULL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS,
all synchronized threads too. On success, 0 is returned. On failure,
the pid of one of the failing threads will be returned and no filters
will have been applied.
The race conditions against another thread are:
- requesting TSYNC (already handled by sighand lock)
- performing a clone (already handled by sighand lock)
- changing its filter (already handled by sighand lock)
- calling exec (handled by cred_guard_mutex)
The clone case is assisted by the fact that new threads will have their
seccomp state duplicated from their parent before appearing on the tasklist.
Holding cred_guard_mutex means that seccomp filters cannot be assigned
while in the middle of another thread's exec (potentially bypassing
no_new_privs or similar). The call to de_thread() may kill threads waiting
for the mutex.
Changes across threads to the filter pointer includes a barrier.
https://git.kernel.org/cgit/li...
I don't think Docker is aimed at the enterprise, it's aimed at making it easier to deploy applications.
Let's take a really complicated cloud application,.... the OpenStack services.
Docker can used to deploy Openstack in 3 min.:
https://www.youtube.com/watch?...
"The issue is that security features are hampering performance"
This is not always true (especially in this case).
OCSP stapeling is faster than normal OCSP.
(as a side note SPDY or HTTP/2 only works with HTTPS/TLS in practice and is faster than HTTP and in many cases faster than HTTPS. Obviously TLS and even TCP on the server need to be properly configured for that as they a large number of optimizations which might not be enabled by default: https://istlsfastyet.com/ )
The summary and many commenters here are also wrong/confused about what is going on.
OCSP is a protocol to ask the CA over HTTP the status of a certificate. The CA then creates a OCSP-response which is timestamped and signed by the CA.
Every time you visit a HTTPS-website and the browser hasn't done a recent check of the OCSP-status it will ask the CA for such a status. It will ask if the certificate the webserver uses is still valid.
This means extra TCP-connections, extra DNS-lookups, extra HTTP-request, time at the CA to create that response. And even some loss of privacy (the CA and any network between you and the CA obviously now can see the site you are visiting !). This also means the CA get a lot of requests to handle and the CA is becomes a single point of failure. Vulnerable to DOS-attacks
The solution to this problem is to have the webserver request an OCSP-response from the CA at a certain interval.
Now when your browser connects to the website the webserver can include the timestamped OCSP-response in the negotiation protocol. Thus the browser doesn't need to contact the CA itself.
Thus if all webservers do this, the CA will not only not be a single point of failure any more, but also not have to create that many OCSP-responses speeding up that operation for any remaining sites.
Now why do Firefox and Chrome include an extra blacklist ?
This is because pretty much every CA included in the browser uses 'intermediate certificates'.
Thus a certificate chain looks like this:
- CA-root-certificate
- intermediate certificate
- website-certificate
The browser includes a copy of only the root certificate.
It doesn't know which intermediate certificates are valid. It needs to do a seperate OCSP-request for that.
And OCSP-stapling protocol sort of has an unfortunate 'flaw', it can only include a single OCSP-response when setting up a TLS-connection.
So what do the browser vendors do:
- include the root-certiciate
- include a automatically updating blacklist of revoked intermediate certificates
- support OCSP-stapling so they know that website-certificate is still valid.
Now you know why this is done.
And now to get back to the performance: OCSP-stapling is faster than contacting the CA directly and including a blacklist of revoked intermediate certificates is also faster than contacting a CA directly.
Yes, that is similar. Thanks, I had forgotten the name of it.
The real question is:
Why are you still using Windows ? ;-)
What I like about WebRTC is that it restores the 'end-to-end encrypted' part we had lost.
Skype, Facetime and others were all sued by this company which has patents:
http://arstechnica.com/apple/2...
They all made deals and changed the way their software worked instead of paying for the patent directly.
Do you know what they changed ? They are no longer peer2peer applications anymore.
And at least in the case of Skype, we know Microsoft can decrypt the calls. And we know they have at least automated systems which watch the text-messages you send over Skype because they have an anti-spam system in place.
WebRTC does real peer2peer for free, without patents, with standardized protocols. With probably-free codecs. At least the Opus audio codec is completely free. VP8 and VP9 probably don't have problems. But you might end up talking to an endpoint which only supports H.264 so you'll need something for that.
And there are libraries which you can use that use the same protocols and you can build your own desktop or smartphone app with that if you want.
I'm sorry, but I see WebRTC as something which solves real problems we thought we didn't have a couple of years ago.
I actually didn't see this story as news, I had seen a video of there work last year from before they were bought by Google.
That same video was linked from the article:
https://www.youtube.com/watch?...
What makes this more interresting is, they didn't tell the AI how to play the game, they let the AI learn to play the game on it's own.
I think one of the things this what makes this also interresting is how few times the AI needed to learn the game and then also be good at it.
The only other solution I can think of is some kind of micropayments system, like with a cryptocurrency.
Vending machines in Japan seem to carry pretty much anything. It's surprising what they can come up with.
Like vending machines with live crab.
I would suggest: _Aardvark007
But important parts are missing.
Some examples:
- AzureAD, specifically ACS
- Site Recovery for disaster recovery
These are all online services with no buy/download equivalent from Microsoft.
Let me be clear: what applies to Azure as a foreigner applies also to Amazon/AWS, Google, Rackspace, IBM/SoftLayer, CenturyLink, DigitalOcean, Vultr, Linode, PeerOne or any other US-based company (even if they run the service in Europe for example).
But I noticed there are others in the world, for example on the OpenStack Marketplace:
http://www.openstack.org/marke...
I doubt it. They are in the business of selling products and services, they don't care what they can sell. They are a business trying to make money and stay relevant.
If running a porn streaming service wouldn't damage their image and was something they thought they knew how to run well and make good money on, I'm sure they would just add it to their list of services.
Now to be a bit more specific, of course they want your data. You see this happening especially on the consumer side.
For example: where can I get a copy of SkyDrive/OneDrive/whatever which I can run on my own systems ?
Anyway, I can't use Azure, I'm a foreigner:
http://media.ccc.de/browse/con...
I would think the number of languages magic number can be slightly higher if you have more development teams/microservices.
What I do know Amazon has a maximum size per development team/microservice: 2 pizza's
https://blog.bufferapp.com/sma...
I read some companies have a policy that the people developing the microservice should also develop the client library for that microservice.
So in that case if you add more languages to an organization, you'll add a lot more overhead (every team would have to have at least one member that knows each language used in the origination, or at least the language of the other team which wants to talk to the microservice).
But I guess I was late with my comment, but I didn't get any extra points for it. ;-)
You know, I don't always have time to keep an eye on what is going on the industry and lots of information/knowledge is spread around all over the place. But it only takes a few months to figure this stuff out. ;-)
As I mentioned above, it's not so much about the language you use it's about applying it to the right task.
node.js might or might not apply to what you need.
You see some companies do:
Node.js here because we got a good templating system, Go for this new part and Erlang for that other part because a really good open source system X already exists for that and Java for that other part because of open source library Y.
So it's very much about seperation of concerns and using the best tool (read: language and existing other libraries or databases) for the task.
The other part is:
Deploying different services seperately (don't let deployment/update of one service depend on the deployment of an other). That is why different services don't share their databases. So they can be updated seperately.
In larger companies, like Netflix, they put a seperate team on every microservice. They are completely self-organising, like a little startup or something like that. They choose the best tools for the microservice they are supposed to build and develop further.