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.

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