For the few equity traders that buy Bitcoin that it is rare and that the Bitcoin economy is going to grow is enough. They just buy some Bitcoin and hold on to it.

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,
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.

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.