skysight-inc/HackerNews huggingface dataset:
Push vs. pull for backups is an interesting philosophical issue, and there's some good discussion of it below. For many setups, pull really doesn't make sense. For example, one of the machines I backup is my personal laptop, and I back it up to a completely untrusted VPS. Therefore I want to be able to encrypt locally and push that encrypted data to the remote VPS. Pulling wouldn't work here, because then I'd have to hand the keys to my laptop to the VPS.

The scenario you're describing, however, sounds like the opposite in terms of trust. And in that case pull may make sense. However it doesn't sound like attic itself natively supports that sort of config. I could envision a sort of hybrid approach where the local machine encrypts to a local attic repository, and then the remote backup server pulls a copy of it. There's nothing stopping you from setting that up, either with attic as-is or with this wrapper script.
The Bad Dragon sex toys I've handled aren't 3d printed. (You wouldn't expect them to be, since 3d printer output is rigid plastic, which you don't want a sex toy to be, and covered with fine ridges, which you really don't want a sex toy to be.)

It's possible that the molds are 3d printed, but if they are, it's using a printer with amazing surface finish, and Bad Dragon's never said anything about using 3d printing. Much more likely they're using conventional manufacturing processes.
I visited Harrapa & Mohenjo-daro many times as I've lived there for the most of my life. I also visited nearby museums and saw the Harappan art, tools etc.

I didn't see a single art warfare ever or a soldier's sword or any war-weapon like thing at all. I've been reading about Indus civilisation since I was 10 but in almost all the time, I came to conclusion that Indus Civilisation was one of the most peaceful era of all that area (I'm not comparing that time with now but relative to other parts of the world at that time).

It is very unfortunate that India & Pakistan has most of the cities as unplanned, dirty & polluted even though they have some of the most fascinated civilisation buried behind their backyard.
Look, if you're gonna down vote at least give reasons. I fail to see how "what is the problem this is solving" (the basic question every entrepreneur asks) is not a legitimate question about this, especially given the fanfare it has in the tech. press.
I run Apache httpd, and there's no way I'd let a wizard anywhere near my configuration files or private keys, much less run it on a production server.

I think it's about time for a free CA that is recognized by all clients, but you still need to establish a trust chain to exchange a CSR for a signed certificate. This service needs to be server agnostic. The barrier to adoption isn't configuration, and HTTPS isn't the only thing that uses certificates.
Elon Musk: SpaceX Will Launch Micro-Satellites
I'm trying to put together a panel on that topic, but it's hard to find people to represent the "asshole" side of the discussion.

Original call for speakers: "For the 2015 edition, we are looking for speakers and panelists. A touchy topic we’d like to address is "ethics in Silicon Valley – startups playing dirty can't be the new normal". If you are qualified and willing to discuss this topic on stage, get in touch"

So far, no takers...
I've also been using sneakemail for at least twelve years. They also let you set up addresses with a bunch of randomly generated letters/numbers that are opaquely mapped to you, but you have to log in to do that.

The only problem is that some sites ban their domains - in particular Adafruit does this (they banned existing use of it, not just new sign ups), and their support said basically "we won't whitelist your address even though you've been ordering stuff from us for over five years".
This is great news, but I am wondering how they will handle revoking certificates. For example: Do we really want malware sites popping up with valid Ssl certificates?
Here's a video showing what he does with them:

https://www.youtube.com/watch?feature=player_embedded&v=CnUz...

Can't say i'm particularly impressed, since the delay is quite large and a kinect could do the same thing.
The "How It Works" page (https://letsencrypt.org/howitworks/) says:

- Obtain a browser-trusted certificate and set it up on your web serve

IdenTrust is listed as a sponsor and is the CA for the letsencrypt.org certificate so I'm guessing they're doing some sort of partnership.
Any company moving into such a territory, should state their position about surveillance.
How to Create a Successful Infographic
Source: http://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-10081/151...
I mean ordinary people who will visit the page.
No, unfortunately the MAC randomization seems to be pretty ineffective. IIRC, it only happens when the phone is sleeping, and has been for several minutes.
http://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac...
IdenTrust will be cross-signing our roots while we apply to root programs.
Interesting. Was unaware of this company till I saw some backlash on Hackaday (and they call out HN for blocking this backlash).

Neat stuff.

http://hackaday.com/2014/11/18/thalmic-labs-shuts-down-free-...

Can anyone address the concerns with the recent shut down of developer access?
Toyota’s $63,000 Mirai Greeted by Japan’s Prius-Like Bet
Family refers to all members of a family - adult members AND children. So, by threatening someone's family, one implicitly threatens any members of a family who are children (as well as the other members of a family).
You raise a good point though, SSL/TLS Certs are trying to deal with two separate problems:

1. Over the wire encryption (which this handles)

2. As a bad, but the best we've got site identification system for stopping phishing mechanism.

Currently, for even the cheapest certs (domain+email validated) - the CAs will reject SSL cert requests for anything that might be a phishing target. Detecting "wellsfargo.com" is pretty easy, where it gets tricky is things like "wellsforgo.com", "wellsfàrgo.com" etc. Which if I'm looking at this right will just sail through with LetsEncrypt.

I suspect we're going to actually end up with two tiers of SSL certs as the browser makers have started to really de-emphasize domain validated certs [1] like this vs the Extended Validation (really expensive) certs, to the point where in most cases now having a domain cert does not know green (and maybe doesn't even show a lock) at all.

As a side note, Google had announced that they were going to start using SSL as a ranking signal [2] (sites with SSL would get a slight bump in rankings), from this perspective the "high" cost of a cert was actually a feature as it made life much more expensive on blackhat SEOs who routinely are setting up hundreds of sites.

1 - Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-s...

2 - http://googlewebmastercentral.blogspot.com/2014/08/https-as-...
Can't you just delete the CA from the browser?

On Firefox it's preferences -> advanced -> certificates -> view certificates.
Adobe Flash is an outright offense if you ask me. A distro providing a separate repo for non-free software is one thing, forcing me to run uninspectable code, which is known to have a horrible security record, under my user's privileges, is another thing. As OpenBSD people say, it's a feature that it's missing. :-P

I don't know what problem with media codecs there are. FFmpeg, as free software, implements H.264 just fine, even though it's a patented format. I don't know how exactly the legal aspects of that work, but I'm happy it somehow works, because otherwise I couldn't watch all my [spoiler]Chinese cartoons[/spoiler].

Now WiFi cards are a problem from what I know. You can buy a WiFi dongle with free software drivers though to get around that issue, or replace your laptop's WiFi card with one that has free drivers. I suspect that will be the one major issue with the GNU OS, and the only thing we can do is ask manufacturers of WiFi hardware to be more cooperative.

The other big problem tends to be the BIOS, but GRUB/Linux-libre at least boot just fine on proprietary BIOS, so it's no issue for those who don't care. Those who want to take the further step for software freedom may want to look into LibreBoot: http://www.libreboot.org/
Great article man !
Wish you the best with Coinalytics !
It is not a legitimate requirement.

HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy.

In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used. The content provider can have a process that sits on top of a VPN / Tor that periodically requests a resource from the server and if it detects that the service is being MITM then it can shut down the service and a certificate authority can be brought in.

Edit: Also, all this BS about how HTTPS implies security is besides the grandparent's point: certificates and encryption are currently conflated to the great detriment of security, and they need not be.
I'm not entirely sure I understand your point, so if I misunderstood you please correct me.

First, TLS has three principles that, if you lose one, it becomes essentially uselsss:

1) Authentication - you're talking to the right server

2) Encryption - nobody saw what was sent

3) Verification - nothing was modified in transit

Without authentication, you essentially are not protected against anything. Any router, any government can generate a cert for any server or hostname.

Perhaps you don't think EV certs have a purpose - personally, I think they're helpful to ensure that even if someone hijacks a domain they cannot issue an EV cert. Luckily, the cost of certificates is going down over time (usually you can get the certs you mentioned at $10/$150). That's what my startup (https://certly.io) is trying to help people get, cheap and trusted certificates (sorry for the promotion here)
> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool"

no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on".

Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private.

Unfortunately, there is no way to guarantee that to be true if the identity of the server certificate can't somehow be tied to the identity of the server.

So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown.

But the moment you accept the connection over ssl, the user agent assumes the connection to be intended to be private and failure to assert identity becomes a terminal issue.

This doesn't mean that the CA way of doing things is the right way - far from it. It's just the best that we currently have.

The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.
Why do all of these services insist on you giving them your mobile number? Even Telegram, which claims to be the all giving god of encryption and privacy, insists on having it no matter what. It's a massive barrier to entry which I'm not willing to cross, and I'm sure other people aren't either.
To be honest, I've abandoned that use for some years now and use simply a catch-all on my domains. Much easier to use, especially as many larger organizations rejecting the + because of "fake" email address.
Visualization Is for Sharing: Using React for Portable Data Visualization
I'm not sure I follow that line of reasoning. Each CA is independently and completely able to issue certificates (not counting EV, but let's leave that out). There are hundreds of CAs. Depending on your trust store, some of them are literally owned by the US Department of Defense. Others are owned by the Chinese government.

How does having _fewer_ CAs make anything easier? Why is the EFF a better route than any of the various other companies that have gotten themselves in the CA program? And given that all the CAs are equivalently trusted at a technical level, why does the human trust afforded the EFF affect whether it's a better target?
That seems more like an ad-hominem than anything.

Their secret chats specifically seem like they would be entirely secure.
The tool will gather the domains, use the CA API to validate ownership, obtain the certs (which cannot be unilaterally created since they are based on a public/private key pair) and manage their expiry.

That's a bit more then "giving us a cert"
I'm pissed off 'cos I'm on the board for rationalwiki.org and we have to pay a friggin' fortune to get the shiny green address bar ... because end users actually care, even as we know precisely what snake oil the whole SSL racket is. Gah.
We have DNS system in place which should be enough to establish trust between browser and SSL public key. E.g. site could store self-signed certificate fingerprint in the DNS record and browser should be fine with that. If DNS system is spoofed, user will be in bad place anyway so DNS system must be secured in any case.
Lots of services create dynamic subdomains in the form of "username.domain.com". To offer SSL on those domains without a wildcard certificate, you'd need to obtain a new certificate and a new IPv4 address every time a user signs up. You also need to update configuration and restart the web server process.
Effective Modern C++ by Scott Meyers [video]
Classic CompSci papers every Software Architect should read
Privacy and Security Principles for Farm Data
Here's some comparison screenshots of the "bling" that is being described (hard to even tell that some of these sites are SSL'd without getting the EV)

https://www.expeditedssl.com/pages/visual-security-browser-s...
You're absolutely right. From first principles, HTTP should have a louder warning than self-signed HTTPS.

Our hope is that Let's Encrypt will reduce the barriers to CA-signed HTTPS sufficiently, that it will become realistic for browsers to show warning indicators on HTTP.

If they did that today, millions of sites would complain, "why are you forcing us to pay money to CAs, and deal with the incredible headache of cert installation and management?". With Let's Encrypt, the browsers can point to a simple, single-command solution.
Can you clarify what's wrong with nixpkgs? https://github.com/NixOS/nixpkgs

Granted, it's not yet perfect, but my experience with it so far has left me very impressed.
Whos auditing the ca?
It isn't always easy when something does seem to be common knoweldge, but you are correct that people try to be more understanding. I have adopted the attitude from this XKCD comic. https://xkcd.com/1053/
That's some nice citations there, buddy. Burden of proof doesn't fall on the accused.
We will look for ways to mitigate the risk of misissuing for any reason, including because someone tries to coerce us to misissue. One approach to this that's interesting is Certificate Transparency.

http://www.certificate-transparency.org/

There's also HPKP, TACK, and DANE, plus the prospect of having more distributed cert scans producing databases of all the publicly visible certs that people are encountering on the web.
You're getting caught up in implementation details. It fulfills the functional requirements in debian, shows that the problem is common to all package managers, it reveals that this corner case has been touched by deb and in the end reinforces my original points that:

a) The requisites for most package managers out there are not that different (i.e. it's the same problem).

b) We have the problem so beaten down that we should be able to properly define the solution boundary.

Is the deb solution suboptimal? Probably. It's not relevant to the main point being argued.
Ironic or facetious?
The idea that people can't be forced to arbitrary behaviour is not the same as the idea that people's minds are rigid. Also modern war is not what it used to. You need huge organization, funds and convincing people to risk their lives.

Except maybe in the USA, that patriotic feeling is no longer prevalent in first world countries. And that with professional armies. What happened last time you had forced draft? Was it Vietnam?

You'd need a huge amount of money for propaganda that would fire back anyway. A sensible percentage of population sees the (usually economic) interests through the justifications.
Yes. This CA will be cross-signed.
Yes you can. Obviously, you can choose not to make secure connections with sites certified by a CA you don't trust. But then you just can't use your bank's website anymore, or your search engine, or whatever.

Users have a clear stake in whatever informational exchange occurs between them and the websites we access. We should have the authority to participate in determining the terms on which that exchange is secured.
> This by itself indicates warfare.
.. or protection from animal predators.
Yes, this will only hit the common small-site case. Hopefully if you're running "multiple web apps across multiple servers using a load balancer" you will have the skill to configure HTTPS properly for that situation, which will probably involve custom configuration on the load balancer. It's not a criticism of something trying to solve the common case, where the common solution up until today is pretty much "just forget about it", that it doesn't work at "cloud scale".
The vast, vast majority, though, of the Chinese internet population do not use VPNs, nor will they when most of what they want/need is available on domestic sites. The slice of the population that deals with the West is tiny, and comparatively unlikely to cause problems. The chilling effect that just needing a VPN has on exploration of accurate foreign information about China and what's happening in the country is substantial and intended.
One possible solution is a BitCoin-like block chain of certificate proof, so that a website's certificate can be verified against the domain without a central authority.
Booster shots: The accidental advantages of vaccines
WhatsApp to encrypt billions of messages a day
No, it will be cross-signed and provide the chain so that it will work immediately in all mainstream browsers.
> no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on".

That would be correct if you could assume that the NSA couldn't fake certificates for websites. But it can, so it's wrong and misleading. It's certificate pinning, notary systems etc. that actually give some credibility to the certificate you're currently using, not whatever the browsers indicate as default.

FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ...
It Ain’t Easy Making Money in Open Source:  Thoughts on the Hortonworks S-1
That's all good in theory, but there have been demonstrated attacks against man-in-the-middle-able protocols and we've lacked the ability to respond usefully, precisely because the protocols were designed to be man-in-the-middle-able. Everyone knows it's happening and it's even easier to detect than your example, but there's nothing useful to do with that knowledge other than complain.

https://www.eff.org/deeplinks/2014/11/starttls-downgrade-att...
There is no reason for the CA to ever see the private key. All they need is a CSR. This approach is fundamentally broken.
Thank you! It should be HN policy to not post paywall sites IMO
Organovo announces preclinicial release of 3d-printed liver tissue
Let's Encrypt is going to publish records of everything it signs, either with Certificate Transparency or some other mechanism.

Browsers will be able to check any cert signed by the Let's Encrypt CA against the published list. If there's a discrepancy, that will be immediately detectable.
I agree 20% is excessive if the recruiter just told someone about the job, but it seems like they should still get something for finding the future employee in the first place.
I don't suppose they will open source the WhatsApp client as part of this. Assuming so, that sounds like a compromise for Open Whisper Systems.
Same here, it's quite often, actually. Enough that I won't do it anymore.
Polar vortex defined: Here's what's really happening with stratospheric warming
Whatsapp requires a telephone number as it uses that for your ID. Same with RedPhone. TextSecure (android) can certainly be used without registering -you just miss out on the push-via-data service.
App Flipping
The NSA has no CA. The only attack they really have is brute force or server compromise - both of which undermine pinning.
The underlying data here comes from the Ptolemy instrument, a gas chromatograph mass-spectrometer (ion trap, in this case) which can measure ratios of molecules in a range of 14 to 140 Da. (It might also be able to identify somewhat larger species by inducing fragmentation and measuring the resulting pattern of smaller molecules within the effective mass range, but I haven't found if this capability was included).

Some more info here:
http://www.lpi.usra.edu/meetings/lpsc2006/pdf/1937.pdf

and: http://sci.esa.int/rosetta/31445-instruments/?fbodylongid=89...

The instrument has its own Twitter feed, of course: https://twitter.com/philae_ptolemy
Easier to just get a custom domain and set up a catch-all account to forward to your gmail.

This way you can do [sender]@domain.com, [company]@domain.com, john1, john2, john3@domain.com and never run out of options. If one starts spamming you can just stop a particular [company]@domain from forwarding.
Lead dev here:

Before writing Colossus I had worked with Finagle for several years, and we still use Finagle for some of Tumblr's older systems. There's definitely overlap in functionality between the two and Colossus definitely borrows some ideas from Finagle, but there are also several significant differences:

For the use cases that lead to its development, Colossus is significantly better performing. In the blog post, when I mention "performance problems we faced with existing frameworks we tried", Finagle was the framework we had moved away from. For example, with Colossus you can keep most I/O related code in the event loops without having to use Futures or any other type of out-of-thread concurrency. This alone has a pretty big impact on throughput for the kinds of small requests our services handle. Overall we gained a 4-5x improvement in throughput and much better tail latency.

Finagle still has its own implementations of Future, Try, Duration, and other types that have been part of the Scala standard library for quite some time now. This makes it very unwieldy to use with other popular Scala libraries, especially Akka, which we use quite heavily now. Finagle also still does not build for Scala 2.11 (though it looks like they're close).

Lastly, because Finagle is written on top of Netty, I think a lot of Netty's Java-ness bleeds through: factories, builders, thread pools, etc. Also, between Finagle, its companion util lib, and Netty, you have a massive amount of code to sort through to understand how something works. That becomes a pretty big barrier to entry when trying to do anything beyond the basics, and was a big factor preventing us from writing more services.
Anyone can write shit code. Decent maintainable code that works, is a different matter.
I've got an Asus Memopad FHD 10 that's running Intel; it was about $30 cheaper than anything similarly specced last Christmas, and I've been generally pleased with it (although system updates tend to break Hangouts for a bit, which I blame on the uncommon platform).
TIL there are still payphones!?