-
Someone who controls your network will simply drop the DNSKEY/DS records, so DNSSEC would not have provided any protection for “MyEtherwallet”. People who have already visited it were (hypothetically) protected by TLS, and people who hadn’t, would have received bogus records anyway.
So DNSSEC could, in an ideal setting, provide a benefit similar to HPKP, but why wait? HPKP is here now.
Furthermore, “DNSSEC wasn’t easy to implement” is a massive understatement.
-
-
-
If someone controls your network, they don’t need to hack anyone else: They can feed you whatever they want.
That’s only true of non-DNSSEC signed records. DNSSEC is PKI allows one to cryptographically delegate authority of a zone. In practice, this means that the root zone signs the public keys of authoritative top-level domains, TLDs then sign the public keys of owners of regular domain names. These keys can then be used to sign any arbitrary DNS record. So, if you have a validating local resolver, it can use the public key of the root zone to cryptographically validate the chain of trust from ICANN down to the authoritative nameserver for a domain.
DNSCurve isn’t a bad idea, I think lookup privacy is a good thing and I would much prefer to trust Google or Cloudflare than my local ISP for unsigned domain names. That being said, it doesn’t fix the massive problem of computers trusting the DNS cache of a 10-year-old router controlled by malware. It’s also really unhelpful when people claim that DNSCurve is some sort of alternative to DNSSEC.
Seriously, go read Dan Kaminsky’s critique of the DNSCurve proposal.
-
DNSSEC is PKI allows one to cryptographically delegate authority of a zone
Which an attacker guarantees you’ll never see.
This isn’t a hypothetical attack: Your computer asks your ISP’s nameservers, and it strips out all the DNSSEC records. Unless your computer expects those records, it won’t ever be able to tell you anything is wrong.
if you have a validating local resolver, it can use the public key of the root zone to cryptographically validate the chain of trust from ICANN down to the authoritative nameserver for a domain.
If you don’t, and for some reason use a “validating local resolver” on another machine, you have nothing.
Even if you have a validating-capable resolver, and you never see that
com has DS record 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766then you might never learn that you might find keys for cloudflare.com.Even if you do have a validating-capable resolver, and you see that
com has DS record 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766you still can’t visit google.com safely.And what about
.ae? Or other roots?DNSSEC supporters are happy enough to ignore the problem of deploying DNSSEC, like it’s somehow someone else’s problem.
That being said, it doesn’t fix the massive problem of computers trusting the DNS cache of a 10-year-old router controlled by malware.
What are you talking about?
It’s also really unhelpful when people claim that DNSCurve is some sort of alternative to DNSSEC.
It’s annoying that DNSSEC “supporters” hand-wave the fact that DNSSEC has no security, and doesn’t have a deployment plan except “do it”.
IPv6 is at 23% deployment. After more than twenty years. DNSSEC is something like 0.5% of the dot-com. After more than twenty years (although admittedly they completely changed what DNSSEC was several times in that time). DNSSEC isn’t a real thing. It’s not even a spec for a real thing. How can I possibly take it seriously?
Seriously, go read Dan Kaminsky’s critique of the DNSCurve proposal.
Have you read it?
It’s bonkers. It admits DNSSEC is a moving target that hasn’t yet been implemented “in all its glory” and puts this future fantasy version of DNSSEC that has been fully deployed and had all operating systems, routers and applications rewritten, against DNSCurve.
Kaminsky is as brain-damaged as those IPv6 nutters, waiting for some magic moment for over twenty years that simply never came – and the only way his “critique” would have any value at all is if it were printed on bog roll.
For what it’s worth: I think DNSCurve solves a problem I don’t have, but it attracts no ire from me.
-
This isn’t a hypothetical attack: Your computer asks your ISP’s nameservers, and it strips out all the DNSSEC records. Unless your computer expects those records, it won’t ever be able to tell you anything is wrong.
A resolver can refuse to perform DNSSEC validation or even strip out records, but a local resolver can detect this and even work around it.
if you have a validating local resolver, it can use the public key of the root zone to cryptographically validate the chain of trust from ICANN down to the authoritative nameserver for a domain.
If you don’t, and for some reason use a “validating local resolver” on another machine, you have nothing.
What do you mean by using a validating local resolver on another machine? It’s local, there is no other machine.
If you are saying that most clients rely on their router (or whatever) to do DNSSEC validation then yes, that router can perform a MITM attack. It’s still more secure than trusting every single upstream DNS resolver, but we need to move to local validation. The caching layer provided by DNS is a byproduct of the limited computing resources 1985.
Even if you have a validating-capable resolver, and you never see that com has DS record 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 then you might never learn that you might find keys for cloudflare.com.
It sounds like you are describing a broken resolver.
Even if you do have a validating-capable resolver, and you see that com has DS record 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 you still can’t visit google.com safely.
I believe the local resolver would just ask
comfor a DS record forgoogle.comand receive either a DS record or an NSEC record. If it doesn’t receive one of those two records, then you are correct: you can’t visit google.com safely. It’s no different than an HTTPS downgrade attack.And what about .ae? Or other roots?
- We can deploy DNSSEC incrementally.
- ~96% of all domains are registered on a TLD that supports DNSSEC. The stats would probably be even better if they were based on traffic instead of total domains.
- All registrars are required to support DNSSEC.
If we can get people to stop claiming that “DNSSEC does nothing for security” and make use of the cool stuff you can do with DNSSEC, then the market will force the last 10% of ccTLDs to adopt it.
DNSSEC supporters are happy enough to ignore the problem of deploying DNSSEC, like it’s somehow someone else’s problem.
I personally am working very, very hard on addressing every pain point there is. There are a lot of moving pieces and the standards left some holes until recently. I believe captive portals and VPN domains are thorny issues, but these issues can be addressed in an incremental fashion.
It doesn’t help when people make erroneous claims about DNSSEC based on an incorrect understanding of DNS, DNSSEC, DNSCurve, and decentralized naming systems.
That being said, it doesn’t fix the massive problem of computers trusting the DNS cache of a 10-year-old router controlled by malware.
What are you talking about?
DNSCurve relies on trusting the DNS resolver above you. For most people that is a 10-year-old router which has never gotten a security update. Best-case scenario is someone switching to Google DNS or Cloudflare - but with proper encryption, no upstream resolver would be capable of performing MITM attacks.
It’s annoying that DNSSEC “supporters” hand-wave the fact that DNSSEC has no security
I have patiently responded to every single claim you have made about DNSSEC’s security model. Please refrain from repeating this claim until you have figured out how a MITM attacker can force a local validating resolver to accept forged DS or NSEC records.
IPv6 is at 23% deployment. After more than twenty years. DNSSEC is something like 0.5% of the dot-com. After more than twenty years (although admittedly they completely changed what DNSSEC was several times in that time). DNSSEC isn’t a real thing. It’s not even a spec for a real thing. How can I possibly take it seriously?
So was IPv6 until ~6 years ago - now there is exponential growth. DNSSEC is at a similar tipping point: the basic security model was worked out a long time ago, but there were plenty of sharp corners until recently (large key sizes, NSEC3, etc). If we can stop people from claiming that the security model is broken then Cloudflare and other big providers will pour money into taking business away from the HTTPS certificate authorities.
It’s also a necessity for decentralized DNS, which gives us an environment where we can implement everything without having to wait for legacy infrastructure to catch up.
Seriously, go read Dan Kaminsky’s critique of the DNSCurve proposal.
It’s bonkers. It admits DNSSEC is a moving target that hasn’t yet been implemented “in all its glory” and puts this future fantasy version of DNSSEC that has been fully deployed and had all operating systems, routers and applications rewritten, against DNSCurve.
The post is mainly useful for explaining how DNSSEC and DNSCurve relate to one another. While the grand vision is the eventual goal, there are incremental benefits and huge gains can be had by simply making the application DNSSEC aware. For example, browsers are already switching to doing DNS resolution themselves, so the work required isn’t much more involved than that of upgrading to TLS.
For what it’s worth: I think DNSCurve solves a problem I don’t have, but it attracts no ire from me.
Then why hate on DNSSEC but evangelize DNSCurve? You can happily ignore DNSSEC as an end user or even as a system admin. If you care about security, well, that’s a different story.
-
-
-
If they hack your primary nameserver and keep the zone signed, then maybe, as long as you’re running the primary. But as the original commenter said, “they can drop your DNSKEYs and DS”, no. They can drop the DNSKEY, but the DS resides in the parent node, and as long as it’s there, resolvers will look for DNSSEC validated responses, which they won’t get.
-
If someone controls your network, whenever you request a DNSSEC “protected” domain, you will never know because the attacker can drop whatever records they want. DNSSEC clearly offers nothing.
If someone controls the network of a website, they don’t need to interfere with the nameservers. They can simply MITM the traffic. Since they can request a TLS certificate from anyone who does HTTP or mail validation, DNSSEC still offers nothing. This is true whether they control the network by broadcasting “invalid” BGP routes, or whether they attack the physical infrastructure.
Why are you defending this snake oil? “Hack[ing] your primary nameserver” is a pointless strawman that nobody cares about: “your primary nameserver” is likely controlled by Amazon or someone else competent. Your webserver is controlled by you, who lack the experience to identify the (complex) services at risk and properly secure them.
-
f someone controls your network, whenever you request a DNSSEC “protected” domain, you will never know because the attacker can drop whatever records they want. DNSSEC clearly offers nothing.
I don’t know what you mean by this. For starters, are you assuming “your network” includes all the nameservers? Let’s assume so. If DNSSEC is enabled, they can’t alter any of the DNS responses because they will break DNSSEC validation for aware resolvers. Sure, they can drop queries but what does that buy them other than a DDOS? They can’t stand up a fake site.
Why are you defending this snake oil? “Hack[ing] your primary nameserver” is a pointless strawman that nobody cares about: “your primary nameserver” is likely controlled by Amazon or someone else competent. Your webserver is controlled by you, who lack the experience to identify the (complex) services at risk and properly secure them.
Clearly you haven’t been paying attention. The entire chain of events that started my posts about this was a BGP hijack that was used to impersonate Route53 nameservers by hijacking Amazon IP space, which were the nameservers that MyEtherWallet was using. From there they stood up fake nameservers which directed victims to a fake myetherwallet site. That’s the exactly what happened, why don’t you go tell the people who had their wallet’s drained not to worry about it because it is all a pointless strawman.
-
-
-
-
-
So DNSSEC could, in an ideal setting, provide a benefit similar to HPKP, but why wait?
Doing PKI at the DNS level means that we can leverage it for every network and application protocol … including public key pinning. It would also enable us to do cool stuff like encrypt at both the network and application layers.
It’s just that sysadmins didn’t want the headache of key management, so everyone engaged in bikeshedding. It didn’t help that a few (well intentioned!) security researchers threw shade on DNSSEC for not solving Zooko’s triangle or offering encryption for DNS lookups.
So now we are stuck with Mozilla funding Let’s Encrypt to the tune of $2 million/year and non-HTTPS applications are forced to replicated all of the infrastructure required for a PKI. Which, in practice, means that it’s either non-existent (SSH) or barely functioning (GPG).
HPKP is here now.
Sadly, HPKP has been deprecated by Chrome. But, FWIW, these standards existed long before HPKP.
-
It didn’t help that a few (well intentioned!) security researchers threw shade on DNSSEC for not solving Zooko’s triangle or offering encryption for DNS lookups.
The current system (CA’s) is human meaningful, secure, and
decentralizedfederated. It’s not perfect, but there are ways to improve the last point, so that we have more control over badly behaving CAs. But even as implemented, that’s better than human meaningful, secure, and a single point of failure (DNSSEC).So now we are stuck with Mozilla funding Let’s Encrypt to the tune of $2 million/year and non-HTTPS applications are forced to replicated all of the infrastructure required for a PKI.
You can use x509 certificates from Let’s Encrypt to secure any IP connection. What’s the problem?
-
It’s not perfect, but there are ways to improve the last point, so that we have more control over badly behaving CAs.
For non-decentralized naming systems, the (abstract) DNSSEC chain of trust looks (roughly) like this:
Government -> ICANN -> Registrar -> DNS Provider -> Local Validating Resolver -> BrowserHTTPS certificate authorities “validate” control over a domain by checking DNS records (either TXT or via an email). Their chain of trust looks like this:
Government -> ICANN -> Registrar -> DNS Provider -> ~650 CAs [1] -> BrowserThe best way to exercise more control over them is to cut them out of the trust chain entirely. Or switch to a decentralized naming system … which also relies on DNS (and thus DNSSEC) for compatibility reasons:
Blockchain -> Lightclient w/ DNSSEC auto-signer -> BrowserBut even as implemented, that’s better than human meaningful, secure, and a single point of failure (DNSSEC).
In terms of the security model, DNS is still a single point of failure. If you don’t like managing PKI you can always outsource it to someone … just like you do with HTTPS certificates.
-
-
My point is that one can trick one of the ~650 CAs into generating an X509 certificate by hacking their upstream DNS client or performing a MitM attack. This would be pretty easy for any large network operator to pull off.
-
-
-
-
Doing PKI at the DNS level means that we can leverage it for every network and application protocol … including public key pinning. It would also enable us to do cool stuff like encrypt at both the network and application layers.
What exactly are you referring to: DNSCurve?
DNSSEC doesn’t offer anything like this.
It’s just that sysadmins didn’t want the headache of key management, so everyone engaged in bikeshedding.
Paul Vixie, June 1995: “This sounds simple but it has deep reaching consequences in both the protocol and the implementation – which is why it’s taken more than a year to choose a security model and design a solution. We expect it to be another year before DNSSEC is in wide use on the leading edge, and at least a year after that before its use is commonplace on the Internet”
Paul Vixie, November 2002: “We are still doing basic research on what kind of data model will work for DNS security. After three or four times of saying NOW we’ve got it THIS TIME for sure there’s finally some humility in the picture … Wonder if THIS’ll work? … It’s impossible to know how many more flag days we’ll have before it’s safe to burn ROMs … It sure isn’t plain old SIG+KEY, and it sure isn’t DS as currently specified. When will it be? We don’t know… There is no installed base. We’re starting from scratch.”
It didn’t help that a few (well intentioned!) security researchers threw shade on DNSSEC for not solving Zooko’s triangle or offering encryption for DNS lookups.
Or the fact DNSSEC creates DDOS opportunities, introduced lots of bugs in the already buggy BIND, and still offers no real security.
No thanks.
So now we are stuck with Mozilla funding Let’s Encrypt to the tune of $2 million/year
DNSSEC has received millions of US tax dollars offers nothing, while Let’s Encrypt actually provides some transport security. Hrm…
non-HTTPS applications are forced to replicated all of the infrastructure required for a PKI. Which, in practice, means that it’s either non-existent (SSH) or barely functioning (GPG).
I don’t see how DNSSEC even begins to solve these problems.
FWIW: Almost everything is HTTPS anyway.
Sadly, HPKP has been deprecated by Chrome
It is sad. Firefox and others still support it, and HSTS + Certificate Transparency is probably good enough anyway.
-
Doing PKI at the DNS level means that we can leverage it for every network and application protocol … including public key pinning. It would also enable us to do cool stuff like encrypt at both the network and application layers.
What exactly are you referring to: DNSCurve?
No, using DNSSEC to bootstrap the public keys for … any cryptographic protocol. Just as DANE can be used to distribute the TLS keys for an HTTPS server, SSHFP records can be used to publish the public keys for a given SSH server. AWS, for example, could just publish SSHFP records when they provision a new instance and you would have end-to-end verification for your SSH connection. No need for Amazon to partner with Let’s Encrypt or force SSH clients to switch to X509 certificates.
Since DNSSEC makes it simple to publish arbitrary public keys for a domain, you can use something like TCPCrypt to encrypt connections at the transport level. Transport level encryption reduces information leakage (SNI headers for HTTPS, what application you are using, network level “domain” fronting, etc) and mitigates flaws in any application layer encryption.
WRT to your Paul Vixie quotes: they are 16 years old. I’ve tried really hard to find showstopper issues, but when you dig into criticisms of DNSSEC they boil down to complaints about DNS, problems that have already been fixed, or gripes about the complexity of managing PKI.
Or the fact DNSSEC creates DDOS opportunities
DNS reflection attacks are a thing because there are tens of thousands of public DNS resolvers willing to send DNS record requests to anyone. The worst offender here are
ANYrequests that return all records associated with a domain. The public key and signature used to verify a DNS response do not incur that much overhead 1 2.The response from DNS providers hasn’t been to rip out DNSSEC, but to rate limit requests that produce large responses. More fundamental changes include switching to TCP, ingress filtering of spoofed UDP packets, supporting edns_client_subnet, and shutting down public DNS servers.
introduced lots of bugs in the already buggy BIND
Please do not blame DNSSEC for BIND being a buggy POS.
and still offers no real security.
DNSSEC prevents a wide range of attacks. Are seriously arguing that removing trust in every DNS server between yourself and the registrar doesn’t materialistically improve security? What about removing trust in the ~650 CAs capable of producing an HTTPS certificate? Wouldn’t you like to live in a world where TCP, SSH, email, IRC, etc can take advantage of PKI instead of opportunistic crypto?
non-HTTPS applications are forced to replicated all of the infrastructure required for a PKI. Which, in practice, means that it’s either non-existent (SSH) or barely functioning (GPG).
I don’t see how DNSSEC even begins to solve these problems.
Publish a DNS record with the public key for the encryption protocol you would like to use (see: SSHFP, DANE, PGP).
It is sad. Firefox and others still support it, and HSTS + Certificate Transparency is probably good enough anyway.
As a decentralized domain name nerd, I strongly disagree. We need a standard way for naming systems to declare the public keys for their services. Seriously, we have to sign TOR domains with HTTPS certificates from DigiCert because the browser doesn’t support DANE.
-
No, using DNSSEC to bootstrap the public keys for … any cryptographic protocol.
This is some fantasy version of DNSSEC that doesn’t exist yet and likely never will: Browers don’t do DANE because it’d piss people off.
Are seriously arguing that removing trust in every DNS server between yourself and the registrar doesn’t materialistically improve security?
Yes.
Until you know that you’re supposed to be seeing a DS/DNSKEY chain, every recursive resolver (and every stub resolver) gains nothing, and risks tricking people into thinking they have some security because they installed something called DNSSEC.
As a decentralized domain name nerd, I strongly disagree.
Well, you’re wrong. Decentralising trust just creates multiple single-points of failure unless you’re willing to wait for consensus, in which case you might as well use HSTS+Certificate Transparency (and your favourite mirror).
-
This is some fantasy version of DNSSEC that doesn’t exist yet and likely never will: Browers don’t do DANE because it’d piss people off.
It would only piss off people who think DNSSEC is a bad thing. Chrome actually implemented it but it was removed due to lack of critical mass. I’m thinking of pitching Cloudflare on pushing for DANE.
Until you know that you’re supposed to be seeing a DS/DNSKEY chain, every recursive resolver (and every stub resolver) gains nothing, and risks tricking people into thinking they have some security because they installed something called DNSSEC.
If the parent zone is signed and has a DS key for the child zone, then your local resolver would know that the child zone is supposed to be signed.
As a decentralized domain name nerd, I strongly disagree.
Well, you’re wrong.
No, I’m not. This was a major issue with Namecoin: we had to MITM every HTTPS connection to check the certificate against the blockchain records then replace it with a local certificate. There was no uniform way of making this work: the hack required tweaking for every OS and application and prevented users from selecting their own SOCKS5 proxy. The entire team agreed that DANE was the only way forward and we even got DigiCert to ensure that they used DANE when minting their
.onioncerts.Decentralising trust just creates multiple single-points of failure
Um, what?
unless you’re willing to wait for consensus
Consensus from the Blockchain?
-
-
-
-
-
-
Most of the large resolver services such as Google. Quad9, OpenDNS and Cloudflare are all DNSSEC enabled.
OpenDNS does not support DNSSEC at this time.
-
-
-
I’m getting really sick of people talking about DNSCurve as if it was an alternative to DNSSEC, the two do completely different things. DNSCurve secures the traffic between the authoritative nameserver and a DNSCurve enabled resolver (the only one I know of being OpenDNS). DNSSEC authenticates the validity of the DNS responses themselves.
-
You’re right. DNSCurve protects all of your DNS traffic from tampering between you and the resolver and the resolver can implement their own security infrastructure for detecting and protecting from tampering and cache poisoning, while DNSSEC validates the DNS traffic of far less than 1% of all domains on the internet AND requires each client to not use a caching resolver if they want to be able to trust the results.
So DNSCurve has a real world impact on protecting users, and DNSSEC is still vaporware.
-
You’re right. DNSCurve protects all of your DNS traffic from tampering between you and the resolver and the resolver can implement their own security infrastructure for detecting and protecting from tampering and cache poisoning.
The only way to reliably detect against tampering with DNS records is for the owner of the domain to sign them cryptographically.
while DNSSEC validates the DNS traffic of far less than 1% of all domains on the internet
IPv6 had pretty low adoption too, until things started to get bad enough.
AND requires each client to not use a caching resolver if they want to be able to trust the results.
They don’t have to use a caching resolver, that’s the whole point of the owner of the domain signing the DNS records - you can verify it for yourself! A client can also query the root name servers directly, it would increase load on the authoritative nameservers and has a different privacy profile … but there is nothing wrong with that.
-
- DNSCrypt for privacy
- TLS for validation (and of course the other security benefits that come with)
That’s the stack everyone should be using. It works and is reliable; duplicate certificates forged by shady CAs is a thing of the past with CAA, certificate transparency, and the ability to do stapling. Pushing down the validation to DNS is the wrong approach.
-
- DNSCrypt for privacy
DNSCrypt is dead. TLS adopted DJB’s curves and some IETF working groups wrote a few standards which can pass through firewalls.
- TLS for validation (and of course the other security benefits that come with)
TLS does not validate that a record came from a domain name name, it only validates that the response came from a third party resolver.
That’s the stack everyone should be using. It works and is reliable; duplicate certificates forged by shady CAs is a thing of the past with CAA, certificate transparency, and the ability to do stapling.
We still have to sign
.oniondomains using DigiCert’s certificate. Certificate transparency doesn’t protect against domains which aren’t using “high assurance” certificates. Nor does this protect any other protocol outside of TLS.Pushing down the validation to DNS is the wrong approach.
Why are you so against cryptographic verification of DNS records?
-
-
-
-
DJB threw a bunch of shade on DNSSEC when he announced DNSCurve, but he was (at best) misguided 1.
DNSCurve however is unlikely to be implemented by ICANN for political reasons.
DNSCurve doesn’t have anything for ICANN to implement as there is no signing of DNS records. It will validate that a response came from a specific DNS cache, but not that the records were produced by the owner of the domain.
He’s right that we need privacy for DNS lookup and the adults in room created DNS over TLS.
-
-
OpenDNS doesn’t support DNSSEC, and prevents doing the validation yourself if you wanted to do so, by stripping required records before forwarding a response to you. 1
Their business model used to rely on NXDOMAIN hijacking, which DNSSEC prevents. They stopped doing that a while ago, but I just checked and they are still stripping out DNSSEC records 🤯!
I really wish I hadn’t gotten sick, I was going to help work on a standard for DNS filtering. At any rate, these are bad actors in the DNS ecosystem.
-
-
-
DNSSEC as a standard is just really badly done. The closest comparison is OpenPGP (as it relates to emails), technically both standards want to increase security but due to design issues, both spectacularly failed to improve the status quo.
It’s good that DNSSEC hasn’t been deployed widely enough for it to “fail-close”.
-
What would you like to change?
-
-
DNSSEC would be cool if it allowed multiple CA hierarchies. I really like the idea of a global key/value store that you bootstrap other secure protocols on top of. DNS could be the basis for that in theory.
But DNSSEC as standardized bubbles up to a single government run CA per TLD, and that’s much less cool.
-
Not liking government control of the domain name system is not a valid reason to dislike cryptographic verification of DNS records … especially since decentralized naming systems also need a protocol for signing their DNS records :D
-
-
It’s a bit dated at this point, but I enjoy how practical the analysis and delivered solution is. Too bad it didn’t go beyond academic prototype.
If you can easily n-gate a submission, maybe it shouldn’t be here.
Spam about ad campaigns and counterreactions is not a core value prop of lobsters. :(
on the other hand, this story is currently on the front page with an above-median vote score, and the other riscv-basics story is the highest voted story currently on the front page, so evidently the users of lobsters found both relevant to their interests.
Yours is some low-quality gatekeeping.
News is the mindkiller. Humans are hardwired to be really interested in new things regardless of their utility, usefulness, or healthiness–you need look no further than the 24 hour news cycle or tabloids or HN front page to observe this phenomena.
If you look at any given submission, it has a bunch of different things it’s “good” at: good in terms of educating about hardware, good in terms of talking about the math behind some compiler optimization, good in whatever. Submissions that are news are good primarily in terms of how new they are, and have other goodness that tangential if it exists at all. The articles may even have a significant off-topic component, such as politics or gossip or advertising.
This results in the following pathologies:
What you dismiss as gatekeeping is an attempt to combat this.
EDIT:
A brief note–your example of the two ARM articles being on the front page illustrate the issue. Otherwise intelligent lobsters will upvote that sort of stuff because it’s “neat”, without noting that with everybody behaving that way we’ve temporarily lost two good spots for technical content–instead, we have more free advertising for ARM (all press is good press) and now slightly more precedent for garbage submissions and call-response (news thing, rebuttal to news thing, criticism/analysis of rebuttal). It’s all so tiresome.
ugggh, you leveled up my brain regarding what belongs on lobste.rs. “I like this!” is not only not necessarily an argument ‘for’, it is sometimes an argument ‘against’. Mind-blown.
I bookmarked and often shared this post since it seemed like a nice set of guidelines. Had a lot of votes in favor, too.
I thought we concluded that votes in favour represent anti-signal.
Haha. Depends on the context. They’re important for meta threads since it can determine site’s future.
This is interesting news, it’s not just drama or clickbait. The big chip makers have maintained an oligopoly through patents on abstract math: an ISA. It’s insane that innovation can only come from a few big players because of their lawyers. RISC-V is the first serious dent that the open source movement has been able to make in this market because (unlike ARM, OpenPOWER, and OpenSPARC) it has a serious commitment to open source and it is technologically superior.
ARM will be the first player to fall to RISC-V because they have a monopoly on lower end chips. Samsung, Qualcomm, NVidia, Apple, Google, etc. are all perfectly capable of making a competitive chips without having to pay a 1% tax to ARM. We are already seeing this with Western Digital’s switch to RISC-V, there is no advantage to paying ARM for simple micro-controllers … which is a huge portion of ARM’s business.
That they are resorting to FUD tactics shows that ARM execs know this. People interested in the larger strategic moves, like myself, find this article about how their FUD tactics backfired very interesting. I would appreciate it if you didn’t characterize this sort of news as spam and the people who follow how big industry players are behaving as just being into drama.
With respect, a good deal of your post is kremlinology.
The ARM execs cannot be guaranteed to “know” anything of the sort–it’s more likely that there is a standard playbook to be run to talk about any competing technology, RISC-V, OSS, or otherwise. Claiming that “oh ho obviously they feel the heat!” is speculation, and without links and evidence, baseless speculation at that.
The people who “follow” big industry players are quite usually just people that want to feel informed, and are quite unlikely to be anybody with any actual actions available given this information. Thus, just because something is interesting to them doesn’t make it necessarily useful or actionable.
Again, all news is spam on a site with historically more of a bend towards information and non-news submissions. Further, it’s not like this hasn’t been covered extensively elsewhere, on Slashdot and HN and Gizmodo and elsewhere. It’s not like it isn’t being shown on many fronts.
Please understand that while in this specific case, you might have an interest–but if all lobsters follow this idea, it trashes the site.
I’m not allowed to infer basic information about the internal state of an organization based on its public actions?
Do you understand why I might feel frustrated when someone mocks arguments defending a topic but then demands others provide extensive context to the conversation s/he inserted themselves into?
It’s not like ARM hasn’t spoken out on this subject before; a high level ARM technology fellow debated RISC-V foundation members a couple of years ago. The debate sounds a lot like an early draft of the arguments presented on the FUD website: RISC-V can’t possibly replicate ARM’s ecosystem and design services.
If you go look at the RISC-V foundation membership list, you will find a lot of ARM licensors and competitors including Qualcomm, Samsung, NVidia, IBM, Huawei, and Google. They are using RISC-V as a vehicle to jointly fund high-quality replacements of ARM’s IP, much of which consists of ISA patents and tooling. RISC-V has a very thorough patent review process, making it difficult to sue RISC-V manufacturers based on the ISA. There is a lot I don’t understand about the value ARM adds in terms of chip design and industry collaborations, but NVidia alone is worth 3x what SoftBank paid for ARM just two years ago.
If ARM execs aren’t worried about RISC-V taking market share, they should be. ARM creating a FUD website is very strong, direct evidence that this is the case.
It feels like you are talking down to me and other interested readers. Are kernel hackers the only people allowed to be interested in kernel development news? I don’t get a lot of actionable information based on the latest scheduler drama, but (as a UX engineer) I am interested in the outcome of these debates.
I came to Lobste.rs for a deeper understanding of the underlying technical and political factors at play here.
I am open to this argument and I probably wouldn’t have perceived your comments so negatively had I not started from the standard definition of spam. Of course, I also understand that it is hard to justify the time to fit such nuance into a comment on an article : )
You clearly have thought a lot about this and discussed it with others, but new and causal readers haven’t. Perhaps you could use less incendiary language? Just say that Lobste.rs focuses on non-news submissions and that you feel industry news is offtopic.
The technical analysis on HN and other sites is … non-existent. I would love to hear more from experts with informed opinions on chip design and manufacture and that’s what I expected of the comments here.
Well, I’m kinda peeved that the comments section of both stories turned into a slow-burn flamewar : /
They actually don’t. A good chunk of the chip market is 8-16 bitters. Billions of dollars worth. In the 32-bit category, there’s a lot of players licensing IP and selling chips. ARM has stuff from low end all the way up to smartphones with piles of proven I.P. plus great brand, ecosystem, and market share. They’re not going anywhere any time soon. MIPS is still selling lots of stuff in low-end devices including 32-bit versions of MCU’s. Cavium used them for Octeon I-III’s for high-performance networking with offload engines.
With most of these, you’d get working hardware, all the peripherals you need, toolchain, books/training on it, lots of existing libraries/code, big company to support you, and maybe someone to sue if the I.P. didn’t work. RISC-V doesn’t have all that yet. Most big companies who aren’t backers… which are most big companies in this space… won’t use it without a larger subset of that or all of that depending on company. I’m keeping hopes up for SiFi’s new I.P. but even it probably has to be licensed for big money. If paying an arm and a leg, many will choose to pay the company known to deliver.
From what I see, ARM’s marketing people or whatever are just reacting to a new development that’s in the news a lot. There some threat to their revenues given some big companies are showing interest in RISC-V. So, they’re slamming the competition and protecting their own brand. Just business news or ops as usual.
The 16 bit category has been almost totally annihilated by small 32-bit designs. The 8-bit category will stands.
(I’m also deeply doubtful of RISC-V while hardware beyond SiFive suffers critical existence failure, but that remains to be seen…)
Argh, I thought “fall” was too strong a choice of words while writing this, I should’ve listened to myself.
My line of thought was that it’s really hard to create a competitive server platform, as evidenced by the niche market SPARC, OpenPOWER, and ARM occupy in the server space. However, there are plenty of low-power, low-complexity ARM cores out there that are up for grabs. I’m hoping that Samsung, Qualcomm, and other RISC-V backers are supporting RISC-V in hopes that they can take their CPU designs in-house and cut ARM out of the equation.
I am largely ignorant of the (actual) lower-end chip market, thanks for the insight.
The RISC-V foundation was very intentional in their licensing and wanted to ensure that designers and manufactures would have plenty of secret sauce they could layer on top of the core spec. This is one of the reasons OpenSPARC failed and why so many different frenemies are collaborating on RISC-V.
Their marketing people made the site, but an ARM technology fellow pitched similarly bad arguments in a debate ~2 years ago. Or maybe I’ve just drunk too much Kool Aid.
I upvoted both submissions. I consciously bought Lobsters frontpage spot for RISC-V advertising and paid loss of technical content in exchange. I acknowlege other negative externalities but I think they are small. Sorry about that.
I think RISC-V advertising is as legitimate as BSD advertising, Rust advertising, etc. here. Yes, technical advertising would have been better. I have a small suspicion of gatekeeping RISC-V (or hardware) against established topics, which you can dismiss by simply stating so in the reply.
Thanks for keeping up the effort to steer the submissions in a more cerebral direction, away from news. I totally agree with you and appreciate it.
I almost never upvote these kind of submissions, but seeing as it can be hard to get these off the main page, maybe it could be interesting for lobsters to have some kind of merging feature that could group stories that are simply different stages of the same news into the same story, thus only blocking one spot.
Now that is interesting. It could be some sort of chaining or hyperlinks that goes in the text field. If not done manually, the system could add it automatically in a way that was clearly attributed to the system. I say the text field so the actions next to stories or comments stay uncluttered.
It’s been done before for huge and nasty submissions; usually done to hot takes.
It would also allow it to act as a timeline of sorts. Done correctly I could even apply quasi automatically to tech release posts as well, making it easier to read prior discussions.
The main question right now would be how to handle the comments ui for those grouped stories.
All publicity is good publicity is actually totally false.The actual saying should be something like “Not all bad publicity is bad for you if it aligns with your identity.”. Fighting OSS definitely doesn’t align with the ARM identity/ethos.
It’s so easy to just react and click that upvote button without thinking; the score is a reflection of emotional appeal, not of this submission’s relevance. “But it’s on the front page” is also a tired argument that comes up in every discussion like this one. @friendlysock makes excellent points in his reply to you, I totally agree with him and appreciate that he takes the time to try to steer the submissions away from news. There are plenty of news sites, I don’t want another one.
or maybe n-gate is a worthless sneer masquerading as a website that doesn’t need to be used as a referent on topical material? Especially given that literally anything posted to HN is going to be skewered there? I’m not the go-to guy on HN cheerleading (at all, in any way) but n-gate is smirky petulant crap and doesn’t exactly contribute to enlightenment on tech topics.
El Reg could be described the exact same way!
thats…..actually a good point.