Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:I'd Like To See Electronic Voting Work (Score 1) 104

by Lennie (#49485617) Attached to: The Voting Machine Anyone Can Hack

If any electronic voting system is going to work, it would be a system that prints what you've voted so the voter can see what he/she voted. And then you have a separate electronic counting of those pieces of paper.

That way you have faster counting of votes and still everything on paper as back up.

Now I know in the past they had some what similar systems in the US and they had problems with printers not working, so I don't know if they'll ever get it right.

There are also a whole lot of people who use terms like math/encryption or blockchain.

So far I haven't seen a system that works.

It does however make for interesting presentations:

Comment: Re:Actually, it's worse than that. (Score 1) 197

by Lennie (#49477297) Attached to: Chrome 42 Launches With Push Notifications

One of the reasons browser vendors can get away with getting rid of as many plugins as possible is because they are adding features to the browsers themselves. WebEx is actually a good example.

Cisco is one of the companies working on WebRTC at W3C and IETF.

So WebEx will support it if it doesn't already I'm sure:

Mozilla and Google support WebRTC and Microsoft is working on supporting it.

About WebRTC:
- is peer2peer like Skype used to be and can do NAT hole punching if I'm not mistaken
- automatically uses a relay as a fallback if peers can't connect directly
- traffic is encrypted so the server or network can't see or change the content
- supports video/voice calling
- support for one of the most used codecs from traditional voice like analog and VoIP so sound doesn't need to be converted.
- has the best audio codec ever created for these type of applications: Opus. Which is an IETF standard created for WebRTC by Skype (before it was acquired by Microsoft) and developers
- screen/desktop sharing
- application sharing
- the standard says: browsers most support both the H.264 and VP8 video codec
- data channels (useful for example for building games)

Comment: Re:Break the key apart? (Score 1) 134

by Lennie (#49457327) Attached to: U.S. Gov't Grapples With Clash Between Privacy, Security

I believe I've seen Bitcoin Multi-Signature wallets use Shamir's algorithm:

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.

Comment: Re:The are working on it (Score 1) 89

by Lennie (#49456741) Attached to: The Problem With Using End-to-End Web Crypto as a Cure-All

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:

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 !):

Maybe later we'll also see DNSSEC/DANE to fix the first time visit on a site:

Comment: Firefox response (Score 2) 176

by Lennie (#49390779) Attached to: Chinese Certificate Authority CNNIC Is Dropped From Google Products

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.

Comment: Re:Are the CAs that do this revoked? (Score 1) 139

by Lennie (#49334205) Attached to: Chinese CA Issues Certificates To Impersonate Google

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

Comment: Re:So much for Debian 8, then... (Score 5, Informative) 338

by Lennie (#49210647) Attached to: Google Chrome Requires TSYNC Support Under Linux

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

This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.

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.

Nothing happens.