MagicCo.

magicco

Also: You can Now ! Play / Follow the Hacker Noon Podcast on Spotify These episodes of the Hacker Noon podcast are sponsored by DigitalOcean . Discover why developers love DigitalOcean and get started with a free $50 credit at https://do.co/hackernoon Event Horizon: Hacker Noon 2.0 with David Smooke, Dane Lyons, and Austin Pocus A special episode recently recorded in London: Hacker Noon CEO David Smooke in conversation with Hacker Noon’s CPO , and Full Stack Developer, . They discuss Hacker Noon 2.0’s progress, the tribulations involved, and what they’d like to see in the final product. Dane Lyons Austin Pocus “On the reader side, we want to optimize for time spent reading, and on the writer side we want to optimize for words published.” — Dane Lyons Listen to this episode on Spotify or wherever you get your podcasts . A Decentralized Approach to the Internet with Ben Forgan In this episode Trent Lapinski interviews Ben Forgan from , you get to discover how the decentralized technology will help us to connect to the Internet in the future. Magic.co “The network design kind of by default will implement VPN functionality. So, you are ideally able to access a broader range of hot spots and access points. And you are also able to do some more securely and more privately. This is the goal. “ Watch this conversation on YouTube , listen to it on Spotify , or stream the episode here right now. AI and Past Rediscovery with Robert Adamson In this episode Trent Lapinski interviews , you get to discover Rob’s recent app which helps you to identify aliens and learn about ancient civilizations and how we can use AI and machine learning to rediscover our past. Robert Adamson “Something is not real, something about this whole reality thing, is not right. And so simulated reality is a theory that we are living in the computer simulation. The Earth as we know it is really simulated, some really advanced civilizations in the future could not computered in.” Listen to the interview on iTunes , or Google Podcast , Spotify , or watch it on YouTube . Hacker Noon From a Community Perspective with Linh Dao Smooke, COO of Hacker Noon In this episode , COO of , and , host of the Learn How to Code podcast, discuss Hacker Noon’s new trajectory from June 2019 and Hacker Noon from a community perspective. Linh Dao Smooke Hacker Noon Chris Castig “We’re looking at Hacker Noon content as having three niches. We have the blockchain, bitcoin, cryptocurrency people. We have the general tech, startup people. And then we have software development. Software is where we started, so it’s always dear to our heart.” Listen to the interview on iTunes , or Google Podcast , Spotify , or watch on YouTube . These episodes of the Hacker Noon podcast would not be possible without DigitalOcean . Thank you for supporting tech interviews ! Free $50 credit at https://do.co/hackernoon Play / Follow the Hacker Noon Podcast on Spotify P.S. Which episode of which podcast first got you into podcasts? I’m compiling a 101 Podcasts to Hear Before You Die list and I’d love to know what you think should be on it.

Tech Podcasts about Hacker Noon 2.0; AI; and A Decentralized Internet 

Introduction As the holiday season was in full swing, a hacker sporting a hoodie, sitting in a car with antennae on the dashboard and a computer on his lap, sat in a parking lot outside a popular cafe chain. Passersby, busied and high on holiday cheer, buzzed in and out and sometimes even stayed for a while. As he watched Wi-Fi traffic for several hours, nobody called the police or even seemed to notice. People accessed websites like Netflix and Google insecurely over HTTP, revealed all of their browsing activities, made phone calls revealing phone numbers, and sent plenty of unencrypted traffic available for him to intercept or modify at will to carry out phishing or vishing attacks. This is how I think such a story could be carried out. I didn’t actually hack anyone, but I did build a tool to show how hackable people are when they use the Internet. It’s like a credit score, but for your security vulnerabilities. A rare photo of me in my teen years with friends (I’m not sure how United Artists Pictures found this gem) I am a security researcher and cypherpunk with a fascination for the human element and its role in everyday people’s privacy and security. I have conducted (only a few years ago) social engineering experiments against, e.g., my own phone providers, having friends of mine trick them into letting them access my accounts and information in dangerous ways (resulting in those companies inadvertently violating federal privacy and consumer protection regulations). In a past life, I had a lot of fun playing with payphones. I am also a big proponent of encrypting everything on the Internet, always. During my day job, I work on making the Internet safer and more performant at Magic — which is building a decentralized Internet backbone for the future. Over the holidays, I set up an experiment harvesting public Wi-Fi traffic. Since everything on the web should be encrypted nowadays (and many people incorrectly think that all traffic is encrypted), one might expect that there isn’t much to be seen. Unfortunately, that’s not the case. While the state of insecurity has improved since prime, an attacker can still phish you and play games with your packets when you use a public network. Sorry to be the bearer of bad news… Firesheep’s The scores are pretty bad: Tons of online traffic remains entirely unencrypted today, leaving the public susceptible to attack. It’s So Easy to Monitor the Public’s Internet Traffic Spying on web traffic sent over a network. Credit: Wireshark Team [GPL ( )], via Wikimedia Commons http://www.gnu.org/licenses/gpl.html First, find an easy target One of the convenient things about the holidays is that plenty of potential victims congregate at shopping centers. This makes it relatively easy for an attacker to target a large number of personal devices just by “setting up shop” near locations where people are accustomed to finding unencrypted Wi-Fi. These shoppers are also likely loaded with money to spend and are doing so at such a high frequency and at so many locations that they’ve probably already nullified some of their bank’s (and their own) ability to detect fraud with any timeliness whatsoever, making them perfect targets for theft as well. Then, deploy your (very generous) free public Wi-Fi Whats the recipe for a public Wi-Fi network? 1. Use absolutely no encryption at all, or2. Use a pre-shared key and tell everyone (no different than #1) Public Wi-Fi is intentionally insecure and susceptible to several modes of attack And, use one of the simple public Wi-Fi attack methods There are a variety of attack vectors for sniffing traffic on public networks. Here are a few surprisingly low-effort and low-cost methods: An attacker can passively listen in on traffic (even from very far away, without connecting or otherwise indicating to the network the attacker’s presence) with either an off-the-shelf wireless network adapter (e.g. a USB network adapter from Alfa) or an off-the-shelf software-defined radio Simply with freely-available software (e.g. Wireshark) and no additional hardware an attacker can connect to a network and promiscuously retrieve network packets from others (this is only sometimes prevented on switched networks) An attacker can deploy a dedicated, rogue to actively intercept packets by broadcasting a new Wi-Fi network for the sole purpose of carrying out attacks Wi-Fi pineapple But this is all probably illegal, right? Does the law effectively protect people on Wi-Fi? Short answer: Not really. While certain caselaw has found * under Federal law in the U.S., there exist some contradictory opinions on the matter, and there also exist a whole host of states’ laws that protect privacy. that receiving unencrypted Wi-Fi communications under certain circumstances might not be illegal That being said, the three modes I mentioned (above) are so easy that a or can use them. So, while The Fuzz should scare you away from hacking your friends, you should not base your own cybersecurity defenses on the assumption that (laws written on) paper will somehow shield you from cyber bullets. lamer script kiddie * Disclaimer: The “jury” is still out (so to speak, since Federal courts are not in agreement) on the legality/illegality of intercepting unencrypted Wi-Fi communications under Federal law. I’m not a lawyer, and none of what appears in this article is legal advice; but, as an example, Google settled a lawsuit for a mere $7MM involving Google Street View intercepting and recording unencrypted traffic sent on other people’s networks, which contained passwords and all sorts of juicy information. Google can probably afford better lawyers than you, so consider yourself forewarned to not do naughty things! I refuse to be held responsible for the consequences of your own actions . Cortados, Pineapples, and Packets: How people freely give an attacker all their data simply for some Wi-Fi Cortados and compromised Wi-Fi go really well together (pictured here is an inexpensive Alfa USB wireless card, with high-gain/long-range antenna, capable of passive monitoring mode) Pineapples are a symbol of hospitality, so I built a Wi-Fi pineapple to make new friends. The Setup: Free Guest Wi-Fi As someone who cares about obeying the law and protecting people’s privacy, I designed a white-hat experiment to uphold principles of honesty, consent, anonymity, and data privacy. Unlike Google Street View, I chose not to surreptitiously record (in memory or to disk) application payloads, any personally identifiable information, or even any metadata about which hosts connected to which servers. I set up a homemade captive portal analogous to what’s referred to as a , but with the key difference that it did not impersonate the names of any nearby or common wireless networks (because I did not want users to have any misconceptions about who operated the network). Wi-Fi pineapple The SSID “Free Guest WiFi” seemed generic enough, and it greeted users with a nice captive portal splash page containing a non-verbose agreement that obtained from the user consent to having the user’s information and communications monitored. Overall, this was a pretty friendly way to conduct the experiment. A real attacker would be far more aggressive. The Would-be Exploit: I wrote specialized software to determine how hackable you are To further protect users’ privacy, about the protocols and ports that applications were using over the network. I wrote a small tool to gather statistics Three lines of code is all it really takes: p = pcap.pcap(name=interface)p.setfilter(‘’)p.loop(0,handler) , as designed, does not record any IP addresses, MAC addresses, host names, or application data, and cannot be configured in a way to do any of that. It serves only one purpose: summarizing types of packets and ports being used in the least intrusive way possible. My tool In fact, my tool is less intrusive than the deep packet inspection and intelligence provided by enterprise access points and routers (e.g. Ubiquiti Networks products), which ensured that I would be less creepy than a sysadmin and significantly less creepy than an ISP. To further help protect privacy, I made sure any captive portal logs were written into a tmpfs volume just in case there could be any usage log leakage. Again, I think this is pretty darn nice of me. A black-hat hacker could simply use Wireshark and see all of the application data and which websites were being visited. Okay, but for real, who uses the “Free Guest WiFi”? Here’s how many people connected over the course of one afternoon: 49 devices connected 100% accepted the ToS in the captive portal and sent data 0 devices used VPNs The scientists among you will notice my experiment introduces selection bias. The statistics gathered only included persons that explicitly scanned for open Wi-Fi networks, chose my network, and accepted the terms on the captive portal splash page. Such people selecting public networks might be more likely to engage in risky internet behaviors. But, the fact that human interaction was required highlights just how easy these types of attacks are. I actively made choices that made it difficult to collect users data and nearly 50 people still connected, even though other open networks existed in the vicinity. Furthermore, due the fact that using my network required human interaction in the first place, it necessarily excludes any from being included in the statistics and includes only devices with which humans are directly interacting (e.g. mobile phones and laptops). Internet of Things (IoT) devices This is all a bit concerning, but important things on the Internet are all encrypted anyways, right? RIGHT? 😬 Unfortunately HTTPS is not enough to protect you. In fact, its often implemented incorrectly even by major websites you know and trust. (Image credit: TACstock1/Shutterstock.com) More bad news here: >42% of all traffic through my pineapple was unencrypted HTTP traffic. My tool ignored non-IP traffic from its statistics. After gathering 489,330 IP packets, it reported that: (compared to almost 57% on Port 443 used by HTTPS) >42% were on Port 80 used by unencrypted HTTP 2,638 were unencrypted DNS packets 18 were unencrypted Network Time Protocol (NTP) packets The raw transport, port, counts, and percentages were as follows: Totals:udp 8992  4      0.000817444260519udp 5090  482    0.0985020333926udp 67    49     0.0100136921914udp 5353  64     0.0130791081683udp 5355  37     0.00756135940981 udp 137   73     0.0149183577545udp 3544  54     0.011035497517 udp 443   203    0.0414852962214tcp 993   63     0.0128747471032tcp 5223  79     0.0161445241453tcp 9001  350    0.0715263727955tcp 5228  199    0.0406678519608 tcp 53    12     0.00245233278156tcp 443   277467 56.7034516584489330 udp 53    2638   0.539104489813 udp 123   18     0.00367849917234 tcp 80    207538 42.4126867349 In conjunction with DNS and NTP being insecure, to have 42% of traffic potentially be unencrypted HTTP traffic sent via Port 80 is deeply concerning. What about those HTTP Strict Transport Security (HSTS) policies that ? Is the traffic non-web traffic or some sort of other false positive? web browsers should be enforcing With my hands tied by not being able to (ethically) examine packets at a deeper level… I later set up a second experiment in my own lab to examine the behavior of a few popular websites myself. I (where I also explain why we are where we are today, and explain what some popular websites are doing incorrectly). discuss these findings further in Part 2 of this series But, I’ll summarize the findings here: Popular websites are , if at all (this includes Google and Netflix) not always implementing HSTS properly Users of public Wi-Fi networks are still vulnerable to , , and other attacks man-in-the-middle (MITM) interception of private data Darn! But, don’t take my word for it… Before you go through the trouble of trying to find data to refute this analysis, LMGTFY: I tried really hard to prove myself wrong, but then I found Google’s , which uses anonymous usage reporting among Chrome users as well as Google’s own internal data as sources to determine the state of HTTPS usage on the web. HTTPS encryption on the web transparency report According to Google’s own report (as of ): December 29, 2018 11–31% of all websites are visited without encryption (accessed over unencrypted HTTP) ~7% of traffic to Google products is unencrypted (as high as 10% for some Google products) **82.6% of this traffic sent to Google originates from mobile devices** (makes me feel awkward to consider using a Google-developed OS ever again) That’s not insanely far off from the statistics recorded by my tool, especially considering the selection bias and also my unscientific observation that more people were drinking coffee and using mobile devices than were sitting at laptops. (just look at that 82.6% number, again!) I’m not saying we need to fear the FUD… but, actually, I am saying that we need to fear the FUD. I’m also saying that you should fear hackers wearing hoodies, with antennae all over their vehicles, that are looking at you through binoculars in broad daylight, but I digress. How Would an Attacker Use This Traffic to Hack You? I did not hack anybody or compromise anybody’s privacy, and I did consult with legal counsel before publishing this. But, here are some of the ways that people using public Wi-Fi can be compromised, today, by inexpensive hardware and/or free tools (e.g. wireless adapter, Wireshark, Bettercap, etc.). Phishing First, to successfully carry out a phishing attack, an attacker could target some of the popular sites that are accessible over HTTP and not implementing HSTS properly, maybe also leveraging DNS requests since all are insecure (in a sense, captive portals used to work by carrying out DNS-forged MITM attacks every time they wanted to display their splash pages, and this is easily accomplished with DNS today since DNS has never been secured properly since). Create a Sense of Urgency Our hypothetical attacker could, ideally, create a sense of urgency to get users to make more mistakes by hurrying (i.e. overlooking the long and slightly modified URL in the address bar). For example, a captive portal that prompts a user for their email address and provides a very short amount of time to check email for a verification link before they get kicked offline could be the perfect companion to a phishing login page for said email provider. Best yet, once grabbing the user’s credentials and confirming that they are correct, booting them off the network with a fake error message might slow them down from noticing the compromise or from resetting their email password. >:~> Fabricate a Familiar Pretext Serving up the hypothetical attacker’s own phishing pages and securing them with Let’s Encrypt certificates should be easy enough. At least, then, they should look “secure” just long enough to fool a frantic Internet addict into trading their digital identity for a few more minutes of Snapchat. If someone wanted to target credentials for a higher-profile website — perhaps one that actually implements HSTS properly but, with no surprise, just like a number of popular websites it isn’t in the preloading list — the attacker could just wait to target potential victims until after their computer sent an NTP request. By playing with time travel and alternate universes (forging an NTP response with a time set in the future), all HSTS policies cached by the user’s browser whose cache entries expired before the new “present” time could be invalidated. Then, the attacker could just carry out a downgrade attack, 301 Redirect via HTTP to a phishing page, and the rest is gravy. Confuse the s/Deputy/User/ Our hypothetical attacker could trick people into installing some backdoor or botnet software. From then on, the attacker could basically pwn their devices, information, and network of contacts whenever convenient, and identity theft or theft of money would be easy. For this, the attacker could pop up some “warnings” about viruses or spyware on the computer, and kindly suggest that users install an actual virus to “fix” it. This would require the user to actually allow the attacker’s software to be installed. Alternatively, our hypothetical attacker could just mine cryptocurrency in users’ web browsers, which wouldn’t require tricking users into giving their consent for software to be installed. Hit the Unencrypted Plaintext Jackpot Additionally, the traffic that my tool saw sent over Port 5090 is interesting, in that it is a port used by common business VoIP mobile apps to send phone calls over the SIP protocol. Some cellular providers similarly offload voice traffic in this way. I was pleasantly surprised to see this in my statistics! Even if SIP payloads are encrypted, their headers are not, and often contain CID and DID (telephone numbers) in the clear. This could be particularly useful to our hypothetical hacker for carrying a vishing attack on victims or their contacts, since CIDs are easily spoofed to make an attacker caller look familiar. If our hypothetical hacker wanted to hack you or your life by phone, he or she could gather these phone numbers and have a little fun with them later. >:~> >:~> All the problems with public Wi-Fi I’m not trying to over-hype the problems with public Wi-Fi, but I do want to keep these issues at the forefront of people’s minds. We’ve made progress improving the Internet’s basic security, but it’s not anywhere close to enough. There are still gaping problems that we (technologists) have failed to fix for the rest of humanity for way too long. On public Wi-Fi networks, even today, an attacker can: See what sites you’re going to (simply by intercepting DNS requests) Carry out downgrade and MITM attacks through initial HTTP page loads Circumvent HSTS by injecting fake future times via NTP (those HSTS policies do have expiration dates, ya know) Phish for sensitive information Vish you, your friends, and your family Inject fake content/ads or even mine cryptocurrency using your CPU Trick you into running insecure plugins like an outdated version of Flash Spoof a news headline about foodborne illness reports from the local establishment and watch people get up and leave abruptly Spoof a captive portal page that looks like it’s from a nearby network and grab some contact information Validate contact information by forcing you to click on a link in email in order to remain connected, thereby creating a sense of urgency and possibly tricking you into entering your email credentials You’re sufficiently freaked out and want to know how you can protect yourself? I’m glad you asked. There are some commonsense things you can do to make yourself a less-easy target. By default, you should use a VPN and the HTTPS Everywhere browser plugin. If you are not, you probably should reconsider your security posture entirely. at least We are actively working on solving these problems at , where we are implementing VPN-like functionality and a capabilities-based security paradigm by default. Magic To learn more and join the conversation on how to build a safer, more performant Internet, check out magic.co or https://github.com/magic-network And, then what? In , I look into the question, to create such a mess. Then, in the upcoming Part 3 of this series, I will discuss the exhaustive list of things one needs to do in order to be safe online, in light of what I discussed in Parts 1 and 2. Part 2 of this series “Why are we here?” and what popular websites and protocols are doing wrong

A hacker intercepted your WiFi traffic, stole your contacts, passwords, & financial data.

It’s 2019 and, still, around 25% of websites on the Internet are visited without encryption. Let’s look at why. This is Part 2 of a three-part series on public Wi-Fi insecurity. In Part 1, , even today, a hacker could victimize users of public Wi-Fi networks. I to catch a glimpse of how prevalent potentially-insecure activities occur on public Wi-Fi, and compared results to a similar report from Google. I showed how easily created a tool The results were consistently bleak: . about a quarter of all website visits occur without the use of HTTPS I was curious why there would be so much traffic over ol’ unencrypted HTTP, but that required actually inspecting packets at a deeper level. I decided jail didn’t sound like fun; so, back at home, I set up a little packet capture lab to capture and then deeply inspect my own personal traffic using Wireshark to see if it would shed any light on what the heck is going on. Here’s what I found. SUMMARY Much of the Web’s traffic remains unencrypted — for no good reason Popular websites, including google.com, netflix.com, and some major financial institutions improperly set security-related HTTP headers, potentially exposing users to man-in-the-middle attacks DNS still undermines attempts at securing the Internet The Internet’s chain of trust is very complex to implement correctly Popular Websites Are Not Strict Enough about HTTPS With some existing web browser tabs open and while already logged-in to services (email, social media, bank), my traffic looked pretty secure, with only an initial HTTP packet when I connected to my test network (which was generated by my OS to test and see if it was behind a captive portal or not). No harm in probing the network using HTTP (other than revealing my OS to anyone spying on that specific network). The next thing to test was what would happen if I closed a tab and then attempted to revisit a website I’ve previously visited over HTTPS. Would my browser automatically know to send all traffic over HTTPS even if I didn’t specify it “https://” at the beginning of the URL? This is what should happen if websites implement HTTP Strict Transport Security (HSTS) policy correctly, which is as simple as using a 301 Redirect to switch from HTTP to HTTPS and then responding over HTTPS with a special HTTP header . Strict-Transport-Security When I opened a new tab and typed in “google.com” (intentionally omitting the “https://”), I expected HSTS policy to kick in and automatically force HTTPS before hurling even one packet over plaintext HTTP. Google, one of the most visited websites in the world, must implement HSTS correctly, right? Nope. I entered “netflix.com” and expected HSTS policy to kick in. Nope. Frantically, I visited a popular bank website, closed the tab, opened a new tab, and tried that. I tried a few additional popular websites. Nope. Nope. Nope. Nope. I tested on both Firefox and Chrome and got the same results, but then noticed “accounts.google.com” enforce HSTS policy. That’s when it hit me: HSTS is (sometimes) only being enforced for subdomains, not parent domains, of popular websites. did I confirmed that “www.google.com” and “www.netflix.com” never go over HTTP, and neither does the root “github.com” revealing that browsers are enforcing HSTS policies correctly, but… (good job, Github, for doing the right thing!) …a majority of popular websites, including Google and Netflix, are setting HSTS policies only for subdomains and not their parent domains, or not setting HSTS at all. This undermines the whole point of HSTS, leading to traffic being sent unencrypted and creating an easy attack vector on any shared or public network. Popular websites failing to enforce HTTP Strict Transport Security for root domains, potentially exposing visitors to man-in-the-middle attacks (as of March 2019) An easy test to see if HTTP Strict Transport Security is enforced: 1. Select the Network tab in Developer tools on Chrome and then enter a URL you’ve previously visited (without the “https://”). 2. If you get a Status 307 with the response header “Non-Authoritative-Reason: HSTS” set, then HTTP Strict Transport Security is being enforced. If there’s any other type of redirect as the first redirect, then it’s not. Great job, Github! You implemented HTTP Strict Transport Security properly! Okay, so, that can’t explain all the insecure HTTP traffic that my analyzer tool was reporting, but it is hugely concerning that websites that need only be accessed over HTTPS, including many that are attempting to enforce strict HTTPS policies, are not configured properly. This means that users who don’t carefully inspect HTTPS certificates and URLs are at risk of man-in-the-middle (MITM) attacks phishing for information. No bueno. But, HSTS isn’t infallible, either. Remember UDP Port 123 from the statistics in of this series? That’s used by the Network Time Protocol (NTP), and is completely unencrypted and unverified. HSTS informs web browsers to remember HSTS policies up until a set expiration time, but everyone’s clocks can be tampered with simply by performing an NTP MITM attack. Part 1 This means that, by simply hacking time, it’s possible to perform a even for websites that implement HSTS. TLS/SSL stripping attack On a separate note, the use of HSTS also presents considerable privacy concerns. Well-resourced agencies who want to track individuals’ online behaviors can exploit HSTS in a way like supercookies. DNS Stands for “Dinosaur” This problem stems from the domain name system (DNS). DNS is efficient, but it’s horribly insecure and everyone has known that for decades. For example: There is no verification that the IP address responses received over DNS are actually sent by our desired DNS servers and not some man-in-the-middle attacker There is no encryption of DNS lookups There’s also no linkage between DNS entries and web server encryption , so it’s possible to spoof DNS replies to point at nefarious servers and exploit the fact that HSTS policies are not always configured correctly (the one exception being DomainKeys to reduce spoofed spam e-mail, I suppose) I don’t want to get my head chewed off by the anti-DNSSEC crowd, so I’ll do my due diligence here and mention I’m NOT saying that I support the current DNSSEC protocol and I am fully aware that there are a number of efficiency and administrative headache with / . I even love the idea of and know about , and yet and HSTS is not enough to protect the public. Let’s get technical for a sec: concerns DNSSEC DANE HTTP Public Key Pinning its virtues key pinning is now dead So, what I AM saying is this: It’s 2019 and we’re still using the old, insecure DNS system and (despite techniques like HSTS) people are still practically vulnerable in very preventable ways. I’m a technologist, so let me ask fellow technologists this: What the heck is wrong with technology and its practitioners (us) that we haven’t implemented a solution to this, and why is this still a problem? Let’s fix the Internet together! This touches upon a complicated discussion known as the , but let’s continue to have this discussion and make it our priority to make technology work better for the people that use it. usable security problem Mic drop Why haven’t we fixed the Internet yet? I would need the space of more than just this article to cover the “Why?” question fully, but I’ll say that the way we got here is (at least) three-fold: Key pinning was complicated by the fact that encryption keys/certificates needed to be changed from time to time and management of such is a huge headache (poor usability for sysadmins) with current tools — so much so that key pinning is now being Management nightmares exist: deprecated and completely abandoned Security is hard to always implement correctly Extensive knowledge and accuracy are required: Since there is a path where people surf the web securely (albeit difficult for normal people and websites to do consistently) we’ve lost a sense of urgency in ripping everything out and starting over (and/or we’re really stupid) We are lazy(?): possible could There are other reasons as well, but the moral of the story is that this is entirely preventable, but it still isn’t being prevented, and that’s messed up if you think about it. really In Internet We Trust All of this is further complicated by the fact that, today, encryption on the Internet still relies upon trusting centralized authorities, certificate authorities (CAs) to be exact, in order to validate the authenticity of encryption keys used during an initial handshake that occurs between clients/browsers and servers. To make matters worse, which algorithms are going to be used to establish privacy are entirely variable, determined during the initial handshake, and the web is littered with clients and servers with a mismatched combination of (simultaneously) less/more secure algorithms and versions (which is why the TLS article is possibly the ). longest and ugliest article on all of Wikipedia TLS is anything but standard, and shouldn’t be trusted. First, during the initial handshake, a client “Alice” (e.g. a web browser) that wishes to securely communicate with another entity “Bob” (e.g. a web server) must reach agreement with Bob as to what the definition of a “secure communications channel” even is. Next, in order for Alice to establish said secure channel with Bob (let’s call it Channel 1), Alice first needs to use another secure channel with Bob (Channel 2) for exchanging keys to encrypt Channel 1; but, to know that Channel 2 is secure, Alice first validates (over Channel 3) with the certificate authority “Val” to make sure an eavesdropper “Eve” isn’t disguised as Bob. So, for Alice to trust that communications with Bob are secure from Eve, Alice needs to trust that Bob isn’t stupid and/or lazy and trust that Val isn’t the NSA in addition to trusting the protocols used to create Channels 1, 2, and 3. This is known as a chain of trust. But, ? Is the solution to ? who watches the watchers Trust No One Trustless is the only way forward. We need a so-called “trustless” Internet, with privacy and security that works fundamentally differently than it does today. But, contrary to how the “trustless” security paradigm sounds, it isn’t really about eliminating trust completely; instead, it’s about minimizing the scope of risk resulting from trust — to trust . That’s because our problem with security and privacy on the Internet things/people, the problem is that we don’t know who to trust or when, and we do not always know with what information we are entrusting them. (After all, we trust lots of things and people every day of our lives, including that the food we eat won’t poison us and that the airplanes we fly in won’t crash.) less isn’t that we trust not There are paradigms other than the chain of trust used on the Internet today. For example, the paradigms create a decentralized/distributed model of trust that eliminates single points of failure. (The problem with a chain of trust is that each and every link is a single point of failure, so each link increases a multiplier for the probability of failure instead of increasing a divisor.) Still, solutions using these paradigms are not yet ready for prime time. web/network of trust Conclusion In the future, the Internet will have adopted a trustless security paradigm, which will provide a reduction of risk and an increase of transparency, accountability, and audit. We will be trusting in systems and (virtual) policies, based upon mathematically provable and verifiable assurances, and darkness will be illuminated and exposed. Institutions will be replaced by communities, aligned through consensus algorithms. This is happening at higher-levels of the Internet protocol stack, with systems designed to replace how we govern, how we transfer wealth, etc. but has yet to happen at the lower, access-enabling and application transport layers. Is effective encryption all that we need? . But, the Internet is built on trust systems, and all paradigms of trust depend upon, first, establishing a secure channel via infallible encryption. The integrity of chains not only hinge upon their weakest link, but dependable secure channels are the fundamental physics that holds any of the links together in the first place. Similarly, a sound web/network of trust must be based upon sound maths. Absolutely not Over at my day job, , we’re actively working on solving these problems by implementing VPN-like functionality and capabilities-based security for the Internet by default. Magic To learn more and join the conversation on how to build a safer, more performant Internet, check out magic.co or https://github.com/magic-network But, this is where we are today. Solutions are within reach, and are even known, yet they are waiting for implementers. That’s (or any shared network) today. That’s why you still must use the HTTPS Everywhere browser plugin, and use a reputable VPN always. In Part 3 of this series, I will address the long list of all that is needed to surf the web safely at present. why you should be afraid to use public Wi-Fi

Why are we (still) sending so much web traffic unencrypted over the Internet?

Thinking functionally has opened my mind about programming. It has given me a greater depth of understanding of code. It has also led me on a quest in which I found myself questioning many of the core features of the language. I have recently been questioning the statement itself. if Having written an entire application completely void of a single statement, I have found to be optional. if if If you are unfamiliar with functional programming this probably sounds like the rantings of a mad man, but stick with me a bit and allow me to explain. Learning multiple ways to solve the same problem amplifies your mental toolkit by magnitudes. First, meet the statement replacement, the : if ternary operator condition ? expr1 : expr2 Functional programming has taught me to write small functions like this:(don’t yell at me for not currying, that’s for another article) const add = (x, y) => x + y The statement doesn’t fit into this type of function, but the ternary operator does! if const isGreaterThan5 = x => x > 5 ? 'Yep' : 'Nope' Soon I began to find almost every instance of an statement could be replaced with an equivalent ternary operation. if // typical code you might stumble uponfunction saveCustomer(customer) {if (isCustomerValid(customer)) {database.save(customer)} else {alert('customer is invalid')}} // ternary equivalentfunction saveCustomer(customer) {return isCustomerValid(customer)? database.save(customer): alert('customer is invalid')} // ES6 styleconst saveCustomer = customer =>isCustomerValid(customer)? database.save(customer): alert('customer is invalid') Then I started to think how the ternary operator could fit into an statement. I was able to do this with a nested ternary, but it was really messy and not easy to understand. else if Until I started to get creative with my formatting. // old school else-iffunction customerValidation(customer) {if (!customer.email) {return error('email is require')} else if (!customer.login) {return error('login is required')} else if (!customer.name) {return error('name is required')} else {return customer}} // ES6 style custom formatted ternary magicconst customerValidation = customer =>!customer.email   ? error('email is required'): !customer.login ? error('login is required'): !customer.name  ? error('name is required'): customer Now you can clearly see all the conditions defined on the left hand side and the values returned on the right side. Even though it is possible to replace every statement with a ternary operator, I am not saying you should do so. This is just another tool for you to use and consider. if This Rethinking JavaScript article is just one in a series. More to come in the near future! I would love to hear your feedback and thoughts on how you would rethink the statement. Do you have a scenario where you are unsure how this will work? Tell me, let me know! if Continue to Part 2 . Rethinking JavaScript: Death of the For Loop _JavaScript’s for loop has served us well, but it is now obsolete and should be retired in favor of newer functional…_hackernoon.com Rethinking JavaScript: Death of the For Loop I know it’s a small thing, but it makes my day when I get those follow notifications on Medium and Twitter ( ). Or if you think I’m full of shit, tell me in the comments below. @joelnet Cheers! Related Articles _Function composition has got to be my favorite part of functional programming. I hope to provide you with a good real…_hackernoon.com Functional JavaScript: Function Composition For Every Day Use. _In my last article, Death of the for Loop, I tried to convince you to abandon the for loop for a more functional…_medium.com Rethinking JavaScript: Break is the GOTO of loops _In my last 3 articles I convinced you to remove the if statement, kill the for loop, and never use break._medium.com Rethinking JavaScript: Eliminate the switch statement for better code _I love the new Promise library that ships with ES6, though one thing has been left out, a function to sequentially…_medium.com Functional JavaScript: Resolving Promises Sequentially

Rethinking JavaScript: The if statement

Reverse engineering visual novels 101, part 2

Reverse engineering visual novels 101

Get Rich Building Verticalized AI Wrappers (Even If You Don’t Code)

রিচ বিল্ডিং ভার্টিক্যালাইজড এআই র‍্যাপার পান (এমনকি যদি আপনি কোড না করেন)

Werden Sie reich durch die Entwicklung vertikaler KI-Wrapper (auch wenn Sie nicht programmieren können)

Hazte rico creando contenedores de IA verticalizados (aunque no sepas programar)

Devenez riche en créant des wrappers d’IA verticalisés (même si vous ne codez pas)

वर्टिकलाइज़्ड AI रैपर बनाकर अमीर बनें (भले ही आप कोड न जानते हों)

Menjadi Kaya dengan Membangun Pembungkus AI Vertikal (Bahkan Jika Anda Tidak Membuat Kode)

垂直統合型 AI ラッパーを構築して金持ちになる (コードを書かなくても)

Rich Building вертикалдандырылған AI орауыштарын алыңыз (тіпті кодтамасаңыз да)

수직화된 AI 래퍼를 구축하여 부자가 되세요(코딩하지 않아도)

Баян барилгын босоо AI боодолтой бол (та код бичээгүй байсан ч)

Fique rico construindo wrappers de IA verticalizados (mesmo que você não codifique)

Разбогатейте, создавая вертикальные оболочки ИИ (даже если вы не пишете код)

Hel dhismo qani ah oo toosan AI ku duub (Xitaa Haddi aadan Codayn)

Get Rich Building Verticalized AI Wrappers (Kahit Hindi Ka Mag-code)

Dikey AI Sarmalayıcıları Oluşturarak Zengin Olun (Kodlamasanız Bile)

رچ بلڈنگ ورٹیکلائزڈ AI ریپر حاصل کریں (چاہے آپ کوڈ نہ بھی کریں)

Làm giàu bằng cách xây dựng các trình bao bọc AI theo chiều dọc (ngay cả khi bạn không viết mã)

通过构建垂直化 AI 包装器致富（即使你不会编码）

Ah, George Eley. a name destined to go down in history—not for any noble cause, mind you, but for his laughably misguided attempt to become the King of Lunch Box Links. Currently studying at the Graduate School of Business at the University of Cape Town, George seems to have missed the memo that being a business school student doesn't give you a license to annoy the entire internet. For those not yet blessed with the knowledge of George's antics, let me paint you a picture. Imagine a virtual vandal, armed not with spray paint but with a bot army, hell-bent on spamming every blog comment section, forum, and search box within reach. His ultimate goal? To boost the search engine rankings of his lunch box website, MagicBoxPro (because, obviously, lunch boxes need a guerrilla marketing campaign). Little did he know, his reign would be short-lived, thanks to a trail of breadcrumbs he unwittingly left behind. Let me tell you how I managed to track down this would-be spam king after he tried—and failed—to bombard my website. It all started with an alert from CleanTalk, the anti-spam plugin I use on my WordPress site. The plugin had flagged an unusual spike in suspicious activity. Normally, CleanTalk does a stellar job of keeping the spammers at bay, but this time something was different. The attempted spam wasn’t just your run-of-the-mill junk—this was a concerted effort, and it had George Eley’s fingerprints all over it. It didn’t take long to find a social media profile that matched the digital fingerprints. The profile name that caught my attention was George Eley, self-proclaimed king of the lunch boxes. The image below depicts an audit of the Lunch Box Kings website's backlink profile, conducted using the SEO tool Ahrefs. The audit reveals that the site is plagued with inbound link spam, indicating a problematic backlink profile with potentially harmful or irrelevant links. But George's escapades don't stop at merely annoying the internet at large. No, he’s taken it a step further by enlisting the help of servers hosted by Leaseweb.com to do his dirty work. That’s right—George has weaponized Leaseweb’s infrastructure to host his spam bots, turning what could be a perfectly respectable server into a breeding ground for spammy, worthless links. It's like using a luxury yacht to smuggle expired canned goods—both baffling and a complete waste of potential. Now, you might be thinking, "Surely, this can't be a terrible idea. The internet is a vast place, and George is just a small, insignificant part of it." But, oh, dear reader, that is where you'd be wrong. You see, George has no respect for your digital property. He and his bot buddies waltz right in, take a metaphorical dump on your website's front lawn, and strut away, leaving behind a trail of poorly disguised spam links and a bad aftertaste. All this in hopes that his lunch boxes will miraculously appear at the top of Google search results. But here's the kicker: 98% of all blog comment sections are automatically no-follow. That means George's "brilliant" strategy is about as effective as trying to sell ice to penguins in Antarctica. The search engines aren’t impressed, and the only thing George’s efforts have achieved is widespread annoyance and a burgeoning reputation as that guy. Yes, that guy—the one who thinks spamming is a valid marketing strategy in 2024. You have to wonder what George was thinking. Did he imagine that webmasters everywhere would fall to their knees, thanking him for blessing their sites with his magical lunch box links? Did he dream of being hailed as a marketing genius, the likes of which the world has never seen? Or was he simply so blinded by the allure of SEO supremacy that he forgot the basic principles of respect, decency, and common sense? The internet is a shared space, a digital community where millions of us coexist (mostly) peacefully. But then there are the spammers—the digital equivalent of the guy who leaves his trash in your front yard because "someone will clean it up eventually." Spammers like George don't just disrespect individual websites; they disrespect the entire online ecosystem. They're like digital parasites, contributing nothing of value and instead feeding off the hard work of others. So, George, if you're reading this—and I suspect you might be, given your obsession with SEO—please, for the love of all things sacred in digital marketing, stop. Take your bots, your lunch boxes, and your Leaseweb servers, and find a more honorable way to promote your products. Maybe try creating quality content? Building genuine relationships with customers? Or, here's a wild idea: respect the internet property of others. Because, at the end of the day, the only thing worse than a spammer is a spammer who doesn't even know how ineffective his tactics are. And trust me, George, nobody wants to buy a lunch box from that guy. Ah, George Eley . a name destined to go down in history—not for any noble cause, mind you, but for his laughably misguided attempt to become the King of Lunch Box Links. Currently studying at the Graduate School of Business at the University of Cape Town, George seems to have missed the memo that being a business school student doesn't give you a license to annoy the entire internet. George Eley For those not yet blessed with the knowledge of George's antics, let me paint you a picture. Imagine a virtual vandal, armed not with spray paint but with a bot army, hell-bent on spamming every blog comment section, forum, and search box within reach. His ultimate goal? To boost the search engine rankings of his lunch box website, MagicBoxPro (because, obviously, lunch boxes need a guerrilla marketing campaign). his MagicBoxPro Little did he know, his reign would be short-lived, thanks to a trail of breadcrumbs he unwittingly left behind. Let me tell you how I managed to track down this would-be spam king after he tried—and failed—to bombard my website. It all started with an alert from CleanTalk, the anti-spam plugin I use on my WordPress site. The plugin had flagged an unusual spike in suspicious activity. Normally, CleanTalk does a stellar job of keeping the spammers at bay, but this time something was different. The attempted spam wasn’t just your run-of-the-mill junk—this was a concerted effort, and it had George Eley’s fingerprints all over it. on my It didn’t take long to find a social media profile that matched the digital fingerprints. The profile name that caught my attention was George Eley, self-proclaimed king of the lunch boxes. The image below depicts an audit of the Lunch Box Kings website's backlink profile, conducted using the SEO tool Ahrefs . The audit reveals that the site is plagued with inbound link spam, indicating a problematic backlink profile with potentially harmful or irrelevant links. SEO tool Ahrefs But George's escapades don't stop at merely annoying the internet at large. No, he’s taken it a step further by enlisting the help of servers hosted by Leaseweb.com to do his dirty work. That’s right—George has weaponized Leaseweb’s infrastructure to host his spam bots, turning what could be a perfectly respectable server into a breeding ground for spammy, worthless links. It's like using a luxury yacht to smuggle expired canned goods—both baffling and a complete waste of potential. Now, you might be thinking, "Surely, this can't be a terrible idea. The internet is a vast place, and George is just a small, insignificant part of it." But, oh, dear reader, that is where you'd be wrong. You see, George has no respect for your digital property. He and his bot buddies waltz right in, take a metaphorical dump on your website's front lawn, and strut away, leaving behind a trail of poorly disguised spam links and a bad aftertaste. All this in hopes that his lunch boxes will miraculously appear at the top of Google search results. But here's the kicker: 98% of all blog comment sections are automatically no-follow. That means George's "brilliant" strategy is about as effective as trying to sell ice to penguins in Antarctica. The search engines aren’t impressed, and the only thing George’s efforts have achieved is widespread annoyance and a burgeoning reputation as that guy . Yes, that guy —the one who thinks spamming is a valid marketing strategy in 2024. that guy that guy You have to wonder what George was thinking. Did he imagine that webmasters everywhere would fall to their knees, thanking him for blessing their sites with his magical lunch box links? Did he dream of being hailed as a marketing genius, the likes of which the world has never seen? Or was he simply so blinded by the allure of SEO supremacy that he forgot the basic principles of respect, decency, and common sense? The internet is a shared space, a digital community where millions of us coexist (mostly) peacefully. But then there are the spammers—the digital equivalent of the guy who leaves his trash in your front yard because "someone will clean it up eventually." Spammers like George don't just disrespect individual websites; they disrespect the entire online ecosystem. They're like digital parasites, contributing nothing of value and instead feeding off the hard work of others. So, George, if you're reading this—and I suspect you might be, given your obsession with SEO—please, for the love of all things sacred in digital marketing, stop. Take your bots, your lunch boxes, and your Leaseweb servers, and find a more honorable way to promote your products. Maybe try creating quality content? Building genuine relationships with customers? Or, here's a wild idea: respect the internet property of others. Because, at the end of the day, the only thing worse than a spammer is a spammer who doesn't even know how ineffective his tactics are. And trust me, George, nobody wants to buy a lunch box from that guy . that guy

The Tragic Tale of the "Lunch Box Spammer": George Eley's Quest for Internet Infamy

Towards the Automation of Book Typesetting: Acknowledgments and References

Python Unit Testing is Even More Convenient Than You Might Realize

Stories, News & Mentions about MAGICCO

Magicco’s Stories on HackerNoon