Podcasts about csrf

Steganography Challenge Didier revealed the solution to last weekend s cryptography challenge. The image used the same encoding scheme as Didier described before, but the columns and rows were transposed. https://isc.sans.edu/forums/diary/Steganography%20Challenge%3A%20My%20Solution/31912/ FBI Warns of End-of-life routers The FBI is tracking larger botnets taking advantage of unpatched routers. Many of these routers are end-of-life, and no patches are available for the exploited vulnerabilities. The attackers are turning the devices into proxies, which are resold for various criminal activities. https://www.ic3.gov/PSA/2025/PSA250507 ASUS Driverhub Vulnerability ASUS Driverhub software does not properly check the origin of HTTP requests, allowing a CSRF attack from any website leading to arbitrary code execution. https://mrbruh.com/asusdriverhub/ RV-Tools SEO Poisoning Varonis Threat Labs observed SEO poisoning being used to trick system administrators into installing a malicious version of RV Tools. The malicious version includes a remote access tool leading to the theft of credentials https://www.varonis.com/blog/seo-poisoning#initial-access-and-persistence

Privacy Aware Bots A botnet is using privacy as well as CSRF prevention headers to better blend in with normal browsers. However, in the process they may make it actually easier to spot them. https://isc.sans.edu/diary/Privacy%20Aware%20Bots/31796 Critical Ingress Nightmare Vulnerability ingress-nginx fixed four new vulnerabilities, one of which may lead to a Kubernetes cluster compromise. Note that at the time I am making this live, not all of the URLs below are available yet, but I hope they will be available shortly after publishing this podcast https://www.darkreading.com/application-security/critical-ingressnightmare-vulns-kubernetes-environments https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities https://kubernetes.io/blog/ FBI Warns of File Converter Scams File converters may include malicious ad ons. Be careful where you get your software from. https://www.fbi.gov/contact-us/field-offices/denver/news/fbi-denver-warns-of-online-file-converter-scam VSCode Extension Includes Ransomware https://x.com/ReversingLabs/status/1902355043065500145

In this episode of the JavaScript Master Podcast, we explore HTMX, a powerful tool that simplifies frontend development by reducing the need for complex JavaScript frameworks. Our guest, Damian Płaza, Senior Software Engineer, Application Architect, and Product Development Leader at Volue, shares his insights on how HTMX can enhance modern web applications.What's inside?✅ What is HTMX? A deep dive into its purpose and core concepts✅ How HTMX compares to modern JavaScript frameworks like React, Vue, and Angular✅ Hypermedia-driven applications – what does that mean in practice?✅ Performance benefits – does HTMX make web apps faster?✅ Reducing JavaScript complexity – how much JavaScript can you eliminate?✅ Common use cases – when is HTMX the best choice?✅ Limitations of HTMX – when might it not be the right tool?✅ HTMX & server-side technologies – how it integrates with PHP, Python, and Node.js✅ Handling dynamic data & DOM updates – does HTMX replace JavaScript completely?✅ Security considerations – how does HTMX handle XSS and CSRF protection?✅ HTMX event model – how it differs from traditional JavaScript event handling✅ How HTMX fits into modern web development – should you use it in your next project?✅ Real-world examples & success stories – companies and projects using HTMX today✅ The future of HTMX – what's on the roadmap?If you're curious about hypermedia-driven applications and looking for ways to simplify frontend development, this episode is packed with valuable insights!

独立行政法人情報処理推進機構（IPA）および一般社団法人JPCERT コーディネーションセンター（JPCERT/CC）は2月4日、WordPress用プラグインActivity Log WinterLockにおけるクロスサイトリクエストフォージェリの脆弱性について「Japan Vulnerability Notes（JVN）」で発表した。

A short episode this week, featuring Keyhole which abuses a logic bug in Windows Store DRM, an OAuth flow issue, and a CSRF protection bypass. Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/265.html [00:00:00] Introduction [00:00:16] Attacking Hypervisors From KVM to Mobile Security Platforms [00:02:30] Keyhole [00:10:12] Drilling the redirect_uri in OAuth [00:18:00] Cross-Site POST Requests Without a Content-Type Header [00:24:03] New AMSI Bypss Technique Modifying CLR.DLL in Memory Podcast episodes are available on the usual podcast platforms: -- Apple Podcasts: https://podcasts.apple.com/us/podcast/id1484046063 -- Spotify: https://open.spotify.com/show/4NKCxk8aPEuEFuHsEQ9Tdt -- Google Podcasts: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy9hMTIxYTI0L3BvZGNhc3QvcnNz -- Other audio platforms can be found at https://anchor.fm/dayzerosec You can also join our discord: https://discord.gg/daTxTK9

Today in the Creator's Lab, Tony Dang joins Elixir Wizards Sundi Myint and Owen Bickford to break down his journey of creating a local-first, offline-ready to-do app using Phoenix LiveView, Svelte, and CRDTs (Conflict-free Replicated Data Types). Tony explains why offline functionality matters and how this feature can transform various apps. He shares insights on different libraries, algorithms, and techniques for building local-first experiences and highlights the advantages of Elixir and Phoenix LiveView. Tony also shares his go-to tools, like Inertia.js for connecting Phoenix backends with JavaScript frontends, and favorite Elixir packages like Oban, Joken, and Hammer, offering a toolkit for anyone building powerful, adaptable applications. Topics discussed in this episode: Tony Dang's background from mechanical engineer to web developer Building an offline-enabled to-do app with Phoenix LiveView and Svelte CRDTs: Conflict-free Replicated Data Types for merging changes offline How to make a LiveView app work offline Sending full state updates vs. incremental updates for performance optimization Inspiring others through open-source projects and community contributions Learning vanilla Phoenix and Channels to understand LiveView better Handling stale CSRF tokens when reconnecting to a LiveView app offline Exploring service workers and browser APIs for managing offline connectivity Balancing the use of JavaScript and Elixir in web development Fostering a supportive and inspiring Elixir community Links mentioned: Working in Elevators: How to build an offline-enabled, real-time todo app (https://www.youtube.com/watch?v=PX9-lq0LL9Q) w/ LiveView, Svelte, & Yjs Tony's Twitter: https://x.com/tonydangblog https://liveview-svelte-pwa.fly.dev/ https://github.com/tonydangblog/liveview-svelte-pwa CRDT: https://en.wikipedia.org/wiki/Conflict-freereplicateddatatype PWA: https://en.wikipedia.org/wiki/Progressivewebapp https://github.com/josevalim/sync https://github.com/sveltejs/svelte https://github.com/woutdp/livesvelte https://github.com/yjs/yjs https://github.com/satoren/yex https://github.com/y-crdt/y-crdt https://linear.app/ https://github.com/automerge/automerge https://hexdocs.pm/phoenix/1.4.0-rc.1/presence.html Vaxine, the Rich CRDT Database for ElixirPhoenix Apps (https://www.youtube.com/watch?v=n2c5eWIfziY) | James Arthur | Code BEAM America 2022 https://github.com/electric-sql/vaxine Hybrid Logical Clocks https://muratbuffalo.blogspot.com/2014/07/hybrid-logical-clocks.html https://en.wikipedia.org/wiki/256(number) CSRF Tokens in LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#getconnectparams/1 https://hexdocs.pm/phoenix/channels.html Authentication with Passkeys (https://www.youtube.com/playlist?list=PL8lFmBcH3vX-JNIgxW3THUy7REthSRFEI) Talk by Tony https://www.meetup.com/dc-elixir/ https://github.com/rails/rails https://github.com/facebook/react-native https://github.com/vuejs https://github.com/laravel/laravel https://hexdocs.pm/phoenixliveview/js-interop.html https://github.com/inertiajs https://github.com/inertiajs/inertia-phoenix https://savvycal.com/ https://github.com/wojtekmach/req https://github.com/oban-bg/oban https://github.com/joken-elixir/joken https://github.com/ExHammer/hammer Special Guest: Tony Dang.

独立行政法人情報処理推進機構（IPA）および一般社団法人JPCERT コーディネーションセンター（JPCERT/CC）は9月9日、複数のアルプスシステムインテグレーション製品およびそのOEM製品におけるクロスサイトリクエストフォージェリの脆弱性について「Japan Vulnerability Notes（JVN）」で発表した。

独立行政法人情報処理推進機構（IPA）および一般社団法人JPCERT コーディネーションセンター（JPCERT/CC）は6月26日、WordPress用プラグインWP Tweet WallsおよびSola Testimonialsにおけるクロスサイトリクエストフォージェリの脆弱性について「Japan Vulnerability Notes（JVN）」で発表した。

Guest: Soheil Khodayari, Security Researcher, CISPA - Helmholtz Center for Information Security [@CISPA]On LinkedIn | https://www.linkedin.com/in/soheilkhodayari/On Twitter | https://x.com/Soheil__K____________________________Hosts: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martinMarco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society PodcastOn ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli____________________________Episode NotesIn this episode of On Location with Sean and Marco, co-host Sean Martin embarks on a solo journey to cover the OWASP AppSec Global event in Lisbon. Sean welcomes Soheil Khodayari, a security researcher at the CISPA Helmholtz Center for Information Security in Saarland, Germany, to discuss the intricacies of web security, particularly focusing on request forgery attacks.They dive into Soheil's background, noting his extensive research in web security and privacy, with interests spanning vulnerability detection, internet measurements, browser security, and new testing techniques. Soheil aims to share valuable insights on request forgery attacks, a prevalent issue in web security that continues to challenge developers and security professionals alike.The conversation transitions to an in-depth exploration of client-side request forgery and how these attacks differ from traditional cross-site request forgery (CSRF). Soheil elaborates on the evolution of web applications and how shifting functionalities to client-side code has introduced new, complex vulnerabilities. He identifies the critical role of input validation and the resurgence of issues related to improper handling of user inputs, which attackers can exploit to cause unintended actions on authenticated sessions.As they prepare for the upcoming OWASP Global AppSec event, Soheil highlights his session, titled "In the Same Site We Trust: Navigating the Landscape of Client-Side Request Hijacking on the Web," scheduled for Thursday, June 27th. He emphasizes the relevance of the session for developers and security professionals who are eager to learn about modern request hijacking techniques, defense mechanisms, and how to detect these vulnerabilities using automated tools.The discussion touches on the landscape of modern browsers, the effectiveness of same-site cookies as a defense-in-depth strategy, and the limitations of these measures in preventing client-side CSRF attacks. Soheil mentions the development of a vulnerability detection tool designed to mitigate these sophisticated threats and invites attendees to integrate such tools into their CI/CD pipelines for enhanced security.Sean and Soheil ultimately reflect on the importance of understanding the nuances of web application security. They encourage listeners to attend the session, engage with the community, and explore advanced security practices to safeguard their applications against evolving threats. This engaging episode sets the stage for a deep dive into the technical aspects of web security at the OWASP Global AppSec event.Top Questions AddressedWhat are request forgery attacks and how have they evolved over time?How do modern browsers and applications handle security against these attacks?What will Soheil Khodayari's session at OWASP Global AppSec cover and who should attend?Be sure to follow our Coverage Journey and subscribe to our podcasts!____________________________Follow our OWASP AppSec Global Lisbon 2024 coverage: https://www.itspmagazine.com/owasp-global-2024-lisbon-application-security-event-coverage-in-portugalOn YouTube:

Guest: Soheil Khodayari, Security Researcher, CISPA - Helmholtz Center for Information Security [@CISPA]On LinkedIn | https://www.linkedin.com/in/soheilkhodayari/On Twitter | https://x.com/Soheil__K____________________________Hosts: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martinMarco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society PodcastOn ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli____________________________Episode NotesIn this episode of On Location with Sean and Marco, co-host Sean Martin embarks on a solo journey to cover the OWASP AppSec Global event in Lisbon. Sean welcomes Soheil Khodayari, a security researcher at the CISPA Helmholtz Center for Information Security in Saarland, Germany, to discuss the intricacies of web security, particularly focusing on request forgery attacks.They dive into Soheil's background, noting his extensive research in web security and privacy, with interests spanning vulnerability detection, internet measurements, browser security, and new testing techniques. Soheil aims to share valuable insights on request forgery attacks, a prevalent issue in web security that continues to challenge developers and security professionals alike.The conversation transitions to an in-depth exploration of client-side request forgery and how these attacks differ from traditional cross-site request forgery (CSRF). Soheil elaborates on the evolution of web applications and how shifting functionalities to client-side code has introduced new, complex vulnerabilities. He identifies the critical role of input validation and the resurgence of issues related to improper handling of user inputs, which attackers can exploit to cause unintended actions on authenticated sessions.As they prepare for the upcoming OWASP Global AppSec event, Soheil highlights his session, titled "In the Same Site We Trust: Navigating the Landscape of Client-Side Request Hijacking on the Web," scheduled for Thursday, June 27th. He emphasizes the relevance of the session for developers and security professionals who are eager to learn about modern request hijacking techniques, defense mechanisms, and how to detect these vulnerabilities using automated tools.The discussion touches on the landscape of modern browsers, the effectiveness of same-site cookies as a defense-in-depth strategy, and the limitations of these measures in preventing client-side CSRF attacks. Soheil mentions the development of a vulnerability detection tool designed to mitigate these sophisticated threats and invites attendees to integrate such tools into their CI/CD pipelines for enhanced security.Sean and Soheil ultimately reflect on the importance of understanding the nuances of web application security. They encourage listeners to attend the session, engage with the community, and explore advanced security practices to safeguard their applications against evolving threats. This engaging episode sets the stage for a deep dive into the technical aspects of web security at the OWASP Global AppSec event.Top Questions AddressedWhat are request forgery attacks and how have they evolved over time?How do modern browsers and applications handle security against these attacks?What will Soheil Khodayari's session at OWASP Global AppSec cover and who should attend?Be sure to follow our Coverage Journey and subscribe to our podcasts!____________________________Follow our OWASP AppSec Global Lisbon 2024 coverage: https://www.itspmagazine.com/owasp-global-2024-lisbon-application-security-event-coverage-in-portugalOn YouTube:

独立行政法人情報処理推進機構（IPA）および一般社団法人JPCERT コーディネーションセンター（JPCERT/CC）は4月23日、TvRock におけるサービス運用妨害（DoS）とクロスサイトリクエストフォージェリの脆弱性についてJVNで発表した。

Today, we're discussing the lawsuits coming out of AT&T's massive data breach affecting 73 million, a critical flaw in the LayerSlider WordPress plugin jeopardizing 1 million sites, and a preventable hack into Microsoft Exchange highlighting cybersecurity's critical stakes. Experts weigh in on the ramifications and preventive strategies, ensuring you stay informed and ahead in the cybersecurity game. Your feedback on these issues is crucial; join the conversation and help shape a more secure digital future. References: For insights on the AT&T lawsuits and data breach impacts: https://www.bleepingcomputer.com/news/security/atandt-faces-lawsuits-over-data-breach-affecting-73-million-customers/ Understanding the critical vulnerability in the LayerSlider WordPress plugin: https://www.bleepingcomputer.com/news/security/critical-flaw-in-layerslider-wordpress-plugin-impacts-1-million-sites/ Analysis of the Microsoft Exchange hack and recommended security reforms: https://www.cybersecuritydive.com/news/microsoft-exchange-hack-china-preventable/712146/ and https://www.cisa.gov/sites/default/files/2024-04/CSRB_Review_of_the_Summer_2023_MEO_Intrusion_Final_508c.pdf Follow us on Instagram: https://www.instagram.com/the_daily_decrypt/ Thanks to Jered Jones for providing the music for this episode. https://www.jeredjones.com/ Logo Design by https://www.zackgraber.com/ Tags for the Episode: AT&T data breach, cybersecurity, legal actions, LayerSlider WordPress plugin, SQL injection, plugin security, Microsoft Exchange hack, cloud service security, cybersecurity reforms, identity theft, data privacy, security protocols, cyber risk management, plugin vulnerabilities, security best practices, cyber attack prevention, digital security, cybersecurity insights, technology law, security updates Search Phrases: AT&T 73 million data breach details Legal consequences of cybersecurity failures How to secure WordPress sites from SQL injection Impact of LayerSlider plugin vulnerability Preventing Microsoft Exchange cyber attacks Enhancing cloud service cybersecurity Best practices in digital security updates Addressing identity theft and data breaches Cybersecurity insights for tech professionals Cyber risk management strategies Lawsuits following major data breaches Plugin security for WordPress administrators Learning from cybersecurity breaches Updates and security in technology law Prevention strategies for cyber attacks Transcript: Apr 4 Welcome back to the Daily Decrypt. AT&T is grappling with the fallout of a data breach that impacted 73 million customers. As class action lawsuits begin to mount, also, over 1 million WordPress sites are at immediate risk due to a critical vulnerability in the Layerslider plugin, which can expose these sites to SQL injection attacks. How can WordPress admins protect themselves from this vulnerability? And finally, the Cyber Safety Review Board has declared the massive intrusion into Microsoft's Exchange Online entirely preventable. And just a reminder, this mega intrusion led to over 60, 000 U. S. State Department officials emails being compromised. How the heck is Microsoft gonna restore trust and confidence from the consumers in their security protocols? Stick around to find out. So it's been two days since my last episode, in which I highlighted the most recent AT& T breach. Well, it's been a long couple of days, the reason there were no new episodes is because I lost internet, and you might be thinking, Hey, you just finished slandering AT& T on this podcast on Monday, and then your AT& T internet goes out? That's correct. There's really no other explanation other than aT& T is seeking revenge against the Daily Decrypt. But I digress. To recap what has happened, AT& T has admitted to a data breach exposing sensitive information of 73 million customers this breach included usernames, social security numbers, email addresses, and AT& T PINs used to make secure account changes on AT& T customer accounts. The timeline reveals that AT& T's initial denial of the breach, which was first alleged by ShinyHunters in 2021, and their recent admission after a second threat actor leaked the data in 2024, raises questions about the effectiveness of corporate data breach detection and response strategies. The leaked data isn't from the past year or even couple of years. The leaked data is from 2019. And it includes 7. 6 million current customers and 65. 4 million former AT& T account holders, which I guess says a lot about AT& T's churn rate, that they have 65 million former customers and only 7 million current customers. Needless to say, a lot of data was breached. Now, what's fascinating about this is that this was brought to AT& T's attention in early 2021 and they denied it. And then another threat actor group released the same data from 2019 and early 2024 AT& T also denied that. They're just saying that they don't know this data doesn't belong to them. This data wasn't stolen from their systems when clearly it was. So only in the last week did AT& T finally admit that that data from 2019 belongs to them and was breached from their networks. So because of this negligence, multiple class action lawsuits have spun up very recently. Most notably, there's one from Morgan Morgan, which is the same law firm that's been suing Google over the fact that it tracks users data even when they're in incognito mode. And I believe Google paid out a settlement. So this is the same law firm that did that. And they're accusing AT& T of negligence, breach of implied contract, and unjust enrichment. And they're aiming for compensatory damages and improved data security protocols. Their lawsuit criticizes AT& T for not acting on known vulnerabilities and delaying breach acknowledgement, jeopardizing customer data privacy and confidence. I'm really glad to see these lawsuits are being spun up. As you heard in Monday's episode, I was calling for multiple class action lawsuits.. So yeah, I hope you get the crap suit out of you. And yes, I am an AT& T customer.. If you are also an AT& T customer and you're concerned about your data being in one of these breaches or this main breach from 2019, I believe the site haveibeenpwned. com has acquired the data from this breach. And so you can just search your email addresses in that site to see if it was compromised. Listen to the episode released this past Monday for some tips on how to stay safe when attackers have all of this information. All the information needed to open up new credit cards, take out new lines of credit in your name, and do a whole lot of stuff. All right. Well, there's another WordPress vulnerability out there with a CVSS score of 9. 8 out of a 10 max. The name of the plugin? Layerslider. This plugin is used by over 1 million sites. and exposes these sites to SQL injection attacks. This flaw allows attackers to potentially extract sensitive data, including password hashes, leading to site takeovers or data breaches. This vulnerability was discovered on March 25th, and was promptly reported to WordFence, earning the researcher 5, 500 bounty. The vulnerability affects layer slider version 7. 9. 11 through 7. 10, which as mentioned before, allows for SQL code injection. And just to quickly discuss what SQL code injection is, it's when data is queried from a database to be populated on a website. Those databases use a language called SQL or SQL that uses a query language, which is what the QL stands for, to query that data. This vulnerability allows attackers to query that data by injecting malicious commands. using SQL. They can essentially pull anything they want out of the databases. So that includes, yeah, password hashes, names, emails, whatever data is on the website. If that's social security numbers, that's vulnerable too. Despite the severity though, the attack is limited to a time based blind SQL injection, which relies on observing response times to infer data. And this type of SQL injection is hard to detect, but it's also hard for the attacker to get large amounts of data. It's more of an inferred sort of data attack. For more information on this attack, check out the article in the show notes by Bleeping Computer. The good news is that the flaw was quickly addressed by the plugin's developers, Creatura, who released an update to version 7. 10. 1 on March 27th, so within 48 hours of being notified. If you are a layer slider user, please go update immediately to mitigate this risk. WordPress is built on the use of plugins. That's what makes it so marketable. The more plugins you have, the more plugins you use, the higher your risk is. And I personally am a WordPress user. The DailyDecrypt. com is a WordPress site, and I'm having a hard time setting up notifications for outdated plugins. It's not very intuitive. Granted, I don't use any plugins other than the podcast plugins hosts this podcast and I'm constantly on the site making sure everything's updated and posting new podcasts, but a lot of people with WordPress sites will set it and forget it. Like they'll put up their site. It's a shop. They respond to orders they get, but they don't actually go onto the WordPress site too much. And a lot of WordPress users are less tech savvy than me. So they probably don't have alerts set up for outdated plugins. I highly encourage you to just set up a reminder that goes off once a week, once a month, whatever interval you think is appropriate for the risk of your website. and just go check to make sure all the plugins are up to date. It's a really quick check, and if they're not up to date, you just press a little button and update them. You're likely not doing advanced programming on your WordPress site that might break with an update, so just, just press the little button. All right, and our final story comes from the Cyber Safety Review Board, where they have officially declared, which is a pretty bold stance, they've officially declared that the intrusion into Microsoft Exchange Online that exposed about 60, 000 U. S. State Department emails, was entirely preventable. This report criticizes Microsoft's corporate culture for insufficient investment in security and risk management and calls for widespread security reforms within Microsoft and among all cloud service providers to prioritize cybersecurity. The Cyber Safety Review Board, or CSRF, urges Microsoft to publicly outline its security reforms and outlines a series of operational decisions that encourages cloud service providers and government partners to make security focused changes. The report, released by CSRF, details the compromise of key U. S. officials mailboxes by China affiliated actors and criticizes Microsoft for charging extra for essential security features like enhanced logging. Which, in the recent past, has since been reversed. Microsoft no longer charges extra. But still, why did they do that in the first place? Microsoft has responded and announced plans for major security reforms, including better infrastructure and security processes. It's worth noting that Microsoft has been very cooperative throughout the CSRB's investigation, and are definitely willing to listen to the suggestions and make some changes, so That's step one, that's Way better than what AT& T did when confronted. Microsoft is looking into this. They want to maintain consumer confidence as much as anybody. They're at the center of our tech universe and even more so than most consumers might even know. A lot of servers and digital infrastructure is hosted on Windows server and Windows machines. And if you've been listening for a while, you've heard DogeSpan and I discuss another recent breach amongst senior developers and executives at Microsoft without multi factor authentication on their development accounts. Attackers were able to get in. So all of these incidents are starting to pile up and really pointing fingers at Microsoft. We got to get this fixed. They're starting to crack down. We're going to keep an eye on them. We're going to keep reporting what happens at Microsoft. Hopefully nothing else big because they hold a lot of data. in their cloud services, Exchange, Azure. Microsoft is a pretty big powerhouse in the cloud service provider. So yeah, hopefully they're throwing some money at this. They're spinning up some new teams and they're really looking at legacy infrastructure. It's a pretty old product that they're continually building on. So they need to start peeling away these layers of this product and figure out how they can boost up security. They need to be leading. and setting a good example for smaller companies by being so secure. Well, that's the show. That's all we got for you. Again, sorry about the quick hiatus. Internet went out. Hopefully it will stay on for the remainder of the week and maybe I can put an episode out on Saturday, recapping some stuff. But if you like what you hear, please go find us on Instagram or The Daily Decrypt and send us a comment or a DM. We'd love to hear from you. Until then, we'll talk to you some more tomorrow.

Jayson joins us to discuss how he is using, and social engineering, AI to help with his security engagements. We also talk about the low-tech tools he employs to get the job done, some tech tools that are in play, and the most important part of any security testing: Talking to people, creating awareness, and great reporting. The latest attacks against WiFi, its illegal to break encryption, BLE Padlocks are as secure as you think, when command not found attacks, how did your vibrator get infected...with malware, the OT jackpot, the backdoor in a random CSRF library, it's a vulnerability but there is no CVE, car theft and Canada, Glubteba, and settings things on fire! Visit https://www.securityweekly.com/psw for all the latest episodes! Show Notes: https://securityweekly.com/psw-818

Jayson joins us to discuss how he is using, and social engineering, AI to help with his security engagements. We also talk about the low-tech tools he employs to get the job done, some tech tools that are in play, and the most important part of any security testing: Talking to people, creating awareness, and great reporting. The latest attacks against WiFi, its illegal to break encryption, BLE Padlocks are as secure as you think, when command not found attacks, how did your vibrator get infected...with malware, the OT jackpot, the backdoor in a random CSRF library, it's a vulnerability but there is no CVE, car theft and Canada, Glubteba, and settings things on fire! Visit https://www.securityweekly.com/psw for all the latest episodes! Show Notes: https://securityweekly.com/psw-818

The latest attacks against WiFi, its illegal to break encryption, BLE Padlocks are as secure as you think, when command not found attacks, how did your vibrator get infected...with malware, the OT jackpot, the backdoor in a random CSRF library, it's a vulnerability but there is no CVE, car theft and Canada, Glubteba, and settings things on fire! Show Notes: https://securityweekly.com/psw-818

The latest attacks against WiFi, its illegal to break encryption, BLE Padlocks are as secure as you think, when command not found attacks, how did your vibrator get infected...with malware, the OT jackpot, the backdoor in a random CSRF library, it's a vulnerability but there is no CVE, car theft and Canada, Glubteba, and settings things on fire! Show Notes: https://securityweekly.com/psw-818

Cross Site Request Forgery (CSRF) is a web vulnerability that poses a serious threat to user data and application integrity. In this video, we delve into the concept of CSRF, explaining what it is and providing a clear example to enhance understanding. #CSRF #CrossSiteRequestForgery #WebVulnerability #WebSecurity #DataProtection #WebApplicationSecurity #CyberSecurity #ProtectUserData

Sponsor by SEC Playground --- Support this podcast: https://podcasters.spotify.com/pod/show/chillchillsecurity/support

Guests: Pedro Adão, Associate Professor, Instituto Superior Técnico, Universidade de Lisboa [@istecnicoOn Linkedin | https://www.linkedin.com/in/pedro-ad%C3%A3o-b5b792/?Marco Squarcina, Senior Scientist, TU Wien [@tu_wien]On Linkedin | https://www.linkedin.com/in/squarcina/?originalSubdomain=atWebsite | https://minimalblue.com/____________________________Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/sean-martinMarco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society Podcast and Audio Signals PodcastOn ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli____________________________This Episode's SponsorsIsland.io | https://itspm.ag/island-io-6b5ffd____________________________Episode NotesIn this Chats on the Road to Black Hat USA, hosts Sean and Marco are joined by guests Pedro and Marco to explore the vulnerabilities and challenges of web security. The conversation begins with an explanation of the Double Submit and Synchronized Token patterns used to protect against CSRF (cross site request forgery) attacks. They discuss the limitations of these patterns, particularly when it comes to the integrity of cookies.The guests highlight the potential for attackers to modify cookies and the need for better solutions. The conversation then unpacks the complexities of web security, including the difficulties of maintaining backward compatibility and the challenges of multiple components and parties involved in web development, delivery, and operations. They address the importance of revising the security of subdomains and implementing security mechanisms like HSTS (HTTP strict transport security) with the inclusive domain directive.The conversation also raises philosophical questions about the responsibility of companies and the development community in addressing web security, as well as the role of legislation in this space. The group emphasizes the need for better platforms and frameworks that prioritize security from the start.The conversation concludes with a discussion on the importance of ongoing research, reporting vulnerabilities to developers, and finding solutions to improve the overall security of web applications. Listeners can expect to gain a deeper understanding of web security challenges and the ongoing efforts to address vulnerabilities and improve the security of the internet ahead of Pedro's and Marco's research presentation at Black Hat USA 2023.Stay tuned for all of our Black Hat USA 2023 coverage: https://www.itspmagazine.com/bhusa____ResourcesCookie Crumbles: Unveiling Web Session Integrity Vulnerabilities: https://blackhat.com/us-23/briefings/schedule/#cookie-crumbles-unveiling-web-session-integrity-vulnerabilities-32551For more Black Hat USA 2023 Event information, coverage, and podcast and video episodes, visit: https://www.itspmagazine.com/black-hat-usa-2023-cybersecurity-event-coverage-in-las-vegasAre you interested in telling your story in connection with our Black Hat coverage? Book a briefing here:

Guests: Pedro Adão, Associate Professor, Instituto Superior Técnico, Universidade de Lisboa [@istecnicoOn Linkedin | https://www.linkedin.com/in/pedro-ad%C3%A3o-b5b792/?Marco Squarcina, Senior Scientist, TU Wien [@tu_wien]On Linkedin | https://www.linkedin.com/in/squarcina/?originalSubdomain=atWebsite | https://minimalblue.com/____________________________Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/sean-martinMarco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society Podcast and Audio Signals PodcastOn ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli____________________________This Episode's SponsorsIsland.io | https://itspm.ag/island-io-6b5ffd____________________________Episode NotesIn this Chats on the Road to Black Hat USA, hosts Sean and Marco are joined by guests Pedro and Marco to explore the vulnerabilities and challenges of web security. The conversation begins with an explanation of the Double Submit and Synchronized Token patterns used to protect against CSRF (cross site request forgery) attacks. They discuss the limitations of these patterns, particularly when it comes to the integrity of cookies.The guests highlight the potential for attackers to modify cookies and the need for better solutions. The conversation then unpacks the complexities of web security, including the difficulties of maintaining backward compatibility and the challenges of multiple components and parties involved in web development, delivery, and operations. They address the importance of revising the security of subdomains and implementing security mechanisms like HSTS (HTTP strict transport security) with the inclusive domain directive.The conversation also raises philosophical questions about the responsibility of companies and the development community in addressing web security, as well as the role of legislation in this space. The group emphasizes the need for better platforms and frameworks that prioritize security from the start.The conversation concludes with a discussion on the importance of ongoing research, reporting vulnerabilities to developers, and finding solutions to improve the overall security of web applications. Listeners can expect to gain a deeper understanding of web security challenges and the ongoing efforts to address vulnerabilities and improve the security of the internet ahead of Pedro's and Marco's research presentation at Black Hat USA 2023.Stay tuned for all of our Black Hat USA 2023 coverage: https://www.itspmagazine.com/bhusa____ResourcesCookie Crumbles: Unveiling Web Session Integrity Vulnerabilities: https://blackhat.com/us-23/briefings/schedule/#cookie-crumbles-unveiling-web-session-integrity-vulnerabilities-32551For more Black Hat USA 2023 Event information, coverage, and podcast and video episodes, visit: https://www.itspmagazine.com/black-hat-usa-2023-cybersecurity-event-coverage-in-las-vegasAre you interested in telling your story in connection with our Black Hat coverage? Book a briefing here:

Episode 28: In this episode of Critical Thinking - Bug Bounty Podcast, the CSRF's up, dude! We kick off with a debate about whether or not deep link vulns in mobile apps can be considered CSRF. We also talk browser extensions and tools like Hackbar, PwnFox, and JS Weasel, and Justin tries to invent a whole new vuln term. There's plenty of good stuff here, so what are you waiting for? Jump on in!Follow us on twitter at: @ctbbpodcastWe're new to this podcasting thing, so feel free to send us any feedback here: info@criticalthinkingpodcast.ioShoutout to YTCracker for the awesome intro music!------ Links ------Follow your hosts Rhynorater & Teknogeek on twitter:https://twitter.com/0xteknogeekhttps://twitter.com/rhynoraterrez0's latest tiphttps://twitter.com/rez0__/status/168134822190014466019Hackbarhttps://addons.mozilla.org/en-US/firefox/addon/hackbartool/PwnFoxhttps://twitter.com/adrien_jeanneau/status/1681364665354289152JS Weaselhttps://www.jswzl.io/Charlie Eriksenhttps://twitter.com/CharlieEriksenLink to talk by Rojanhttps://twitter.com/uraniumhacker/status/1681381857383030785Bypassing GitHub's OAuth flowhttps://blog.teddykatz.com/2019/11/05/github-oauth-bypass.htmlGreat SameSite Confusionhttps://jub0bs.com/posts/2021-01-29-great-samesite-confusion/Check out Nahamsec's Channelhttps://www.youtube.com/c/nahamsecTimestamps:(0:01:45) The deep link debate(00:08:00) LHE and in-person interviews(00:09:25) SQLMAP and raw requests(00:11:11) Hackbar, PwnFox, and browser extensions(00:16:45) JS Weasel tool and its features(00:25:28) Rojan's Research and Public Talks(Start of main content)(00:28:36) Cross-Site Request Forgery (CSRF)(00:35:00) Bypassing GitHub's OAuth flow(00:45:00) A Small SameSite Story(00:48:50) CSRF Exploitation Techniques(01:07:15) CSRF Bug Stories(01:15:30) NahamSec and DEFCON

We open up this weeks bug bounty podcast with a discussion about Google's recent support for passkeys, tackling some misunderstanding about what they are and how open the platform is. Also some talk towards the end about potential vulnerabilities to look out for. Then we dive into the vulnerabilities for the week, involving bypassing phone validation in OpenAI, a bad origin check enabling abuse of a permissive CORS policy, and an order of operations issue breaking the purpose of sanitization in Oracle's Opera. Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/209.html [00:00:00] Introduction [00:02:43] So long passwords, thanks for all the phish [00:23:49] OpenAI Allowed “Unlimited” Credit on New Accounts [00:28:53] A smorgasbord of a bug chain: postMessage, JSONP, WAF bypass, DOM-based XSS, CORS, CSRF... [00:44:28] Exploiting an Order of Operations Bug to Achieve RCE in Oracle Opera [00:52:16] Testing Zero Touch Production Platforms and Safe Proxies The DAY[0] Podcast episodes are streamed live on Twitch twice a week: -- Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities -- Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. We are also available on the usual podcast platforms: -- Apple Podcasts: https://podcasts.apple.com/us/podcast/id1484046063 -- Spotify: https://open.spotify.com/show/4NKCxk8aPEuEFuHsEQ9Tdt -- Google Podcasts: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy9hMTIxYTI0L3BvZGNhc3QvcnNz -- Other audio platforms can be found at https://anchor.fm/dayzerosec You can also join our discord: https://discord.gg/daTxTK9

In today's episode of Elixir Wizards, Michael Lubas, founder of Paraxial.io, joins hosts Owen Bickford and Bilal Hankins to discuss security in the Elixir and Phoenix ecosystem. Lubas shares his insights on the most common security risks developers face, recent threats, and how Elixir developers can prepare for the future. Common security risks, including SQL injection and cross-site scripting, and how to mitigate these threats The importance of rate limiting and bot detection to prevent spam SMS messages Continuous security testing to maintain a secure application and avoid breaches Tools and resources available in the Elixir and Phoenix ecosystem to enhance security The Guardian library for authentication and authorization Take a drink every time someone says "bot" The difference between "bots" and AI language models The potential for evolving authentication, such as Passkeys over WebSocket How Elixir compares to other languages due to its immutability and the ability to trace user input Potion Shop, a vulnerable Phoenix application designed to test security Talking Tom, Sneaker Bots, and teenage hackers! The importance of security awareness and early planning in application development The impact of open-source software on application security How to address vulnerabilities in third-party libraries Conducting security audits and implementing security measures Links in this episode: Michael Lubas Email - michael@paraxial.io LinkedIn - https://www.linkedin.com/in/michaellubas/ Paraxial.io - https://paraxial.io/ Blog/Mailing List - https://paraxial.io/blog/index Potion Shop - https://paraxial.io/blog/potion-shop Elixir/Phoenix Security Live Coding: Preventing SQL Injection in Ecto Twitter - https://twitter.com/paraxialio LinkedIn - https://www.linkedin.com/company/paraxial-io/ GenServer Social - https://genserver.social/paraxial YouTube - https://www.youtube.com/@paraxial5874 Griffin Byatt on Sobelow: ElixirConf 2017 - Plugging the Security Holes in Your Phoenix Application (https://www.youtube.com/watch?v=w3lKmFsmlvQ) Erlang Ecosystem Foundation: Security Working Group - https://erlef.org/wg/security Article by Bram - Client-Side Enforcement of LiveView Security (https://blog.voltone.net/post/31) Special Guest: Michael Lubas.

Several simple bugs with significant impacts, XSS to being able to install apps, CSRFing via a Captcha, and a Google IDOR. Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/163.html [00:00:00] Introduction [00:00:29] Defcon Talks are Available [00:03:10] Galaxy Store Applications Installation/Launching without User Interaction [00:08:49] Facebook SMS Captcha Was Vulnerable to CSRF Attack [00:15:32] Google Data Studio Insecure Direct Object Reference [00:21:06] HTTP Request Smuggling Due to Incorrect Parsing of Multi-line Transfer-Encoding The DAY[0] Podcast episodes are streamed live on Twitch twice a week: -- Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities -- Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. We are also available on the usual podcast platforms: -- Apple Podcasts: https://podcasts.apple.com/us/podcast/id1484046063 -- Spotify: https://open.spotify.com/show/4NKCxk8aPEuEFuHsEQ9Tdt -- Google Podcasts: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy9hMTIxYTI0L3BvZGNhc3QvcnNz -- Other audio platforms can be found at https://anchor.fm/dayzerosec You can also join our discord: https://discord.gg/daTxTK9

Got a Minute? Website owner checkout today's episode of The Guy R Cook Report podcast - the Google Doc for this episode is @ 20221004 How to enable CSRF Protection on your web page ----more---- Support this podcast Subscribe where you listen to podcasts I help goal oriented business owners that run established companies to leverage the power of the internet Contact Guy R Cook @ https://guyrcook.com The Website Design Questionnaire https://guycook.wordpress.com/start-with-a-plan/ In the meantime, go ahead follow me on Twitter: @guyrcookreport Click to Tweet Be a patron of The Guy R Cook Report. Your help is appreciated.   https://guyrcook.com https://theguyrcookreport.com/#theguyrcookreport Follow The Guy R Cook Report on Podbean iPhone and Android App | Podbean   https://bit.ly/3m6TJDV Thanks for listening, viewing or reading the show notes for this episode. Vlog files for 2022 are at 2022 video episodes of The Guy R Cook ReportHave a great new year, and hopefully your efforts to Entertain, Educate, Convince or Inspire are in play vDomainHosting, Inc 3110 S Neel Place Kennewick, WA 509-200-1429

Chris talks about a small toy app he maintains on the side and working with a project called capybara_table. Steph is getting ready for maternity leave and wonders how you track velocity and know if you're working quickly enough? They answer a listener's question about where to get started testing a legacy app. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. jnicklas/capybara_table: (https://github.com/jnicklas/capybara_table) Capybara selectors and matchers for working with HTML tables Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Just gotta hold on. Fly this thing straight to the crash site. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. CHRIS: And I'm Steph Viccari. STEPH: And together, we're here to share a bit of what we've learned along the way. I love that you rolled with that. [laughs] CHRIS: No, actually, it was the only thing I could do. I [laughs] was frozen into action is a weird way to describe it, but there we are. STEPH: I mentioned to you a while back that I've always wanted to do that. Today was the day. It happened. CHRIS: Today was the day. It wasn't even that long ago that you told me. I feel like you could have waited another week or two. I feel like maybe I was too prepared. But yeah, for anyone listening, you may be surprised to find out that I am not, in fact, Steph Viccari. STEPH: And they'll be surprised to find out that I actually am Chris Toomey. This is just a solo monologue. And you've done a great job of two voices [laughs] this whole time and been tricking everybody. CHRIS: It has been a struggle. But I'm glad to now get the proper recognition for the fact that I have actually [laughs] been both sides of this thing the whole time. STEPH: It's been a very impressive talent in how you've run both sides of the conversation. Well, on that note, [laughs] switching gears just a bit, what's new in your world? CHRIS: What's new in my world? Answering now as Chris Toomey. Let's see; I got two small updates, one a very positive update, one a less positive update. As is the correct order, I'm going to lead with the less positive thing. So I have a small toy app that I maintain on the side. I used to have a bunch of these little purpose-built singular apps, typically Rails app sort of things where I would play with a new technology, but it was some sort of like, oh, it's a tracker. It's a counter. We talked about breakable toys in the past. These were those, for me, serve different purposes, productivity things, or whatever. But at some point, I was like, this is too much work, so I consolidated them all. And I kept like, there was a handful of features that I liked, smashed them all together into one Rails app that I maintain. And that's just like my Rails app. It turns out it's useful to be able to program the internet. So I was like, cool, I'll do that for myself. I have this little app that I maintain. It's got like a journal in it and other things. I think I've talked about the journal in the past. But I don't actually take that good care of it. I haven't added any features in a while. It mostly just does what it's supposed to, but it had...entropy had gotten the better of it. And so, I had a very small feature that I wanted to add. It was actually just a Rake task that should run in the background on a schedule. And if something is out of order, then it should send me an email. Basically, just an update of like, you need to do something. It seemed like such a simple task. And then, oh goodness, the failure modes that I fell into. First, I was on Heroku-18. Heroku is currently on their Heroku-22 stack. 18 being the year, so it was like 2018, and then there's a 2020 stack, and then the 2022. That's the current one. So I was two stacks behind, and they were yelling at me about that. So I was like, okay, but whatever. Can I ignore that for a little while? Turns out no, because I couldn't even get the app to boot locally, something about some gems or some I think Webpacker was broken locally. So I was trying to fix things, finally got that to work. But then I couldn't get it to build on CircleCI because Node needed Python, Python 2 specifically, not Python 3, in order to build Node dependencies, particularly LibSass, I want to say, or node-sass. So node-sass needed Python 2, which I believe is end of life-d, to build a CSS authoring tool. And I kind of took a step back at that moment, and I was like, what did we do, everybody? What is going on here? And thankfully, I feel like there was more sort of unification of tools and simplification of the build tool space and whatnot. But I patched it, and I fixed some things, then finally I got it working. But then Memcache wasn't working, and I had to de-provision that and reprovision something. The amount of little...like, each thing that I fixed broke something else. I was like, the only thing I can do at this point is just burn the entire app down and rebuild it. Thankfully, I found a working version of things. But I think at some point, I've got to roll up my sleeves some weekend and do the full Rails, Ruby, everything upgrade, just get back to fresh. But my goodness, it was rough. STEPH: I feel like this is one of those reasons where we've talked in the past about you want to do something, and you keep putting it off. And it's like, if I had just sat down and done it, I could have knocked it out. Like, oh, it only took me like 5-10 minutes. But then there's this where you get excited, and then you want to dive in. And then suddenly, you do spend an hour or however long, and you're just focused on trying to get to the point where you can break ground and start building. I think that's the resistance that we're often fighting when we think about, oh, I'm going to keep delaying this because I don't know how long it's going to take. CHRIS: There's something that I see in certain programming communities, which is sort of a beginner-friendliness or a beginner's mindset or a welcomingness to beginners. I see it, particularly in the Svelte world, where they have a strong focus on being able to pick something up and run with it immediately. The entire tutorial is built as there's the tutorial on the one side, like the text, and then on the right side is an interactive REPL. And you're just playing with the Svelte REPL and poking around. And it's so tangible and immediate. And they're working on a similar thing now for SvelteKit, which is the meta-framework that does server-side rendering and all the fancy stuff. But I love the idea that that is so core to how the Svelte community works. And I'll be honest that other times, I've looked at it, and I've been like, I don't care as much about the first run experience; I care much more about the long-term maintainability of something. But it turns out that I think those two are more coupled than I had initially...like, how easy is it for a beginner to get started is closely related to or is, you know, the flip side of how easy is it for me to maintain that over time, to find the documentation, to not have a weird builder that no one else has ever seen. There's that wonderful XKCD where it's like, what's the saddest thing on the internet? Seeing the question that you have asked by one other person on Stack Overflow and no answers four years ago. It's like, yeah, that's painful. You actually want to be part of the boring, mundane, everybody's getting the same errors, and we have solutions to them. So I really appreciate when frameworks and communities care a lot about both that first run experience but also the maintainability, the error messages, the how okay is it for this system to segfault? Because it turns out segfaults prints some funny characters to your terminal. And so, like the range from human-friendly error message all the way through to binary character dump, I'm interested in folks that care about that space. But yeah, so that's just a bit of griping. I got through it. I made things work. I appreciate, again, the efforts that people are putting in to make that sad situation that I experienced not as common. But to highlight something that's really great and wonderful that I've been working with, there is a project called capybaratable. capybaratable is the gem name. And it is just this delightful little set of matchers that you can use within a Capybara, particularly within feature spec. So if you have a table, you can now make an assertion that's like, expect the table to have table row. And then you can basically pass it a hash of the column name and the value, but you can pass it any of the columns that you want. And you can pass it...basically, it reads exactly like the user would read it. And then, if there's an error, if it actually doesn't find it, if it misses the assertion, it will actually print out a little ASCII table for you, which is so nice. It's like, here's the table row that I saw. It didn't have what you were looking for, friend, sorry about that. And it's just so expressive. It forces accessibility because it basically looks at the semantic structure of a table. And if your table is not properly semantically structured, if you're not using TDs and TRs, and all that kind of stuff, then it will not find it. And so it's another one of those cases where testing can be a really useful constraint from the usability and accessibility of your application. And so, just in every way, I found this project works so well. Error messages are great. It forces you into a better way of building applications. It is just a wonderful little tool that I found. STEPH: That's awesome. I've definitely seen other thoughtboters when working in codebases that then they'll add really nice helper methods around that for like checking does this data exist in the table? And so I'm used to seeing that type of approach or taking that type of approach myself. But the ASCII table printout is lovely. That's so...yeah, that's just a nice cherry on top. I will have to lock that one away and use that in the future. CHRIS: Yeah, really, just such a delightful thing. And again, in contrast to the troubles of my weekend, it was very nice to have this one tool that was just like, oh, here's an error, and it's so easy to follow, and yeah. So it's good that there are good things in the world. But speaking of good things, what's new in your world? I hope good things. And I hope you're not about to be like, everything's terrible. But what's up with you? [laughter] STEPH: Everything's on fire. No, I do have some good things. So the good thing is that I'm preparing for...I have maternity leave that's coming up. So I am going to take maternity leave in about four-ish weeks. I know the date, but I'm saying the ish because I don't know when people are listening. [laughs] So I'm taking maternity leave coming up soon. I'm very excited, a little panicked mostly about baby preparedness, because, oh my goodness, it is such an overwhelming world, and what everyone thinks you should or shouldn't have and things that you need to do. So I've been ramping up heavily in that area. And then also planning for when I'm gone and then what that's going to look like for the team, and for clients, and for making sure I've got work wrapped up nicely. So that's a big project. It's just something that's on my mind, something that I am working through and making plans for. On the weird side, I ran into something because I'm still in test migration world. That is one of like, this is my mountain. This is my Everest. I am determined to get all of these tests. Thank you to everyone who has listened to me, especially you, listen to me talk about this test migration path I've been on and the journey that it's been. This is the goal that I have in mind that I really want to get done. CHRIS: I know that when you said, "Especially you," you were talking to me, Chris Toomey. But I want to imagine that every listener out there is just like, aww, you're welcome, Steph. So I'm going to pretend for my own sake that that's what you meant by, especially you. It's especially every one of you out there in the audience. STEPH: Yes, I love either version. And good point, because you're right, I'm looking at you. So I can say especially you since you've been on this journey with me, but everybody listening has been on this journey with me. So I've got a number of files left that I'm working through. And one of the funky things that I ran into, well, it's really not funky; it was a little bit more of an educational rabbit hole for me because it's something that I hadn't considered. So migrating over a controller test over from Test::Unit to then RSpec, there are a number of controller tests that issue requests or they call the same controller method multiple times. And at first, I didn't think too much about it. I was like, okay, well, I'm just going to move this over to RSpec, and everything is going to be fine. But based on the way a lot of the information is getting set around logging in a user and then performing an action, and then trying to log in a different user, and then perform another action that was causing mayhem. Because then the second user was never getting logged in because the first user wasn't getting logged out. And it was causing enough problems that Joël and I both sat back, and we're like, this should really be a request back because that way, we're going through the full Rails routing. We're going through more of the sessions that get set, and then we can emulate that full request and response cycle. And that was something that I just hadn't, I guess, I hadn't done before. I've never written a controller spec where then I was making multiple calls. And so it took a little while for me to realize, like, oh, yeah, controller specs are really just unit test. And they're not going to emulate, give us the full lifecycle that a request spec does. And it's something that I've always known, but I've never actually felt that pain point to then push me over to like, hey, move this to a request spec. So that was kind of a nice reminder to go through to be like, this is why we have controller specs. You can unit test a specific action; it is just hitting that controller method. And then, if you want to do something that simulates more of a user flow, then go ahead and move over to the request spec land. CHRIS: I don't know what the current status is, but am I remembering correctly that the controller specs aren't really a thing anymore and that you're supposed to just use request specs? And then there's features specs. I feel like I'm conflating...there's like controller requests and feature, but feature maybe doesn't...no, system, that's what I'm thinking of. So request specs, I think, are supposed to be the way that you do controller-like things anymore. And the true controller spec unit level thing doesn't exist anymore. It can still be done but isn't recommended or common. Does that sound true to you, or am I making stuff up? STEPH: No, that sounds true to me. So I think controller specs are something that you can still do and still access. But they are very much at that unit layer focus of a test versus request specs are now more encouraged. Request specs have also been around for a while, but they used to be incredibly slow. I think it was more around Rails 5 that then they received a big increase in performance. And so that's when RSpec and Rails were like, hey, we've improved request specs. They test more of the framework. So if you're going to test these actions, we recommend going for request specs, but controller specs are still there. I think for smaller things that you may want to test, like perhaps you want to test that an endpoint returns a particular status that shows that you're not authorized or forbidden, something that's very specific, I think I would still reach for a controller spec in that case. CHRIS: I feel like I have that slight inclination to the unit spec level thing. But I've been caught enough by different things. Like, there was a case where CSRF wasn't working. Like, we made some switch in the application, and suddenly CSRF was broken, and I was like, well, that's bad. And the request spec would have caught it, but the controller spec wouldn't. And there's lots of the middleware stack and all of the before actions. There is so much hidden complexity in there that I think I'm increasingly of the opinion, although I was definitely resistant to it at first, but like, yeah, maybe just go the request spec route and just like, sure. And they'll be a little more costly, but I think it's worth that trade-off because it's the stuff that you're not thinking about that is probably the stuff that you're going to break. It's not the stuff that you're like, definitely, if true, then do that. Like, that's the easier stuff to get right. But it's the sneaky stuff that you want your tests to tell you when you did something wrong. And that's where they're going to sneak in. STEPH: I agree. And yeah, by going with the request specs, then you're really leaning into more of an integration test since you are testing more of that request/response lifecycle, and you're not as likely to get caught up on the sneaky stuff that you mentioned. So yeah, overall, it was just one of those nice reminders of I know I use request specs. I know there's a reason that I favor them. But it was one of those like; this is why we lean into request specs. And here's a really good use case of where something had been finagled to work as a controller test but really rightfully lived in more of an integration request spec. MIDROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half. So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! STEPH: Changing gears just a bit, I have something that I'd love to chat with you about. It came up while I was having a conversation with another thoughtboter as we were discussing how do you track velocity and know if you're working quickly enough? So since we often change projects about every six months, there's the question of how do I adapt to this team? Or maybe I'm still newish to thoughtbot or to a team; how do I know that I am producing the amount of work that the client or the team expects of me and then also still balancing that and making sure that I'm working at a sustainable pace? And I think that's such a wonderful, thoughtful question. And I have some initial thoughts around it as to how someone could track velocity. I also think there are two layers to this; there could be are we looking to track an individual's velocity, or are we looking to track team velocity? I think there are a couple of different ways to look at this question. But I'm curious, what are your thoughts around tracking velocity? CHRIS: Ooh, interesting. I have never found a formal method that worked in this space, no metric, no analysis, no tool, no technique that really could boil this down and tell a truth, a useful truth about, quote, unquote, "Velocity." I think the question of individual velocity is really interesting. There's the case of an individual who joins a team who's mostly working to try and support others on the team, so doing a lot of pairing, doing a lot of other things. And their individual velocity, the actual output of lines of code, let's say, is very low, but they are helping the overall team move faster. And so I think you'll see some of that. There was an episode a while back where we talked about heuristics of a team that's moving reasonably well. And I threw out the like; I don't know, like a pull request a day sort of thing feels like the only arbitrary number that I feel comfortable throwing out there in the world. And ideally, these pull requests are relatively small, individual deployable things. But any other version of it, like, are we thinking lines of code? That doesn't make sense. Is it tickets? Well, it depends on how you size your tickets. And I think it's really hard. And I think it does boil down to it's sort of a feeling. Do we feel like we're moving at a comfortable clip? Do I feel like I'm roughly keeping pace with the rest of the team, especially given seniority and who's been on the team longer? And all of those sorts of things. So I think it's incredibly difficult to ask about an individual. I have, I think, some more pointed thoughts around as a team how we would think about it and communicate about velocity. But I'm interested what came to mind for you when you thought about it, particularly for the individual side or for the team if you want to go in that direction. STEPH: Yeah, most of my initial thoughts were more around the individual because I think that's where this person was coming from because they were more interested in, like, how do I know that I'm producing as much as the team would expect of me? But I think there's also the really interesting element of tracking a team's velocity as well. For the individual, I think it depends a lot on that particular team and their goals and what pace they're moving at. So when I do join a new team, I will look around to see, okay, well, what's the cadence? What's the standard bar for when someone picks up a ticket and then is able to push it through? How much cruft are we working with in the codebase? Because then that will change the team's expectations of yes, we know that we have a lot of legacy code that we're working with, and so it does take us longer to get through things. And that is totally fine because we are looking more to optimize our sustainability and improving the code as we go versus just trying to get new features in. I think there's also an important cultural aspect. So some teams may, unfortunately, work a lot of extra hours. And that's something that I won't bend for. I'm still going to stick to my sustainable hours. But that's something that I keep in mind that just if some other people are working a lot of evenings or just working extra hours to keep that in mind that if they do have a higher velocity to not include that in my calculation as heavily. I also really liked how you highlighted that certain individuals often their velocity is unblocking others. So it's less about the specific code or features or tickets that they're producing, but it's how many people can they help? And then they're increasing the velocity of those individuals. And then the other metrics that unfortunately can be gamified, but it's still something to look at is like, how many hours are you spending on a particular feature, the tickets? But I like that phrasing that you used earlier of what's your progress? So if someone comes to daily sync and they mention that they're working on the same thing and we're on like day three, or four, but they haven't given an update around, like, oh, I have this new thing that I'm focused on, or this new area that I'm exploring, that's when I'll start to have alarm bells go off. And I'm like, okay, you've been working on the same thing. I can't quite tell if you've made progress. It sounds like you're still in the depths of the original thing that you were on a couple of days ago. So at that point, I'm going to want to check in to see how you're doing. But yeah, I think that's why this question fascinates me so much is because I don't think there's one answer that fits for everybody. There's not a way to tell one person to say, "Hey, this is your output that you should be producing, and this applies to all teams." It's really going to vary from team to team as to what that looks like. I remember there was one team that I joined that initially; I panicked because I noticed that their team was moving at a slower rate in terms of the number of tickets and PRs and stuff that were getting pushed up, reviewed, and then merged. That was moving at a slower pace than I was used to with previous clients. And I just thought, oh, what's going on? What's slowing us down? Like, why aren't we moving faster? And I actually realized it's just because they were working at a really sustainable pace. They showed up to the office. This was back in the day when I used to go to an office, and people showed up at like 9:00 a.m. and then 5:00 o'clock; it was a ghost town, and people were gone. So they were doing really solid, great work, but they were sticking to very sustainable hours. Versus, a previous team that I had been on had more of like a rushed feeling, and so there was more output for it. And that was a really nice reset for me to watch this team and see them do such great work in a sustainable fashion and be like, oh, yeah, not everything has to be a fire, not everything has to be rushed. I think the biggest thing that I'd look at is if velocity is being called into question, so if someone is concerned that someone's not producing enough or if the team is not producing enough, the first place I'm going to look is what's our priorities and see are we prioritizing correctly? Or are people getting pulled into a lot of work that's not supporting the priorities, and then that's why suddenly it feels like we're not producing at the level that we need to? I feel like that's the common disconnect between how much work we're getting done versus then what's actually causing people or product managers, or management stress. And so reevaluating to make sure that they're on the same page is where I would look first before then thinking, oh, someone's not working hard enough. CHRIS: Yeah, I definitely resonate with all of that. That was a mini masterclass that you just gave right there in all of those different facets. The one other thing that comes to mind for me is the question is often about velocity or speed or how fast can we go. But I increasingly am of the opinion that it's less about the actual speed. So it's less about like, if you think about it in terms of the average pace, the average number of features that we're going through, I'm more interested in the standard deviation. So some days you pick up a ticket, and it takes you a day; some days you pick up a ticket, and suddenly, seven days later, you're still working on it. And both at the individual level and at the team level, I'm really interested in decreasing that standard deviation and making it so that we are more consistently delivering whatever amount of output it is but very consistently doing that. And that really helps with our ability to estimate overall bodies of work with our ability for others to know and for us to be able to sort of uphold expectations. Versus if randomly someone might pick up a piece of code or might pick up a ticket that happens to hit a landmine in the code, it's like, yeah, we've been meaning to refactor that for a while. And it turns out that thing that you thought would be super easy is really hard because we've been kicking the can on this refactoring of the fundamental data model. Sorry about that. But today's your day; you lose. Those are the sort of things that I see can be really problematic. And then similarly, on an individual side, maybe there's some stuff that you can work on that is super easy for you. But then there's other stuff that you kind of hit a wall. And I think the dangerous mode to get into is just going internal and not really communicating about that, and struggling and trying to get there on your own rather than asking for help. And it can be very difficult to ask for help in those sorts of situations. But ideally, if you're focusing on I want to be delivering in that same pace, you probably might need some help in that situation. And I think having a team that really...what you're talking about of like, if I notice someone saying the same thing at daily sync for a couple of days in a row, I will typically reach out in a very friendly, collegial way, hey, do you want someone else to take a look at that with you? Because ideally, we want to unblock those situations. And then if we do have a team that is pretty consistently delivering whatever overall velocity but it's very consistent at that velocity, it's not like 3 one day and then 0, and then 12, and then 2; it's more of like, 6,5,6,5 sort of thing, to pick random numbers out of the air, then I feel so much more able to grow that, to increase that. If the question comes to me of like, hey, we're looking at the budget for the next quarter; do we think we want to hire another developer? I think I can answer that much more accurately at that point and say what do I think that additional individual would be able to do on the team. Versus if development is kind of this sporadic thing all over the place, then it's so much harder to understand what someone new joining that team would be able to do. So it's really the slow is smooth, smooth is fast adage that I've talked about in the past that really captured my mind a while back that just continues to feel true to me. And then yeah, I can work with that so much better than occasional days of wild productivity and then weeks of sadness in the swamp of refactoring. So it's a different way to think about the question, but it is where my mind initially went when I read this question. STEPH: I'm going to start using that description for when I'm refactoring. I'm in the refactoring swamp. That's where I'm spending my time. [laughs] Talking about this particular question is helping me realize that I do think less in terms of like what is my output in the strict terms of tickets, and PRs, and things like that. But I do think more about my progress and how can I constantly show progress, not just to the world but show it to myself. So if there are tickets that then maybe the ticket was scoped too big at first and I've definitely made some really solid progress, maybe I'm able to ship something or at least identified some other work that could be broken out, then I'm going to do that. Because then I want everybody to know, like, hey, this is the progress that was made here. And I may even be able to make myself feel good and move something over to the done column. So there's that aspect of the work that I focus on more heavily. And I feel like that also gives us more opportunities to then iterate on what's the goal? Like, we're not looking to just churn out work. That's not the point. But we really want to focus on meaningful work to get done. So if we're constantly giving an update on this as the progress that I've made in this direction, that gives people more opportunities to then respond to that progress and say, "Oh, actually, I think the work was supposed to do this," or "I have questions about some of the things that you've uncovered." So it's less about just getting something done. But it's still about making sure that we're working on the right thing. CHRIS: Yeah, it doesn't matter how fast we're going if we're going in the wrong direction, so another critical aspect. You can be that person on the team who actually doesn't ship much code at all. Just make sure that we don't ship the wrong code, and you will be a critical member of that team. But shifting gears just a little bit, we have another listener question here that I'd love to get into. This one is about testing a legacy app. So reading this question, it starts off with a very nice note to us, Steph. "I want to start by saying thanks for putting out great content week after week." We are very happy to do so." So a question for you two. I just took over a legacy Rails app. It's about 12 years old, and it's a bit of a mess. There was some testing in place, but it was completely broken and hadn't been touched in over seven years. So I decided to just delete it all. My question is, where do I even start with testing? There are so many callbacks on the models and so many controller hooks that I feel like I somehow need to have a factory for every model in our repo. I need to get testing in place ASAP because that is how I develop. But we are also still on Ruby 2 and Rails 4.0. So we desperately have to upgrade. Thanks in advance for any advice." So Steph, I actually replied in an email to this kind listener who sent this. And so, I definitely have some thoughts, but I'm interested in where would you start with this. STEPH: Legacy code, I wouldn't know anything about working in legacy code. [laughs] This is a fabulous question. And yeah, the response that you provided is incredible. So I'm very excited for you to share the message that you replied with. So I'm going to try not to steal any of those because they're wonderful. But to add to that list that is soon to come, often where I start with applications like these where I need some testing in place because, as this person mentioned, that's how they work. And then also, at that point, you're just scared to ship anything because you just don't know what's going to break. So one area that you could start with is what's your rollback strategy? So if you don't have any tests in place and you send something out into the world, then what's your plan to then be able to either roll back to a safe point or perhaps it's using feature flags for anything new that you're adding so that way you can quickly turn something on and off. But having a strategy there, I think, will help alleviate some of that stress of I need to immediately add tests. It's like, yes, that's wonderful, but that's going to take time. So until you can actually write those tests, then let's figure out a plan to mitigate some of that pain. So that's where I would initially start. And then, as for adding the test, typically, you start with testing as you go. So I would add tests for the code that I'm adding that I'm working on because that's where I'm going to have the most context. And I'm going to start very high. So I might have really slow tests that test everything that is going to be feature level, integration level specs because I'm at the point that I'm just trying to document the most crucial user flows. And then once I have some of those in place, then even if they are slow, at least I'm like, okay, I know that the most crucial user flows are protected and are still working with this change that I'm making. And in a recent episode, we were talking about how to get to know a Rails app. You highlighted a really good way to get to know those crucial user flows or the most common user flows by using something like New Relic and then seeing what are the paths that people are using. Maybe there's a product manager or just someone that you're taking the app over that could also give you some help in letting you know what's the most crucial features that users are relying on day to day and then prioritizing writing tests for those particular flows. So then, at this point, you've got a rollback strategy. And then you've also highlighted what are your most crucial user flows, and then you've added some really high level probably slow tests. Something that I've also done in the past and seen others do at thoughtbot when working on a legacy project or just working on a project, it wasn't even legacy, but it just didn't have any test coverage because the team that had built it before hadn't added test coverage. We would often duplicate a lot of the tests as well. So you would have some integration tests that, yes, frankly, were very similar to others, which felt like a bad choice. But there was just some slight variation where a user-provided some different input or clicked on some small different field or something else happened. But we found that it was better to have that duplication in the test coverage with those small variations versus spending too much time in finessing those tests. Because then we could always go back and start to improve those tests as we went. So it really depends. Are you in fire mode, and maybe you need to duplicate some stuff? Or are you in a state where you can be more considerate with your tests, and you don't need to just get something in place right away? Those are some of the initial thoughts I have. I'm very excited for the thoughts that you're about to share. So I'm going to turn it over to you. CHRIS: It's sneaky in this case. You have advanced notice of what I'm about to say. But yeah, this is a super interesting topic and one of those scary places to find yourself in. Very similar to you, the first thing that I recommended was feature specs, starting at that very high level, particularly as the listener wrote in and saying there are a lot of model callbacks and controller callbacks. And before filters and all of this, it's very indirect how this application works. And so, really, it's only when the whole thing is integrated together that you're going to have a reasonable sense of what's going on. And so trying to write those high-level feature specs, having a handful of them that give you some confidence when you're deploying that those core workflows are still working as expected. Beyond that, the other things that I talked about one was observability. As an aside, I didn't mention feature flags or anything like that. And I really loved that that was something you highlighted as a different way to get to confidence, so both feature flags and rollbacks. Testing at the end of the day, the goal is to have confidence that we're deploying software that works, and a different way to get that is feature flags and rollbacks. So I really love that you highlighted that. Something that goes really well hand in hand with those is observability. This has been a thing that I've been exploring more and more and just having some tooling that at runtime will tell you if your application is behaving as expected or is not. So these can be APM-type tools, but it can also be things like Sentry or Honeybadger error monitoring, those sorts of things. And in a system like this, I wouldn't be surprised if maybe there was an existing error monitoring tool, but it had just kind of decayed over time and now just has perhaps thousands of different entries in it that have been ignored and whatnot. On more than one occasion, I've declared Sentry bankruptcy working with clients and just saying like, listen; this thing can't tell us any truths anymore. So let's burn it down and restart it. So I would recommend that and having that as a tool such that much as tests are really wonderful before the code gets out there into the wild; it turns out it's only when users start using it that the real stuff happens. And so, having observability, having tooling in place that will tell you when something breaks is equally critical in my mind. One of the other things I said, and this is probably the spiciest take on my list, is questioning the trade-off space that you're in. Is this an application that actually has a relatively low defect rate that users use and are quite happy with, and expect that level of performance and correctness, and all of those sorts of things, and so you, frankly, need to be careful with it? Or, is it potentially something that has a handful of bugs and that users are used to a certain lower fidelity experience, let's call it? And can you take advantage of that if that happens to be true? Like, I would be very careful to break something that has never been broken before that there's no expectation of that. But if we can get away with moving fast and breaking things for a little while just to try and get ourselves out of the spot that we're in, I would at least want to consider that trade-off space. Because caution slows you down, it means that your progress is going to be limited. And so, if we're able to reduce the caution filter just a little bit and move a little bit more rapidly, then ideally, we can get out of this place that we're in a little more quickly. Again, I think that's a really subtle one and one that you'd have to get buy-in from product managers and probably be very explicit in the conversations and sort of that trade-off space. But it is something that I would want to explore if I found myself in this sort of situation. The last thing that I highlighted was the fact that the versions of Ruby and Rails that were listed in the question are, I think, both end of life at this point. And so from a security perspective, that is just a giant glaring warning sign in the corner because the day that your app gets hacked, well, that's a bad day. So testing, unfortunately, I think that's the main way that you're going to get by on that as you're going through upgrades. You can deploy a new version of the application and see what happens and see if your observability can get you there. But really, testing is what you want to do. So that's where building out that testing is all the more critical so that you can perform those security upgrades because they are now truly critical to get done. And so it gives sort of more than a nice to have, more than this makes me feel comfortable. It is pretty much a necessity if you want to go through that, and you absolutely need to go through the security upgrades because otherwise, you're going to get hacked. There are just automated scanners out there. They're going to find you. You don't need to be a high vulnerability target to get taken down on the internet these days. So if it hasn't happened yet, it's going to. And I think that's an easy business case to sell is, I guess, the way that I would frame it. So those were some of my thoughts. STEPH: You bring up a really good point about needing to focus on the security upgrades. And I'm thinking that through a little bit further in regards to what trade-offs would I make? Would I wait till I have tests in place to then start the upgrades, or would I start the upgrades now but just know I'm going to spend more time manual testing on staging? Or maybe I'm solo on the project. If I have a product manager or someone else that can also help the testing with me, I think I would go for that latter approach where I would start the upgrades today and then just do more manual testing of those crucial flows and then have that rollback strategy. And as you mentioned, it's a trade-off in terms of, like, how important is it that we don't break anything? CHRIS: I think similar to the thing that both of us hit on early on is like, have some feature specs that just kick the whole application as one connected piece of code. Have that in place for the security upgrade, testing. But I agree, I wouldn't want to hold off on that because I think that's probably the scariest part of all of this. But yeah, it is, again, trade-offs. As always, it depends. But I think those are my thoughts. Anything else you want to add, Steph? STEPH: I think those are fabulous thoughts. I think you covered it all. CHRIS: Sounds good. Well, in that case, should we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

I'm happy to welcome Leslie Edwin, president of Cushing's Support and Research Foundation (CSRF), to our microphones. The CSRF is a leading Cushing's disease and syndrome patient support organization. We talked about the opportunities and barriers for Cushing's patients and advocates. Geri Brown, a Cushing's patient and member of the CSRF, also joined us to talk about her perceptions as a new group member. Our discussion provided a great deal of patient information on the CSRF programs and plans.  

Steph has an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. Chris got to do something exciting this week using dry-monads. Success or failure? This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. Bartender (https://www.macbartender.com/) dry-rb - dry-monads v1.0 - Pattern matching (https://dry-rb.org/gems/dry-monads/1.0/pattern-matching/) alfred-workflows (https://github.com/tupleapp/alfred-workflows/blob/master/scripts/online_users.rb) Raycast (https://www.raycast.com/) ruby-science (https://github.com/thoughtbot/ruby-science) Inertia.js (https://inertiajs.com/) Remix (https://remix.run/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time. Flaky tests slow everyone down, break your flow, and make things downright miserable. In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start? BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed. STEPH: What type of bird is the strongest bird? CHRIS: I don't know. STEPH: A crane. [laughter] STEPH: You're welcome. And on that note, shall we wrap up? CHRIS: Let's wrap up. [laughter] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris, I saw a good movie I'd like to tell you about. It was just over the weekend. It's called The Duke, and it's based on a real story. I should ask, have you seen it? Have you heard of this movie called The Duke? CHRIS: I don't think so. STEPH: Okay, cool. It's a true story, and it's based on an individual named Kempton Bunton who then stole a particular portrait, a Goya portrait; if you know your artist, I do not. But he stole a Goya portrait and then essentially held at ransom because he was a big advocate that the BBC News channel should be free for people that are living on a pension or that are war veterans because then they're not able to afford that fee. But then, if you take the BBC channel away from them, it disconnects them from society. And it's a very good movie. I highly recommend it. So I really enjoyed watching that over the weekend. CHRIS: All right. Excellent recommendation. We will, of course, add that to the show notes mostly so that I can find it again later. STEPH: On a more technical note, I have a small update, or it's more of a question. It's an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. This has been quite a journey that Joël and I have been on for a while now. And we're making progress, but we're realizing that we're spending like 95% of our time in the test setup and porting that over, specifically because we're mapping fixture data over to FactoryBot, and we're just realizing that's really painful. It's taking up a lot of time to do that. And initially, when I realized we were just doing that, we hadn't even really talked about it, but we were moving it over to FactoryBot. I was like, oh, cool. We'll get to delete all these fixtures because there are around 208 files of them. And so that felt like a really good additional accomplishment to migrating the test over. But now that we realize how much time we're spending migrating the data over for that test setup, we've reevaluated, and I shared with Joël in the Slack channel. I was like, crap. I was like, I have a bad idea, and I can't not say it now because it's crossed my mind. And my bad idea was what if we stopped porting over fixtures to FactoryBot and then we just added the fixtures to a directory that RSpec would look so then we can rely on those fixtures? And then that way, we're literally then ideally just copying over from Test::Unit over to RSpec. But it does mean a couple of things. Well, one, it means that we're now running those fixtures at the beginning of RSpec test. We're introducing another pattern of where these tests are already using FactoryBot, but now they have fixtures at the top, and then we won't get to delete the fixtures. So we had a conversation around how to manage and mitigate some of those concerns. And we're still in that exploratory. We're going to test it out and see if this really speeds us up referencing the fixtures. The question that's wrapped up in this is there's something different between how fixtures generate data and how factories generate data. So I've run into this a couple of times now where I moved data over to just call a factory. But then I was hitting these callbacks or after-save-hooks or weird things that were then preventing me from creating the record, even though fixtures was creating them just fine. And then Joël pointed out today that he was running into something similar where there were private methods that were getting called. And there were all sorts of additional code that was getting run with factories versus fixtures. And I don't have an answer. Like, I haven't looked into this. And it's frankly intentional because I was trying hard to not dive into understanding the mechanics. We really want to get through this. But now I'm starting to ponder a little more as to what is different with fixtures and factories? And I liked that factories is running these callbacks; that feels correct. But I'm surprised that fixtures doesn't, or at least that's the experience that I'm having. So there's some funkiness there that I'd like to explore. I'll be honest; I don't know if I'm going to. But if anybody happens to know what that funkiness is or why fixtures and factories are different in that regard, I would be very intrigued because, at some point, I might look into it just because I would like to know. CHRIS: Oh, that is interesting. I have not really worked with fixtures much at all. I've lived a factory life myself, and thus that's where almost all of my experience is. I'm not super surprised if this ends up being the case, like, the idea that fixtures are just some data that gets shoveled into the database directly as opposed to FactoryBot going through the model layer. And so it's sort of like that difference. But I don't know that for certain. That sounds like what this is and makes sense conceptually. But I think this is what you were saying like, that also kind of pushes me more in the direction of factories because it's like, oh, they're now representative. They're using our model layer, where we're defining certain truths. And I don't love callbacks as a mechanism. But if your app has them, then getting data that is representative is useful in tests. Like one of the things I add whenever I'm working with FactoryBot is the FactoryBot lint rake task RSpec thing that basically just says, "Are your factories valid?" which I think is a great baseline to have. Because you may add a migration that adds a default constraint or something like that to the database that suddenly all your factories are invalid, and it's breaking tests, but you don't know it. Like subtly, you change it, and it doesn't actually break a test, but then it's harder later. So that idea of just having more correctness baked in is always nice, especially when it can be automated like that, so definitely a fan of that. But yeah, interested if you do figure out the distinction. I do like your take, though, of like, but also, maybe I just won't figure this out. Maybe this isn't worth figuring it out. Although you were in the interesting spot of, you could just port the fixtures over and then be done and call the larger body of work done. But it's done in sort of a half-complete way, so it's an interesting trade-off space. I'm also interested to hear where you end up on that. STEPH: Yeah, it's a tough trade-off. It's one that we don't feel great about. But then it's also recognizing what's the true value of what we're trying to deliver? And it also comes down to the idea of churn versus complexity. And I feel like we are porting over existing complexity and even adding a smidge, not actual complexity but adding a smidge of indirection in terms that when someone sees this file, they're going to see a mixed-use of fixtures and factories, and that doesn't feel good. And so we've already talked about adding a giant comment above fixtures that just is very honest and says, "Hey, these were ported over. Please don't mimic this. But this is some legacy tests that we have brought over. And we haven't migrated the fixtures over to use factories." And then, in regards to the churn versus complexity, this code isn't likely to get touched like these tests. We really just need them to keep running and keep validating scenarios. But it's not likely that someone's going to come in here and really need to manage these anytime soon. At least, this is what I'm telling myself to make me feel better about it. So there's also that idea of yes, we are porting this over. This is also how they already exist. So if someone did need to manage these tests, then going to Test::Unit, they would have the same experience that they're going to have in RSpec. So that's really the crux of it is that we're not improving that experience. We're just moving it over and then trying to communicate that; yes, we have muddied the waters a little bit by introducing this other pattern. So we're going to find a way to communicate why we've introduced this other pattern, but that way, we can stay focused on actually porting things over to RSpec. As for the factories versus fixtures, I feel like you're onto something in terms of it's just skipping that model layer. And that's why a lot of that functionality isn't getting run. And I do appreciate the accuracy of factories. I'd much rather know is my data representative of real data that can get created in the world? And right now, it feels like some of the fixtures aren't. Like, how they're getting created seemed to bypass really important checks and validations, and that is wrong. That's not what we want to have in our test is, where we're creating data that then the rest of the application can't truly create. But that's another problem for another day. So that's an update on a trade-off that we have made in regards to the testing journey that we are on. What's going on in your world? CHRIS: Well, we got to do something exciting this week. I was working on some code. This is using dry-monads, the dry-rb space. So we have these result objects that we use pretty pervasively throughout the app, and often, we're in a controller. We run one of these command objects. So it's create user, and create user actually encompasses a ton of logic in our app, and that object returns a result. So it's either a success or a failure. And if it's a success, it'll be a success with that new user wrapped up inside of it, or if it's a failure, it's a specific error message. Actually, different structured error messages in different ways, some that would be pushed to the form, some that would be a flash message. There are actually fun, different things that we do there. But in the controller, when we interact with those result objects, typically what we'll do is we'll say result equals create user dot run, (result=createuser.run) and then pass it whatever data it needs. And then on the next line, we'll say results dot either, (results.either), which is a method on these result objects. It's on both the success and failure so you can treat them the same. And then you pass what ends up being a lambda or a stabby proc, or I forget what they are. But one of those sort of inline function type things in Ruby that always feel kind of weird. But you pass one of those, and you actually pass two of them, one for the success case and one for the failure case. And so in the success case, we redirect back with a notice of congratulations, your user was created. Or, in the failure case, we potentially do a flash message of an alert, or we send the errors down, or whatever it ends up being. But it allows us to handle both of those cases. But it's always been syntactically terrible, is how I would describe it. It's, yeah, I'm just going to leave it at that. We are now living in a wonderful, new world. This has been something that I've wanted to try for a while. But I finally realized we're actually on Ruby 2.7, and so thus, we have access to pattern matching in Ruby. So I get to take it for a spin for the first time, realizing that we were already on the correct version. And in particular, dry-monads has a page in their docs specific to how we can take advantage of pattern matching with the result objects that they provide us. There's nothing specific in the library as far as I understand it. This is just them showing a bunch of examples of how one might want to do it if they're working with these result objects. But it's really great because it gives the ability to interact with, you know, success is typically going to be a singular case. There's one success branch to this whole logic, but there are like seven different ways it can fail. And that's the whole idea as to why we use these command objects and the whole Railway Oriented Programming and that whole thing which I have...what is this word? [laughs] I feel like I should know it. It's a positive rant. I have raved; that is how our users kindly pointed that out to us. I have raved about the Railway Oriented Programming that allows us to do. But it's that idea that they're actually, you know, there's one happy path, and there are seven distinct failure modes, seven unhappy paths. And now, using pattern matching, we actually get a really expressive, readable, useful way to destructure each of those distinct failures to work with the particular bits of data that we need. So it was a very happy day, and I got to explore it. This is, again, a feature of Ruby, not a feature of dry-monads. But dry-monads just happens to embrace it and work really well with it. So that was awesome. STEPH: That is awesome. I've seen one or two; I don't know, I've seen a couple of tweets where people are like, yeah, Ruby pattern matching. I haven't found a way to use it. So I'm excited that you just shared a way that you found to use it. I'm also worried what it says about our developer culture that we know the word rant so well, but rave, we always have to reach back into our memory to be like, what's that positive word or something that we like? [laughs] CHRIS: And especially here on The Bike Shed, where we try to gravitate towards the positive. But yeah, it's an interesting point that you make. STEPH: We're a bunch of ranters. It's what we do, pranting ranters. I don't know why we're pranting. [laughs] CHRIS: Because it's that exciting. That's what it is. Actually, there was an interesting thing as we were playing around with the pattern matching code, just poking around in the console session with it, and it prints out a deprecation warning. It's like, warning: this is an experimental feature. Do not use it, be careful. But in the back of my head, I was like, I actually know how this whole thing plays out, Ruby 2.7, and I assure you, it's going to be fine. I have been to the future, at least I'm pretty sure. I think the version that is in Ruby 2.7 did end up getting adopted basically as it stands. And so, I think there is also a setting to turn off that deprecation warning. I haven't done it yet, but I mostly just enjoyed the conversation that I had with this deprecation message of like, listen, I've been to the future, and it's great. Well, it's complicated, but specific to this pattern matching [laughs] in Ruby 3+ versions, it went awesome. And I'm really excited about that future that we now live in. STEPH: I wish we had that for so many more things in our life [laughs] of like, here's a warning, and it's like, no, no, I've seen the future. It's all right. Or you're totally right; I should avoid and back out of this now. CHRIS: If only we could know how the things would play out, you know. But yeah, so pattern matching, very cool. I'll include a link in the show notes to the particular page in the dry-monads docs. But there are also other cool things on the internet. In an unrelated but also cool thing that I found this week, we use Tuple a lot within our organization for pair programming. For anyone who's not familiar with it, it's a really wonderful piece of technology that allows you to pair program pretty seamlessly, better video quality, all of those nice things that we want. But I found there was just the tiniest bit of friction in starting a Tuple call. I know I want to pair with this person. And I have to go up and click on the little menu bar, and then I have to find their name, then I have to click a button. That's just too much. That's not how...I want to live my life at the keyboard. I have a thing called Bartender, which is a little menu bar manager utility app that will collapse down and hide the icons. But it's also got a nice, little hotkey accessible pop-up window that allows me to filter down and open one of the menu bar pop-out menus. But unfortunately, when that happens, the Tuple window isn't interactive at that point. I can't use the arrow keys to go up and down. And so I was like, oh, man, I wonder if there's like an Alfred workflow for this. And it turns out indeed there is actually managed by the kind folks at Tuple themselves. So I was able to find that, install it; it's great. I have it now. I can use that. So that was a nice little upgrade to my workflow. I can just type like TC space and then start typing out the person's name, and then hit enter, and it will start a call immediately. And it doesn't actually make me more productive, but it makes me happier. And some days, that's what matters. STEPH: That's always so impressive to me when that happens where you're like, oh, I need a thing. And then you went through the saga that you just went through. And then the people who manage the application have already gotten there ahead of you, and they're like, don't worry, we've created this for you. That's one of those just beautiful moments of like, wow, y'all have really thought this through on a bunch of different levels and got there before me. CHRIS: It's somewhat unsurprising in this case because it's a very developer-centric organization, and Ben's background being a thoughtbot developer and Alfred user, I'm almost certain. Although I've seen folks talking about Raycast, which is the new hotness on the quick launcher world. I started eons ago in Quicksilver, and then I moved to Alfred, I don't know, ten years ago. I don't know what time it is anymore. But I've been in Alfred land for a while, but Raycast seems very cool. Just as an aside, I have not allowed myself... [laughs] this is another one of those like; I do not have permission to go explore this new tool yet because I don't think it will actually make me more productive, although it could make me happier. So... STEPH: I haven't heard of that one, Raycast. I'm literally adding it to the show notes right now as a way so you can find The Duke later, and I can find Raycast later [chuckles] and take a look at it and check it out. Although I really haven't embraced the whole Alfred workflow. I've seen people really enjoy it and just rave about it and how wonderful it is. But I haven't really leaned into that part of the world; I don't know why. I haven't set any hard and fast rules for myself where I can't play around with these technologies, but I haven't taken the time to do it either. CHRIS: You've also not found yourself writing thousands of lines of Vimscript because you thought that was a good idea. So you don't need as many guardrails it would seem. That's my guess. STEPH: This is true. CHRIS: Whereas I need to be intentional [laughs] with how I structure my interaction with my dev tools. STEPH: Instead, I'm just porting over fixtures from one place to another. [laughs] That's the weird space that I'm living in instead. [laughs] CHRIS: But you're getting paid for that. No one paid me for the Vimscript I wrote. [laughter] STEPH: That's fair. Speaking around process-y things, there's something that's been on my mind that Valeria, another thoughtboter, suggested around how we structure our meetings and the default timing that we have for meetings. So Thursdays are my team-focused day. And it's the day where I have a lot of one on ones. And I realized that I've scheduled them back to back, which is problematic because then I have zero break in between them, which I'm less concerned about that because then I can go for an hour or something and not have a break. And I'm not worried about that part. But it does mean that if one of those discussions happens to go over just even for like two or three minutes, then it means that someone else is waiting for me in those two to three minutes. And that feels unacceptable to me. So Valeria brought up a really good idea where I think it's only with the Google Meet paid version. I could be wrong there. But I think with the paid version of it that then you can set the new default for how long a meeting is going to last. So instead of having it default to 30 minutes, have it default to 25 minutes. So then, that way, you do have that five-minute buffer. So if you do go over just like two or three minutes with someone, you've still got like two minutes to then hop to the next call, and nobody's waiting for you. Or if you want those five minutes to then grab some water or something like that. So we haven't implemented it just yet because then there's discussion around is this a new practice that we want everybody to move to? Because I mean, if just one person does it, it doesn't work. You really need everybody to buy into the concept of we're now defaulting to 25 versus 30-minute meetings. So I'll have to let you know how that goes. But I'm intrigued to try it out because I think that would be very helpful for me. Although there's a part of me that then feels bad because it's like, well, if I have 30 minutes to chat with somebody, but now I'm reducing it to 25 minutes each time, I didn't love that I'm taking time away from our discussion. But that still feels like a better outcome than making somebody wait for three to five minutes if something else goes over. So have you ever run into something like that? How do you manage back-to-back meetings? Do you intentionally schedule a break in between or? CHRIS: I do try to give myself some buffer time. I stack meetings but not so much so that they're just back to back. So I'll stack them like Wednesdays are a meeting-heavy day for me. That's intentional just to be like, all right, I know that my day is going to get chopped up. So let's just really lean into that, chop the heck out of Wednesday afternoons, and then the rest of the week can hopefully have slightly longer deep work-type sessions. And, yeah, in general, I try and have like a little gap in between them. But often what I'll do for that is I'll stagger the start of the next meeting to be rather than on the hour or the half-hour, I start it on the 15th minute. And so then it's sort of I now have these little 15-minute gaps in my workflow, which is enough time to do one or two small things or to go get a drink or whatever it is or if things do run over. Like, again, I feel what you're saying of like, I don't necessarily want to constrain a meeting. Or I also don't necessarily want to go into the habit of often over-running. I think it's good to be intentional. Start meetings on time, end meetings on time. If there's a great conversation that's happening, maybe there's another follow-up meeting that should happen or something like that. But for as nonsensical of a human as I believe myself to be, I am rather rigid about meetings. I try very hard to be on time. I try very hard to wrap them up on time to make sure I go to the next one. And so with that, the 15-minute staggering is what I've found works for me. STEPH: Yeah, that makes sense. One-on-ones feels special to me because I wholeheartedly agree with being very diligent about like, hey, this is our meeting time. Let's do a time check. Someone says that at the end, and then that way, everybody can move on. But one on ones are, there's more open discussion space, and I hate cutting people off, especially because it might not be until the last 15 minutes that you really got into the meat of the conversation. Or you really got somewhere that's a little bit more personal or things that you want to talk about. So if someone's like, "Yeah, let me tell you about my life goals," and you're like, "Oh, no, wait, sorry. We're out of time." That feels terrible and tragic to do. So I struggle with that part of it. CHRIS: I will say actually, on that note, I'm now thinking through, but I believe this to be true. Everyone that reports to me I have a 45-minute one-on-one with, and then my CEO I set up the one-on-one. So I also made that one a 45-minute one-on-one. And that has worked out really well. Typically, I try and structure it and reiterate this from time to time of, like, hey, this is your space, not mine. So let's have whatever conversation fits in here. And it's fine if we don't need to use the whole time, but I want to make sure that we have it and that we protect it. Because I often find much like retro, I don't know; I think everything's fine. And then suddenly the conversation starts, and you're like, you know what? Actually, I'm really concerned now that you mentioned it. And you need that sort of empty space that then the reality sort of pop up into. And so with one on one, I try and make sure that there is that space, but I'm fine with being like, we can cut this short. We can move on from one-on-one topics to more of status updates; let's talk about the work. But I want to make sure that we lead with is there anything deeper, any concerns, anything you want to talk through? And sort of having the space and time for that. STEPH: I like that. And I also think it speaks more directly to the problem I'm having because I'm saying that we keep running over a couple of minutes, and so someone else is waiting. So rather than shorten it, which is where I'm already feeling some pain...although I still think that's a good idea to have a default of 25-minute meetings so then that way, there is a break versus the full 30. So if people want to have back-to-back meetings, they still have a little bit of time in between. But for one on ones specifically, upping it to 45 minutes feels nice because then you've got that 15-minute buffer likely. I mean, maybe you schedule a meeting, but, I don't know, that's funky. But likely, you've got a 15-minute buffer until your next one. And then that's also an area that I feel comfortable in sharing with folks and saying, "Hey, I've booked this whole 45 minutes. But if we don't need the whole time, that's fine." I'm comfortable saying, "Hey, we can end early, and you can get more of your time back to focus on some other areas." It's more the cutting someone off when they're talking because I have to hop to the next thing. I absolutely hate that feeling. So thanks, I think I'll give that a go. I think I'll try actually bumping it up to 45 minutes, presuming that other people like that strategy too, since they're opting in [laughs] to the 45 minutes structure. But that sounds like a nice solution. CHRIS: Well yeah, happy to share it. Actually, one interesting thing that I'm realizing, having been a manager at thoughtbot and then now being a manager within Sagewell, the nature of the interactions are very different. With thoughtbot, I was often on other projects. I was not working with my team day to day in any real capacity. So it was once every two weeks, I would have this moment to reconnect with them. And there was some amount of just catching up. Ideally, not like status update, low-level sort of thing, but sort of just like hey, what have you been working on? What have you been struggling with? What have you been enjoying? There was more like I needed bigger space, I would say for that, or it's not surprising to me that you're bumping into 30 minutes not being quite long enough. Whereas regularly, in the one on ones that I have now, we end up cutting them short or shifting out of true one-on-one mode into more general conversation and chatting about Raycast or other tools or whatever it is because we are working together daily. And we're pairing very regularly, and we're all on the same project and all sorts of in sync and know what's going on. And we're having retro together. We have plenty of places to have the conversation. So the one-on-one again, still, I keep the same cadence and the same time structure just because I want to make sure we have the space for any day that we really need that. But in general, we don't. Whereas when I was at thoughtbot, it was all the more necessary. And I think for folks listening; I could imagine if you're in a team lead position and if you're working very closely with folks, then you may be on the one side of things versus if you're a little bit more at a distance from the work that they're doing day to day. That's probably an interesting question to ask, and think about how you want to structure it. STEPH: Yeah, I think that's an excellent point. Because you're right; I don't see these individuals. We may not have really gotten to interact, except for our daily syncs outside of that. So then yeah, there's always like a good first 10 minutes of where we're just chatting about life and catching up on how things are going before then we dive into some other things. So I think that's a really good point. Cool, solving management problems on the mic. I dig it. In slightly different news, I've joined a book club, which I'm excited about. This book club is about Ruby. It's specifically reading the book Ruby Science, which is a book that was written and published by thoughtbot. And it requires zero homework, which is my favorite type of book club. Because I have found I always want to be part of book clubs. I'm always interested in them, but then I'm not great at budgeting the time to make sure I read everything I'm supposed to read. And so then it comes time for folks to get together. And I'm like, well, I didn't do my homework, so I can't join it. But for this one, it's being led by Joël, and the goal is that you don't have to do the homework. And they're just really short sections. So whoever's in charge of leading that particular session of the book club they're going to provide an overview of what's covered in whatever the reading material that we're supposed to read, whatever topic we're covering that day. They're going to provide an overview of it, an example of it, so then we can all talk about it together. So if you read it, that's wonderful. You're a bit ahead and could even join the meeting like five minutes late. Or, if you haven't read it, then you could join and then get that update. So I'm very excited about it. And this was one of those books that I'd forgotten that thoughtbot had written, and it's one that I've never read. And it's public for anybody that's interested in it. So to cover a little bit of details about it, so it talks about code smells, ways to refactor code, and then also common patterns that you can use to solve some issues. So there's a lot of really just great content that's in it. And I'll be sure to include a link in the show notes for anyone else that's interested. CHRIS: And again, to reiterate, this book is free at this point. Previously, in the past, it was available for purchase. But at one point a number of years ago, thoughtbot set all of the books free. And so now that along with a handful of other books like...what's Edward's DNS book? Domain Name Sanity, I believe, is Edward's book name that Edward Loveall wrote when he was not a thoughtboter, [laughs] and then later joined as a thoughtboter, and then we made the book free. But on the specific topic of Ruby Science, that is a book that I will never forget. And the reason I will never forget it is that book was written by the one and only CTO Joe Ferris, who is an incredibly talented developer. And when I was interviewing with thoughtbot, I got down to the final day, which is a pairing session. You do a morning pairing session with one thoughtbot developer, and you do an afternoon pairing session with another thoughtbot developer. So in the morning, I was working with someone on actually a patch to Rails which was pretty cool. I'd never really done that, so that was exciting. And that went fine with the exception that I kept turning on Caps Lock on their keyboard because I was used to Caps Lock being CTRL, and then Vim was going real weird for me. But otherwise, that went really well. But then, in the afternoon, I was paired with the one and only CTO Joe Ferris, who was writing the book Ruby Science at that time. And the nature of the book is like, here's a code sample, and then here's that code sample improved, just a lot of sort of side-by-side comparisons of code. And I forget the exact way that this went, but I just remember being terrified because Joe would put some code up on the screen and be like, "What do you think?" And I was like, oh, is this the good code or the bad code? I feel like I should know. I do not know. I'm not sure. It worked out fine, I guess. I made it through. But I just remember being so terrified at that point. I was just like, oh no, this is how it ends for me. It's been a good run. STEPH: [laughs] CHRIS: I made it this far. I would have loved to work for this nice thoughtbot company, but here we are. But yeah, I made it through. [laughs] STEPH: There are so many layers to that too where it's like, well if I say it's terrible, are you going to be offended? Like, how's this going to go for me if I speak my truths? Or what am I going to miss? Yeah, that seems very interesting (I kind of like it.) but also a terrifying pairing session. CHRIS: I think it went well because I think the code...I'd been following thoughtbot's work, and I knew who Joe was and had heard him on podcasts and things. And I kind of knew roughly where things were, and I was like, that code looks messy. And so I think I mostly got it right, but just the openness of the question of like, what do you think? I was like, oh God. [laughs] So yeah, that book will always be in my memories, is how I would describe it. STEPH: Well, I'm glad it worked out so we could be here today recording a podcast together. [laughs] CHRIS: Recording a podcast together. Now that I say all that, though, it's been a long time since I've read the book. So maybe I'll take a revisit. And definitely interested to hear more about your book club and how that goes. But shifting ever so slightly (I don't have a lot to say on this topic.) but there's a new framework technology thing out there that has caught my attention. And this hasn't happened for a while, so it's kind of novel for me. So I tend to try and keep my eye on where is the sort of trend of web development going? And I found Inertia a while ago, and I've been very, very happy with that as sort of this is the default answer as to how I build websites. To be clear, Inertia is still the answer as to how I build websites. I love Inertia. I love what it represents. But I'm seeing some stuff that's really interesting that is different. Specifically, Remix.run is the thing that I'm seeing. I mentioned it, I think, in the last episode talking about there was some stuff that they were doing with data loading and async versus synchronous, and do you wait on it or? They had built some really nice levers and trade-offs into the framework. And there's a really great talk that Ryan Florence, one of the creators of Remix.run, gave about that and showed what they were building. I've been exploring it a little bit more in-depth now. And there is some really, really interesting stuff in Remix. In particular, it's a meta-framework, I think, is the nonsense phrase that we use to describe it. But it's built on top of React. That won't be true for forever. I think it's actually they would say it's more built on top of React Router. But it is very similar to Next.js for folks that have seen that. But it's got a little bit more thought around data loading. How do we change data? How do we revalidate data after? There's a ton of stuff that, having worked in many React client-side API-heavy apps that there's so much pain, cache invalidation. How do you think about the cache? When do you fetch from the network? How do you avoid showing 19 different loading spinners on the page? And Remix as a framework has some really, I think, robust and well-thought-out answers to a lot of that. So I am super-duper intrigued by what they're doing over there. There's a particular video that I think shows off what Remix represents really well. It's Ryan Florence, that same individual, the creator of Remix, building just a newsletter signup page. But he goes through like, let's start from the bare bones, simplest thing. It's just an input, and a form submits to the server. That's it. And so we're starting from web 2.0, long, long ago, sort of ideas, and then he gradually enhances it with animations and transitions and error states. And even at the end, goes through an accessibility audit using the screen reader to say, "Look, Remix helps you get really close because you're just using web fundamentals." But then goes a couple of steps further and actually makes it work really, really well for a screen reader. And, yeah, overall, I'm just super impressed by the project, really, really intrigued by the work that they're doing. And frankly, I see a couple of different projects that are sort of in this space. So yeah, again, very early but excited. STEPH: On their website...I'm checking it out as you're walking me through it, and on their website, they have "Say goodbye to Spinnageddon." And that's very cute. [laughs] CHRIS: There's some fundamental stuff that I think we've just kind of as a web community, we made some trade-offs that I personally really don't like. And that idea of just spinners everywhere just sending down a ball of application logic and a giant JavaScript file turning it on on someone's computer. And then immediately, it has to fetch back to the server. There are just trade-offs there that are not great. I love that Remix is sort of flipping that around. I will say, just to sort of couch the excitement that I'm expressing right now, that Remix exists in a certain place. It helps with building complex UIs. But it doesn't have anything in the data layer. So you have to bring your own data layer and figure out what that means. We have ActiveRecord within Rails, and it's deeply integrated. And so you would need to bring a Prisma or some other database connection or whatever it is. And it also doesn't have more sort of full-featured framework things. Like with Rails, it's very easy to get started with a background job system. Remix has no answer to that because they're like, no, no, this is what we're doing over here. But similarly, security is probably the one that concerns me the most. There's an open conversation in their discussion portal about CSRF protection and a back and forth of whether or not Remix should have that out of the box or not. And there are trade-offs because there are different adapters that you can use for auth. And each would require their own CSRF mitigation. But to me, that is the sort of thing that I would want a framework to have. Or I'd be interested in a framework that continues to build on top of Remix that adds in background jobs and databases and all that kind of stuff as a complete solution, something more akin to a Rails or a Laravel where it's like, here we go. This is everything. But again, having some of these more advanced concepts and patterns to build really, really delightful UIs without having to change out the fundamental way that you're building things. STEPH: Interesting. Yeah, I think you've answered a couple of questions that I had about it. I am curious as to how it fits into your current tech stack. So you've mentioned that you're excited and that it's helpful. But given that you already have Rails, and Inertia, and Svelte, does it plug and play with the other libraries or the other frameworks that you have? Are you going to have to replace something to then take advantage of Remix? What does that roadmap look like? CHRIS: Oh yeah, I don't expect to be using Remix anytime soon. I'm just keeping an eye on it. I think it would be a pretty fundamental shift because it ends up being the server layer. So it would replace Rails. It would replace the Inertia within the stack that I'm using. This is why as I started, I was like, Inertia is still my answer. Because Inertia integrates really well with Rails and allows me to do the sort of it's not progressive enhancement, but it's like, I want fancy UI, and I don't want to give up on Rails. And so, Inertia is a great answer for that. Remix does not quite fit in the same way. Remix will own all of the request-response lifecycle. And so, if I were to use it, I would need to build out the rest of that myself. So I would need to figure out the data layer. I would need to figure out other things. I wouldn't be using Rails. I'm sure there's a way to shoehorn the technologies together, but I think it sort of architecturally would be misaligned. And so my sense is that folks out there are building...they're sort of piecing together parts of the stack to fill out the rest. And Remix is a really fantastic controller and view from their down experience and routing layer. So it's routing, controller, view I would say Remix has a really great answer to, but it doesn't have as much of the other stuff. Whereas in my case, Inertia and Rails come together and give me a great answer to the whole story. STEPH: Got it. Okay, that's super helpful. CHRIS: But yeah, again, I'm in very much the exploratory phase. I'm super intrigued by a lot of what I've seen of it and also just sort of the mindset, the ethos of the project as it were. That sounds fancy as I say it, but it's what I mean. I think they want to build from web fundamentals and then enhance the experience on top of that, and I think that's a really great way to go. It means that links will work. It means that routing and URLs will work by default. It means that you won't have loading spinner Armageddon, and these are core fundamentals that I believe make for good websites and web applications. So super interested to see where they go with it. But again, for me, I'm still very much in the Rails Inertia camp. Certainly, I mean, I've built Sagewell on top of it, so I'm going to be hanging out with it for a while, but also, it would still be my answer if I were starting something new right now. I'm just really intrigued by there's a new example out there in the world, this Remix thing that's pushing the envelope in a way that I think is really great. But with that, my now…what was that? My second or my third rave? Also called the positive rant, as we call it. But yeah, I think on that note, what do you think? Should we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsor by SEC Playground แบบสอบถามเพื่อปรับปรุง Chill Chill Security Channel: https://forms.gle/e5K396JAox2rZFp19 Music by https://www.bensound.com/ --- Support this podcast: https://anchor.fm/chillchillsecurity/support

Sponsor by SEC Playground แบบสอบถามเพื่อปรับปรุง Chill Chill Security Channel: https://forms.gle/e5K396JAox2rZFp19 Music by https://www.bensound.com/ --- Support this podcast: https://anchor.fm/chillchillsecurity/support

Yet another episode. Always something to discuss. Ken and Seth talk about a recent article covering *theoretical* software supply chain exploits and how this will be a big thing this year. A review of Portswigger's nominations for Top Ten Web Hacking techniques of 2021. Finally, a discussion on the upcoming Chrome changes to do pre-flight requests for non-routable IP address CSRF requests.

Some readily understood vulnerabilities, but with some interesting impacts, from escalating self-XSS to cross-account CSRF, data exfiltration with CSS, web-cache poisoning and MFA bypassing. Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/bypassing-mfa-webcache-poisoning-and-aws-sagemaker.html [00:00:00] Introduction [00:00:34] Humble Book Bundle: Hacking by No Starch Press [00:05:50] AWS SageMaker Jupyter Notebook Instance Takeover [00:16:39] [Glassdoor] CSS injection via link tag whitelisted-domain bypass [00:21:15] [Symfony] Webcache Poisoning via X-Forwarded-Prefix and sub-request [00:25:47] Bypassing Box's Time-based One-Time Password MFA [00:31:26] Exploring Container Security: A Storage Vulnerability Deep Dive [00:36:28] Hakluke: Creating the Perfect Bug Bounty Automation [00:37:10] Data Exfiltration via CSS + SVG Font The DAY[0] Podcast episodes are streamed live on Twitch twice a week: - Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities - Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. The audio-only version of the podcast is available on: -- Apple Podcasts: https://podcasts.apple.com/us/podcast/id1484046063 -- Spotify: https://open.spotify.com/show/4NKCxk8aPEuEFuHsEQ9Tdt -- Google Podcasts: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy9hMTIxYTI0L3BvZGNhc3QvcnNz -- Other audio platforms can be found at https://anchor.fm/dayzerosec You can also join our discord: https://discord.gg/daTxTK9 Or follow us on Twitter (@dayzerosec) to know when new releases are coming. #BugBounty #EthicalHacking #InfoSec #Podcast

Chris regains several of his developer merit badges and embarks on a perilous CSRF (Cross-Site Request Forgery) adventure. Steph shares highlights from Plucky, a management training course, including ways we can "click" and "break apart" from our current role, and how to have hard conversations. They also discuss how software development processes change at different team sizes, processes that break down as teams grow, and processes that are resilient at any team size. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy The Nightmare Before Christmas - What's This (https://youtu.be/QLvvkTbHjHI) Giant Robots Smashing into other Giant Robots - Plucky with Jen Dary (https://www.giantrobots.fm/search?utf8=%E2%9C%93&term=plucky) Plucky (https://www.beplucky.com/) Services are Not a Silver Bullet (https://thoughtbot.com/blog/services-are-not-a-silver-bullet) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Boom. I'm recording. Magic is happening. [singing] What's this? What's this? It's a Bike Shed episode. What's this? What's this? CHRIS: You did that on the mic. [laughter] So you just started recording too, so it's not like you're like, "Oh, I forgot I was recording." STEPH: Oh, I didn't have a finishing line that rhymes with shed. CHRIS: Head, dead, bread, spread. STEPH: [singing] Is TDD dead? I don't know. [laughs] CHRIS: Cool. I liked it. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world? CHRIS: What's new? I had a fun experience over the past week or two of regaining some of my developer merit badges, which is always enjoyable. So one was I had to configure AWS, specifically S3 and IAM such that I could upload files to an S3 bucket, which seems like one of those things that a developer should be able to do, and it's just not that hard. And, man, I failed so many times, and I stared at the screen. And the ARNs I think that's another acronym that I had to try and figure out what it means and fight against. Anyway, I got there. So that's one merit badge earned. I really hope [laughs] I correctly and securely configured access to an S3 bucket such that we could upload files in our Rails app. Cool, neat. Moving on, the next merit badge that I went for was restoring the sea of green dots. Our RSpec output had gathered some noise. There was a whole bunch of noise across a variety of things. There were some dev tools that were dumping some stuff in there. And there was something related to apparition, which is the...I want to say it's the Capybara feature spec driver that we're using now, which sits on top of ChromeDriver or something like that. I don't really understand the details, but it was complaining about something. And I found a fix, and then I fixed it and whatnot. But it was one of those. I did this on a Saturday because I was just like, you know what? This will be cathartic and healing. And then I got to the sea of green dots, and I was so happy to get to it. STEPH: This is me...I'm giving you a round of applause. CHRIS: Well, thank you. Arguable whether it delivered any real value to users, but again, this was Saturday effort, so I was allowed to indulge my fastidious caretaker of the code role. STEPH: Sorry, before we move on to more serious, can we pause to talk about developer merit badges? I really, really want cute felt badges that we can...I mean, I can't design them. I don't have the talent. But I think between us and other folks, we could design amazing merit badges, and then people could collect those. I'm very much in love with that idea. CHRIS: I love the idea. I am now certain that if we were to really pursue this, that we would fall into the deepest of bike sheds as we try and define well; what are all the merit badges? And what are the different levels? STEPH: [laughs] CHRIS: And how many do you need to collect before you can get to what are the different...There are just so many different taxonomies that we could introduce, and, oh man, I could spend a couple of weeks on that. STEPH: [laughs] It has a very strong Pokémon vibe too of you got to catch them all. CHRIS: Absolutely. STEPH: Okay. All right. We won't digress into bikeshedding merit badges, but I'm still very, very interested in that idea. CHRIS: Indeed. If anyone out there in the listener space wants to just make these, that would be great. This is the way that I avoid bikeshedding now is I just say I'm not allowed to make these decisions or even think about it. But if these happened into the world, I would be happy about that. STEPH: Oh, I just remembered we do have something similar at thoughtbot. They're not physical where you can hold them, but I think we've talked about turning them into physical badges. But we have our internal tool hub that we used to track our schedules. And one of the fun Ralphapalooza events that we had, a team came up with the idea of introducing badges in the tool hub, so then you could award people badges. You could give people badges. And it's very cute. So they could probably help us with the taxonomy. They've probably already figured out a number of badges we could get started with. CHRIS: And of course, this is where my brain went initially to like, oh, what would the taxonomy be? But I think that's how this goes bad. And if we just keep it in the this is cute and fun, and what are all the possible merit badges, but they're all equal, and the points are made up anyway, and then it's just a fun thing, then I'm like, I'm super into this. Let's do that. Have you used a regular expression to parse HTML? Congratulations, you get a merit badge. Have you not used regular expressions to parse HTML? You get a different merit badge. [chuckles] STEPH: [laughs] I feel very positive that I could be chief of cute and fun. I could manage that department. CHRIS: Yes, that feels like definitely a role that you could really excel at. But shifting around ever so slightly, I did run into a fun bug this week. And it was a mystery tour of, I'm going to say, sadness and then eventual learning and understanding, and I think we've come to a better place. But I want to tell a story, take us on a quick tour of the adventure that I went through. So we recently saw a handful of exceptions come through in our exception monitoring service and then piped into Slack, where we see those around CSRF token expiry. So this occasionally happens in a Rails app. The CSRF token that was on the page gets rotated. And therefore, when someone...if they have an older version of the page open and they try and submit a form or something like that, then CSRF protection is going to kick in. And you do get some false negatives there or some cases where like, nope, this is actually a fine user, this is not hacking, this is nothing bad. It's just that that user had a tab open or something like that. I'll be honest; I want to understand better the timeline of expiry and how Rails expires those and whatnot. But it's one of those things; it's deep enough in Rails that I trust that they are doing a very reasonable thing. And I think the failures that we're seeing that's part of the game. And so, mostly, we wanted to add a nicer handling around that. So thankfully, Inertia actually has a really wonderful page in their docs about handling Cross-Site Request Forgery expiration token, this whole thing. This is a particular failure mode that your app might have. And so it's nice to be able to provide a nicer user experience. And so what we ended up doing is if we catch that exception, we have a rescue_from in our application controller that will instead of having this be a 500 and just a full, like, something went wrong error page, we instead respond in an Inertia-like way to basically show a flash message that says, "This page has expired. Please refresh the page to continue." And if the user just refreshes the page, then they will get a new CSRF token. And from there, everything is going to be fine. So it's not ideal. But it is, I think, both secure and now a nicer user experience. STEPH: Yeah, that sounds really nice. When they refresh the page, do they lose all that form data? I'm curious how painful of a flow that is for the user. CHRIS: Currently, yes. Inertia actually has a really nice feature for remembering form data. If you've ever been on GitHub and you're filling in a box, and then you go away to a different tab, and you come back, and it's still there, and you're happy about that, it's that sort of thing. So we could configure that. At this point, we don't have...most of our forms are pretty small. So this is not something that we opted to do proactive management around. But that is definitely something that we could add but not something that's default or anything like that. STEPH: Cool. Yeah, that makes sense. I was just curious because yeah, either small form doesn't really matter, or also, this may be just a small enough error that only a handful of people are experiencing it that it's also just not that big of a deal. CHRIS: Yes, this definitely should be an edge case. And we've also recently been working on functionality to log folks out after a period of inactivity, which would also, I think, obviate this in a different way. So all total, this shouldn't be a big deal. And this was basically a quick, little snippet of code that we thought we could just drop in, and everything would be great because it shouldn't happen much. But then I was testing out a different feature on staging, and everything I tried to do was popping up this little alert flash message that was like, "Hey, your page is expired." And I was like, that seems bad. And then I realized literally every action, any non-GET request, was getting this response that the CSRF token didn't match. And I was like, well, this seems bad. Luckily, it was only on staging and hadn't made it to production. But it had made it to staging, which meant it had gotten through CI, which was very concerning because we have a pretty robust set of feature specs at this point. We built up a bunch of fakes for all of the external data systems that we're interacting with. And we're really putting the app through its paces and trying to do so in a very production-like way. And so I was like, this is such a deep fundamental breakage. I don't know what's going on here. And so I started to investigate. And it turns out that in a recent commit, I had started using Axios, which is a little wrapper around the Fetch API. They may not actually use the Fetch API under the hood, but it allows you to have a nicer interface to make XHRs. And we implicitly had that in our package already by virtue of Inertia. Inertia uses it under the hood, but I wanted to make it explicit because now I was using it directly. So I figured that's cool. I will yarn add Axios, and then I will continue on with my day. And I worked on my feature and everything was great. And then I pushed it up into a pull request, and everything was great, and CI passed. And I got it onto staging, and everything was very sad. So then I started on the adventure of like, what is going on here? It turns out that somewhere between version 0.21.1 of Axios and 0.23.0, which there's a bunch of things about those version numbers that make me uncomfortable but here we are, somehow the behavior where you can configure the XSRF header name, which is what they're calling it on their side, the configuration stopped working. And so our override that says this is what our CSRF or XSRF token should be called when it's sent back up to the server in a header that was getting lost. And so they were falling back to their default name, Axios was. And, therefore, Rails was like, "There's no CSRF token here. So this is going to be a no for me. I'm going to reject all of the requests." So the fix was relatively easy to roll back and to pin the version of Axios to the previous version that we had been using. I didn't actually intend to upgrade it. I just intended to make it an explicit dependency. But by doing that, I accidentally upgraded it. I don't love that there was this pretty deep breakage in that. I haven't done the good work of trying to open an issue. I still want to scan through and see if there is an open issue or a conversation around this before I start making any noise. But I think if I don't find anything, this is the sort of thing that should be reported because I can't imagine I'm the only one running into this. Likewise, I was very sad that my test suite did not find this. Turns out in Rails, CSRF protection is just turned off in test mode, which may be overall makes sense. But for feature specs, in particular, I definitely want to have it. And so, it was nice that I was able to find the relevant configuration. And we introduced an RSpec configuration that says, "If it's a feature spec, save off the existing configuration and enable CSRF. And then after the spec, go back to whatever the previous was." So now all feature specs run with CSRF. And I did make sure to push up that as a singular change to CI, and CI was very unhappy with me. Many, many features-specs failed, which was good. That was what we were going for. They failed for the right reason because things were fundamentally broken. And then, I was able to update the package-lock or the package.json on the yarn lock, pin the version, fix everything. But man, there was this period of like, oh man, the app is broken in such a fundamental way. Users just can't do stuff anymore. They can view anything, but they couldn't change any data. And it just snuck through CI. And that feeling is the worst feeling. We had, at this point, built up a lot of trust in our test suite. It was really telling us when stuff was wrong, and if it was green, I felt very good merging. And suddenly, this just really shook me to my core on that front. STEPH: I love these journeys that you take us on. I mean, they're painful for you, and I am sorry to hear that. But I love these journeys that you take us on. [chuckles] CHRIS: I usually only take us on them when I've figured out the answer. And I'm like, all right, here's where we're at. It was rough for a little while, but now we are happy. And thankfully, the one configuration of saying, hey, Rails, also, please include this as part of our production like, configuration for test mode. So I feel better that moving forward, this breakage won't happen again. STEPH: We should add that as another merit badge for telling a bug story. All right, I'm taking off my hat of chief of fun and cuteness. So this may not be terribly relevant to all the things that you just shared. But I am curious where you mentioned that with Axios because you'd specified the name of the token, and then that overriding behavior is what then broke. And so then that's what led to this whole adventure that you went on. I'm curious, why did y'all customize the name of that token? CHRIS: A, this is a great question. B, I'm not super sure. C, I think the reason is because we were trying to align to Rails. So we have a little middleware on the Rails side that will serialize the CSRF token into a cookie. And then that cookie value gets read by Axios and sent back up as a header on the request. So this is the way that with Inertia CSRF just kind of works and is good. And it's different than Rails' normal. We put a hidden input into any form. And so Rails holistically knows about both sides of that, and everything works fine. But now I have to manually round trip the CSRF token. And Axio's default configuration is a header name X-XSRF-TOKEN, and we needed X-CSRF-TOKEN because that's what Rails is looking for. I probably could have configured it the other way on the Rails side. But one way or another, I had to get Rails and Axios to come to an agreement, to meet at a table, and to agree to collectively protect the app. And so I had to mediate that discussion, and that's what ended us here. STEPH: A meeting of the minds. [chuckles] Cool, cool, cool. Yeah, that makes sense. I was just curious because then that would have changed the whole journey. But yeah, that is super interesting. And I definitely resonate with the idea of when you've really invested in your test suite, and you trust it that then when it doesn't catch something that obviously breaks the application, then that feels like something worth prioritizing and digging into and then figuring out how to bring back that parity. I don't know that I've turned on enable CSRF for feature spec. So I'm also very interested in looking at that configuration and considering if I need that for any of my future client projects if that's something that I need to remember for the future because that's very niche but good to know about. CHRIS: I feel like this only really comes up if you're working in the...it's called the odd middle ground that Inertia ends up occupying. If you're in a traditional Rails app that is generating HTML server-side, forms are generated. They got the CSRF token inlined there in a hidden input. And then when you post that form, it's coming back up. The names automatically are going to match. You don't need to worry about it. And it's probably fine to not have it included in test mode. And if you're at the other end of the spectrum and you've got API interaction, and that's the way you're doing everything, then you have a different auth mechanism and cookies, and whatnot just don't apply in the same way. And so it won't really matter on that side but for a different reason. And it's only because we're in this interesting middle ground, which, again, I really love. And it's the thing that I love about Inertia. But this is a rare case where it's like, oh, we do have to bring the two sides to meet in the middle. And this is a case where, unfortunately, due to a very subtle breakage on a minor release of...a package that we're using silently broke so, yeah. But yeah, thankfully, everything is back to working. And again, we've been able to enhance the test suite in that little way that I feel confident again because this won't sneak in another time. We have coverage around this. We're good to go. So while I was very scared when this initially happened, I feel better now. I'm happy to go into the weekend feeling better about this. But that's my story. What's new in your world? STEPH: So I feel like I've been having one of those weeks where I have less code adventures. In fact, it's one of those days where I went to thoughtbot's daily sync...because we often have our client daily syncs, but then we still have a thoughtbot sync as well. And I went to the group, and I was like, I get to write code today. It's going to be a great day. All the other things I'm doing are also interesting, but I get particularly excited when I get some maker's time and get to write some code. So I feel like I've had less coding adventures recently and more hiring and process-related adventures. And specifically, I just completed the Plucky Manager Training, which is a program that's founded and led by Jen Dary, who was recently on thoughbot's podcast, The Giant Robots Smashing Into Other Giant Robots. I'll be sure to include a link in the show notes for anyone that's interested. CHRIS: I believe this was the third time she was on. It's at least the second, possibly the third. And all of them are great listens, just as an aside, so we should include links to all of them. STEPH: Yes, I think she's one of the rare guests that has been on the show three times. And I think I've only listened to the first couple minutes of that episode. But I think they talk about the fact that this is her third episode, which is really, really cool. And I'm still frankly synthesizing all the information and the ideas that I've collected from the course. But I do have a few quick takes that I'm interested in sharing with you. So the first one is my cohort...we were the Panda Cohort, so go, Pandas. And some of the things that we talked about were…, and I think that this may have been the first day. So it was three days, and it was three hours for those three days. And they're spread out over a couple of weeks, which is really nice because then you show up for those three hours of the class, but then you leave with some ideas and some things to experiment with. You get a week to then try out an experiment and then come back to class next time and talk about this is how it went; it went to wonderful, or it went terrible. And you get to share that with others and work through it. And in the first class, we talked about coaching versus managing, which I found just a helpful definition to review. So managing is more direct, and telling someone what to do while coaching is encouraging someone to determine their own path and find their own solution. And I find that as a team lead at thoughtbot, I'm very often more in that coaching space than I am in that managing space. I think it's frankly pretty rare that I actually need to put on a manager's hat. And I often feel like I'm wearing my coaching hat instead. And some of the other things we talked about one of them is what is work? Which is a fun question to ask. And Jen had an analogy for this speaking about imagine that you have a plastic Easter egg. So it's got two sides, and side one is all the skills and desires and things that you're fulfilled by. And side two is a company that needs those skills. And it's great when those line up and click together, like when you take a job or get a promotion. Have you ever played...do you know what I'm talking about? Those little plastic Easter eggs. Have you ever played with those as a kid? CHRIS: Yes, certainly. STEPH: [laughs] I realize I just launched into that analogy. [chuckles] And then Jen goes on to say that's totally normal for then those sides to unclick. And Jen continues to say that it's totally normal for them to unclick. So maybe the company changes direction, the company is acquired. You've fallen out of love with something that you do about your job, or you have kids, and that has changed the things that you are fulfilled by and what you're looking for. And that's not necessarily bad. So it can be like, hey, you are working on x now, and you're not fulfilled by that anymore. But then another company comes along and says, "Hey, we're working on this, and you are fulfilled by that." So then another click happens. And essentially, it's a nice analogy to represent someone's career path and the ways that we are going to shift and re-prioritize what we're interested in. But it's also a really nice way to help it feel less personal because both sides are allowed to change. The company can change. You, as an employee, can change. And then you can look for that next click that is going to match up with a company that meets your skills and things that help you feel fulfilled. One of the other topics that we talked about are hard conversations, which I love that we dug into this one because that's certainly one that I struggle with or...I mean, we all get that feeling if you have to confront someone if you have to have that uncomfortable discussion with someone. It is a very hard thing to do. And so we had some very honest conversations around what is a hard conversation? What does that represent? And essentially, they represent that there is stalled progress and something can be improved. So Jen likens a hard conversation to a tool. It's something that you can use to then help something move forward again if something feels stalled or if there's something that needs to change. And during those hard conversations, you may not get to the resolution that you're looking for. So you may be looking for a specific outcome. But you also have another person that needs time to respond and to take in everything that you have said and process that information. So when you have a hard conversation, you may actually only move forward an inch. So if you had a lofty goal of we're going to talk and then we're going to have this hard conversation, and we're going to get to this space...But instead, you actually just make incremental progress. Like, okay, at least this person is now aware of this concern. That might be your win for the hard conversation versus actually tackling; how are we going to address it? I just want them to be aware of this concern. And it's a very vulnerable conversation, and they often take time before you can get to that ideal resolution. But essentially, the idea is get in the game, start the conversation, and then have follow-up conversations for that hard conversation. And I really appreciated that framing because I often will think of hard conversations of oh, we have to have this hard conversation and get to this specific outcome. But if you shift the goal line to be like, no, I really just need to at least make this person aware of a concern, that makes it a lot more approachable. And then also probably yields more fruitful outcomes because that gives the other person time to think about what you've shared to also come to the table with their own ideas and then work together to then get to that ideal resolution. CHRIS: I like that framing a lot. I can definitely see the case where you, as someone who has recognized something that needs to change (perhaps you're a manager),lineup you've now thought about that a good bit; you've observed it, but the individual that you're bringing that to this may be novel. This may be a surprise for them. And so if you come into that interaction both about to share this information but then also trying to resolve it and trying to get to I need you to internalize it, and I need you to fundamentally change your behavior as a result of this conversation we're going to have, that's quite possibly not a realistic outcome. And if you're trying for that, it might inherently lead to just a bad outcome because that individual is not in a position to do that. But they are potentially ready to hear it. And so you can just achieve step one and then later have step two. So I like that a lot. STEPH: Yeah, in general, I found the course incredibly helpful, very insightful. It was also really nice to hear from other managers that are facing similar problems or perhaps novel problems and then getting to weigh in and help each other. So it's a wonderful course. I'll be sure to include a link in the show notes for anyone that is interested. And I'll probably come back with some more insights from the class because it's really...we just wrapped up. So I'm sure I still have some ideas that will percolate over time, and I want to come back and share those with the group. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Pivoting just a bit, we have a listener question that I'm excited to dive into. This question comes from the one and only, the Edward Loveall, fellow thoughtboter. And Edward wrote in, "How does the process of software development change at different team sizes? What's a process that breaks down soon after the team starts growing? What's a process that is resilient at all sizes? And by process, I mean anything that involves other people including organizing tasks, code review, deployment, or anything else that isn't you alone writing code in a vacuum." I'm really excited about this question because I think there's a lot here. And there's actually one part that I'm struggling with a bit, so I'm curious to see what you think, Chris, about it. But I'm going to start off with saying that I think there are a number of management processes that definitely break down as a team grows. But in the spirit of Edward's question, I'm going to focus more on the software development process and how those might need to change and what starts to break as your team grows. So starting off with processes that break after the team starts growing, this one, frankly, what really starts to break is not a process specifically, but it's the lack of process that really starts to become visible and painful. So, how do we track work? Before, maybe the product manager or someone would just send you a message and say, "Hey, can you work on this?" or "Hey, can you fix this thing?" And how does code need to be reviewed before being merged? Does it need to be reviewed? Are people just merging as they get stuff done? How are deploys performed? Oh, we have a super urgent production fix that needs to go out, and the only person that knows how to deploy is out sick today? Cool. That's the type of process that I think that really breaks down, or at least you start to notice when the team starts to grow. What are your thoughts? CHRIS: I definitely feel that first one very strongly. We're feeling it right now on the team, which is still very small. There are only three developers working on the project, and then we have a product manager. And each week, we're slowly iterating, and tweaking, and honing, and trying to introduce just enough process in terms of how we define the work to be done, communicate the status of it, all of that fun stuff. We started with Trello. And we just had a board with some columns, and then we had more columns, and then we got rid of a few of them. And then we recently added a Power-Up to the Trello board, which allows for epics. So there are cards which are epics which tie to sub cards. And I'm staring at it, and I'm like, how long until we're Jira? How long can I hold out here and not be Jira? But it does feel like we're slowly iterating towards a more useful process for this team rather than process for process' sake, which I feel like is a really useful distinction. There's also a question of like, what can be known or what can be adequately measured and whatnot versus what can't be? So we've talked many a time on the show about estimation and velocity and trying to track that and the pitfalls inherent with that. And so there's, in my mind, two different camps. There's the process we want to avoid. And again, to reference German Velasco's wonderful blog post, Say No To More Process. And I really feel like there is a tendency often when things go wrong to then try and paper over that with process. Oh, this team didn't use the design system. So we need to write ESLint rules to make sure you can't import from the directories that aren't the thing. And it's like, we can do that, and I've definitely done that. And I will do that again in the future. But I always have the lens of do we need this? Is it worth the trade-off, the cost, the overhead, the complexity that it's bringing in? But definitely, organizing and communicating tasks is one of the ones that becomes really difficult. The more people that are working on something, the more you need probably more than one person staying out in front of them and trying to define the next bit of work that needs to be done after that. Code review feels like it probably should stay similar, with the exception that I lose the ability to review all code at some point. Right now, I'm trying to review every single PR that goes through or close to it. At some point, I'm just going to have to give up on that. But for now, that's my goal. But fundamentally, code review, I think, will hopefully take the same shape. Deployment, similarly, like, I've talked about the merge queue thing. I want to get a little bit of process in there but not too much. There is definitely some necessity for change. But I definitely want to resist the urge to change everything and to just say, like, slowly over time; we're going to have to be a big Byzantine organization with lots of rules and standard operating procedures and all of that. I've heard anecdotally, and I don't know if this is true, so maybe someone out there on the internet can correct me if I'm wrong, but my understanding is that at Google, they're pretty tight in terms of what languages and frameworks can be used and what processes, and workflows, and build tools and all of that whereas Facebook, as a counterpoint, is relatively lax. Obviously, React is used very heavily on the core web application. But there's some flexibility in terms of different languages and frameworks and things for sub-projects or small individual teams having a little bit more autonomy. And I think that's a really interesting thing of are you one large, cohesive, organized company or do you try to act like a bunch of small disparate but roughly connected teams that share good ideas but can work independently? And that changes how I would think about this question. STEPH: I really like how you're describing the addition of process. It sounds like a just-in-time process. So as you're learning that something needs to be added, then that's when you look for answers. And then you sprinkle on a bit of process that everyone agrees that feels very helpful within also the right to review and see if that still makes sense for the team. There's one additional area where I think the lack of process really shines through in addition to the number of ways that you've mentioned is also onboarding. So if you have a very small team and you are onboarding, it's likely that...Chris, you can let me know if I'm wrong, but when someone's joining the team, there's probably a good chance that they get to pair with you at some point, or they even get welcomed by you to the team. And then, they get an overview of the product and the codebase. And there's probably this really nice session where they get to ask you questions, and then they have that onboarding session. Does that sound about right? CHRIS: Yes. But I would go so far as to say it's not just a day or a session, but it's probably a couple of days. So yes, and. STEPH: That's even better. And with some of the smaller teams that I've seen, that onboarding process is where they are pairing with that lead person on the team. And that's going well until suddenly that lead person can't pair with everybody. And nobody has really thought about how to streamline that onboarding or how to coach or teach someone else to be a really good onboarding pair. And I have strong feelings about this area because we often focus so much on hiring, but then we drop the ball when it comes to onboarding that new, wonderful colleague that we've worked so hard to recruit. And at the end of that day, someone's going to reach out to them and say, "Hey, how was your first day?" And it makes a big difference for that person's retention as to how those first couple of days ago. So I think onboarding is another really important part that when you're a smaller team, you probably don't need much process because you have more of that personable onboarding experience. But as the team grows, there needs to be more of a process to help other teammates join the team. CHRIS: It's interesting. I think I totally agree with you that over time, there is a necessity to be more intentional and to have a little bit more structure in the process. And I don't think you're saying this, but I just want to make sure we are saying the thing that I think we believe, which is that shouldn't replace the human that helps you onboard. Like, I still like the idea that everybody gets a pair for some amount of time when they start at a new company. And you're working together on a feature, or you're working together on bug fixes. You're shipping to production as soon as possible. But you're not doing that based on some guides in a wiki. You're doing that with another human that's helping you. There should also be guides, and a wiki, and documentation, and formalization as the organization grows but not in place of having another person that you get to talk to. STEPH: We're just going to send you a little yellow rubber duck and then with a little Post-It note that says, "Good luck [laughs] with your onboarding process." Definitely. I agree with everything you said. It does not replace that human element where there's someone that's helping you onboard. I just see that onboarding is one of those things that gets forgotten, or we often point someone to a README which I do think is great because then it is battle-testing our README. But then there still needs to be someone that is readily there to say, "Hey, how's it going? What are you struggling with? Can I pair with you?" There still has to be that human element that is helping guide you through the process. And I think smaller teams may forget that they actually need to assign somebody to you to make sure that you have someone that you know. Like, hey, this is who I can reach out to with all my questions. Because they're probably not going to be comfortable posting in the company channel at that point or a larger communication to say, "Hey, I'm stuck on something." CHRIS: There's one other area that comes to mind, or I guess it's more of an anecdote that I have heard, but it speaks back to GitHub's early, early days. And they were somewhat famous for being very flat in terms of the organization and very self-organized, and everybody's figuring it out, and you're working on the thing that's most important in your mind. And for a long time, this was a celebrated facet of the company and a thing that they talked about rather publicly. And then I think there was this collective recognition, and maybe they reached a tipping point where that just didn't work anymore. Or maybe it actually hadn't been working for a bit, and there was just the collective realization of that. But it was interesting to watch from the outside as GitHub added more formalization, more structure, more managers, and hierarchy, and career ladders, and things of that nature. And I think there's a way to do all of those things in a complicated, overloaded, heavy way. But I think a different version of it is...like, you were using the word coaching earlier. Having formal structures within your organization to encourage people on their career path, to help them grow, to have structure around that, I think is a really difficult thing to get right. But I think it is critical, and I think just not having it can't be the answer past a certain probably pretty small size. So that is an interesting one where I think you do need to introduce some process and formalization around how you think about the group of people and how they work together within your organization. STEPH: I agree. I think where some folks may see a lack of hierarchy; others feel a lack of support. And adding levels of management should really be focused on the outcome is that we're helping people feel supported. So even getting feedback as you're adding those different levels of management, like, hey, did we make your life better? Did we make your life worse? I think that's a great question for management to ask as they're exploring a less flat structure. CHRIS: So, Steph, I have a question for you now on a variant of this topic. In general, we seem to be fans of having a codebase. Probably a Rails app that's got a database behind it, and that's where you put the data. Everybody commits to that same repository. It's all kind of one collected thing. And often, organizations grow to a certain size, and they're like, this is untenable. We cannot have this many people working on this same codebase. So we shall do the logical thing, which is we will break it up into small pieces. And those pieces will communicate over HTTP, and it will be great because then our teams can be separate from each other and can manage their little piece of the world. What do you think about that? Is there truth there? Is it not true at all? What do you think? STEPH: All right, so your team is getting too big, and to the point that you feel like you need to split it out so then you can have small teams, and they can all work independently on different parts and services of the codebase. I don't love the idea. I'm trying to think through because I feel like there's a lot of nuance here. But I don't love the idea that that's the driving force as to why are we making the change? And that is often a question that comes to mind whenever we are making a big change, either architecture or process-related is like, what's driving this? And then how are we going to measure it? And if we are driving it just because we have a large team, let's talk more. Why are people blocked? Why can't people work together? What's preventing people from being able to contribute to the same codebase? Are people blocked for a long time because they're having to wait on someone else to complete that work? I have a lot of questions that I don't know if I can fully answer your question. But my instinct is to say let's not break up the architecture just because our team grew in size. CHRIS: Yeah, I think I definitely agree with that. There's probably a breaking point where it's just too many individuals, and there'll be too much contention. But I think resisting that or at least naming that as like, okay, that's what we're saying but is that really what's true? Or are we actually feeling that this system is so deeply coupled that there's no way to change some small piece of the code without impacting other parts of it? Like, is the CSS completely untenable because we're just using global class names, and it's leaking everywhere? Okay, do we need a different solution there? And then it's actually fine. We don't need to have different services that have their own different style sheets. We just need a different approach to CSS. That's a particularly easy one to go for because there's inherently a global namespace there. But the same thing is true in a lot of different contexts. So services are a way to break things apart and enforce those boundaries. But if inherently coupling is your problem, then you're just going to be coupled over HTTP, and I think it's going to be difficult. There's a wonderful blog post by Josh Clayton, which I think does a better job than I'm doing in this moment of highlighting some of the questions I would want to ask. The blog post is titled Services are Not a Silver Bullet. And so Josh goes through and enumerates a bunch of the different versions of the story that he's heard throughout the years of well, we need to go to services because x, because our test suite is slow because pull requests are constantly having merge conflicts and whatnot, because the code is very deeply coupled and any change here affects everything else. And a fix over here broke something over there. This is no good. And so he does a really good job of presenting alternatives or at least questions that you can ask to say, like, is this the problem, or is this a symptom? And we need to address the more underlying cause. And so I think there is a point where you just can't have 1,000 people trying to commit to the same Rails codebase. That feels like it's maybe too big. But it takes a while to get to 1,000 people. And there will be times where extracting a service makes sense or integrating with an external service that exists. Like, I've talked about Stripe before as my canonical like, yeah, it's actually deeply intertwined with the data model, but they're just dealing with such a distinct complexity set over there. And they have such expertise on that that I'm happy to accept the overhead of the fact that that service lives outside of my core application, and I need to deal with synchronizing state and all of that. I will take on that complexity, but it's not worth it for everything, and it's not a silver bullet. Again, to reference the name of Josh's blog post there, Services are Not a Silver Bullet. And so, coming back to Edward's original question, I would say that having a monolithic codebase works for a really long time, but there is probably a breaking point somewhere well along, but fight it for as long as you can. I think. STEPH: I really like how you touched on coupling because it really helps ask those questions to get to the heart of what are the pain points that you are feeling? And it is less of a decision that is based on people and process but more if you're going to split out a portion of your architecture. It is in response to an actual business need and a business value versus some other pain points that you're trying to fix. A particular example might be like maybe you have a portion of your application that really just needs to spend a lot of time crunching data. And it's really not as specific to your application; it's something that can happen on its own. And then it's beneficial to move that outside so it can scale and relate it to the work that it needs to perform versus keeping it in-house with the application. I do want to circle back to another question that Edward included which is what's a process that is resilient at all sizes? And the ones that really come to mind for me...and these are a bit amorphous intentionally because it will look different for each company. But three areas that are very resilient at all sizes, whether you are 1 to 2 employees versus you've got hundreds or thousands it's communication, testing, and accountability. So communication, where are we headed, and how do we know what we're working on? For testing, it's how do we test our changes? Do we write tests? Do we use QA? Do we have a staging environment? What does that look like? What's our parity between staging and production? And then how do we know what's in progress, and how do we know when it's done? Those are three core areas that, regardless of your team size,,I think are very crucial to the team success. What do you think? What are some of the processes that are resilient at all sizes? CHRIS: I actually really like the list that you just provided. That is a wonderful trifecta, and I think it will take you very far, so probably not much to add from me. But I guess on that note, should we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/websocket-hijacking-github-review-bypass-and-sqli-to-rce.html Just a handful of traditional vulns this week: IDOR, CSRF, SQLi, a logic vuln and zi's boomer side starts to show. [00:00:18] Remote Chaos Experience [00:03:30] [Concrete CMS] Stored unauth XSS in calendar event via CSRF [00:08:47] ‘Websocket Hijacking' to steal Session_ID of victim users [00:14:17] IDOR + Account Takeover leads to PII leakage [00:27:27] Bypassing required reviews using GitHub Actions [00:33:20] How I Escalated a Time-Based SQL Injection to RCE The DAY[0] Podcast episodes are streamed live on Twitch (@dayzerosec) twice a week: Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. The Video archive can be found on our Youtube channel: https://www.youtube.com/c/dayzerosec You can also join our discord: https://discord.gg/daTxTK9 Or follow us on Twitter (@dayzerosec) to know when new releases are coming.

[00:00:50] The guys chat about the new release of Turbo 7.0.1.[00:01:46] Chris tells us how he moved all of the GoRails, CSS, and JavaScript from Webpacker into CSS and JS bundling, and it went pretty smooth except for something dumb he did. [00:04:50] Propshaft is brought up and we learn what it does.  [00:08:44] Why do we need the hashes at the end? Andrew explains why it's all about caching. [00:11:08] Ryan Bates is mentioned since he commented on the Propshaft repo. Also, Ryan, if you are listening, we would love for you to be a guest on our show!  ☺[00:12:39] Hotwire is the topic here, and although it's been released, but not officially, Chris tells us some things that are noteworthy. Jason tells us more about the Stimulus 3 stuff and the ability to the callbacks on targets.[00:20:33] Chris shares something that happened when he was looking at fixing a few things with madmin.[00:24:41] Chris asks the guys if they've ever gone into the weeds on engines and initializers in them and all the different callbacks. [00:30:22] Andrew fills us in on what his experience has been like working with Engines in the past month and Chris tells us what his approach for Jumpstart Pro has been.[00:35:33] We hear a story from Chris when he was learning Rails, and he mentions using Lockbox.[00:38:46] Chris wonders if the guys started a PR for Rails 7, and Andrew tells us how it's going. [00:41:30] Since Jason is a Safari user, Chris wonders if he has run into the bug where the CSRF token or the hidden fields can get overridden by Safari and the guys chat about it. [00:45:52] Jason really wanted to talk about Phoenix LiveView because he read a bunch about it and he's super interested in it, but he's saving it for the next episode. Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterTurbo 7.0.1 Propshaft-GitHubLockbox-GitHubAdd autocomplete= “OFF” to Firefox-proof automagically added hidden fields like _method #42610-GitHub

Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/a-flickr-csrf-gitlab-omigod-azure-again.html Some high impact vulnerabilities this week, CSRF in account deletion, remote code execution as root, and an apache "0day" that discloses PHP source. [00:00:23] [Flickr] CSRF in Account Deletion feature [00:03:38] OMIGOD: Critical Vulnerabilities in OMI Affecting Countless Azure Customers [00:23:38] How I found my first Adobe Experience Manager related bug. [00:27:41] [GitLab] Stored XSS in main page of a project [00:31:01] [Mattermost] Privilege Escalation leading to post in channel without having privilege [00:34:15] Hacking CloudKit - How I accidentally deleted your Apple Shortcuts [00:48:52] Apache 0day bug, which still nobody knows of, and which was fixed accidentally The DAY[0] Podcast episodes are streamed live on Twitch (@dayzerosec) twice a week: Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. The Video archive can be found on our Youtube channel: https://www.youtube.com/c/dayzerosec You can also join our discord: https://discord.gg/daTxTK9 Or follow us on Twitter (@dayzerosec) to know when new releases are coming.

1 Tiger Shroff के नए घर को लेकर बोले पापा जैकी श्रॉफ, ‘वो उसने अपनी मां को गिफ्ट किया है मैं तो बस...' 2 सलमान खान की तलाशी लेने वाले जवान का नहीं हुआ मोबाइल फोन जब्त, मामले पर अब आया सीआईएसएफ का जवाब 3 पिता और भाई अभिनेता फिर भी फिल्मों में काम नहीं करना चाहतीं कृष्णा श्रॉफ, ठुकराए कई फिल्मों के ऑफर 4 11 साल बाद प्रकाश राज ने दोबारा रचाई पत्नी पोनी वर्मा से शादी, जानें एक्टर ने क्यों किया ऐसा 5 BellBottom Box Office Collection: जानिए, 6 दिनों में कितना कमा सकी अक्षय कुमार की फ़िल्म बेलबॉटम 6 एंटरटेनमेंट न्यूज़ हेडलाइंस  7 वायरल एंटरटेनमेंट न्यूज़ - Bigg Boss OTT: सोती हुई शमिता शेट्टी को राकेश बापट ने किया KISS, ताबड़तोड़ वायरल हो रहा है वीडियो Support the show: https://www.jagran.com/ See omnystudio.com/listener for privacy information.

This week on the podcast, we chat about a recent report from Qrator that highlights some of the massive weaknesses in the backbone of the internet. After that, we discuss a recent research blog post from Yan (@bcrypt) showing her work in finding a CSRF flaw in OK Cupid that bypassed Cross-Origin Resource Sharing (CORS) protections.

In this Hasty Treat, Scott and Wes talk about CSRF (Cross Site Request Forgery)! Prismic - Sponsor Prismic is a Headless CMS that makes it easy to build website pages as a set of components. Break pages into sections of components using React, Vue, or whatever you like. Make corresponding Slices in Prismic. Start building pages dynamically in minutes. Get started at prismic.io/syntax. Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Show Notes 05:40 - What is it? https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#samesite-cookie-attribute Someone can submit a form FROM or TO your domain, automatically. 07:50 - Solutions SameSite Cookie https://medium.com/swlh/secure-httponly-samesite-http-cookies-attributes-and-set-cookie-explained-fc3c753dfeb6 Lax — Default value in modern browsers. Cookies are allowed to be sent with top-level navigations and will be sent along with GET requests initiated by a third party website. The cookie is withheld on cross-site subrequests, such as calls to load images or frames, but is sent when a user navigates to the URL from an external site, such as by following a link. Strict — As the name suggests, this is the option in which the Same-Site rule is applied strictly. Cookies will only be sent in a first-party context and not be sent along with requests initiated by third party websites. The browser sends the cookie only for same-site requests (that is, requests originating from the same site that set the cookie). If the request originated from a different URL than the current one, no cookies with the SameSite=Strict attribute are sent. None — Cookies will be sent in all contexts, i.e sending cross-origin is allowed. The browser sends the cookie with both cross-site and same-site requests. CSRF Token Check Origin / Referrer Headers Captcha Ask for Password Token Tweet us your tasty treats! Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Live from their parent's basement and dripping with tin foil - Seth and Ken talk about how CSRF is a thing in GraphQL. Kubernetes gets an intentionally-vulnerable setup, and you should definitely check the security of your docker. Finally, some noise about the NoSQL Injection Cheat Sheet.

Lisa spricht diesmal mit Christoph darüber, wie man Ein- und Ausgaben in Web-Anwendungen absichert. Schließlich ist der laxe Umgang mit diesen Werten, die üblicherweise aus den Eingaben von Nutzer:innen entstehen, regelmäßig eines der größten Sicherheitsrisiken.

Eduardo Castro se desata y nos invita a comentar trucos y construcciones idiomáticas no evidentes https://podcast.jcea.es/python/17 Participantes: Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Conectando desde Madrid. Eduardo Castro, email: info@ecdesign.es. Conectando desde A Guarda. Javier, conectando desde Madrid. Víctor Ramírez, twitter: @virako, programador python y amante de vim, conectando desde Huelva. Dani, conectando desde Málaga. Miguel Sánchez, email: msanchez@uninet.edu, conectando desde Canarias. Jorge Rúa, conectando desde Vigo. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia - Creative Commons Attribution 4.0 International License. [00:52] Haciendo tiempo hasta que entre más gente. Raspberry Pi Pico: https://www.raspberrypi.org/products/raspberry-pi-pico/. Jesús Cea está encantado con su rango de alimentación. Micropython: https://www.micropython.org/. [06:02] Truco: Python -i: Ejecuta un script y pasa a modo interactivo. También se puede hacer desde el propio código con code.InteractiveConsole(locals=globals()).interact(). Jesús Cea se queja de que usando la invocación desde código no funciona la edición de líneas. Javier da la pista correcta: para que funcione, basta con hacer import readline antes de lanzar el modo interactivo. [11:17] Regresión con ipdb: https://pypi.org/project/ipdb/. [12:37] Nueva versión de Pyston https://www.pyston.org/. Intérprete de Python más rápido. Un 50% más rápido que cpython. [16:22] Ver si dos fechas son iguales con datetime https://docs.python.org/3/library/datetime.html. Trabajar siempre en UTC https://es.wikipedia.org/wiki/Tiempo_universal_coordinado, aunque solo tengas una zona horaria. [19:52] Jesús Cea ha investigado cómo funcionan los POSTs HTTP en las protecciones CSRF https://es.wikipedia.org/wiki/CSRF. Buena práctica: La respuesta al POST es una redirección a un GET. Patrón Post/Redirect/Get (PRG) https://es.wikipedia.org/wiki/Post/Redirect/Get. Ventajas de usar un framework. [24:32] ¿Optimizaciones cuando tienes grandes cantidades de datos? Tema muy amplio, hacen falta detalles del problema. Se ofrecen algunas ideas: Map/Reduce: https://en.wikipedia.org/wiki/Map_reduce. Usar generadores u otras construcciones "lazy" siempre que sea posible. https://wiki.python.org/moin/Generators. [31:52] Gestión de memoria en Python. Design of CPython’s Garbage Collector: https://devguide.python.org/garbage_collector/. Hora de sacar la basura garbage collector - Pablo Galindo y Victor Terrón - PyConES 2018 https://www.youtube.com/watch?v=G9wOSExzs5g. [35:17] Tipografía para programadores: Victor Mono: https://rubjo.github.io/victor-mono/. Fira Code: https://fonts.google.com/specimen/Fira+Code. Fira Code Retina: https://github.com/tonsky/FiraCode/issues/872. [37:17] Eduardo Castro se ha currado una lista de trucos sencillos pero interesantes: En estas notas solo referenciamos los puntos a los que dedicamos más tiempo, se habló de más cosas. El documento para poder seguir los comentarios de la grabación está en https://demo.hedgedoc.org/s/hEZB92q40#. hash(float('inf')) -> 314159. [43:02] LRU Caché: "blame". [01:33:57] Usos de lambda. Módulo Operator: https://docs.python.org/3/library/operator.html. [01:35:52] Algunos trucos cortos adicionales. collections.deque: https://docs.python.org/3/library/collections.html. dateutil: https://pypi.org/project/python-dateutil/. itertools: https://docs.python.org/3/library/itertools.html. if a < x < b: >>> import dis >>> dis.dis(lambda x: a < x < b) 1 0 LOAD_GLOBAL 0 (a) 2 LOAD_FAST 0 (x) 4 DUP_TOP 6 ROT_THREE 8 COMPARE_OP 0 ( 18 ROT_TWO 20 POP_TOP 22 RETURN_VALUE Desempaquetado complejo: >>> a, b, (c, d), *e, f = 1, 2, (3, 4), 5, 6, 7, 8, 9 >>> print(a,b,c,d,e,f) 1 2 3 4 [5, 6, 7, 8] 9 Usar la variable "guión bajo" para descartar valores. Ojo con la internacionalización. [01:56:22] Python cada vez tiene más "gotchas". Algunos ejemplos: Operador morsa. Tratado con projilidad en tertulias anteriores. Parámetros mutables. Definir "closures" dentro de un for pero usarlo fuera. Tuplas con un solo elemento. Es más evidente el constructor tuple(), pero ojo: tuple('abc') -> ('a', 'b', 'c'). [02:01:06] ¡Terminamos con los trucos! [02:01:37] Ideas para indexar y buscar el documentos: Whoosh: https://whoosh.readthedocs.io/en/latest/intro.html. Solr: https://solr.apache.org/. [02:04:22] Deberes para el futuro: módulos dis https://docs.python.org/3/library/dis.html y enum https://docs.python.org/3/library/enum.html. [02:04:47] Sugerencia sobre visión artificial: https://www.pyimagesearch.com/. De lo mejor que hay. [02:06:47] regex https://pypi.org/project/regex/ que libera el GIL https://en.wikipedia.org/wiki/Global_interpreter_lock. [02:07:47] Acelerador y distribución de programas Python precompilados en binario y empaquetados en un directorio e, incluso, en un único fichero: Nuitka: https://nuitka.net/. [02:08:57] Design of CPython’s Garbage Collector: https://devguide.python.org/garbage_collector/. [02:09:17] Cierre. [02:10:52] Casi se nos olvida el aviso legal para grabar y publicar las sesiones. [02:12:55] Final.

Polémica Frameworks, compilación al vuelo, compiladores y rendimiento Python, scraping web y la persistencia vuelve a la carga https://podcast.jcea.es/python/16 Participantes: Jesús Cea, email: jcea@jcea.es, twitter: @jcea, https://blog.jcea.es/, https://www.jcea.es/. Conectando desde Madrid. Eduardo Castro, email: info@ecdesign.es. Conectando desde A Guarda. Javier, conectando desde Madrid. Víctor Ramírez, twitter: @virako, programador python y amante de vim, conectando desde Huelva. Dani, conectando desde Málaga, invitado por Virako. Javier, conectando desde Sevilla, también invitado por Virako. Antonio, conectado desde Albacete. Jorge Rúa, conectando desde Vigo. Audio editado por Pablo Gómez, twitter: @julebek. La música de la entrada y la salida es "Lightning Bugs", de Jason Shaw. Publicada en https://audionautix.com/ con licencia - Creative Commons Attribution 4.0 International License. [01:17] Event sourcing y nieve. Borrasca Filomena: https://es.wikipedia.org/wiki/Borrasca_Filomena. [03:52] Los comentarios legales habituales para poder grabar la tertulia. [04:47] Presentaciones varias, dinámica y motivación de las tertulias. [11:22] Los problemas logísticos de Jesús Cea con sus charlas. [12:52] Debate: Frameworks y cómo condicionan el conocimiento del lenguaje y la forma de desarrollar código. Mucha tela que cortar. [30:22] Conexión con el mundo asyncio. [34:12] Digresión: ¿Cómo funciona la protección CSRF? https://es.wikipedia.org/wiki/Cross-site_request_forgery. Diferencia semántica entre verbos HTTP: GET y POST https://en.wikipedia.org/wiki/POST_(HTTP). Algunos recursos de seguridad web (no exhaustivo, la lista es infinita): CSRF: https://es.wikipedia.org/wiki/Cross-site_request_forgery. Cross-Origin Resource Sharing (CORS) https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. Content Security Policy Reference https://content-security-policy.com/. La documentación de FastAPI https://fastapi.tiangolo.com/ tiene mucho de seguridad: CORS (Cross-Origin Resource Sharing): https://fastapi.tiangolo.com/tutorial/cors/. OAuth2 with Password (and hashing), Bearer with JWT tokens https://fastapi.tiangolo.com/tutorial/security/oauth2-jwt/. About HTTPS https://fastapi.tiangolo.com/deployment/https/. [39:52] Proyecto ItsNat https://en.wikipedia.org/wiki/ItsNat. Estado en el servidor y el cliente solo gestiona eventos y actualizaciones del DOM que le envía el servidor. Se está moviendo otra vez la inteligencia del navegador al servidor. [44:42] ¿Realmente es imprescindible usar Javascript si tu interfaz es el navegador? Brython: https://brython.info/. Pyjs (antiguo Pyjamas): https://en.wikipedia.org/wiki/Pyjs. Emscripten: https://emscripten.org/. [48:57] ¡Compilación al vuelo! Versionado de diccionarios. PEP 509 Add a private version to dict: https://www.python.org/dev/peps/pep-0509/. Compilación al vuelo: Pyjion: https://pyjion.readthedocs.io/en/latest/index.html. Conflicto con la portabilidad del intérprete. numba: https://numba.pydata.org/. Hay pocos "core developers" y heredar código avanzado que luego hay que mantener es un problema. LLVM: https://en.wikipedia.org/wiki/LLVM. [01:04:27] Los lenguajes de programación deben ser conservadores porque no tienes ni idea de lo que están utilizando los programadores. [01:05:32] Si la documentación se ha actualizado, más vale que hayas actualizado tu código a "cómo se hacen ahora las cosas". [01:06:47] Tema recurrente: ¿Es mejor estar dentro o fuera de la biblioteca estándar? Boost: https://www.boost.org/. [01:09:12] Compiladores de Python: Cython: https://cython.org/. Rendimiento y ofuscación. nuitka: https://nuitka.net/. numba: https://numba.pydata.org/. PyPy: https://www.pypy.org/. [01:10:42] Mejoras recientes en la implementación de Python: Issue 26647: ceval: use Wordcode, 16-bit bytecode: https://bugs.python.org/issue26647. Issue 9203: Use computed gotos by default: https://bugs.python.org/issue9203. [01:14:52] Psyco https://en.wikipedia.org/wiki/Psyco. [01:16:22] Etiquetado de tipos para ayudar a los JIT. Cython: https://cython.org/. MYPY: http://mypy-lang.org/. MYPYC: https://mypyc.readthedocs.io/en/latest/index.html. Especialización. [01:22:37] GHC (The Glasgow Haskell Compiler): https://www.haskell.org/ghc/. [01:25:07] Memoria transaccional https://en.wikipedia.org/wiki/Transactional_memory. Implementaciones en Python: Sistemas de persistencia como Durus https://www.mems-exchange.org/software/DurusWorks/ o ZODB http://www.zodb.org/. Mecanismos de resolución de conflictos. [01:34:32] Más sobre optimizaciones y guardas. Mucha discusión sobre el GIL: https://en.wikipedia.org/wiki/Global_interpreter_lock. La atomicidad de operaciones no está documentada en ningún sitio. [01:42:02] Ejemplo de bytecode: >>> def rutina(n): ... n += 1 ... n = n + 1 ... >>> dis.dis(rutina) 2 0 LOAD_FAST 0 (n) 2 LOAD_CONST 1 (1) 4 INPLACE_ADD 6 STORE_FAST 0 (n) 3 8 LOAD_FAST 0 (n) 10 LOAD_CONST 1 (1) 12 BINARY_ADD 14 STORE_FAST 0 (n) 16 LOAD_CONST 0 (None) 18 RETURN_VALUE [01:45:02] Cuando haces cosas muy avanzadas que usan cosas no definidas formalmente, mejor verificar las suposiciones. [01:46:47] La ventaja de probar cosas en proyectos personales: ¿Por qué Jesús Cea se ha hecho su propio scraper web? "Maldades". scrapy: https://scrapy.org/. [01:49:22] Migración de versiones en sistemas de persistencia. [02:05:07] Event sourcing. Event sourcing: https://dev.to/barryosull/event-sourcing-what-it-is-and-why-its-awesome. Logs de modificaciones. [02:08:07] Ventajas de haber usado scrapy: https://scrapy.org/. Concurrencia. tarpit. Problemas habituales: Normalización de URLs. Webs mal formadas. [02:13:47] Módulos de scraping: newspaper3k: https://pypi.org/project/newspaper3k/. [02:15:02] Recapitulación. Pyjion: https://pyjion.readthedocs.io/en/latest/index.html. MYPYC: https://mypyc.readthedocs.io/en/latest/index.html. [02:16:02] Compilación de módulos de Python para MS Windows. Generar un wheel. Aprovechar sistemas de integración continua que levantan máquinas virtuales. [02:22:21] Final.

On the 25 the episode of Zemach FM we are continuing on the cybersecurity series. In this episode, we are discussing about some of the main threats and vulnerabilities on the internet. The main titles discussed on this episode include cookie vulnerabilities and threats, Denial of service attacks, Web app vulnerabilities, and social engineering. We discuss what methods are used by attackers to perform them, to what extent it could affect a service, and some of the measures that can be taken to prevent or stop the attacks listed above. Episode Timeline 01:30 Title introduction 04:30 Vulnerabilities and threats caused by cookies 05:40 What exactly is cookie used for 07:13 How cross site request forgery (CSRF) works 10:53 What is a Cross site scripting (XSS) attack 12:03 The three different types of XSS attacks 15:00 XSS attack prevention methods 18:07 What is a denial of service attack 20:18 What is the difference between distributed and non-distributed denial of service attack 21:36 How a distributed denial of service works 23:53 Common types of denial of service attacks 28:54 Ways of preventing and stopping a denial of service attack 33:53 SQL injection what it is and how it works 37:00 Ways of preventing an SQL injection 38:03 Click jacking attacks 40:02 Social engineering attacks 42:57 What is a phishing attack 43:30 Examples of a phishing attack 46:30 Social engineering and scams in our country 53:10 Closing talk Contact the hosts Henok Tsegaye Twitter Instagram LinkedIn Abdulhadmid Oumer Twitter Instagram linkedIn Follow Zemach FM and give us comment

In this episode of Syntax, Scott and Wes talk about building your own authentication — diving deep into JWT, sessions, tokens, cookies, local storage, CSRF, and how it all works! Prismic - Sponsor Prismic is a Headless CMS that makes it easy to build website pages as a set of components. Break pages into sections of components using React, Vue, or whatever you like. Make corresponding Slices in Prismic. Start building pages dynamically in minutes. Get started at prismic.io/syntax. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It’s an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We’ve also got an amazing selection of GraphQL tutorials at hasura.io/learn. Show Notes 01:51 - Overview Level Up uses a JWT & secure cookie-based authentication and tracks sessions via a db table. Accounts.js 05:13 - JWT Base 64 encoded (not encrypted) token that contains data. We have both accessTokens and refreshTokens. JWT has three parts: Header What kind of algo was used Payload Data about the user Email Username UserID refreshToken, authToken, sessionId Signature This ensures that no one monkeyed with the above parts. If you change your email in the payload, the signature is not invalid, because in order to generate the signature, it uses the header and payload as part of it. accessToken A short lived JWT that contains the sessionToken, userId and expires after 90min. refreshToken A long lived JWT that contains just the sessionToken and doesn’t expire. JWT can be decoded and read, but you have to encode them with your secret. JWT can be stored anywhere, there are two main places: 20:26 - Cookies We use httpOnly, secure cookies to store the accessToken and the refreshToken. The accessToken is a session cookie and is removed whenever the browser is closed. The refreshToken is valid for 100 days but is also re-created and revalidated for 100 more days each time the accessToken is generated. Because these are httpOnly cookies, they cannot be accessed by JavaScript in the client and can only be set and removed on the server. Note: Safari has stricter rules than others for same domain cookies (e.g. localhost won’t work). 34:26 - Sessions Sessions are when a user logs in on a device. If you open a phone and log in and a computer and log in, those will create two different sessions. A session contains information about the user’s connection (like their IP) but it also contains the userId which allows us to create new accessTokens from a valid session. Sessions can be valid or invalid. This allows us to log anyone out by setting their session to valid: false. Sessions also have sessionToken which are generated on authentication or create account. 38:10 - CORS Cross-origin-resource-sharing Can be super tricky to get working cross-domain You usually have to actually visit the website for the cookie to be set, even with lax cors 46:06 - CSRF 48:47 - Authentication process bcrypt.js 52:13 - Helper Packages NextAuth.js is super easy Passport.js auth0 Links Caddy Fastify ××× SIIIIICK ××× PIIIICKS ××× Scott: reMarkable 2 Wes: Opration Odessa Shameless Plugs Scott: Node Fundamentals Authentication - Sign up for the year and save 25%! Wes: Advanced React - Use the coupon code ‘Syntax’ for $10 off! Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

Rizqi Djamaluddin Twitter -  https://twitter.com/rizqi_djmLaravel Documents: Eloquent - https://laravel.com/docs/8.x/eloquentSQL Injection - https://en.wikipedia.org/wiki/SQL_injectionCross Site Scripting (XSS) - https://en.wikipedia.org/wiki/Cross-site_scriptingAWSTakeout - https://github.com/tighten/takeoutMinio - https://min.io/S3 - https://s3.com/NGINX - https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/HTML Purifier - http://htmlpurifier.org/Laravel Documents: CSRF Protection - https://laravel.com/docs/8.x/csrfCORS - https://en.wikipedia.org/wiki/Cross-origin_resource_sharingRate Limiting - https://en.wikipedia.org/wiki/Rate_limiting2 Factor Authentication - https://authy.com/what-is-2fa/OWASP - https://owasp.org/Laravel Slack - https://larachat.co/ Episode SponsorshipTranscription sponsored by LarajobsEditing sponsored by Tighten

Fedora arrives from the future, the big players line up behind KernelCI, and researchers claim significant vulnerabilities in Horde. Plus, Google's new dashboard for WordPress and ProtonMail's apps go open source.

An interview with Alison Gianotto / Snipe, creator of Snipe IT Snipe.net Snipe-IT @snipeyhead Editing sponsored by Larajobs Transcription sponsored by GoTranscript.com [music] Matt: All right, cool. All right. Welcome back to the latest episode of Laravel Podcast. It's been a little bit of a break for those of you who tune in to every new episode, but I've got another great interview here. As with every single one, I'm interested and excited to introduce someone to you. Some of you have heard of before, a lot of you might not know that she actually works in Laravel. Either way, it's going to be great. This is Snipe. Although in my head, you have been Snipeyhead because I feel that's been your Twitter name for a while. Real name, Alison Gianotto, but I'm probably just going to end up calling you Snipe for rest of this call. Before I go in asking you questions, the first thing I want to do is just I always ask somebody, if you meet somebody in the grocery store who you know isn't technical at all, and they ask you, "What do you do?" What's the first way you answer that question? Snipe: I say I work with computers. Matt: Right, and then if they say, "My cousin works with computers and whatever." Where do you go from there? Snipe: Well, it depends on their answer. If they say, "Do you fix computers?" I'm like, "Not exactly." If they say, "Really? What type of computer work do you do?" I say, "Well, I'm a programmer." They're like, "So you make games?" "Well, not exactly." If they say something like, "Mobile apps or web? What languages?" Then I'm like, "Okay, now I can actually have a conversation." I don't do it to be disrespectful to the person asking. It's just confusing to them, and so I like to keep it bite-sized enough that no one gets confused. Matt: If you talk to a grandma in a store who doesn't have much exposure with computers, and you say, "Well, I work in InfoSec with blah-blah-blah." Then she's going to go, "Huh?" I totally hear you. If somebody does ask and they say, "You know what? I actually work in Rails," or, "I know what a framework is." How do you answer someone when they are more technical? Let's say, somebody-- You understand that this person is going to get all the names that you drop. Where do you go from there? How do you tell someone about what you do? Snipe: I actually usually say that I run a software company. I say, "I run a small software company that basically works on open source software." Usually, they look at me like, "How do you--" Matt: How do you make money? Snipe: Literally makes no sense. [laughter] Matt: Which is where we're going to go. Let's actually go there. Snipe-IT, it's a company that has an open source product. I'm guessing that you make your money by paid support plans and hosting plans. Right? Then you also have the whole thing available for free in open source? Snipe: That's correct. Yes. Matt: Could you give us a little pitch for anybody who doesn't know what Snipe-IT is, and what it does, and who it's for? Snipe: I'm so bad at this. I'm the worst salesperson ever. Matt: Well, I'm helping you grow. [laughter] Matt: Thirty seconds or less. Snipe: If you have any kind of a company and you buy assets like laptops, or desktops, or monitors, you need to keep track of them and you know who has what, what software is installed on what. Then usually I'm like, "I've got this nailed. I've got this nailed." Then I end up saying, "It's not a very sexy project, but people need it." [chuckles] Matt: Right, right, right. You have to justify yourself in your sales. Snipe: I know it. I really do. I'm really the worst at it. People get really excited. We're going to DEF CON this year like we usually do. I'm actually bringing my whole crew. Matt: Cool. Snipe: Because I really want them to be able to experience the way people react when they realize that we are Snipe-IT because they just get so excited. I've had people run across the conference floor to give me a hug that I've never met. Matt: Wow. Snipe: It's really cool. There was another time I was talking to, I think, YTCracker on the conference floor. He introduces me to one of his friends. He's like, "Yes, she's got a IT asset management software." He's like, "Really? I just heard about one of those. That was really great." I know exactly where this is going. I'm watching him look at his phone. He's like, "Yes, I just heard about it. It's really amazing. I think through your competition." I'm just sitting there smirking and I'm like, "Okay." Totally, I know exactly where this is going, but I let him spend five minutes looking it up on his phone. He's like, "It's called Snipe It?" I just look at him like, "Hi, I'm Snipe." [laughter] Snipe: It was actually wonderful. Matt: It's one of the benefits not just of having the company, but actually naming it after yourself. You're like, "No. I'm actually the Snipe. That's me." Snipe: I'm excited to bring my crew out to DEF CON this year so they can really get to experience that first hand. Because like anything else in open source and in company support in general, a lot of times, you only hear the negative stuff. You hear about when something is broken or when something doesn't work exactly the way they want it to work. To actually get just random people coming up-- I'm getting us swag. I'm getting us t-shirts printed out. I'm super excited. Matt: I love it. There's nothing like having the opportunity to see the people who love what you're doing to really motivate you to go back and do it again. I hear that, for sure. Snipe: Definitely. Open source can be really tough with that because for the most part, the only thing that you're hearing is, "It doesn't work," or, "Why doesn't it do it do this thing?" Or people telling you how they think your software should work. To just get basically unbridled love, it really recharges me. It makes me want to work on a project even harder. Matt: Plus, the phrase unbridled love is just fantastic. [laughter] Matt: It should be in our lexicon more often. Snipe: I agree. Matt: It's asset management software. I'm imagining I've got a 500-person company, and every single person gets issued a laptop within certain specs. After it's a certain amount of time old, then it gets replaced. We're going to make sure they have the latest build of whatever, Windows and the latest security patches, and that kind of stuff. It's at the point where you don't have-- My company has, I think, 17 people right now. There is just a spreadsheet somewhere. This is when you get to the point where a spreadsheet is really missing people. People aren't getting their upgrades. People don't have security updates. My guess was the reason there was InfoSec involved in this at DEF CON is because security updates is a big piece of why that's the case. Did I assume right? Could you tell us a little bit more about how InfoSec and security are related to what you're doing here? Snipe: You're kind of right. We don't currently have a network agent, so we don't have anything that listens on the wire. We do have a JSON REST API, though. Basically, we're now working with folks like Jira, Atlassian, and we're going to be working with a JaMP API to try and basically make that stuff easier. I feel like its out of scope for us to try and build another networking agent, but we have an API. If we can just build those bridges, then it just makes it a little bit easier. Ultimately, in terms of security, the real reason why I think people in InfoSec appreciate this tool, especially given the fact that we don't have-- And some people in InfoSec actually like the fact that we don't have a monitoring agent because that actually becomes a separate problem in and of itself. Let me give you a backstory on why I created this in the first place. Matt: Please do. Snipe: Maybe that'll help explain a little bit more. I was the CTO of an ad agency in New York City. We had grown from-- I think I was employee number 12, and we were now at 60 something people. We were using a Google Sheet shared between three IT people, some of which were not necessarily the most diligent- [laughter] Matt: Sure. Snipe: -about keeping things up to date. Basically, when you've got a single point of truth that is no longer a single point of truth, it becomes a bit of a hellish nightmare. Additionally, if you're repurposing-- Because it's an ad agency, so you have a lot of turnover. You don't have any history on any particular asset if this asset is actually bad. If the hard drive on this is actually just bad and should be replaced. If this is bad hardware, then we should consider just unsetting it, and getting a brand new box, whatever. We had to move offices. We were moving our main office and also our data center. Of course, when you're trying to move a 60-person company, and servers, and everything else, the very first thing that you have to do is to know what you have. That was an enlightening experience. It basically turned out that we had about $10,000 worth of hardware that we just didn't know where it was anymore. Matt: Wow. Snipe: People got fired. This is basically before I was a CTO and before I had set up the exiting process. People had been fired or had quit and just taken their laptops with them. That's got company data on it. That was a huge, huge issue for us. I was like, "Okay, we need something that we can integrate into our exit strategy or exit process to make sure that we're reclaiming back all of the data that--" Because some of those stuff is client data. It's actually really sensitive from a corporate perspective. Also, sometimes it's customer data. It was really important to have a way to handle that a bit better. That's it. The asset part is the most important part of that software. We do have support for licenses where the cloud offering portion of that is not as fully developed. We're going to be building in a services section soon. That will describe, for example, if you had Snipe-IT as a vendor, where would we fit in this ecosystem for our customers? We don't actually have a good answer for that. We're going to be building out a services section that lets you know how much money you're paying every month, how many seats you have. Matt: That's great. That would cover not just global stuff, but also individual subscriptions like Adobe and PHP-- Snipe: Sure, sure. Matt: Cool. That's awesome. Snipe: Licenses are really hard. They're hard because you can have-- One of our customers actually has a hundred thousand licenses. Matt: Oh, my Lord. Snipe: Because you've got this notion of a software license and then a bunch of different seats. There are some licenses that have one seat, and only one seat they only ever will. Then there are ones that have tens of thousands. For example, Microsoft Suite. If you have a large company, you're going to have a lot of those licenses. One of the things I care really deeply about in Snipe-IT, and I think one of the reasons why we've been successful in this really saturated marketplace, because it is a really saturated marketplace, is that I care a lot about the users' experience. I know, for example, that our licenses section, the UI on that, the UX on that is not as optimized as it could be. That will be the next thing that we're really tackling is because it is a popular section. It's one that because of the nature of the variability of licenses, makes that a really tricky UX problem to solve. That's one of the things that I love about this work is getting to solve those kinds of problems. Matt: You're just starting to make me interested in this which means you're doing your job of the sales pitch. You said you got something you're super comfortable with. Snipe: [laughs] Matt: I always struggle-- Somebody made a joke and they said something like, "It's a drinking game for how many times Matt says 'I could talk about this for hours' during a podcast." Snipe: I did see that, yes. Matt: We're there already. [laughter] Matt: I want to step back from Snipe-IT just a little bit. Snipe It, I want to call it Snipe It now that you said that. Snipe: Please don't call it that. [laughs] Matt: I won't, I promise. Think a little bit about what got you to here, and what got you to the point where you're a name and an online persona. I saw you had some interactions with @SwiftOnSecurity the other day. Everyone got all excited seeing the two of you interacting. What was the story? I want to eventually go back to when you got into computers in the first place. First, what was the story of the process of you going from just any other person on the Internet, on Twitter, on GitHub, or whatever to being a persona that is relatively well-known across multiple communities? Snipe: I can't really answer that for you because I don't really understand it myself. Other than lots of poop jokes-- Matt: It's the best. Snipe: Yes. [chuckles] I think, probably, I've been on Twitter for a while. Also, I was on IRC for a long time. I think I'm still an op in the ##php channel on Freenode, although I don't visit there as often as I used to. I was really involved in that as I was learning PHP, and as I was helping other people learn PHP. I don't know. I've always been a mouthy broad, and I think that's probably worked because whether you like me or not, you remember me. [laughs] Matt: Yes, for sure. Snipe: I'm doing my very best to not swear on your podcast, by the way. I've caught myself at least five times that I'm like, "No, no, no." [laughs] Matt: If it happens, it happens but I appreciate it. Snipe: I'm doing my very best. I'm at a conference-- Matt: Broad was a good one, yes. All right, exactly. Snipe: Yes, I know. Yes, exactly. I was like, "B-b-b-broad." Matt: [laughs] Snipe: Which is an offensive term in and of itself, but it's still- Matt: We toned it down a little. Snipe: -better than the alternative, I think. [laughter] Matt: I love it. Snipe: I'm trying my best here, Matt. Matt: I appreciate it very much. Was it in the world of PHP? First of all, I heard longevity. I've been here for a while. That's always a big win. Poop jokes, that's also obviously big win. Give the people what they want. Snipe: I don't know if I can say dick jokes on your podcast. Matt: Well, you did. There we are. Snipe: Dick jokes are definitely big part of my repertoire. [laughs] Matt: Yes, I know. Being an interesting person, having been around for a while, but was it in PHP, and teaching PHP, and being around in the PHP world for a while, was that the main space where you came to prominence versus InfoSec, versus being open source business owner? Was it primarily in being a PHP personality where you came to at least your original knownness? Snipe: I think probably. Probably, yes. When I grab onto something, I don't let go of it. I've been doing some Perl work. I've probably started with Perl, but that was back in the days when I ran Linux as a desktop on purpose. [laughs] Matt: Oh, my goodness. Snipe: I was writing some Perl stuff. Heard about this this crazy thing called PHP which looked way easier and was way more readable, and ended up writing some-- Now, terribly insecure. I know this now, because it's like 2000, 2001, something like that. Which is for going back a ways. I had just started to put out stupid scripts like e-card scripts and things like that, because they served the need that I needed to have filled. This is a well-known secret, but I worked Renaissance Fairs for a very long time. I was guild member number four of the International Wenches Guild. Matt: What? Snipe: Yes. That's not even the most interesting thing I can tell you. Anyway, I was running their website Wench.org which now looks terrible because Facebook took over that community. I used to have interactive like sending roses to each other. Because in the Renaissance Fair community, different rose colors have different meaning. It's basically like an online greeting card thing with these built-in rose color meanings. You could pick different colors of roses and send them to people that you liked, or people you didn't like, or whatever. Having this playground of a huge community of people who-- Basically, I would post to the forums. I'd say, "I'm thinking about building this. What do you guys think?" By the time they actually answered me, I had already built it anyway. I was just like, "This looks really interesting. I want to see if I can do this." Matt: To do it, yes. Snipe: Yes, exactly. It was really, really cool to have access to, basically, a beta-testing community that was super excited about anything that I put out. It definitely stoked the fires for me, stretching and doing things that I may not have done if I didn't have a reason to do it before. Matt: Well, I love how much passion plays a part there. Not this ill-defined like, "I'm passionate about programming. That means I spend all my free time doing it," but more like-- I've noticed that a lot of people who are a little bit older had PHP-- Actually, just developers in general which is quite a few people I've had on the show. Snipe: Are you calling me old? Matt: Me too. I'm in the group too. Snipe: Are you calling me old? Oh my God. That's it. This interview is over. [laughter] Matt: You're going to burn the place down. I think those of us who started back when becoming a programmer wasn't necessarily going to make you big and rich. There's a little bit of that idea today. Go do a six-month boot camp, and then you're going to be rich or something. I think when a lot of us started-- I'm putting myself in that bucket, in the '90s and the '80s. When we started, it was because it was something that allowed us to do things we couldn't do otherwise. I don't know your whole back story, so I want to hear it, but a lot of the people I've noticed, "I was in the dancing community. I was in the video game community. I was in the Renaissance whatever Fair community." Snipe: I used to work on Wall Street. That was what I was doing before I got into computers. [laughs] Matt: Okay. Well, before I talk anymore, we need to talk about this. Tell me the story. Tell me about Wall Street, and then tell me when did you actually first get into computers? Snipe: I left high school. I was living with my sister in a tent in Montana for about nine months. Then it got too cold, our toothpaste started to freeze during the day. We were like, "F this business." We went down to Colorado because we'd met some friends at Colorado School of Mines. Stayed there for a little bit. Came back to New Jersey, and was like, "Well, I don't want to go to college. I also don't have any money for college." [laughs] There's that. I ended up waitressing for a little bit. Was waitressing, wearing my indoor soccer shoes, because I was a soccer player for 13 years. The coach from Caine College came in to eat at my restaurant. He looks at me with disdain and he goes, "You actually play soccer with those, or are they just for fashion?" Matt: Oh, my goodness. Snipe: I'm like, "Bitch, I was All-State. What are you talking about?" [laughter] Snipe: He's like, "Do you want to go to college?" I'm like, "I guess." He invited me to go to Caine College where I studied education of the hearing impaired for exactly one semester. [laughter] Snipe: I was like, "Holy crap. This is so boring. I can't do this." Not the education of the hearing impaired part. Matt: Just college. Snipe: Yes, it just wasn't my jam. I was like, "I want to move to New York." I moved to New York City. I pick up a paper, and I'm like, "Okay, I'm super not qualified to do any of these things." Basically, I was a leatherworker at a Renaissance Fair. I'd done makeup work for the adult film industry. I'm like, "Um." Of course, the easiest way to Wall Street is sales. I had the most grueling interview I've ever had in my life, because I didn't know anything about real sales compared to retail. I remember sweating so hard. I'd just dyed my hair back to a normal color. You could still see a little bit of green in it, and I'm wearing my sister's fancy, fancy suit. I have no idea what I'm actually going to be doing there. It is literally out of Glengarry Glen Ross, high-pressure sales that they're expecting from me. I'm like, "I'm 17, 18 years old. I have no idea what I'm doing." I managed to pull it out. At the very last minute, I got the job. Matt: Nice. Snipe: Was working at a place that did forex futures. Then they went out of business because the principals moved back to Argentina with all of our clients' money. That spent a little bit of time in the attorney general's office, making it really clear that we had nothing to do with it. Matt: At least it was there and not jail. Snipe: That's absolutely true. It's not that uncommon that the main traders are the ones that actually have the access to the real money. Then we started working at a stock shop. I realized I was working until six, seven o'clock at night, busting my ass all for lines in a ledger. I was actually pretty good at that job, but I also caught myself using those creepy, sleazy sales techniques on my friends and my family. When you catch yourself saying, "Well, let me ask you this." You're like, "Ah, ah." Matt: "I hate myself. Oh, my God, what am I doing?" Snipe: I know. I just realized that I hated myself, and that I didn't want to do it anymore. I quit my job. I had a boyfriend at that time that had a computer. That's pretty much it. I had done some basic programming, literally BASIC programming in high school. Matt: Like QBasic? Snipe: Yes. BASIC in high school. In fact, funny story, when I wrote my first book-- I almost didn't graduate high school because my parents were getting divorced, and I just checked out. I was good in all my classes, I just checked out. I had to pass a computer programming class in order to graduate. My teacher, who was the track coach as well, Coach Terrell, he knew me from soccer. He calls me into his office. He's like, "Alison, I've got to tell you. You just weren't here, and you know that if you don't show up, I penalize you for that. Did really well on all your tests, but attendance is not optional in this class. I just don't think I can pass you." I'm like, "I'm not going to graduate then." He's like, "All right. Well, the thing is that when you're here, you do really good work. I'm going to let you go this time, but you've really got to get your shit together." Matt: Wow. Snipe: When I published my first programming book, I sent him a copy. [laughter] Matt: That's awesome. Snipe: I wrote on the inside, "Dear Coach Terrell, thanks for having faith in me." [laughs] Matt: That's amazing, and you know he has that sitting on the shelf where everyone can see it. Snipe: Yes, yes, yes. Matt: That's really cool. Snipe: That was really nice of him. [laughs] My life would have had a slightly different outcome if I'd had to take some more time, and get a GED, and everything else just because I didn't show up to my programming class. Matt: Wow. Snipe: Anyway, I left Wall Street because I had a soul, apparently. Matt: Turns out. Snipe: It turns out, "Surprise." I totally still have one. [laughter] Matt: It's funny because you're telling me this whole story, and what I'm seeing in front of my face in Skype is your avatar. For anyone who's never seen this avatar, it's got a star around one eye, smirky, slanty eyes, looking down where you're like, "I'm going to get you." It's funny hearing you tell this story, and just the dissonance is so strong of seeing that, hearing your voice, and then hearing you talk about being on Wall Street. Obviously, I'm looking back. Hindsight is 20/20, but seeing this story turned out the way it has so far does not surprise me, looking at the picture of you that I'm looking at right now. Snipe: Mohawk people have souls too. Matt: It turns out, yes. Snipe: I got that mohawk as a fundraiser for EFF. Matt: Really? Snipe: I raised like $1,500 for EFF a bunch of years ago. Matt: You just liked it and kept it? Snipe: Yes. Once I had it, I was like, "Wait a minute. This completely fits me. Why did I not have this my entire life?" Matt: That's awesome. Snipe: Yes, there was a good reason behind it. Matt: Honestly, what I meant is actually the inverse which is that I associate having the soul-- When you imagine a soulless, crushing New York City job where you hate what you're doing, you don't usually associate it with the sense of owning who I am and myself that is associated with the picture I'm looking at right in front of me. Your boyfriend at that time had a computer, you actually had a little bit of history because you'd studied at least some coding. You said primarily and BASIC in high school. Where did you go from there? Was that when you were doing the Renaissance Fairs, and you started building that? Or was there a step before that? Snipe: No. Remember, this is back when the Web-- I'm 42. Matt: I wasn't making any assumptions about what the Web was like at that point. Snipe: I think there might have been one HTML book that was about to come out. That's where we were. If you wanted to do anything on the Web, you basically figured out how to right-click- Matt: View source them. Snipe: -and view source, and you just poked at things until they did what you wanted. There was no other way around that. I realized that I really liked it because it let me say what I wanted to say, it let me make things look-- For what we had back then, we didn't have JavaScript, or CSS, or any of that stuff. Matt: Right. Use that cover tag. Snipe: Yes, exactly. It was enormously powerful to be able to have things to say, and put them out there, and other people could see it. Then I just started to freelance doing that. I was also doing some graphic design for one of those-- It's like the real estate magazines, like Autotrader type of things but for cars. I used to do photo correction for them using CorelDraw, I think it was. Matt: Oh, my gosh, that's a throwback. Snipe: Yes. I'm an old, old woman. [laughter] Matt: I've used CorelDraw in my day, but it's been a long time. Snipe: Our hard drives would fill up every single day, and so we'd have to figure out what had already gone to press that we can delete it off. Basically, Photoshopping, to use Photoshop as a verb inappropriately, garbage cans and other stuff out of people's black and white, crappy photos. Because he was nice enough to give me a job. I offered and I said, "You know, I can make you a website." He's like, "Yes, the Internet's a fad." I was like, "I'm just trying to build up my portfolio, dude, for you for free." He's like, "Yes, yes, yes, it's not going to stick." I'm like, "Okay." [laughs] Matt: All right, buddy. Snipe: That's where it started. Then I think I moved to Virginia for a short amount of time, and then Georgia. Got a job at a computer telephony company where I was running their website, and also designing trade show materials like booths and stuff, which, by the way, I had no idea how to do. No one was more surprised than I was when they took pictures of the trade show and the booth actually looked amazing. Matt: That should look good. Snipe: I was like, "Look, yes." Matt: "Hey, look at that." [laughter] Snipe: That's very, very lucky. There was definitely a lot of fake it until you make it. Also, I've never designed a trade show booth, but trade show booths do get designed by someone, and at least a handful of those people have never done it before. Matt: Right. I'm relatively intelligent person, I understand the general shape of things. Snipe: Yes. Get me some dimensions, I'm sure I could make this work. Matt: What is the DPI thing again? [chuckles] Snipe: Yes, exactly. That was exciting and fun. Then I moved back to New York to teach web design and graphic design at an extension of Long Island University. Matt: Cool. Snipe: Yes, it was actually very, very cool. The school was owned by these two teeny-tiny Israeli ladies. They were absolutely fabulous. It was kind of a crash course in Hasidic and Orthodox Jewish culture. It was in Flatbush, so basically, 90% of my students were Hasidic or Orthodox. I think I broke every rule ever. The two owners of the school would just look at me and laugh. They wouldn't offer me any guidance. They just liked watching. Matt: Well, it would be awkward. Yes. Snipe: Exactly. I'm like, "Why would you do that to me?" [laughter] Snipe: They're just laughing. I could hear them laughing from upstairs- Matt: That's hilarious. Snipe: -when they knew I was putting my foot in another cultural mess. That was really, really fun. I learned a lot from that. I learned a lot about teaching. I even got to have a deaf student one time, which was great, except I didn't know-- I used to know or still know American sign language, but when I learned, there weren't any computer-related signs. It was actually a weird barrier that I hadn't thought about. We're like, "Okay, I can sign as I'm talking," but then I'm like, "Wait, do I have to spell all this stuff out every single time? I have no idea." That was cool. Then I started just doing HTML for a company called Cybergirl, which is not a porn site. I always have to clarify that. Not that there's anything wrong with porn, but it was not, in fact, a porn site. It was an online women's community. Matt: Cool. Snipe: They weren't really super profitable in the community itself, so they had a separate part that did websites for clients. I was put on to work mostly with their clients. They had stuff written in ASP, ColdFusion. Because the people who had designed it weren't there anymore, I basically had to learn all of these languages. Also, we only had a part time sysadmin, so when we'd hire someone new, I'm like, "I guess I'm creating email accounts for people now." I became a stand-in for a lot of different roles. Got to play with a lot of different languages, some of which I liked vastly better than others. ColdFusion? Really? [laughs] Matt: ASP wasn't that bad. There was worse things than classic ASP. Snipe: Yes, there are. That is a thing that could be said. That is an opinion one might have. [laughter] Matt: Trying to keep a positive spin on it. Snipe: I would say that all of these languages, the ones that are still around, have come a very long way since then, including PHP. Matt: Yes, yes. .NET is not a classic ASP. PHP 5, whatever. PHP 7 is no PHP 3, for sure. Snipe: Certainly. Matt: Were you using PHP at that point already, then? Was that one your-- Snipe: Yes. That was one I was-- Because I'd already done some Perl stuff, and it just wasn't that hard. One of our clients had a website, I think it was The Bone Marrow Foundation, had their website in PHP. That forced me to do a bit more legwork on it. That was the beginnings, the very beginnings. Matt: At that point, we're probably talking about single-page PHP files for each page. At the top, you've got a common.inc that you're doing your database connections. Then below that, it's just a template, right? Okay. Snipe: Functions.inc and usually some sort of PHTML. [laughs] Matt: God, PHTML, yes. Okay, all right. Snipe: I told you, I am an old, old lady. Matt: Honestly, we worked on a site that still used PHTML and things like four or five years ago. I was like, "I didn't even know that PHP parser is still allowed for this." Apparently, some of these things still stick around. Snipe: Whatever you set as your acceptable file formats, it'll parse. Matt: Yes, you can make it happen. Snipe: I can have a .dot site file extension if I wanted to. Matt: I like that idea now. Jeez. When was the transition? What were the steps between there and ending up where you are now? Are we still many steps behind, or did you get out on your own pretty quickly after that? Snipe: I was doing some contract work. Thanks to a friend that I'd met through IRC. I was doing some contract work for a company out in San Diego. They were an ad agency. This is the beginning of the days when marketing companies were trying to own digital, and they were trying to build up their digital departments. They moved me out there because they're like, "You're amazing, so come on out here and build up our team." I did. I built up their team. We had some really cool clients. We had San Diego Zoo, San Diego Padres, California Avocado Commission. At that time, I didn't like avocados. I was giving away free avocados that I did not like. Matt: [chuckles] Oh, no. That's so good. Snipe: I hate myself now for knowing how many avocados I could have had. [laughs] I got to build lots of custom web apps, all the database-y stuff. That was really fun. I left there, started my own web design company for lack of a better term, where I was basically using PHP, but also pretending like I knew how to design anything at all. Sorry, hang on. Incoming call. Building my own custom applications for people. None of it is really that fancy, but whatever. That was fun. Then I broke my foot. This is before the ACA, and so I had no insurance. Thousands of dollars and a spiral fracture later, I'm like, "Maybe I should get a real job." [laughter] Snipe: I started to work for the San Diego Blood Bank, which was a great gig. It's probably my favorite job. The pay wasn't that great, but my coworkers were great. Your hours were your hours. There was no overtime. If you had to work overtime, you got paid double time and a half, something like that. It was insane. Matt: Especially compared to the ad agency world, which is basically the exact opposite. Snipe: Yes. Yes. There's no amount of blood you can show to prove that you're loyal to that particular market. I ended up moving back to New York and ended up working for the Village Voice for a little while. Matt: Really? That's cool. Snipe: Yes, that was cool. Unfortunately, they had already been bought out by Newtimes, and so they were not the Village Voice that I grew up with, the one that warmed the liberal cockles of my heart. It was actually a crap place to work, to be honest. People were getting fired all the time. There was this one guy, he used to hang out in the archives room with an X-Acto blade and a piece of paper and would just cut at the piece of paper. He was actually scary. Everyone was afraid of him, because that's office shooter kind of crazy. Matt: Exactly, exactly. Snipe: I left there, finally, and worked for another ad agency. That's the one that I was working at when I finally started to work with Snipe-IT. Finally started to make Snipe-IT. For a while, while I was in California, the nice thing about running your own gig back then, because it was like a one-man shop, so I didn't have people that I had to worry about. I got a chance to work with tigers for about a year. It was just exhausting. That was around the time when I was writing my book, too. Working with tigers, commuting four hours a day, coming home stinking like raw chicken and tiger pee. Then working on my book, and then whatever I can possibly eke out for customers. It was pretty chaotic and definitely exhausting, but they were good times. Matt: I don't want to preach too far on this, but I feel like the more of our story that takes us around different aspects of life and different experiences, the more we bring to the thing we're in right now. That's one of the reasons I keep pushing on people having histories before they came to tech or diverse histories in tech. It's not to say that someone who just graduated from college and instantly got a job as a developer is therefore now incomplete, but I think that a lot of what makes a lot of people interesting is what they bring outside. That's true for anybody, right? What makes you different from the people around you makes you different, and makes you interesting, and it makes you have a perspective to be able to bring that the people around you don't. It sounds like you have quite a few of those, at least as you enter into the communities that I'm asking you from the perspective of whether PHP, or Laravel, or anything like that. I don't know where I'm going with that, but anyway. Snipe: [laughs] Matt: That's very interesting to hear. Snipe: I always say I sound really interesting on paper. I'm not really that interesting to talk to, but when you actually look at all the crap I've done, it's like, "Wow. That's kind of a lot." Matt: Right. That is a lot going on. Snipe: It's all weird. Weird stuff. Matt: If I remember right, the book that you wrote was a Wrox PHP book, right? Snipe: Yes, yes. You can still get it on Amazon, but it costs more to ship. Matt: Really? I got to-- Snipe: Actually, I'm not sure. It may just be eBay. The last time I checked, it was selling for $2.95 and costs like $80 to ship. [laughs] Matt: Professional PHP4 Web Development Solutions. Snipe: Yes. Matt: I don't see a Mohawk. I don't know which one's you. Snipe: No, no. Matt: [laughs] Snipe: Yes, I know. Gosh, it's a mystery of the ages, isn't it? [laughs] Matt: All right. Yes. $22.99. Wow. What was your experience like writing a book? Would you do it again? Snipe: Possibly, but I would need a bit more written assurances up front about how-- This is a co-authored book. Basically, we were not given communication information with each other. We were writing these chapters completely independently and it sucked. I offered to set up a bulletin board just so we could-- For some reason, they didn't want us talking to each other or something. I don't know, but I was like, "Because I don't know where this chapter is going to fall, I want to make sure that I'm not rehashing a thing that's already been discussed, or touching on something that needs more information." They never facilitated that. They actually pushed back against it. It was really frustrating. You're literally writing chapters in a vacuum that then have to be cohesive when you string them all together. I would need to know if it was going to be a co-authorship. I would need to know that this will truly be collaborative. Because the way it looks on the cover, it looks like we're all hanging out. No, I don't think I've ever spoken to those people ever. [laughs] Matt: Wow. Jeez. Snipe: It's really weird. It's really weird. I did not like that. I thought that was really just not a way to give the best experience to the reader. If I was going to collaborate, I would have to make sure that there was something like that. I've toyed with writing a couple of books over the last few years. It is also a bit of a time suck. Matt: Yes, it is. My perception, what I've told people in the past is that people often ask me, "Should I write a book with a traditional publisher like you did?" Because mine was with O'Reilly. "Or should I self-publish like a lot of the people in our community have?" My general perception has been, if you want to make money, self-publish. Snipe: Definitely. Matt: If you want reach that's outside of your current ability, then consider a traditional publisher. You've got quite a bit of reach and I wonder whether it's-- Snipe: This is like 2003, though. Matt: I don't mean for them, but I mean now. If you're going at it now. It seems like there'll probably be less of a reason for you to do a traditional publisher at this point. Snipe: I don't know, though. I still kind of O'Reilly. Matt: You still like it? Snipe: Being a published O'Reilly author, I still toy with that, honestly. Matt: I tell people I got a degree in secondary English education, basically. This O'Reilly book is my proof that I'm actually a real programmer. Snipe: [laughs] You know what? Honestly, that was really important to me back then. Snipe: Me too, really. Matt: I don't know where things would have gone, I don't know if I would have-- I probably would have stuck with it because I really, really liked it. I think that gave me a bit of confidence that I really needed. Proof, again, because I didn't graduate college. I nearly didn't graduate high school because of the programming class. [laughs] It was a way for me to say not just to the rest of the world, but to myself, like, "Hey, I actually know what I'm talking about." Matt: You can't underappreciate just how significant that is. I love that you said it. It's not just to everybody else, it's to you, too. Snipe: More than anyone else, to myself, honestly. I don't care what you guys think. [laughs] Matt: I spent several thousand hours writing a book with a major publisher so that I can overcome impostor syndrome. It's totally worth it. [laughter] Snipe: I still have it. That's a thing, I have it. Matt: I still have it, but maybe a little less. Snipe: At least if someone actually pushes the impostor syndrome too far, I'll be like, "I wrote a book. What have you done?" Matt: Exactly. Snipe: Meanwhile, I go off and rock in the corner as if, "Oh, my God. I don't deserve to be here. I don't deserve to be here." Matt: Exactly. It certainly doesn't make it go away, but maybe it's a tool in our arsenal to battle it. Snipe: That's a very good way to describe it. Matt: I like it. Snipe: I would need that to be a bit more of a tighter process. Matt: Well, if you decide to write with O'Reilly, I know some people. Just give me a call. Snipe: [laughs] I also know some people in O'Reilly. Matt: I was just going to say I'm pretty sure you don't need me for any of that kind of stuff. I just had to say it to try and seem like I actually matter, so this works. Snipe: Of course, you matter. Matt: I matter. Snipe: I got up early for you, Matt. I got up early for you. Matt: That's true. Snipe: You don't have any idea. Matt: That's true, this is quite early your time. I appreciate it. Snipe: [laughs] Matt: I'm trying to not talk forever. I'm trying to move us on even though I'm just my usual caveats, everyone take a drink. You eventually started Snipe-IT. I think we skipped a couple of things. We were talking about you becoming the CTO of the ad agency and being in a place where you needed to manage that kind of stuff. You started Snipe-IT. You now have a remote team. Could you tell me a little about the makeup of your team, and what it's like running a remote team, and the pros and cons you've experienced, and anything else that you would want to share about what that experience is like for you? Snipe: Well, I'm really lucky, first of all, because although our team is remote, we're all also local. We can actually see each other, we'll go out and have beers when we hit a major milestone. We'll go out and have some champagne and celebrate that we do get to see each other's faces. Also, we were friends first, so that helps. It's totally, totally different. If you're looking for advice on how to run a real remote team, that I can't help you with. I can't tell you how to manage your friends through Slack, though. [laughs] Matt: Basically, you and a bunch of friends live like an hour driving distance to each other or whatever and choose to work from home? Snipe: More like seven minutes. [laughs] Matt: Jeez. Snipe: Yes, yes. Matt: Okay, so this is really just like, "We just don't feel like going to an office," kind of vibe. Snipe: It's pants, it's pants. I'm not putting on pants. I've worked too hard in my career to have to put on pants anymore. There is a reason this isn't a video call, Matt. Seriously. [laughter] Matt: I wish that this was one of the podcasts-- Snipe: I think I just made Matt blush, by the way. Matt: I wish this was one of the podcasts where they name each episode, because that would have been the name right there for this episode. I might have to, just for this one, just give it a name just for that. Okay. I hear you. I get it. Snipe: The thing is I hadn't actually planned on hiring when I did. The reality is I should have, because I was really buckling under the helpdesk. That customer support load was a lot. It was causing me a great deal of anxiety. Looking back at it now, it was really untenable. Of course, I think that I'm 10 feet tall and bulletproof, so I'm like, "I got this. I got this." Meanwhile, it's four o'clock in the morning and I can't even see straight anymore. I ended up having to hire someone for a personal reason. She's actually worked out great. She's an absolute rock star on the helpdesk. She's never worked a helpdesk before, and she owns it. It's actually really, really great. Once I'd hired her, I think-- The onboarding takes a little bit. Especially, literally never worked a helpdesk before, so it's not just onboarding with my company, it's like onboarding the entire concept. As soon as she got her footing, she just completely handled it. It was really great. The next hire was a developer/sysadmin that I've known for a while. He is just fantastic. He's actually the harder one because he, I think, requires a little bit more structure, and a little bit more face time. I need to be better. I do. I need to be better about working with that because in my head, I'm still managing this the way that I want to be managed. I forget that that's actually not my job anymore. Matt: People are different. Snipe: Yes, people are different. Also, not everybody wants what I want. Frankly, it doesn't matter what I want. Ultimately, that's no longer a luxury that I have, caring more about how I want things to go for myself. That priority has shifted, and so I'm having to painfully learn [chuckles] that lesson. Not painfully. I love my entire team. They're absolutely amazing. I'm super, super grateful for them every day that goes by. Every time one of them takes vacation, we all hold on to our desks. We're like, "Okay, we can get through this, we can get through this." It's a learning curve, certainly. I've run my own small business, I've run dev teams. This is a different thing though, because the reason why I wanted to make this a company instead of just running this as a side project is because I've worked for tons of shitty companies. I want to build the company that I wish I'd worked for. Matt: I'm so sorry for doing this, but I was doing that thing where you're hearing somebody talking and waiting for your chance to talk. I literally was about to say Dan and I, when we started Tighten, the first thing we said was, "We want to build the company we want to work for." You just said and I'm like, "Exactly." That introduces the problem you're talking about, which is you just assume everybody wants the same things you want. It also means nobody else gets to force you to put people through things that you wouldn't want to be put through. It's an incredible freedom if you can make it profitable. Snipe: Yes. Absolutely. Getting to institute stuff that I think is really worker-friendly. We all make our own hours. We have office hours so that when Victoria's handling the helpdesk, she's got access to the text that she needs during a certain amount of time. In general, she's got a kid. We have to have that flexibility, so that she-- Honestly, she just lets us know that she's going to pick up her kid. It's like, "Okay, cool. See you back in half an hour or whatever." Vacation, she had not had a real vacation in probably 10 or 15 years. Last year, we were like, "You are taking vacation." She kept checking into Slack. I'm like, "Girl, I will actually revoke your credentials." Matt: [laughs] Exactly. Snipe: Do not play with me. Matt: I love it. Snipe: This year, I've decided that there's two weeks basically mandatory vacation, and we're going to put $3,000 towards each person's vacation funds- Matt: That's cool. Snipe: -so that they can actually go and do something awesome, and relaxing, and not stress about money while they're there, and just get to go and actually enjoy things, and come back refreshed and ready to work. It's pretty cool being able to come up with stuff like this and really like, "What would I have needed?" Because when I was working at the ad agencies especially, I would accrue my PTO. Honestly, that's why Snipe-IT existed. It was because I had two and a half weeks, three weeks of PTO that was not going to roll over. They made me take vacation in November. They wouldn't let me do it in December. They made me do it in November, and I was like, "Yes, three weeks of just relaxing, playing video games." That didn't work. I accidentally the product. [laughs] Now, I accidentally the business. Matt: That's awesome. One of the things I often talk about as an entrepreneur, as a business owner is something that I think people are scared of talking about, which is power. Because being a business owner means you get to hire, you get to figure out how money is spent, you get to figure out what pressures are and are not put in the people you work with. I call that power, but I think power doesn't have to be a scary word because, really, what matters is what you do with the power. When we hear power as a negative thing, it is usually because the people on power are benefiting themselves. I think that something is really beautiful, and wonderful, and we need more of in the world is when we can see power as a positive thing, because people get power and then use it for the benefit of other people. I just want to applaud and affirm what you're doing, because you just described that. It's like, "I got power, and the first thing I did was work to make other people's lives better understanding what the situation that they were in was." I love hearing that. I'm really glad that we got to talk about this today. Snipe: Well, thank you. I'm looking forward to coming up with more stuff like that. Matt: I love it. Snipe: It's super important to me. Our customers are incredibly important to us, obviously, but my staff is as important. You can't have one without the other either direction. Matt: In the end, they're just both people who you work with. The hope is that you're able to make both groups of people really have lives that are better because they had a chance to interact with you. Snipe: Yes, absolutely. Matt: Okay. We are almost out of time. I asked people at Tighten if they had any questions for you. They gave me a million, and I haven't gotten any of them. They're all going to be mad at me, so I'm trying to look at the one that I could pull up that won't turn into a 30-minute long conversation. Snipe: I'm Italian. There is literally nothing you can talk to me about that won't turn into a 30-minute conversation. [laughs] Matt: All right. I'll literally go with the question that has the least words in it and see if that gets us anywhere. Coffee or tea? Snipe: Red Bull. Matt: There you go. See how short that was? All right. Snipe: This podcast is sponsored by Red Bull. [laughter] Matt: It's so funny that it's been the thing at Tighten for the longest time, where those of us who started the company and the first hires were primarily coffee people. There's one tea holdout, but over time, the tea contingent has grown. Just within the last nine months, we hired two people who are Red Bull addicts. All of a sudden, we're shopping for the company on-site and they're like, "Orange Red Bull, no sugar, energy, blah, blah, blah." I'm like, I have a course in Red Bull flavors. Anyway, I still think it's pretty gross, but I did try some of them. Snipe: It's disgusting. No, it is utterly vile. It is really, really gross. [laughter] Matt: I don't get it. Please pitch me on why I would drink red Bull instead of coffee then. Snipe: No. If you don't drink Red Bull, then there will be more for me. First of all, I'm not going to pitch that. Matt: World's dwindling storage of Red Bull. Snipe: Obviously, we buy our stores out of local Red Bull, it's ridiculous. We have a main store, and then we have a failover store. Listen, you don't drink it because it tastes good. It tastes like dog ass, but it wakes you up. It keeps you awake. It feels the same role that coffee does, and frankly, I don't think that coffee tastes that good. Matt: Okay. Fair enough. Snipe: I can ask the same question to you. Matt: Right. For you, it's a combination. You don't like the flavor of either, but one of them you can buy in bulk and throw in the fridge? Snipe: Yes, yes. Matt: Got it. I get that. I love the flavor of coffee, but I'm like a geek. I have all the equipment, and all that kind of stuff. Snipe: Of course, you do. [laughter] Matt: Am I predictable? I am predictable. Okay. Snipe: I will neither confirm nor deny. My lawyer has advised me. [laughs] Matt: Not to make a statement on this particular-- I have one more and I'm praying that I can make it short, but I probably won't. You are a member of the Laravel community. You use Laravel. You share things every once in a while, but for someone who is such a big name, who's a member of the Laravel community, much of your popularity is not within the Laravel community. You're not popular because you're speaking at Laracon, you're not creating Laravel packages that all the people are consuming. It's this interesting thing where you're a very well-known person who uses Laravel and is a member of the Laravel community but is not necessarily gaining all that fame within Laravel space. It's an interesting overlap. As someone who does have exposure to lots of the tech communities, you're in the InfoSec world, you've been in PHP for a while, but you're also solidly Laravel. Do you have any perspectives on either, maybe the differences between InfoSec and PHP, differences between InfoSec and Laravel, and/or is there anything that you would say to the Laravel community, or things you'd either applaud or hope to see grow? Is there anything you just want to say about the way Laravel compares, or connects, or overlaps, or whatever with the rest of the world that you're in? Snipe It's always an ongoing joke in the InfoSec community. PHP developers are pretty much the easiest punching bag in the InfoSec community. Matt: And everywhere else. Snipe: In fact, I think just yesterday, I submitted an eye-rolling gift in relation to someone at InfoSec, bagging on PHP developers. I get it. When the language first came out, it was really easy to learn. You didn't need to have any knowledge of programming, or discipline, or best practices. There were no best practices for quite some time in PHP. I totally get that. The thing is that that's not really the world that we live in anymore. It's actually hard to write a PHP application without using a framework these days. Because the frameworks are so much better and it's so much faster, that for me, I'm pretty sure I could still write a PHP application without a framework, but why the hell would? If I ever have to write another gddmn login auth routine, I'll kill myself. I will actually kill myself. Comparing InfoSec to PHP or Laravel is like comparing apples to orangutans. They're entirely different animals and there is a little bit of overlap, but typically not. In general, PHP has a bad reputation in InfoSec. In fact, I will tell you a very brief story about how I got into InfoSec. This one's always a fun one. I used to run a nonprofit organization when I moved to California the first time. It was basically like Megan's Law for animal abusers. Criminal animal abuse. I would pull in data, break it down statistically based on a couple of different pointers like domestic violence connection, blah blah blah blah blah, and basically run statistics on that stuff. This was going back a very, very long time when nobody really knew or gave a crap at all about AppSec. At one point, my website got hacked. The organization's website got hacked. I am literally on my way to speak at a conference in Florida, an animal welfare conference. I'm checking in. I'm like, "Hi, I'm Alison Gionatto. I'm a speaker." She goes, "You're petabuse.com. That's great. I'm so sorry to hear about what happened." I'm like, "I've been on a plane for a couple of hours." I'm like, "Wait, what?" [chuckles] I run to my hotel room, and somebody has defaced the website with an animated GIF, and a song playing in the background which was basically a clip from Meetspin, and they linked to Meatspin. If any of your listeners don't know what Meatspin is- Matt: I don't. Snipe: -please do not Google that. You can google it, but have safe search on. Matt: Is it like Goatse kind of stuff? Snipe: Yes. "You spin me right round, baby, right round" playing in the background on autoloop. To this day, when I hear that song, I shiver a little bit. Matt: Trigger, yes. Snipe: Exactly. I ended up actually talking to this guy who thought that we were a much bigger organization than we were. He was trying to extort money, of course. I was like, "Dude, you have you have no idea. We get like $800 in donations every month. You are barking up the wrong tree." He's like, "I thought you were bigger. I'm sorry, but it is what it is." I toyed with him long enough to figure out what he had done. The thing is, this is on a Cobalt RaQ server. First of all, we're going back. Second of all, those are not exactly going for their security, but it was what I could afford. Honestly, it's what I could afford. I figured it out, I locked him out. I did leave him one final kind of F you text. [laughter] Snipe: Just so that he knew. That was how I got into this in the first place was basically a horrific, horrific internet meme and the defacement of my organization's website. Again, this is 2004, 2005. Application security became really important to me, and that's why I'm here. [chuckles] That's why I go to DEF CON. That's why I speak about application security and security in general. To get back to your original question, there isn't really an overlap. There is this disdainful relationship, for the most part, coming from both directions because InfoSec people don't typically treat programmers in general very well, but especially not PHP developers. PHP developers are tired of getting shit on, and so they don't necessarily treat-- It becomes a bit of a self-fulfilling-- Matt: Impostor, yes. Exactly. Snipe: Honestly, it's all just a bunch of dumbass egos and it's stupid. If we would just talk to each other a little bit more, we'd probably be a little better off. Matt: Come on, somebody. You'll be surprised to hear that I could talk about InfoSec and PHP for an hour, but we're out of time. I don't know if I'm going to have you back sometime or I don't know what, but this's been amazing. I really appreciate you spending some time with me. Before we cut off for the day and I cry because of all the topics I'm not going to cover, is there anything you wanted to talk about? Anything you want to plug, anything you want to cover, anything you want to say to the people that we haven't got to cover today? Snipe: Nothing that really comes to mind. I am still really passionate about AppSec. If you're using a framework and you're not utilizing all of the security stuff that's built in already, specifically Laravel is really good with that. I've had write some Middleware to add some additional CSP headers and things like that. If you're already paying the price, the overhead of using a framework, then freaking use it. Actually use all of the bits that are good, not just the bits that you don't feel like writing. Laravel makes it really hard to avoid the CSRF tokens. You'll actually have to go out of your way to disable those. I like that about Laravel. I like that it's opinionated. I like that it doesn't want you to screw this up. That said, any developer left to their own devices sufficiently motivated will still screw it up. Matt: Will screw something up, yes. Snipe: Yes, Exactly. Frameworks like Laravel, I think once that are headed in the right direction, so your default login already uses bcrypt to hash the password. You would, again, have to go out of your way to write something that would store something in cleartext or MD5. I think it's a step in the right direction. Use your frameworks, learn what their built-in security functionality is, and use them. Matt: Use it. [laughs] Snipe: One of the packages I'm actually writing for Laravel right now is an XSS package which will basically walk through your schema, and will try and inject rows of XSS stuff in there so that when you reload the app and if you got to any kind of functional testing or acceptance testing setup, you'll be able to see very quickly what you've forgotten to escape. Matt: I love it. Snipe: For a normal Laravel app, that's actually hard to do because the double braces will escape everything. For example, if you're using data from an API, maybe you're not cleaning it as well or whatever. That's one of the packages that I actually am working on. Matt: That's great. Also, if you're using JavaScript, it's really common for people to not escape it, and so that all of a sudden, they forget to clean it. Snipe: Exactly. I wanted one quick way to basically just check and see how boned I was. That'll be fun. Matt: Yes. Does it have a name yet that we can watch for or would you just link it once you have it? Snipe: Well, the only name-- You know how the mocking data packages called Faker? You can imagine what I'm considering calling this that I probably won't call it? [laughs] Matt: Probably won't, but now we can all remember it that way? Yes. Snipe: No promises. Absolutely no promises is all I'm saying. [laughs] Matt: Assuming it's safe for work, I will link the name in the show notes later. If not, you could just go-- [crosstalk] [laughter] Snipe: Again, no promises. Matt: I like it. Okay. You all have taken enough drinks, so I won't say my usual ending for you to drink too. Snipe, Alison, thank you so much. Thank you for the ways you have spoken up for a lot of things that really matter both in this call and our community as a whole. Thank you for hopefully helping me but also our entire community get better going forward, but also the things you brought to us in the past in terms of application security. I don't know why I didn't say this earlier, but Mr. Rogers is maybe one of my top heroes of all time. That was what was going through my mind when you were talking about running your company. Thank you for being that force both for running companies that way and taking care of people, and then, of course, by proxy for just the people who you're working with. The more people that are out there doing that, I think the better it is for all of us. This has been ridiculously fun. If anyone wants to follow you on Twitter, what's your Twitter handle and what are other things they should check out? That URL for Snipe-IT? I will put all of these in the show notes, but I just wanted you to get a chance to say them all at the end. Snipe: My Twitter handle is @snipeyhead, because @snipe was taken. I'm still pissed at that guy. [laughter] Snipe: The URL for Snipe-IT is snipeitapp.com. Not very creative. All of our issues are on GitHub. Your pool of requests are welcome. [laughter] Snipe: As always. Matt: Nice. Snipe: It is free. If it helps you solve some of your problems at your organization, we would love for you to try it out. If you'd like to give us money, that's awesome too. Ultimately, the more people who are using it, the better. Matt: Nice. Okay. Well, thank you so much for your time. Everyone, check out the show notes as always. We'll see you again in a couple of weeks with a special episode. I'll tell you more what it is when that one happens. See you. Snipe: [chuckles] Thank you so much, Matt.

Justin and Jason discuss getting into Forrst, why arguments tend to escalate when conducted via text, Justin's struggle with his Man on a Wire post, the dynamics of CEO compensation, using form tokens to prevent CSRF attacks, the possibility of moving Pluggio to the enterprise, Justin's surprising experience with Facebook adds, whether Jason should get an iPhone or an Android phone, spooky experiments that see the future, the impact of technology on political freedom, how Jason is teaching his 6-year old son HTML, server and client-side HTML rendering, migrating off Google App Engine and building a workflow engine in Appignite.