I can't wait to see how this industry will change after LE is fully running -- this is amazing. Are there any stats about the different cert types, specially about their deployment count and usage over time?
One thing I don't understand about the guarantees given by CAs is the one about the warranty, like the "$1,750,000 Warranty" from Comodo. How exactly can they provide that? Or is that some sort of MUST have if you want to partner with an insurance company?
What types of stats are you looking for? "Different types" meaning different CAs?
The warranty is odd. Its required to provide a warranty in certain situations by the CA/B Forum (industry standards body). This is partially because some countries laws require they be provided for the class of products/services that SSL falls under, so requiring it from everyone sort of levels the playing field.
But the large CAs (Symantec, Comodo, etc) are big fans regardless. They can advertise this preposterous "warranty" which protects you, and usually the customer does not ask too much about it and just likes the sound of it or assumes it will cover them if they are hacked (which is not what its for). It actually just covers some very small situations where the CA mis-issues your certificate.
Some lawyers and experts at TrendMicro and Firefox found that due to how the terms are written there is basically no way the end-user would ever actually see that money. Those insurance warranties have never been used.
About the stats: by "specially about their deployment count and usage over time" I meant the number of certs deployed by cert type (DV, OV, EV) and how has their usage progressed over time? If the second part is not clear, let's say that 5 years ago EV certs represented 2% among issued certs, and today it represents 1.4% -- I'm looking for historic data about this.
Thanks about the warranty clarification, so it only protects you if the /CA/ does something bad to you? In that case wouldn't it possible to sue the entity for, possibly, an even larger sum?
Stats like that may be available but I can not think of anything at the moment. I will look into that and let you know.
>Thanks about the warranty clarification, so it only protects you if the /CA/ does something bad to you? In that case wouldn't it possible to sue the entity for, possibly, an even larger sum?
Yes, I believe the damage has to be due to the CAs behaviors. The two major situations I can think of that would qualify would be:
1. The CA issues a certificate for your domain/company to someone who was not authorized. However I would think that cert would then have to be used in an actual attack so you could quantify your damages.
2. The CA is breached in some way that allowed your certificate to be compromised or allowed an attacker to create a fraudulent certificate for your domain/company.
That is a very good question about suing the CA for other damages. I am not aware if this has ever occurred but it certainly seems like it could.
I assume I'm jealous for a project that brings nothing new compared to so many other solutions and still grabs 76 stars (as I write this). It seems, after all, github stars are another way to say "I'm popular" and not so much that a project is good.
That is a pretty rude comment and I would def. argue it reflects a pretty narrow view of the world. I think the project is alright and it looks quite useful if you need something to curl a site, check something, and blast an e-mail (essentially your own ITTT).
To the point I'm jealous for a project that brings nothing new compared to so many other solutions, I suspect the author of the program needed to call up a website check for an event and get notified; s/he probably found this to be the motivation for building this much more than getting github stars. Other people found it useful as well, and maybe it is easier for people to grep this implementation and build on it than other crawlers.
Most broadly, bitcoin combines a lot of well understood and older technologies into something completely knew. It seems this was your gripe, the project didn't do that. I just want to point out complex coordination and reorganization of current libraries/practices/technologies can be quite useful, novel and interesting.
edit: I actually concur with the above post a bit more now. I do think things done in Go get a but over hyped and if this is what parent was referring to, I suspect s/he was correct even if a bit prickly in expressing it.
The more relevant part about passcodes (4 or 6 digits) is described on page 12.
It's not fully specified, but since the PDF mentions "iteration count" then Apple is using some sort of KDF after you enter your PIN to make brute force attacks harder to perform. It also mentions the following delays:
Sure, that correction is correct ;) but it's not mentioned in that section of the mentioned documented. It leads me to believe that the restrictions described do not apply to them.
> It leads me to believe that the restrictions described do not apply to them.
Which restrictions? The table of delays is on the same page as "six-digit, four-digit, and arbitrary-length alphanumeric passcodes", about 3 paragraphs away. If this is what you're referring to, I see no reason to believe PINs vs. passwords are treated differently.
Is there such a thing as "moving" to another browser for development purposes? You will have to use both at some point, at least for some sanity check.
If you're developing something with React, Chrome will provide a better experience since React dev tools plugin is only available for Chrome. I'm not aware of some tool that is exclusive to Firefox, so I don't have a reason to favor it.
For most of the backend, I try to stick to one browser. Right now Chrome gives me all the request details and other things I need. But I want to see where FDE stands on this.
Don't you see some contradiction between your two sentences? You're attempting to recommend something that supposedly "magically" works so people using it don't need to understand the details about authentication. Seems like the quickest way to end up with all sorts of problems.
I read it as "don't bother with details, just use this thing here that does a lot of other things but happens to have a lib that might do it".
I think it's absolutely a good idea to use battle tested code, but you need at least working knowledge on what you're doing to apply it properly. Same thing applies for crypto in general: you generally don't implement it yourself, you generally use battle tested code, but you need to understand what you're doing. The idea that you can eliminate any of these steps and have something working properly is wishful thinking.
If this is sound, the theory that bitcoin is just the first cryptocurrency of its generation is now confirmed: bitcoin is dead.
If that website about bitcoin obituaries is around this update should be added there.
Clarifications as requested:
1) The article is about ECC
2) The article doesn't mention secp256k1, but it mentions EC curves in general and special those in the 256 bit field -- which secp256k1 is one of them
3) If NSA is able to crack 256 bits curves, what makes secp256k1 special to all this? Nothing.
They are color palettes based on Swiss design that originated in the 1950s, and a big influence on the look of flat design now. Not so much the function; Swiss design (international typographic style) placed an emphasis on removing visual embellishments to make design an effective tool of communication. The minimalism and simplicity were a means to an end, not an end in itself.
Here is a fun example of the bright colors preferred by these designers:
Hey, thank you! So, if I'm understanding this a Swiss-Style <T> is a T that is simple and effective.
Your reply starts by mentioning color palettes based on Swiss design, but is that the case here? It seems colors individually are not part of ITS, but how they are used (and therefore all colors can be used on it, as long as properties of this design philosophy are observed).
You got it! While there isn't a "Swiss palette", bright and contrasting colors were popular for both technical and stylistic reasons:
"The following points must be considered whenever it is planned to use colour: the effect on the viewer, its usability in the various advertising media and the technical possibilities of reproduction.
The sparing, but methodical and logical use of colour has a more telling effect than a combination of many different colours. If colour is used, it should be plainly visible and the reasons for its use immediately apparent."
- Josef Müller-Brockmann The Graphic Artist and His Design Problems (1961)
which is a good book even now, it's a practical guide with plenty of examples, so you can get a good look inside his head, even if you don't necessarily agree with everything he wrote.
I'm not questioning what you're saying, as it seems to be correct based on what I know (I may or may not have watched the Helvetica documentary) but what's with the graininess in the color picker? It doesn't fit with anything else I'm looking at on this topic.
My guess is to simulate how the colors will look on paper, they always look like they "pop" (god I hate that word lol) on a screen more than when printed out. You can turn it off by clicking "noise" at the top right.
The Swiss style seems to have influenced the covers of a lot of old sci-fi books, so I mentally associate these kinds of color schemes with faded old paper and sitting indoors on a rainy afternoon.
Swiss-Style has nothing to do "being in the style of Switzerland." Rather, it refers to the "Swiss Style" aka "International Typographic Style," a school of graphic design.
Seems like it's trying to generate a bunch of aesthetically-pleasing 4-color palettes, and present them in a helpful way.
I suspect that the building shape is engineered to create a border between each pair of colors. (The standard alternative would be, say, 4 vertical bars, which only shows you how 3 of the color pairs look against each other.)
The noise might be working under the assumption that you're going to apply noise to the colors when you use them, too.
There's a big gap in parsing the bitcoin blockchain vs parsing a local database.
The blockchain is a public ledger so any (encrypted or not) information you store there can be retrieved by anyone. Downloading it is very slow, and parsing it in a reliable way, i.e. using bitcoind's rpc, is even slower. So you'll want to build an index from it, which you'll happen to store in a local database. So after all that you end up with a local database and public information that anyone can access.
So, the linked BlockchainID, publicly stores all secrets in an encrypted format. Why would that be good, and even necessary for a decentralized identity?
It is trying to solve key storage and public identity at the same time. How could it possibly be a good idea to store secrets publicly?
One thing I don't understand about the guarantees given by CAs is the one about the warranty, like the "$1,750,000 Warranty" from Comodo. How exactly can they provide that? Or is that some sort of MUST have if you want to partner with an insurance company?