jb613

Patents started out as a 20 year protection on mechanical mechanisms or chemical processes as long as what was protected was publicly documented in full.

1) Patents are not an American invention. England had them before, and the Romans before that.

2) I'll assume you implied U.S. patents. The Founders regarded patents so highly that they wrote them into the U.S. Constitution. It was written generically and not limited or fixed to only "mechanical or chemical" but rather "to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries".

Thing is though that 20 years is a very long time when we are talking software. By the time the RSA patent ran out, the algorithm described was largely obsolete.

RSA patent expired nearly 20 years ago yet RSA is still used today. For example, the public key used to secure https://news.ycombinator.com is RSA.

Not that patents have not been a problem even before computers. Serious refinements of the steam engine for example didn't happen until after the initial patent ran out. Similarly Smith and Weston sat on their refinements for the Colt revolver until the patent ran out.

The myth is that patents block innovation. The reality is that blocking someone from doing something incentives them to find another way to do it. Afterall, if all you want to do is copy then how is that "blocking innovation"?

One has to wonder who the customers this is setup to appease. If something is later found, corporate customers have litigation options - so more likely this is for nation-states.

The more slow-moving government will get involved, the more industry will be pulled towards open source where there is no need to get government approval.

Sure - it won't be easy and will come with other pitfalls, but in some circumstances these may be easier hurdle than waiting months/years for some government to approve your product sale.

"I think you're missing the point."

Ditto. I know exactly what you're saying - tree's take long time to grow, the world is complex and subtly nuanced, once we lose that it's gone, etc. FYI I get all that - or for the purpose of this conversation pretend that I get it and try to look past that and at what I'm saying.

We can either fight change or adapt. Cavemen once complained about demand of caves outstripping supply too. The cost of fighting change is likely far greater than the cost of adapting.

Secondly, if you're going to worry about the Amazon (not saying we shouldn't worry about it) then why aren't you worried about the lost biodiversity once under Silicon Valley? Or NYC? Or Paris? Or Johannesburg? Or Beijing? It just seems we're getting involved in other people's business when we have a lot to cleanup ourselves.

No, Easter island wouldn't have had taro, chickens, goats, pigs WITHOUT the polynesian humans bringing them.

Capitalism may also offer answers. For example, as tree supply diminishes, each tree will become more valuable (assuming wood demand stays stable) thereby incentivizing tree farmers to plant trees over other crops.

The world changes and humans need to along with it. I'm sure cavemen once sat around the fire worrying about how all the good caves were being used up.

"Going to be interesting watching this one play out."

I suspect, access of "14,000 highly confidential and proprietary files shortly before his resignation" will play a major role in swaying the deciders. Experience tells us that not all of those 14k were critical, what if it had be 1 or 2 critical design docs? In a different or future case, we may see that happen. Corps have incentive to reduce competitors, but now may start recognizing the potential leverage they have - "Our network logs show Joe accessed our main design doc 1 week before he left for company doing similar work!".

"It is, however, sad to think that this technology could be set back a few years because of Levandowski's actions."

I am less concerned about one piece of technology and more concerned about the future of employer relations in general. Employers will become increasingly suspicious of employees leaving and will take actions to either prevent this or to stifle the actual knowledge gained to be used elsewhere.

What concerns me is that we are going to see more and more of this in the coming years - corporations concerned over ex-employees taking their knowledge with them and taking legal recourse. In this case, they complain about access of 14k proprietary files - which is pretty damning, but I could see similar damning evidence over accessing a couple of critically important design docs relatively near the end of employment. How do you distinguish between files being accessed merely for the purpose out your work vs theft? How can you ascertain what was in their minds and hearts for accessing for those files - and worse, how little would it take to sway a judge or jury that accessing of such files were deliberate (ie part of the bigger picture)? Courts have been wrong before. Previous generations this didn't come up because they stayed in 1 or 2 jobs their entire lives, at least in this aspect, today's environment is completely different.

There is a difference between weakened and backdoored. Weakened is along the lines what you're saying - that likely others than just the governments can easily access, whereas backdoored (if done properly) means only the govt. Of course, this assumes a perfect world and that there is a proper way to backdoor - in the real world, adversaries simply attack the governments backdoors/keys.

Nonetheless, given your context of "there is no encryption going on at all" I argue does not necessarily hold for a backdoor - or at least not at the outset and if done properly. If the govt backdoor is a key for which huge amount of care is taken to protect and take the extreme example of the govt encrypting the only copy of the key and firing it off in one direction into space - there is a backdoor but this is not necessarily equivalent to "no encryption at all".

"wants to regulate cryptography"??? - I suggest it's already in place. For example, if you wish to create crypto software or hardware (or in some cases even simply importing a crypto library) - for 2 sides to communicate requires sharing either the source, software binaries, or hardware itself - and if 1 of those is outside of the country then obviously export and/or import of the source/sw/hw occurs and therefore crypto controls come into effect.

Given free market indicators such as Bitcoin marketcap and the recent rise of Monero vs zcash - perhaps absolute privacy is not what the market values?

government subsidies cause distortions. Somehow providing basic income to incentivize people to live more in rural areas would only cause those currently living in rural areas to be more costly. The salaries of farmers, oil rig workers, truck drivers, miners, lumberjacks, etc... would rise.

Plug one hole in the dike and others will pop up. Just let the free market work and people choose where they want to live and work.

That's ridiculous. The Wright Brothers changed the world. On par if not exceeding today's equivalent of Marc Andreesen (Netscape), Bill Gates (Microsoft), Brin&Page (Google) - and the last time I checked, people like that DO own big house(s) and CAN afford to travel and do experiments without any worries about rent, food, healthcare.

By today's standards, many people were "poor" back then - it's all relative. Maybe in 100+ years they'll look back and marvel at how "poor" Andreesen/Gates/etc... were too.

You can be poor today and still make it big. You don't need a college degree or the massive debt that entails, you can make up for that with a good idea + hard work + persistence + live as frugal as possible + a little luck. It's not exactly the same - some things are harder and some things are easier, but overall it's still doable.

The reason you will lose that bet is the "any country". In some less developed countries, inflation is out of control (govt sees money printing as the only solution) bitcoin as measured against their currency is rising. Daily. Couple that with the fact that those same places do ironically have high mobile phone usage, and it's only a matter of time until it's surpassed 5%.

If not ID is required then why (and how do they enforce):

   "The maximum for unregistered clients is 5'000 CHF/EUR per day"

I suspect that selling iTunes credit or pre-paid phone codes requires adhering to all kinds of rules and agreements set by the corporations (Apple, phone corps). You can't simply build a box and slap iTunes logo on the outside - there's Trademarks involved. Then there's the government regulations and taxes to comply with.

Contrast that with bitcoin - no corporations to deal with, no government rules&regulations and paperwork - all you really need is an Internet connection and and simple digital signatures.

So no - I don't think iTunes or pre-paid phone codes are easier to sell than bitcoin.

Why are the default rules not provided?

fw-daemon/rules.go references "/var/lib/sgfw/sgfw_rules" yet nowhere to be found.

I suspect we centralized trust at the encouragement of folks like the NSA and similar ilk.

In the mid-90's, CA certs were put into Netscape Navigator (IE joined later) in order to facilitate the new wild wacky concept that someone might buy something online. They called it "e-commerce".

Trust was centralized because it was far easier to add the then ~half-dozen CA's rather then somehow vetting every joe that wanted to self-sign their certs. PGP's web-of-trust existed but it was deemed less viable.

Besides, the whole SSL certs thing was a major business premise behind creating Netscape - profits. Without that there might not have been a dot-com and the huge amount of money that followed since then.

lacks features such as per process rules. You have to do hacks like assign rules to users

From a practical standpoint, I find it hard to imagine that the cost of added complexity for configuring application rules per user would outweigh the benefits of simply configuring them system wide. I remember the days of terminal clients logging into mainframes but all I see are single user desktops. Things like location on the network matter more in an application firewall than which user is accessing the desktop.

Still doesn't make any sense to me. Whether a CA performs a DNS query in order to do domain validation via email, http or to check a CAA record doesn't matter.

Brush up on CA cert issuance. You seem to be assuming that all CA's perform similar levels of due diligence before issuing certs. They don't, they differ widely. Some go much further than simply DNS validation.

I'm suggesting making CAA mandatory.

For practical reasons, I am skeptical this will happen. Too many paying entities. In the spec/contract, the MUSTs will be lowered to SHOULDs.

The certificate would not have been issued in my example.

IF the CA checked the CAA...

CAA would have probably prevented the mis-issuance.

Exactly - "probably".

CAA is only fully effective if all CAs implement it (or in other words: if it becomes mandatory).

1) it won't happen. some CA's may/already-have implemented it but how is the browser/user to know which have and which haven't? 2) unclear that it is even fully effective

Again, you fail to demonstrate how this complexity does more harm than good. art. Introducing a new mechanism requires demonstration that the added complexity is worth the effort. And in this case, it is clear that unless everyone implements it, there is no added benefit. Added cost without benefit is a bad start

I'm not sure I follow. My point is that if you're arguing that a DNS query is some kind of added complexity, then I have bad news for you, because DNS queries are already a part of all domain validation methods (whether it is email, HTTP, DNS, etc.)

We're talking about CA's issuing certs - DNS queries for email, http are outside of CA cert issuance.

This has nothing to do with browsers. It's a mechanism to improve the CA domain validation process.

The browsers need to decide when to trust a cert - and if/when CAA becomes involved in cert issuance, then I suggest this DOES have something to do with browsers. Furthermore, you're suggesting co-existence between CA's that check CAA and CA's that don't - which implies that either the browser or user has to make a determination of whether to trust.

But we're talking past each other. So using your example, think of it like this, how will you as a user know when you visit github that another WoSign hasn't happened? ...or rather - how would a LAYPERSON know they are secure? Github might detect it - but how do ordinary USERS?

If they had used CAA, and github.com had a CAA record indicating WoSign is not permitted to issue certificates for that domain, it's quite possible that the certificate would not have been issued.

that (wrongly) assumes ALL CA's trusted by EVERY browser will perform CAA check before issuing a cert for github.

CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases, but it's not (and never has been advertised as) a solution to the problem of a fully-compromised CA.

The problem is not so much "fully-compromised CA" as it is we're trusting a whole pile of CA's and not all them behave the same.

you need access to the DNS in order to change (and bypass) CAA records, whereas you only need control over the web server in order to obtain a certificate that can be used to ransom a domain

Any attacker that can gain access to web site admin credentials can also get the DNS credentials.

CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases

You're using defense-in-depth again. Replace "-in-depth" with "-added-complexity". Here's a directly relevant example - HPKP arose from deficiencies in static pinning - which arose from deficiencies of CA/SSL ecosystem - which arose from deficiencies of plaintext traffic. It's not adding security "-in-depth" when all you're doing is resolving deficiencies in existing deployed solutions. The "depth" is single-level, not multiple.

CAs already rely on DNS for domain validation

Not all - only a subset of certs issued

If the CA fails to follow the whitelist, it's not worse than a CA that does not implement CAA. Without pointing out evidence that shows how this addition could make things worse, I don't think this is a good argument against CAA.

because the USER can't tell. The user is under the impression of increased security (because upgrading to browser version X.Y said it now supports CAA) yet the user doesn't know which cert was issued by a CA that checked CAA. And you can't add yet another indicator to the UI because the user is already numb from just the certificate itself.

actually reduce the risk associated with that attack

and as I tried to point out to you, it's ineffective against the threat of an attacker gaining access

Yeah - in theory, but in reality the browsers are reluctant because of all the other sites that a CA has issued certs for - no browser wants to be singled out for blocking some other non-related sites.

There's too many paying entities to appease - not just hundreds of CA's but various browser vendors as well. Either MUSTs will be changed to SHOULDs - or fragmentation of the CA/Browser body itself.

Look no further than at some of the past transgressions browsers let CA's get away with.

It's certainly an effective defense-in-depth mechanism.

1) We've seen time and again that complexity is the enemy of security. Generally, the more moving parts, the more likely for another flaw. This is less defense-in-depth than it is added complexity. The attackers have time on their side to figure out where the next hole is.

2) The OP suggests that HPKP failed because of practical reasons (domain admins are scared to death of getting it wrong and bricking their site) - things like CAA only add to the complexity.

1) CAA tries to address the threat of attacker getting a cert issued for your domain - to carry out such an attack inherently requires taking over your DNS record or your domain account - if they can do this then they can also reconfigure your CAA record.

2) CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA.

You are underestimating 1) the number of CA's embedded in your browser, 2) how easy it is to get one of those CA's to issue a cert for someone else's domain.

with CAA and you can change your configuration it any time

so too could an attacker. If an attacker is able to set HPKP, then they could just as easily reconfigure CAA to a CA that issues them a cert for your domain.

CAA (that little-known standard for enforcing which CAs can issue certs for your domain)

I'm sure the CA's absolutely LOVE this - customers are signaling that they will stay with CA 'X'.

Given 'vendor lockin' or 'guaranteed recurring revenue', cert prices would drop thru the floor for 1st year only for renewals to increase.