I wonder what would be wrong with a few Digital Ocean or Kimsufi VPS or microserver systems? If managing your own server daemons is too hard, I wonder what that person is doing in the field of computing?
Trusting cheap vps company to host your business apps isn't a smart idea. Btw what makes you capable of deciding who should or shouldn't work in the field of computing?
Google and AWS provide a lot of things that Digital Ocean don't. Auto scaling to millions with Google, so much stuff with AWS that you can't keep track of it. (eg "Today, the AWS Marketplace contains more than 1,000 listings in 24 categories ranging from big data to bug-tracking to business intelligence"). That said for your typical startup with a small number of users the simpler providers may be the way to go.
Focus on building your product and don't worry about complex infrastructure. Google manages your application, database, and storage servers so you don't have to.
Very seductive of simple minds. Congratulations, Google, you have discovered of how to start fishing for the bottom of the barrel ...
Vladimir Voevodsky is making an interesting step when he says that rewrite steps in math are clearly homeomorphisms. I would like to see some more formal examples of that. It sounds like a promising path.
Concerning the replacement of ZFC by Russell types -- contrary to lambda calculus' functions -- I have not run often enough in illustrations that demonstrate the usefulness of Russell types.
I am personally much more vouching for a replacement of Zermelo and Fränkel's sets by Alonzo Church's functions than Bertrand Russell's types at this point. It is probably just an issue of lack of familiarity, though.
Well, there must be something seriously wrong with healthcare funding if the workers need to protest at a seemingly unrelated office, that is, the one of Microsoft. What if they decided to relocate?
I totally agree that witch doctors, commercialized superstition, and spiritual hypocrites plague the realm of religion. But then again, plaguing the field of software, we have Microsoft, Apple, and other witch doctors. Does that mean that we should abandon the field of software? There is also linux, gnu, github and lots of other useful things, no?
It very much looks like a situation in which the system has already been compromised and is running malicious programs that it shouldn't. These malicious programs could still face the hurdle of being held at bay by the permission system that prevents them from reading your key file.
However, they could indeed be able to circumvent the permission system by figuring out what sensitive data your program left behind in uninitialized memory and in CPU registers.
Not leaving traces behind then becomes a serious issue. Could the kernel be tasked with clearing registers and clearing re-assigned memory before giving these resources to another program? The kernel knows exactly when he is doing that, no?
It would be a better solution than trying to fix all possible compilers and scripting engines in use. Fixing these tools smells like picking the wrong level to solve this problem ...
I'm not sure this is the scenario we're fighting. The problem is when your program (which handles sensitive data) has a flaw in it: for example, it might be possible to trick it into leaking uninitialized data (possibly out of bounds) over the wire. Another potential issue is core dumps (and maybe swapping, but that's a little different). You don't want sensitive data to be written on the disk.
Malicious programs running with your program's privileges are a different scenario altogether, and usually they can do a lot of damage. Want sensitive information out of another process? Try gdb.
But yes, it is trivial for the kernel to zero a page before handing it out.
What about malicious programs without privileged access ? Is it possible for them to just keep requesting new memory pages from the kernel and see leaked data that was free'd by another process they shouldn't have access to or is this something kernels are already preventing ?
In NDN, all data is signed by data producers and verified by the consumers, and the data name provides essential context for security.
Centralizing the concept of security in the network's architecture will create an intractable problem. Certain parties will still want to impose their desire to be able to eavesdrop on the data. Therefore, there cannot be any real security in such centralized design for security.
The in tempore non suspecto in which it was still possible to roll out security jokes such as SSL, is over now. Nowadays, 95% of the world population (and their governments) will refuse to adopt any centralized security design, because they do not trust it.
I'm wondering how the proposed security model differs from current practices. What you've quoted doesn't seem different. After all, on the web today, data producers send a certificate which the client "verifies". At least the long list of "CA" names in my browser purports to be "verified" by an "authority".
The part that got my attention was the criminals having fooled users into revealing passwords using certificates purchased from CAs (at a total cost of $150,000).
That seems to mean the current CA system is broken. It's not a big surprise that a centralized security concept is in NDN--Verisign is one of its main supporters.
I think this is the first time I've heard of NDN, and I've only spent a short while reading about it. My first impression is:
1) It involves addressing chunks of data rather than hosts that hold those chunks. Somewhat like using URLs at the network level. So instead of IP/HTTPS where the network learns of host communications without learning of specific data exchanges, NPN would reveal those specific data exchanges to the network.
2) The mandatory "signature, coupled with data publisher information, enables determination of data provenance..." aspect would cut both ways. For we would be data consumers in some contexts and data producers in other contexts.
I hope I read something to dispel my concern, but I worry about increased metadata exposures and reduced ability to achieve beneficial levels of privacy/anonymity.
As usual, people ranting on HN without bothering to read what they're ranting about.
You're assuming centralization. All that's in the specs are slots for a locator and signature value. It's left up to the application to define trust semantics be it PKI, WoT or whatever.
That is why I'm of the mind that both canonical identity and permission need to be managed in a globally distributed fashion with blockchain. In order to facilitate the level of data transfer that would need to happen between devices to accommodate the distribution of global scale permission data, networking does need to change fundamentally.
I envision my fridge having a permission entry that neighbor can use my car tomorrow, and also that a person I will never meet has purchased a ticket for a flight to Argentina next week. That data is constantly being shared on a mesh network with my car and everybody else's I drive down the road next to, across all of my devices and those of every other participant. No government or corporation should be able to have the whole set of data, and none of it should be able to have a very long half-life.
The only way we can move forward to a truly connected version of the future is with trust, and the only way to have a truly trusted security model is to have it be globally distributed. NDN may or may not be the next version of networking to support it, but I'm rather confident that TCP/IP isn't going to be the way we get there.
As much as I like the idea that all communications should be confidential, your response doesn't refute the original poster's point, which is that any architecture that is impervious to eavesdropping would not be adopted by parties who want to impose their desire to eavesdrop on it, which is (according to the original poster) 95% of the world population (and their governments). (citation needed)
> I hope fighting that strawman you built was fun, but I really don't know where the BS snark came from.
The BS snark which started it was your still-unsupported assertion that “SSL is a security joke”.
> Well written code is always better than the crap that OpenSSL was (crap as admitted by most of security experts and groups working with it).
It's easy to criticize OpenSSL and, well, every other SSL library which has had problems. It's a lot harder to replace it and actual security experts have thus far chosen to overhaul OpenSSL rather than trying to replace it from scratch. I trust the judgment of the OpenBSD and Google security teams over your assertion that it's so easy to replace.
Yes, this entire privacy scare is an opportunity to get rid of the advert-based business model and offer the opportunity to privacy-conscious users to get the same or a better service, in exchange for a few bitcoin cents, instead of getting tracked so that the jackals can better precision-bomb you with false commercial messages.
> to get rid of the advert-based business model and offer the opportunity to privacy-conscious users to get the same or a better service, in exchange for a few bitcoin cents
Great in theory, but people in general do not understand the advertising model or just don't care enough about being tracked that the micro-payment alternative is attractive to them (even if there is a method of making it essentially anonymous and untrackable). I'd be happy to pay small amounts for an ad-free un-tracked experience, as may you, but we are in a minority small enough that it isn't worth chasing (and to be frank, I'm cynical enough to not believe I won't be tracked (more than just to ensure I got what the payment covered) even if I did pay...
Exactly. You have posted exactly what I wanted to post but you've bested me ;-) This is not a problem at all. This is an opportunity. That is what the non-profits at the Tor project do not see, exactly because they are non-profits. They do not see that every problem is a dreamed-of opportunity -- because you can work on solving it -- and when you've solved it, you can collect nominal peanut fees from the users in order to get rich.
