Hello group I have not posted items in awhile and have forgotten to create my own post. So I am tacking onto this one. Sorry. I have an old mac 6500, and wondering what to do with it or could someone use it. Thanks Jan
-----Original Message----- From: Ed Wiser <wisero...@gmail.com> To: Macintosh topics <macgroup@erdos.math.louisville.edu> Sent: Sun, Apr 1, 2018 8:04 pm Subject: [MacGroup] Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.cloudflare.com_announcing-2D1111_&d=DwIFaQ&c=OAG1LQNACBDguGvBeNj18Swhr9TMTjS-x4O_KuapPgY&r=F2GFXrjLFqVo3VwvIlo_XYeEiRRjHv15rxcenz7A21woG2aFGcrzndoSsskxfmOs&m=xKvgcPa9UKGY0wmrlYHlBLtwYDny6EAg32bCVVz9D6Q&s=cOkvkTwNv13EbBMfIUhqupT1KBJljDLmUl6L0XGMDk0&e= Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service Matthew Prince01 Apr 2018 Cloudflare's mission is to help build a better Internet. We're excited today to take another step toward that mission with the launch of 1.1.1.1 — the Internet's fastest, privacy-first consumer DNS service. This post will talk a little about what that is and a lot about why we decided to do it. (If you're interested in the technical details on how we built the service, check out Ólafur Guðmundsson's accompanying post.) Quick Primer On DNS DNS is the directory of the Internet. Whenever you click on a link, send an email, open a mobile app, often one of the first things that has to happen is your device needs to look up the address of a domain. There are two sides of the DNS network: Authoritative (the content side) and Resolver (the consumer side). Every domain needs to have an Authoritative DNS provider. Cloudflare, since our launch in September 2010, has run an extremely fast and widely-used Authoritative DNS service. 1.1.1.1 doesn't (directly) change anything about Cloudflare's Authoritative DNS service. On the other side of the DNS system are resolvers. Every device that connects to the Internet needs a DNS resolver. By default, these resolvers are automatically set by whatever network you're connecting to. So, for most Internet users, when they connect to an ISP, or a coffee shop wifi hot spot, or a mobile network then the network operator will dictate what DNS resolver to use. DNS's Privacy Problem The problem is that these DNS services are often slow and not privacy respecting. What many Internet users don't realize is that even if you're visiting a website that is encrypted — has the little green lock in your browser — that doesn't keep your DNS resolver from knowing the identity of all the sites you visit. That means, by default, your ISP, every wifi network you've connected to, and your mobile network provider have a list of every site you've visited while using them. Network operators have been licking their chops for some time over the idea of taking their users' browsing data and finding a way to monetize it. In the United States, that got easier a year ago when the Senate voted to eliminate rules that restricted ISPs from selling their users' browsing data. With all the concern over the data that companies like Facebook and Google are collecting on you, it worries us to now add ISPs like Comcast, Time Warner, and AT&T to the list. And, make no mistake, this isn't a US-only problem — ISPs around the world see the same privacy-invading opportunity. DNS's Censorship Problem But privacy concerns extend far beyond just ad targeting. Cloudflare operates Project Galileo to protect at no cost politically or artistically important organizations around the world from cyber attack. Through the project we protect groups like LGBTQ organizations targeted in the Middle East, journalists covering political corruption in Africa, human rights workers in Asia, and bloggers on the ground covering the conflict in Crimea. We're really proud of the project and we're really good at stopping cyber attacks launched at its participants. But it's been depressing to us to watch all too frequently how DNS can be used as a tool of censorship against many of the groups we protect. While we're good at stopping cyber attacks, if a consumer's DNS gets blocked there's been nothing we could do to help. In March 2014, for instance, the government of Turkey blocked Twitter after recordings showing a government corruption scandal leaked online. The Internet was censored by the country's ISP's DNS resolvers blocking DNS requests for twitter.com. People literally spray painted 8.8.8.8, the IP of Google's DNS resolver service, on walls to help fellow Turks get back online. Google's DNS resolver is great, but diversity is good and we thought we could do even better. Building a Consumer DNS Service The insecurity of the DNS infrastructure struck the team at Cloudflare as a bug at the core of the Internet, so we set out to do something about it. Given we run one of the largest, most interconnected global networks — and have a lot of experience with DNS — we were well positioned to launch a consumer DNS service. We began testing and found that a resolver, running across our global network, outperformed any of the other consumer DNS services available (including Google's 8.8.8.8). That was encouraging. We began talking with browser manufacturers about what they would want from a DNS resolver. One word kept coming up: privacy. Beyond just a commitment not to use browsing data to help target ads, they wanted to make sure we would wipe all transaction logs within a week. That was an easy request. In fact, we knew we could go much further. We committed to never writing the querying IP addresses to disk and wiping all logs within 24 hours. Cloudflare's business has never been built around tracking users or selling advertising. We don't see personal data as an asset; we see it as a toxic asset. While we need some logging to prevent abuse and debug issues, we couldn't imagine any situation where we'd need that information longer than 24 hours. And we wanted to put our money where our mouth was, so we committed to retaining KPMG, the well-respected auditing firm, to audit our code and practices annually and publish a public report confirming we're doing what we said we would. Enter 1.1.1.1 The one thing that was left was we needed a pair of memorable IPs. One of the core reasons for the DNS system is that IPs aren't very memorable. 172.217.10.46 isn't nearly as memorable as Google.com. But DNS resolvers inherently can't use a catchy domain because they are what have to be queried in order to figure out the IP address of a domain. It's a chicken and egg problem. And, if we wanted the service to be of help in times of crisis like the attempted Turkish coup, we needed something easy enough to remember and spraypaint on walls. We reached out to the team at APNIC. APNIC is a Regional Internet Registery (RIR) responsible for handing out IPs in the Asia Pacific region. It is one of five RIRs that manage IP allocation globally, the other four being: ARIN (North America), RIPE (Europe/Middle East), AFRINIC (Africa), and LATNIC (South America). APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network. We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born. Seriously, April 1? The only question that remained was when to launch the new service? This is the first consumer product Cloudflare has ever launched, so we wanted to reach a wider audience. At the same time, we're geeks at heart. 1.1.1.1 has 4 1s. So it seemed clear that 4/1 (April 1st) was the date we needed to launch it. Never mind that it was a Sunday. Never mind that it was on Easter and during Passover. Never mind that it was April Fools Day — a day where tech companies often trot out fictional services they think are cute while the media and the rest of the non-tech world collectively roll their eyes. We justified it to ourselves that Gmail, another great, non-fictional consumer service, also launched on April 1, 2004. Of course, as Cloudflare's PR team has repeatedly pointed out to me in the run up to launch, the Gmail launch day was a Thursday and not on Easter. Nearly every media briefing I did this week ahead of the launch the reporter made me swear that this wasn't a joke. And it's not. I swear. And the best way to prove that is go to 1.1.1.1, follow the instructions to set it up, and see for yourself. It's real. And it's awesome. Why Did We Build It? The answer to why we built the service goes back to our mission: to help build a better Internet. People come to work at Cloudflare every day in order to make the Internet better, more secure, more reliable, and more efficient. It sounds cheesy, but it's true. When, in 2014, we decided to enable encryption for free for all our customers a lot of people externally thought we were crazy. In addition to the technical and financial costs, SSL was, at the time, the primary difference between our free and paid service. And yet, it was a hard technical challenge, and clearly the right thing to do for the Internet, so we did it. And, in one day, we doubled the size of the encrypted web. I'm proud of the fact that, three and a half years later, the rest of the industry is starting to follow suit. The web should have been encrypted from the beginning. It's a bug it wasn't. We're doing what we can do fix it. When, last year, we made DDoS mitigation free and unmetered across all our plans a lot of people again scratched their heads. But it was the right thing to do. You shouldn't have to have a big bank account to stand up to hackers and bullies online. Over time we're convinced that DDoS mitigation will be a commodity included with all platforms, so of course we should be leading the way to get to that inevitable that end. Part of the reason we've been able to hire such a great team is that we take on big challenges like this when they're the right thing to do. Walk around the office and our team's laptops are adorned with 1.1.1.1 stickers because we're all proud of what we're doing. That alone made building this a no brainer. (PS - Sound fun? We're hiring.) Toward a Better DNS Infrastructure But there's more. DNS itself is a 35-year-old protocol and it's showing its age. It was never designed with privacy or security in mind. In our conversations with browser, operating system, app, and router manufacturers nearly everyone lamented that, even with a privacy-first service like 1.1.1.1, DNS inherently is unencrypted so it leaks data to anyone who's monitoring your network connection. While that's harder to monitor for someone like your ISP than if they run the DNS resolver themselves, it's still not secure. What's needed is a move to a new, modern protocol. There are a couple of different approaches. One is DNS-over-TLS. That takes the existing DNS protocol and adds transport layer encryption. Another is DNS-over-HTTPS. It includes security but also all the modern enhancements like supporting other transport layers (e.g., QUIC) and new technologies like server HTTP/2 Server Push. Both DNS-over-TLS and DNS-over-HTTPS are open standards. And, at launch, we've ensured 1.1.1.1 supports both. We think DNS-over-HTTPS is particularly promising — fast, easier to parse, and encrypted. To date, Google was the only scale provider supporting DNS-over-HTTPS. For obvious reasons, however, non-Chrome browsers and non-Android operating systems have been reluctant to build a service that sends data to a competitor. We're hoping that with an independent DNS-over-HTTPS service now available, we'll see more experiments from browsers, operating systems, routers, and apps to support the protocol. We have no need to be the only such service. More diversity in DNS providers is a Good Thing™. If, over time, a robust ecosystem of networks offering DNS-over-HTTPS support develops then that'll go down as one of the things we'll be proud of in furthering our mission to help build a better Internet. Tying It All Together While DNSPerf now ranks 1.1.1.1 as the fastest DNS resolver when querying non-Cloudflare customers (averaging around 14ms globally), there's an added benefit if you're a Cloudflare customer using our Authoritative DNS. Because the resolver and the recursor are now on the same network, running on the same hardware, we can answer queries for Cloudflare's customers incredibly quickly. We can also support immediate updates, without having to wait for TTLs to expire. In other words, every new user of 1.1.1.1 makes Cloudflare's Authoritative DNS service a bit better. And, vice versa, every new user of Cloudflare's Authoritative DNS service makes 1.1.1.1 a bit better. So, if you're an existing Cloudflare customer, encourage your users to try 1.1.1.1 and you'll see performance benefits from all those who do. Visit https://urldefense.proofpoint.com/v2/url?u=https-3A__1.1.1.1_&d=DwIFaQ&c=OAG1LQNACBDguGvBeNj18Swhr9TMTjS-x4O_KuapPgY&r=F2GFXrjLFqVo3VwvIlo_XYeEiRRjHv15rxcenz7A21woG2aFGcrzndoSsskxfmOs&m=xKvgcPa9UKGY0wmrlYHlBLtwYDny6EAg32bCVVz9D6Q&s=_fFM9_GvbKbL1v_u86ri6dhMXtZciXrUV-YjT6tgD-Y&e= from any device to get started with the Internet's fastest, privacy-first DNS service. Tagged with Product News, resolver, 1.1.1.1, DNS Sent from my iPhone _______________________________________________ MacGroup mailing list Posting address: MacGroup@erdos.math.louisville.edu Archive: <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_macgroup-40erdos.math.louisville.edu_&d=DwIFaQ&c=OAG1LQNACBDguGvBeNj18Swhr9TMTjS-x4O_KuapPgY&r=F2GFXrjLFqVo3VwvIlo_XYeEiRRjHv15rxcenz7A21woG2aFGcrzndoSsskxfmOs&m=xKvgcPa9UKGY0wmrlYHlBLtwYDny6EAg32bCVVz9D6Q&s=hDbwbS9IufZsTkzpZ6b4B9U9DmXTfHQgyCn3zO-2kOU&e=> Answers to questions: <http://erdos.math.louisville.edu/macgroup/>
_______________________________________________ MacGroup mailing list Posting address: MacGroup@erdos.math.louisville.edu Archive: <http://www.mail-archive.com/macgroup@erdos.math.louisville.edu/> Answers to questions: <http://erdos.math.louisville.edu/macgroup/>
