Sign up

An open source list of de­vel­oper ques­tions to ask prospec­tive em­ploy­ers

This com­mit does not be­long to any branch on this repos­i­tory, and may be­long to a fork out­side of the repos­i­tory.

Use Git or check­out with SVN us­ing the web URL.

Work fast with our of­fi­cial CLI. Learn more.

If noth­ing hap­pens, down­load GitHub Desktop and try again.

If noth­ing hap­pens, down­load GitHub Desktop and try again.

If noth­ing hap­pens, down­load Xcode and try again.

Your code­space will open once ready.

There was a prob­lem prepar­ing your code­space, please try again.

Permalink

An open source list of de­vel­oper ques­tions to ask prospec­tive em­ploy­ers

You can’t per­form that ac­tion at this time.

You signed in with an­other tab or win­dow. Reload to re­fresh your ses­sion.

You signed out in an­other tab or win­dow. Reload to re­fresh your ses­sion.

I’ve had my fair share of App Store re­jec­tions in the past:

But I was­n’t pre­pared to be re­jected be­cause my app is “not good enough” for the App Store.

I tried to launch a sim­ple, no-frills iOS app for party-go­ers and mu­sic fes­ti­vals in 🇷🇴 Romania.

The back­end would be a sim­ple Google Sheet which my brother would up­date daily with cu­rated un­der­ground par­ties and the usual fes­ti­vals.

My brother is not a pro­gram­mer, so en­ter­ing data had to be as low tech as pos­si­ble.

So ok, I did a ba­sic SwiftUI im­ple­men­ta­tion where I fetch the .csv of the sheet, mas­sage that data into a grid of events, and add the fol­low­ing use­ful iOS fea­tures:

* Add to Calendar but­ton (which uses EventKit to fill in the URL, Location, End Date fields au­to­mat­i­cally, and adds the nec­es­sary re­minder alerts)

* Get di­rec­tions but­ton (which gives you a Google Maps link to the ex­act co­or­di­nates of the event. Super use­ful as some events are in forests or places where the ad­dress is not enough)

* Buy tick­ets but­ton (which should al­ways point you to the cor­rect web­site to get tick­ets from)

All of the above are only pos­si­ble be­cause my brother spends hours of his time every day to look for event lo­ca­tion, co­or­di­nates, ticket web­site, FB/IG/Official web­site links. Info which is not read­ily avail­able on a sin­gle in­ter­net web­page.

Then I cre­ated a sim­ple web­site at sub­sol.one and sent the app to App Store re­view.

After days of wait­ing, I got the most stu­pid re­jec­tion I ever read:

We no­ticed that your app only in­cludes links, im­ages, or con­tent ag­gre­gated from the Internet with lim­ited or no na­tive iOS func­tion­al­ity. Although this con­tent may be cu­rated from the web specif­i­cally for your users, since it does not suf­fi­ciently dif­fer from a mo­bile web brows­ing ex­pe­ri­ence, it is not ap­pro­pri­ate for the App Store.

We en­cour­age you to re­view your app con­cept and work to­wards cre­at­ing an app that of­fers cus­tomers an en­gag­ing and last­ing ex­pe­ri­ence that also meets the App Store’s high ex­pec­ta­tions for qual­ity and func­tion­al­ity.

So the app does not suf­fi­ciently dif­fer from a mo­bile web brows­ing ex­pe­ri­ence. Ok. Fair enough.

I thought the app is use­ful enough as it is for now.

Considering that the iOS App Store still can’t get rid of so many scam apps which are even used for ex­tor­tion and black­mail, I re­ally did­n’t un­der­stand how this was an ac­cept­able rea­son for a re­jec­tion.

The app is sim­ple, fast, does what it says with­out any BS un­needed com­plex­ity. I thought sub­se­quent fea­tures would be added based on what the users would ask for.

But sure, let’s add some pre­ma­ture iOS na­tive fea­tures for Apple:

* Push Notifications: so you can know in­stantly when new par­ties are found

* User Location: used for sort­ing by how close the events are to you, and for no­ti­fy­ing only on events near you

* Share but­ton: for shar­ing Universal Links to events with other peo­ple

Still, af­ter even more ag­o­nis­ing days of wait­ing, the same re­jec­tion came along.

I added more iOS fea­tures, be­cause why not:

* Events on the map: to vi­su­ally as­sess where each event is hap­pen­ing in the coun­try

This was sur­pris­ingly easy to do in SwiftUI, I was amazed my­self

* This was sur­pris­ingly easy to do in SwiftUI, I was amazed my­self

* Homescreen wid­gets: ut­terly use­less, but can’t get more iOS-y and less we­bapp-y than this, right?

Three more days of Waiting for re­view and, as be­fore, an­other re­jec­tion with the same generic mes­sage. This time I had to ask, what the heck did they want from me?

I sent the fol­low­ing mes­sage to the App Store re­view­ers:

What ex­actly do you need for this app to be ac­cepted? I have peo­ple ask­ing for it, it’s al­ready done and these re­jec­tions are keep­ing them from us­ing the app.

It al­ready uses the fol­low­ing na­tive iOS func­tion­al­i­ties:

Push Notifications on new events (this is not pos­si­ble on the web in iOS)

Getting user lo­ca­tion us­ing CoreLocation and sort­ing events by how close they are

Uses the above two func­tions for no­ti­fy­ing only on new par­ties within 30km of the user lo­ca­tion (again, not pos­si­ble to do such a thing in a web app)

Shows the events on the na­tive iOS MapKit UI

Uses a cus­tom URL scheme (subsol:) and Universal Links for easy shar­ing of par­ties

Has home­screen wid­gets for view­ing the lat­est events

Allows the user to add the event to cal­en­dar with most fields al­ready filled in (event lo­ca­tion, when it ends, use­ful URLs etc.)

And all I got was an­other generic re­sponse:

Thank you for your re­sponse. We en­cour­age you to con­sider ways to make your app stand out.

We un­der­stand that it can be dif­fi­cult to de­ter­mine what the best ex­pe­ri­ence is to of­fer your users.

While there is­n’t one set an­swer that works for every app, the fol­low­ing iOS de­vel­op­ment videos of­fer great in­for­ma­tion for help­ing un­der­stand how your app can pro­vide a great user ex­pe­ri­ence: — Essential Design Principles — Design Tips for Great Games

You may also want to re­view the Human Interface Guidelines avail­able on Apple Developer.

I con­sid­ered us­ing some more de­vice sen­sors to jus­tify the app be­ing an app.

I even did a par­al­lax an­i­ma­tion (because I thought it looked cool and it uses the ac­celerom­e­ter) and added one of those Taptic Engine but­ton-like vi­bra­tions on click­ing on the event im­age.

But I think they just don’t like the idea of the app, and no mat­ter what I add to it, they won’t ac­cept it.

I re­cently saw a Lack Rack—an in­ex­pen­sive Ikea Lack table put to use rack­mount­ing servers—and now I keep run­ning into them. Pictured above is Paul Curry’s £5 ex­am­ple, re­plete with vinyl wood tex­ture.

They need lit­tle ex­pla­na­tion: Ikea makes a cheap lit­tle table whose legs are ex­actly 19″ wide and (barely) sturdy enough to ac­cept screws and the weight of most rack­mount equip­ment. (I would­n’t chance a loaded Apple Rac in it). Here’s an or­phaned photo posted to red­dit fea­tur­ing a typ­i­cal ex­am­ple:

Eth0 en­ter­tains a spec­i­fi­ca­tion and of­fers a fan­tas­tic IKEA-style ma­nial for the Lack Rack. The most no­table rec­om­men­da­tion: use cav­ity screws to in­crease the load-bear­ing strength of the mostly-hol­low legs if you’re putting in ma­chines more than 5cm down from the table­top.

Its low-cost and per­fect fit are great for mount­ing up to 8 U of 19″ hard­ware, such as switches (see be­low), or per­haps other 19″ gear. It’s very easy to as­sem­ble, and thanks to the de­sign, they are sta­ble enough to hold (for ex­am­ple) 19″ switches and you can put your bot­tle of Club-Mate on top! Multi-shiny LackRack can also be painted to your spe­cific pref­er­ences and the air­flow is un­prece­dented!

And of course the table­top is per­fect for plac­ing a mon­i­tor or lap­top, like the one in Frank Denneman’s lab:

Things some­times get quite out of hand.

Shazam turns 20 to­day, and as of this week, it has of­fi­cially sur­passed 70 bil­lion song recog­ni­tions. A main­stay in pop­u­lar cul­ture, the plat­form has changed the way peo­ple en­gage with mu­sic by mak­ing song iden­ti­fi­ca­tion ac­ces­si­ble to every­one. For more than 225 mil­lion global monthly users, to “Shazam” is to dis­cover some­thing new.

To mark the oc­ca­sion, Shazam in­vites fans to take a trip down mem­ory lane with a spe­cial playlist com­prised of the most Shazamed song of each cal­en­dar year for the past 20 years. Featuring every­thing from Train’s “Hey, Soul Sister” to Sia’s “Cheap Thrills,” the playlist is a true re­flec­tion of the mu­sic fans across the globe ac­tively searched for over the past two decades. Listen now ex­clu­sively on Apple Music.

Over the years, Shazam’s global charts have played a cru­cial role in help­ing to iden­tify break­ing new tal­ent like Masked Wolf, who was one of Shazam’s 5 Artists to Watch in 2021 and ended up hav­ing the most Shazamed track glob­ally that year with “Astronaut In The Ocean.”

“The fact that peo­ple all over the world took time out of their day to pull out their phone and Shazam my songs is a huge honor for me as an artist,” said Masked Wolf. “You know you’ve got some­thing spe­cial if you see the Shazam stats mov­ing.”

Shazam’s charts have also be­come a barom­e­ter for un­ex­pected pop cul­ture mo­ments. Kate Bush’s 1985 song “Running Up That Hill” be­ing fea­tured in “Stranger Things” led to an all-time peak in Shazams of the singer, and the track took No. 1 on the Shazam Global Top 200 for 10 days. It ended up reach­ing the top of 25 na­tional charts — more than any other song in 2022.

Keeping its fin­ger on the pulse of mu­sic, Shazam has also played a key role in bring­ing lo­cal artists to a global au­di­ence. The longest-run­ning global No. 1 song of 2021 was “Love Nwantiti [Remix]” by Nigerian artist CKay, which be­came the sec­ond song to ever sur­pass one mil­lion Shazams in a week.

“Shazam has played an im­pact­ful role in my ca­reer,” said CKay. “It al­lowed mil­lions of peo­ple all over the world to dis­cover me and my unique Nigerian sound. It made me a global sen­sa­tion even be­fore I started to per­form all over the world. The story of CKay can­not be told with­out Shazam con­nect­ing me to the world.”

With its con­tin­ued com­mit­ment to in­no­va­tion over the past two decades, Shazam is pi­o­neer­ing new ways to bring fans closer to the mu­sic and artists they love with new tools like the con­cert dis­cov­ery fea­ture, which spot­lights con­cert in­for­ma­tion and tick­ets on sale for shows nearby, sim­ply by Shazaming a song, or by search­ing for it in the Shazam app or web­site.

While Shazam re­mains fo­cused on the fu­ture of mu­sic dis­cov­ery, to­day’s an­niver­sary of­fers an op­por­tu­nity to look back at the no­table mo­ments and mile­stones that make up its two-decade his­tory.

Shazam turns 20 to­day, and as of this week, it has of­fi­cially sur­passed 70 bil­lion song recog­ni­tions. A main­stay in pop­u­lar cul­ture, the plat­form has changed the way peo­ple en­gage with mu­sic by mak­ing song iden­ti­fi­ca­tion ac­ces­si­ble to every­one. For more than 225 mil­lion global monthly users, to “Shazam” is to dis­cover some­thing new.

To mark the oc­ca­sion, Shazam in­vites fans to take a trip down mem­ory lane with a spe­cial playlist com­prised of the most Shazamed song of each cal­en­dar year for the past 20 years. Featuring every­thing from Train’s “Hey, Soul Sister” to Sia’s “Cheap Thrills,” the playlist is a true re­flec­tion of the mu­sic fans across the globe ac­tively searched for over the past two decades. Listen now ex­clu­sively on Apple Music.

Over the years, Shazam’s global charts have played a cru­cial role in help­ing to iden­tify break­ing new tal­ent like Masked Wolf, who was one of Shazam’s 5 Artists to Watch in 2021 and ended up hav­ing the most Shazamed track glob­ally that year with “Astronaut In The Ocean.”

“The fact that peo­ple all over the world took time out of their day to pull out their phone and Shazam my songs is a huge honor for me as an artist,” said Masked Wolf. “You know you’ve got some­thing spe­cial if you see the Shazam stats mov­ing.”

Shazam’s charts have also be­come a barom­e­ter for un­ex­pected pop cul­ture mo­ments. Kate Bush’s 1985 song “Running Up That Hill” be­ing fea­tured in “Stranger Things” led to an all-time peak in Shazams of the singer, and the track took No. 1 on the Shazam Global Top 200 for 10 days. It ended up reach­ing the top of 25 na­tional charts — more than any other song in 2022.

Keeping its fin­ger on the pulse of mu­sic, Shazam has also played a key role in bring­ing lo­cal artists to a global au­di­ence. The longest-run­ning global No. 1 song of 2021 was “Love Nwantiti [Remix]” by Nigerian artist CKay, which be­came the sec­ond song to ever sur­pass one mil­lion Shazams in a week.

“Shazam has played an im­pact­ful role in my ca­reer,” said CKay. “It al­lowed mil­lions of peo­ple all over the world to dis­cover me and my unique Nigerian sound. It made me a global sen­sa­tion even be­fore I started to per­form all over the world. The story of CKay can­not be told with­out Shazam con­nect­ing me to the world.”

With its con­tin­ued com­mit­ment to in­no­va­tion over the past two decades, Shazam is pi­o­neer­ing new ways to bring fans closer to the mu­sic and artists they love with new tools like the con­cert dis­cov­ery fea­ture, which spot­lights con­cert in­for­ma­tion and tick­ets on sale for shows nearby, sim­ply by Shazaming a song, or by search­ing for it in the Shazam app or web­site.

While Shazam re­mains fo­cused on the fu­ture of mu­sic dis­cov­ery, to­day’s an­niver­sary of­fers an op­por­tu­nity to look back at the no­table mo­ments and mile­stones that make up its two-decade his­tory.

August 2002: Shazam launches as a text mes­sage ser­vice based in the UK. At the time, users could iden­tify songs by di­al­ing “2580” on their phone and hold­ing it up as a song played. They were then sent an SMS mes­sage telling them the song ti­tle and the name of the artist.

July 2008: Shazam launches on the brand-new App Store. Shazam later launched its Android ver­sion in October 2008.

April 2015: Shazam be­comes avail­able on the first Apple Watch.

First Shazamed song on the iOS app: “How Am I Different” by Aimee Mann (July 10, 2008)

First track to reach 1,000 Shazams: “Cleanin’ Out My Closet” by Eminem (September 2002)

First track to reach one mil­lion Shazams: “TiK ToK” by Ke$ha (February 2010)

First track to reach 10 mil­lion Shazams: “Somebody That I Used to Know” by Gotye feat. Kimbra (December 2012)

First track to reach 20 mil­lion Shazams: “Prayer In C (Robin Schulz Radio Edit)” by Lilly Wood & The Prick and Robin Schulz (October 2015)

Fastest track to reach 1 mil­lion Shazams: “Butter” by BTS (nine days)

Fastest track to reach 10 mil­lion Shazams: “Shape of You” by Ed Sheeran (87 days)

Fastest track to reach 20 mil­lion Shazams: “Dance Monkey” by Tones And I (219 days)

Most Shazamed of All Time

Drake is the most Shazamed artist of all time with over 350 mil­lion Shazams across songs the artist has led or fea­tured on. “One Dance” is Drake’s most pop­u­lar track at over 17 mil­lion Shazams.

“Dance Monkey” by Tones And I is the most Shazamed song ever with over 41 mil­lion Shazams.

“Crazy” by Gnarls Barkley was the most Shazamed song us­ing the “2580” text ser­vice.

Top Dance: “Prayer In C (Robin Schulz Radio Edit)” by Lilly Wood & The Prick and Robin Schulz

Top Singer/Songwriter: “Take Me to Church” by Hozier

The first Shazamed song used the ser­vice’s prelaunch pub­lic beta.

Copy text

The first Shazamed song used the ser­vice’s prelaunch pub­lic beta.

IEEE web­sites place cook­ies on your de­vice to give you the best user ex­pe­ri­ence. By us­ing our web­sites, you agree to the place­ment of these cook­ies. To learn more, read our Privacy Policy.

Late last year, I started ex­pe­ri­enc­ing some un­usual in­ter­mit­tent con­nec­tion is­sues on my Desktop. In gen­eral, I had a sta­ble con­nec­tion with av­er­age la­tency; how­ever, at (seemingly) ran­dom times through­out the week, I would start ex­pe­ri­enc­ing sud­den 2000ms+ la­tency spikes every cou­ple of sec­onds.

This made all au­dio/​video call­ing soft­ware un­us­able and most on­line games un­playable.

This is­sue ap­peared to line up with my cross-coun­try move from Washington State to South Carolina, so there were too many fac­tors to eas­ily pin­point the is­sue. However, as it mainly only ef­fected gam­ing and au­dio/​video calls, I did­n’t put too much fo­cus on it.

Over the past cou­ple of months I have (slowly) tried to fig­ure out why this was hap­pen­ing, with lit­tle luck un­til to­day.

Initially, the only thing that was clear about the is­sue was that it was lim­ited to my desk­top com­puter only. My lap­top and other de­vices con­nected to the wifi did not have this is­sue, even when placed in the ex­act same spot as the desk­top.

First, I pur­chased a new, highly-re­viewed, wifi adapter on Amazon. It did­n’t re­solve the is­sue. It did, how­ever, come with an of­fer for a free 64GB flash drive in ex­change for a good re­views.

Later, (for un­re­lated rea­sons) I built an en­tirely new desk­top com­puter, not us­ing any­thing from the old one, ex­cept the new wifi adapter. This in­cluded a fresh in­stall of Windows 10.

It was great, this new com­puter had no is­sues! I had sus­pected that my old moth­er­board’s USB ports might have been dam­aged dur­ing the move to SC, so that must have been the case. Everything is good now, right?

No. Everything is not good now.

A few weeks later, and the is­sue sud­denly be­gan hap­pen­ing on the new com­puter also, and I had no idea what the cause could be.

I tried us­ing mul­ti­ple dif­fer­ent wifi adapters that I owned.

I tried chang­ing the wifi chan­nel, as it ap­peared to over­lap a neigh­bors.

I tried turn­ing off Windows Update Delivery Optimization (p2p up­date shar­ing). After turn­ing this off and restart­ing, the is­sue ap­peared to be re­solved, but then reap­peared later.

At one point, my wifi is­sue even an­noyed one of my broth­ers so badly, due to drop­ping Skype calls, that he bought me an­other (slightly less sketchy) wifi adapter on Amazon. This ap­peared to tem­porar­ily re­solve the is­sue af­ter in­stalling the Realtek dri­ver and restart­ing, but then it came back.

Nothing seemed to work.

Today, in a last-ditch des­per­ate at­tempt at fix­ing the is­sue, I:

* Turned off the box fan in my room

I im­me­di­ately sus­pected in­ter­fer­ence from the wire­less draw­ing tablet or box fan, so tried those again, but they were not the cause.

I could­n’t pos­si­bly imag­ine how a web browser or draw­ing ap­pli­ca­tion could cause this, but I tried any­way.

First I ran FireFox, opened mul­ti­ple tabs on dif­fer­ent sites, and waited…

Why the hell would dig­i­tal paint­ing soft­ware cause wifi lag spikes?

As it turns out, there are mul­ti­ple in­stances of peo­ple com­plain­ing about this is­sue with MBPP.

If we take a quick look with Process Monitor, we can see that it’s def­i­nitely do­ing some­thing odd.

At the ex­act same time the lag spikes oc­cur, MBPP starts query­ing the reg­istry keys for all of the net­work in­ter­faces.

To dig a bit deeper into why this is hap­pen­ing, we can at­tach to the process with a de­bug­ger (x64dbg here), and set break­points on the Win32 Reg* APIs.

Eventually, our RegOpenKeyExInternalW break­point is hit, and we can take a look at the call stack to de­ter­mine where this is be­ing called.

Looking at the call stack, we can see that first non-sys­tem li­brary in the call stack is qt5net­work.

Surprisingly, no more de­bug­ging is needed, as a quick google search for “q5network ping is­sue” will lead you to QTBUG-40332.

If I un­der­stand cor­rectly, any Qt5 (QNetworkAccessManager will check for wifi in­ter­face changes every 10 sec­onds for the pur­pose of bearer man­age­ment, caus­ing mas­sive lag spikes and/​or packet drops en­tirely. Even if QNetworkAccessManager is in­stan­ti­ated in­ter­nally for some­thing sim­ple, like an HTTP re­quest.

I sup­pose the workaround is sim­ple enough, set the en­vi­ron­ment vari­able QT_BEARER_POLL_TIMEOUT to -1.

I just wish I knew that around 8 months ago.

Qt5 has been crip­pling my wifi sys­tem-wide for past 7-8 months, just by run­ning MediBang Paint Pro.

I stu­pidly at­trib­uted it to many other things, be­cause, hon­estly, who would ex­pect Qt to be the cause of their sys­tem-wide wifi prob­lems?

Many of us have ex­pe­ri­enced the frus­tra­tion of vis­it­ing a web page that seems like it has what we’re look­ing for, but does­n’t live up to our ex­pec­ta­tions. The con­tent might not have the in­sights you want, or it may not even seem like it was cre­ated for, or even by, a per­son.

We work hard to make sure the pages we show on Search are as help­ful and rel­e­vant as pos­si­ble. To do this, we con­stantly re­fine our sys­tems: Last year, we launched thou­sands of up­dates to Search based on hun­dreds of thou­sands of qual­ity tests, in­clud­ing eval­u­a­tions where we gather feed­back from hu­man re­view­ers.

We know peo­ple don’t find con­tent help­ful if it seems like it was de­signed to at­tract clicks rather than in­form read­ers. So start­ing next week for English users glob­ally, we’re rolling out a se­ries of im­prove­ments to Search to make it eas­ier for peo­ple to find help­ful con­tent made by, and for, peo­ple. This rank­ing work joins a sim­i­lar ef­fort re­lated to rank­ing bet­ter qual­ity prod­uct re­view con­tent over the past year, which will also re­ceive an up­date. Together, these launches are part of a broader, on­go­ing ef­fort to re­duce low-qual­ity con­tent and make it eas­ier to find con­tent that feels au­then­tic and use­ful in Search.

We con­tin­u­ally up­date Search to make sure we’re help­ing you find high qual­ity con­tent. Next week, we’ll launch the “helpful con­tent up­date” to tackle con­tent that seems to have been pri­mar­ily cre­ated for rank­ing well in search en­gines rather than to help or in­form peo­ple. This rank­ing up­date will help make sure that un­o­rig­i­nal, low qual­ity con­tent does­n’t rank highly in Search, and our test­ing has found it will es­pe­cially im­prove re­sults re­lated to on­line ed­u­ca­tion, as well as arts and en­ter­tain­ment, shop­ping and tech-re­lated con­tent.

For ex­am­ple, if you search for in­for­ma­tion about a new movie, you might have pre­vi­ously seen ar­ti­cles that ag­gre­gated re­views from other sites with­out adding per­spec­tives be­yond what’s avail­able else­where. This is­n’t very help­ful if you’re ex­pect­ing to read some­thing new. With this up­date, you’ll see more re­sults with unique, au­then­tic in­for­ma­tion, so you’re more likely to read some­thing you haven’t seen be­fore.

As al­ways, we’ll con­tinue to re­fine our sys­tems and build on this im­prove­ment over time. If you’re a con­tent cre­ator, you can learn more about to­day’s up­date and guid­ance to con­sider on Search Central.

We know prod­uct re­views can play an im­por­tant role in help­ing you make a de­ci­sion on some­thing to buy. Last year, we kicked off a se­ries of up­dates to show more help­ful, in-depth re­views based on first-hand ex­per­tise in search re­sults.

We’ve con­tin­ued to re­fine these sys­tems, and in the com­ing weeks, we’ll roll out an­other up­date to make it even eas­ier to find high-qual­ity, orig­i­nal re­views. We’ll con­tinue this work to make sure you find the most use­ful in­for­ma­tion when you’re re­search­ing a pur­chase on the web.

We hope these up­dates will help you ac­cess more help­ful in­for­ma­tion and valu­able per­spec­tives on Search. We look for­ward to build­ing on this work to make it even eas­ier to find orig­i­nal con­tent by and for real peo­ple in the months ahead.

This is an Internet Standards Track doc­u­ment.¶

This doc­u­ment is a prod­uct of the Internet Engineering Task Force (IETF). It rep­re­sents the con­sen­sus of the IETF com­mu­nity. It has re­ceived pub­lic re­view and has been ap­proved for pub­li­ca­tion by the Internet Engineering Steering Group (IESG). Further in­for­ma­tion on Internet Standards is avail­able in Section 2 of RFC 7841.¶

Information about the cur­rent sta­tus of this doc­u­ment, any er­rata, and how to pro­vide feed­back on it may be ob­tained at https://​www.rfc-ed­i­tor.org/​info/​rfc9293.¶

Copyright (c) 2022 IETF Trust and the per­sons iden­ti­fied as the doc­u­ment au­thors. All rights re­served.¶

This doc­u­ment is sub­ject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (https://​trustee.ietf.org/​li­cense-info) in ef­fect on the date of pub­li­ca­tion of this doc­u­ment. Please re­view these doc­u­ments care­fully, as they de­scribe your rights and re­stric­tions with re­spect to this doc­u­ment. Code Components ex­tracted from this doc­u­ment must in­clude Revised BSD License text as de­scribed in Section 4.e of the Trust Legal Provisions and are pro­vided with­out war­ranty as de­scribed in the Revised BSD License.¶

This doc­u­ment may con­tain ma­te­r­ial from IETF Documents or IETF Contributions pub­lished or made pub­licly avail­able be­fore November 10, 2008. The per­son(s) con­trol­ling the copy­right in some of this ma­te­r­ial may not have granted the IETF Trust the right to al­low mod­i­fi­ca­tions of such ma­te­r­ial out­side the IETF Standards Process. Without ob­tain­ing an ad­e­quate li­cense from the per­son(s) con­trol­ling the copy­right in such ma­te­ri­als, this doc­u­ment may not be mod­i­fied out­side the IETF Standards Process, and de­riv­a­tive works of it may not be cre­ated out­side the IETF Standards Process, ex­cept to for­mat it for pub­li­ca­tion as an RFC or to trans­late it into lan­guages other than English.¶

In 1981, RFC 793 [16] was re­leased, doc­u­ment­ing the Transmission Control Protocol (TCP) and re­plac­ing ear­lier pub­lished spec­i­fi­ca­tions for TCP.¶

Since then, TCP has been widely im­ple­mented, and it has been used as a trans­port pro­to­col for nu­mer­ous ap­pli­ca­tions on the Internet.¶

For sev­eral decades, RFC 793 plus a num­ber of other doc­u­ments have com­bined to serve as the core spec­i­fi­ca­tion for TCP [49]. Over time, a num­ber of er­rata have been filed against RFC 793. There have also been de­fi­cien­cies found and re­solved in se­cu­rity, per­for­mance, and many other as­pects. The num­ber of en­hance­ments has grown over time across many sep­a­rate doc­u­ments. These were never ac­cu­mu­lated to­gether into a com­pre­hen­sive up­date to the base spec­i­fi­ca­tion.¶

The pur­pose of this doc­u­ment is to bring to­gether all of the IETF Standards Track changes and other clar­i­fi­ca­tions that have been made to the base TCP func­tional spec­i­fi­ca­tion (RFC 793) and to unify them into an up­dated ver­sion of the spec­i­fi­ca­tion.¶

Some com­pan­ion doc­u­ments are ref­er­enced for im­por­tant al­go­rithms that are used by TCP (e.g., for con­ges­tion con­trol) but have not been com­pletely in­cluded in this doc­u­ment. This is a con­scious choice, as this base spec­i­fi­ca­tion can be used with mul­ti­ple ad­di­tional al­go­rithms that are de­vel­oped and in­cor­po­rated sep­a­rately. This doc­u­ment fo­cuses on the com­mon ba­sis that all TCP im­ple­men­ta­tions must sup­port in or­der to in­ter­op­er­ate. Since some ad­di­tional TCP fea­tures have be­come quite com­pli­cated them­selves (e.g., ad­vanced loss re­cov­ery and con­ges­tion con­trol), fu­ture com­pan­ion doc­u­ments may at­tempt to sim­i­larly bring these to­gether.¶

In ad­di­tion to the pro­to­col spec­i­fi­ca­tion that de­scribes the TCP seg­ment for­mat, gen­er­a­tion, and pro­cess­ing rules that are to be im­ple­mented in code, RFC 793 and other up­dates also con­tain in­for­ma­tive and de­scrip­tive text for read­ers to un­der­stand as­pects of the pro­to­col de­sign and op­er­a­tion. This doc­u­ment does not at­tempt to al­ter or up­date this in­for­ma­tive text and is fo­cused only on up­dat­ing the nor­ma­tive pro­to­col spec­i­fi­ca­tion. This doc­u­ment pre­serves ref­er­ences to the doc­u­men­ta­tion con­tain­ing the im­por­tant ex­pla­na­tions and ra­tio­nale, where ap­pro­pri­ate.¶

This doc­u­ment is in­tended to be use­ful both in check­ing ex­ist­ing TCP im­ple­men­ta­tions for con­for­mance pur­poses, as well as in writ­ing new im­ple­men­ta­tions.¶

This doc­u­ment ob­so­letes RFC 793 as well as RFCs 6093 and 6528, which up­dated 793. In all cases, only the nor­ma­tive pro­to­col spec­i­fi­ca­tion and re­quire­ments have been in­cor­po­rated into this doc­u­ment, and some in­for­ma­tional text with back­ground and ra­tio­nale may not have been car­ried in. The in­for­ma­tional con­tent of those doc­u­ments is still valu­able in learn­ing about and un­der­stand­ing TCP, and they are valid Informational ref­er­ences, even though their nor­ma­tive con­tent has been in­cor­po­rated into this doc­u­ment.¶

The main body of this doc­u­ment was adapted from RFC 793′s Section 3, ti­tled “FUNCTIONAL SPECIFICATION”, with an at­tempt to keep for­mat­ting and lay­out as close as pos­si­ble.¶

The col­lec­tion of ap­plic­a­ble RFC er­rata that have been re­ported and ei­ther ac­cepted or held for an up­date to RFC 793 were in­cor­po­rated (Errata IDs: 573 [73], 574 [74], 700 [75], 701 [76], 1283 [77], 1561 [78], 1562 [79], 1564 [80], 1571 [81], 1572 [82], 2297 [83], 2298 [84], 2748 [85], 2749 [86], 2934 [87], 3213 [88], 3300 [89], 3301 [90], 6222 [91]). Some er­rata were not ap­plic­a­ble due to other changes (Errata IDs: 572 [92], 575 [93], 1565 [94], 1569 [95], 2296 [96], 3305 [97], 3602 [98]).¶

Changes to the spec­i­fi­ca­tion of the ur­gent pointer de­scribed in RFCs 1011, 1122, and 6093 were in­cor­po­rated. See RFC 6093 for de­tailed dis­cus­sion of why these changes were nec­es­sary.¶

The dis­cus­sion of the RTO from RFC 793 was up­dated to re­fer to RFC 6298. The text on the RTO in RFC 1122 orig­i­nally re­placed the text in RFC 793; how­ever, RFC 2988 should have up­dated RFC 1122 and has sub­se­quently been ob­so­leted by RFC 6298.¶

RFC 1011 [18] con­tains a num­ber of com­ments about RFC 793, in­clud­ing some needed changes to the TCP spec­i­fi­ca­tion. These are ex­panded in RFC 1122, which con­tains a col­lec­tion of other changes and clar­i­fi­ca­tions to RFC 793. The nor­ma­tive items im­pact­ing the pro­to­col have been in­cor­po­rated here, though some his­tor­i­cally use­ful im­ple­men­ta­tion ad­vice and in­for­ma­tive dis­cus­sion from RFC 1122 is not in­cluded here. The pre­sent doc­u­ment, which is now the TCP spec­i­fi­ca­tion rather than RFC 793, up­dates RFC 1011, and the com­ments noted in RFC 1011 have been in­cor­po­rated.¶

RFC 1122 con­tains more than just TCP re­quire­ments, so this doc­u­ment can’t ob­so­lete RFC 1122 en­tirely. It is only marked as “updating” RFC 1122; how­ever, it should be un­der­stood to ef­fec­tively ob­so­lete all of the ma­te­r­ial on TCP found in RFC 1122.¶

The more se­cure ini­tial se­quence num­ber gen­er­a­tion al­go­rithm from RFC 6528 was in­cor­po­rated. See RFC 6528 for dis­cus­sion of the at­tacks that this mit­i­gates, as well as ad­vice on se­lect­ing PRF al­go­rithms and man­ag­ing se­cret key data.¶

A note based on RFC 6429 was added to ex­plic­itly clar­ify that sys­tem re­source man­age­ment con­cerns al­low con­nec­tion re­sources to be re­claimed. RFC 6429 is ob­so­leted in the sense that the clar­i­fi­ca­tion it de­scribes has been re­flected within this base TCP spec­i­fi­ca­tion.¶

The de­scrip­tion of con­ges­tion con­trol im­ple­men­ta­tion was added based on the set of doc­u­ments that are IETF BCP or Standards Track on the topic and the cur­rent state of com­mon im­ple­men­ta­tions.¶

In the “Transmission Control Protocol (TCP) Header Flags” reg­istry, IANA has made sev­eral changes as de­scribed in this sec­tion.¶

RFC 3168 orig­i­nally cre­ated this reg­istry but only pop­u­lated it with the new bits de­fined in RFC 3168, ne­glect­ing the other bits that had pre­vi­ously been de­scribed in RFC 793 and other doc­u­ments. Bit 7 has since also been up­dated by RFC 8311 [54].¶

The “Bit” col­umn has been re­named be­low as the “Bit Offset” col­umn be­cause it ref­er­ences each header flag’s off­set within the 16-bit aligned view of the TCP header in Figure 1. The bits in off­sets 0 through 3 are the TCP seg­ment Data Offset field, and not header flags.¶

IANA has as­signed val­ues as in­di­cated be­low.¶

The “TCP Header Flags” reg­istry has also been moved to a sub­reg­istry un­der the global “Transmission Control Protocol (TCP) Parameters” reg­istry <https://​www.iana.org/​as­sign­ments/​tcp-pa­ra­me­ters/>.¶

The reg­istry’s Registration Procedure re­mains Standards Action, but the Reference has been up­dated to this doc­u­ment, and the Note has been re­moved.¶

The TCP de­sign in­cludes only rudi­men­tary se­cu­rity fea­tures that im­prove the ro­bust­ness and re­li­a­bil­ity of con­nec­tions and ap­pli­ca­tion data trans­fer, but there are no built-in cryp­to­graphic ca­pa­bil­i­ties to sup­port any form of con­fi­den­tial­ity, au­then­ti­ca­tion, or other typ­i­cal se­cu­rity func­tions. Non-cryptographic en­hance­ments (e.g., [9]) have been de­vel­oped to im­prove ro­bust­ness of TCP con­nec­tions to par­tic­u­lar types of at­tacks, but the ap­plic­a­bil­ity and pro­tec­tions of non-cryp­to­graphic en­hance­ments are lim­ited (e.g., see Section 1.1 of [9]). Applications typ­i­cally uti­lize lower-layer (e.g., IPsec) and up­per-layer (e.g., TLS) pro­to­cols to pro­vide se­cu­rity and pri­vacy for TCP con­nec­tions and ap­pli­ca­tion data car­ried in TCP. Methods based on TCP Options have been de­vel­oped as well, to sup­port some se­cu­rity ca­pa­bil­i­ties.¶

In or­der to fully pro­vide con­fi­den­tial­ity, in­tegrity pro­tec­tion, and au­then­ti­ca­tion for TCP con­nec­tions (including their con­trol flags), IPsec is the only cur­rent ef­fec­tive method. For in­tegrity pro­tec­tion and au­then­ti­ca­tion, the TCP Authentication Option (TCP-AO) [38] is avail­able, with a pro­posed ex­ten­sion to also pro­vide con­fi­den­tial­ity for the seg­ment pay­load. Other meth­ods dis­cussed in this sec­tion may pro­vide con­fi­den­tial­ity or in­tegrity pro­tec­tion for the pay­load, but for the TCP header only cover ei­ther a sub­set of the fields (e.g., tcpcrypt [57]) or none at all (e.g., TLS). Other se­cu­rity fea­tures that have been added to TCP (e.g., ISN gen­er­a­tion, se­quence num­ber checks, and oth­ers) are only ca­pa­ble of par­tially hin­der­ing at­tacks.¶

Applications us­ing long-lived TCP flows have been vul­ner­a­ble to at­tacks that ex­ploit the pro­cess­ing of con­trol flags de­scribed in ear­lier TCP spec­i­fi­ca­tions [33]. TCP-MD5 was a com­monly im­ple­mented TCP Option to sup­port au­then­ti­ca­tion for some of these con­nec­tions, but had flaws and is now dep­re­cated. TCP-AO pro­vides a ca­pa­bil­ity to pro­tect long-lived TCP con­nec­tions from at­tacks and has su­pe­rior prop­er­ties to TCP-MD5. It does not pro­vide any pri­vacy for ap­pli­ca­tion data or for the TCP head­ers.¶

The “tcpcrypt” [57] ex­per­i­men­tal ex­ten­sion to TCP pro­vides the abil­ity to cryp­to­graph­i­cally pro­tect con­nec­tion data. Metadata as­pects of the TCP flow are still vis­i­ble, but the ap­pli­ca­tion stream is well pro­tected. Within the TCP header, only the ur­gent pointer and FIN flag are pro­tected through tcpcrypt.¶

The TCP Roadmap [49] in­cludes notes about sev­eral RFCs re­lated to TCP se­cu­rity. Many of the en­hance­ments pro­vided by these RFCs have been in­te­grated into the pre­sent doc­u­ment, in­clud­ing ISN gen­er­a­tion, mit­i­gat­ing blind in-win­dow at­tacks, and im­prov­ing han­dling of soft er­rors and ICMP pack­ets. These are all dis­cussed in greater de­tail in the ref­er­enced RFCs that orig­i­nally de­scribed the changes needed to ear­lier TCP spec­i­fi­ca­tions. Additionally, see RFC 6093 [39] for dis­cus­sion of se­cu­rity con­sid­er­a­tions re­lated to the ur­gent pointer field, which also dis­cour­ages new ap­pli­ca­tions from us­ing the ur­gent pointer.¶

Since TCP is of­ten used for bulk trans­fer flows, some at­tacks are pos­si­ble that abuse the TCP con­ges­tion con­trol logic. An ex­am­ple is “ACK-division” at­tacks. Updates that have been made to the TCP con­ges­tion con­trol spec­i­fi­ca­tions in­clude mech­a­nisms like Appropriate Byte Counting (ABC) [29] that act as mit­i­ga­tions to these at­tacks.¶

Other at­tacks are fo­cused on ex­haust­ing the re­sources of a TCP server. Examples in­clude SYN flood­ing [32] or wast­ing re­sources on non-pro­gress­ing con­nec­tions [41]. Operating sys­tems com­monly im­ple­ment mit­i­ga­tions for these at­tacks. Some com­mon de­fenses also uti­lize prox­ies, state­ful fire­walls, and other tech­nolo­gies out­side the end-host TCP im­ple­men­ta­tion.¶

The con­cept of a pro­to­col’s “wire im­age” is de­scribed in RFC 8546 [56], which de­scribes how TCP’s clear­t­ext head­ers ex­pose more meta­data to nodes on the path than is strictly re­quired to route the pack­ets to their des­ti­na­tion. On-path ad­ver­saries may be able to lever­age this meta­data. Lessons learned in this re­spect from TCP have been ap­plied in the de­sign of newer trans­ports like QUIC [60]. Additionally, based partly on ex­pe­ri­ences with TCP and its ex­ten­sions, there are con­sid­er­a­tions that might be ap­plic­a­ble for fu­ture TCP ex­ten­sions and other trans­ports that the IETF has doc­u­mented in RFC 9065 [61], along with IAB rec­om­men­da­tions in RFC 8558 [58] and [67].¶

There are also meth­ods of “fingerprinting” that can be used to in­fer the host TCP im­ple­men­ta­tion (operating sys­tem) ver­sion or plat­form in­for­ma­tion. These col­lect ob­ser­va­tions of sev­eral as­pects, such as the op­tions pre­sent in seg­ments, the or­der­ing of op­tions, the spe­cific be­hav­iors in the case of var­i­ous con­di­tions, packet tim­ing, packet siz­ing, and other as­pects of the pro­to­col that are left to be de­ter­mined by an im­ple­menter, and can use those ob­ser­va­tions to iden­tify in­for­ma­tion about the host and im­ple­men­ta­tion.¶

Since ICMP mes­sage pro­cess­ing also can in­ter­act with TCP con­nec­tions, there is po­ten­tial for ICMP-based at­tacks against TCP con­nec­tions. These are dis­cussed in RFC 5927 [100], along with mit­i­ga­tions that have been im­ple­mented.¶

This sec­tion is adapted from RFC 1122.¶

Note that there is no re­quire­ment re­lated to PLPMTUD in this list, but that PLPMTUD is rec­om­mended.¶

Webhooks are the foun­da­tion of mod­ern API de­vel­op­ment. They en­able us to re­act to changes in our sys­tems, an in­com­ing text mes­sage, a suc­cess­ful pay­ment, or that lat­est pull re­quest no mat­ter our stack. While web­hooks are uni­ver­sal in con­cept, they are un­stan­dard­ized API con­tracts with few or­ga­ni­za­tions pay­ing at­ten­tion to their de­sign, se­cu­rity con­trols, and over­all op­er­a­tional ex­pe­ri­ence.

It serves both as a di­rec­tory of web­hook providers and a col­lec­tion of best prac­tices for pro­vid­ing and con­sum­ing web­hooks. Starting from se­cu­rity, mov­ing into pay­load pro­tec­tion, and con­tin­u­ing into op­er­a­tional­iz­ing web­hooks, we delve into the con­cepts and prac­tices cur­rently avail­able in the wild.

Yes! We have many web­hooks to doc­u­ment, pat­terns to un­cover, and best prac­tices to high­light! Our con­tribut­ing page cov­ers how you can help.

Web de­vel­op­ment is hard. As you have more mov­ing pieces in­te­grat­ing more sys­tems across dif­fer­ent or­ga­ni­za­tions, it only be­comes harder.

At ngrok, our goal is to sim­plfiy build­ing for the in­ter­net. Since most peo­ple find us through their fa­vorite web­hook provider, we knew in­te­grat­ing web­hook ver­i­fi­ca­tion would make ap­pli­ca­tions more se­cure and re­li­able at scale. During that ef­fort, we in­ves­ti­gated 100 web­hook providers and built in-prod­uct ver­i­fi­ca­tions for 50 of the most pop­u­lar providers. We found prac­tices that stood out as ex­cep­tion­ally pow­er­ful and oth­ers that left much to be de­sired.

Our goal in shar­ing this is to in­form teams to choose pat­terns that make build­ing and con­sum­ing web­hooks eas­ier, faster, and more se­cure.