I once worked in a git repository that required those kinds of restrictions.

This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it).

Needing to figure out a way to protect those parts of the codebase it was decided in the end that the "easiest" way of doing this was to split the repository in half, with the actual artifact building taking place from the half that had the NDA code. The rest of the application (basically the whole application) was then used as a dependency by it.

Still didn't quite solve the issue, but access to that repository was heavily controlled.

Strikes me as bizarre that payment code would be sensitive, unless it's a security by obscurity thing (which would also be concerning).

Keys, secrets, etc. yes. But code? What am I missing here?

As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time.

See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling a joint demonstration of the Radeon card that was going to be in the system, and never partnering with ATI again.

https://web.archive.org/web/20001216031800/https://www.zdnet...

From the linked article, it was a press release, not just to his employees.

> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.

Oh, I misremembered then. Yikes.

> and never partnering with ATI again.

Except of course shipping ATI hardware for years afterwards, then also using nvidia, then dropping nvidia and only using ATI/AMD until transitioning to Apple Silicon.

Well:

1. They kept existing designs, since even Jobs wasn't so crazy as to demand a complete re-architecture of existing laptop models on a whim; plus they probably also had contractual obligations/pre-purchase arrangements

2. They switched to nvidia, but from everything I know they also hated working with nvidia (IIRC Jobs accused nvidia of stealing Pixar tech)

3. AMD is a different company than ATI (technically), and Apple of that era was different than the Steve Jobs temper tantrum era.

But yes, relevant details.

Also Steve Jobs Apple is probably much different than today's Apple.

Sounds like a bit of a dick...

For violating an embargo and publishing a press release announcing products of another company that hadn’t been debuted? What “non-dick” response do you think is appropriate against a prospective partner that violated clear guidelines that defined their partnership which basically included “#1: Keep your mouth shut”, exactly?

They unilaterally issued a press release about Apple's upcoming release.

That's kinda a no-no for partnerships.

He was, but this incident wasn't an example. That's a righteous punishment for an infraction like that.

Going scorched earth was kind of Steve’s thing.

One word: "Courage"

Not sure I understand? Sounds like a temper tantrum to me.

Inside joke. Apple's marketing guy used the word "courage" as an explanation when removing the headphone jack.

lol

That decision had a lot of detractors at the time, but it ultimately seems to have been correct.

I don't know if I agree.

People who moved to bluetooth got arguably worse sound quality.

For wired headphones, there were very few lightning headphones and they mostly sucked.

Now with usb-c you can get a broader range of headphones (because other phones have gone with usb-c).

either kind needs a dac inside the dongle, or the shell of the headphone, or have a bulky external dac.

3.5mm is still king for decent wired headphones/earbuds.

Most people don't like wire and don't care about genuinely good sound through wire vs. artificially sweetened (DSP-ed) sound through Bluetooth. That's what Apple is targeting at, the mass consumer.

Wired headphones are making a comeback though. They're even considered trendy/fashionable now.

https://www.cnn.com/world/wired-headphones-comeback-spc

https://mashable.com/article/wired-headphones-instagram-acco...

Honestly that "most people" seems to be more marketing driven than real opinion.

When you simply can't purchase one thing, then you move to the next thing.

I have several wired and wireless headphones, all for different uses, and the existence of wireless headphones don't make the wired ones less useful for their particular strenghts.

It was wrong then, it is still wrong now.

All my three phones have a headphone jack.

I don't have or plan to have an iPhone.

It still has a lot of detractors but it is hard to beat such a sheer market flex.

Four words: You're holding it wrong.

I believe that the action does reflect Jobs' ego in the following way.

Namely, his belief that CEO == company.

Jobs would never take the view that the action of the CEO of ATI is actually one bad actor acting alone which doesn't represent what ATI wants as an organization, and is unfair and damaging to that organization and all of its employees.

The reason he would not take that view is because then he would not be able to believe that he is the single most important thing at Apple, overshadowing everything else.

If the leak had been the responsibility of some rank and file employee at ATI, with appropriate action taken against that employee by the ATI CEO, it is likely that Jobs would likely have reacted differently, because it then would not longer be seen as a personal matter between him and the CEO, where the corporations are just pawns in a game of teach-you-a-lesson.

Ultimately, it is the CEO who has to take responsibility. They are the chief executive officer, after all. And they are well compensated for it.

But did you notice how this was backwards: the company taking responsibility for the CEO's actions, in the court presided by Jobs.

It’s funny how exciting Apple Pay was when introduced, only Apple pulled the lock-everyone-in card and now we’re all using QRcodes.

In the US you can use Apple Pay anywhere NFC payments are accepted. It's generally completely open on the acceptance side at this point

It's anywhere close to open and requires vendors to seek approval from Apple for every implementation - Apple just has the market share to make everyone dance to their tune.

Apple Pay works on any terminal that supports NFC tap to pay payments. There are thousands, tens of thousands of terminals in the US that are not "Apple Pay" that you can use it on

Same here in australia. We had NFC payments ("tap and pay") since ~2006. Nearly a decade before apple pay launched in Nov 2015. For us, apple pay was like "oh, I can use my phone instead of my credit card? Neat."

People use it everywhere here, just because its easier than carrying around a card.

Most developed countries I've been to use NFC/Apple Pay. Where you see the use of QR codes is in China, Africa, and other countries that VISA/MC/AMEX hasn't penetrated (for either political or socioeconomic reasons).

I'm in HK, most HKers use ApplePay with NFC, and don't use QR codes. Over in mainland China, however, it's all QR codes (with AliPay, WePay).

I guess the "we" depends strongly on location - I've no problem using Apple Pay basically everywhere except Walmart.

No idea what this is referring to...

Many countries in the world have local systems for quick, direct bank transfers encoded with QR codes to be used by local payment systems or local banking apps.

SHEESH

Because it's Apple. They are huge, have scary lawyers, write scary contracts, and want to "delight the user" with features only when they announce them. They hate leaks, and demand separate teams for basically any/all development.

> security by obscurity thing... What am I missing here?

You are looking at the problem from the wrong direction.

If you build a honeypot, to trap hackers, does it behove you to explain what the bait is, and how the trap works?

Know your customer, fraud detection heuristics, finger prints, behavioral triggers are all areas where banks, and financial institutions need to keep the sauce secret. Telling the other party "how" you catch them just gives them the steps of what not to do.

Alternatively, you can also just try not to have security issues, and resolve them with urgency when they do pop up.

The code revealed the existence of Apple Pay, which had not been publicly confirmed.

It seems this wasn’t about the code itself, it was about Apple Pay not being announced yet. So only people under NDA would be allowed to even know what they are working on.

It's kinda like that, there could be a proprietary fraud detection heuristic in there that you don't want to get out.

The non-strawman version of "security through obscurity" is the belief that a system is secured by means of keeping its mechanisms secret.

Suppose an organization doesn't believe such a thing; it's still more secure to keep code secret than not.

Obscurity is a valid layer of security, just not a valid corner stone or linchpin of security.

In particular, when code operates as a service (end users don't have the executable code on their machines) then protecting the source code is a real security measure. Without it, attackers can only probe the service as a black box, guessing about what it is doing.

Yes Apple Pay relies on security through obscurity even today. See the Veritasium recently made a video about it https://youtu.be/PPJ6NJkmDAo?is=iUuJ0W9xUHF_6gTU

There is a bunch of mundane stuff in the banking/finance world masked off by paperwork.

It's not sensitive in the leaking state secrets sense it's sensitive in the risk adverse lawyers on both sides think it's sensitive.

The Bureaucracy exists to perpetuate the Bureaucracy.

Maybe that’s some scoring to decide if you should be able to pay or not with some method.

Can confirm split repos is an excellent solution for protecting IP.

PCI DSS has various controls for code handling credit card cards which tends to require different workflows for code that touches credit card numbers, from say, marketing pages. So splitting the code into different repos can be quite common.

Not sure what it is on the Apple Pay side but with FPLS it is/was basically your keys would be revoked and you would be ineligible to ever get new ones… so no content that requires DRM on iOS for the life of the company.

Banks absolutely love security by obscurity. No clue why.

It had nothing to do with security - it had to do with contractual obligations. Contracts with Apple (also Google, Samsung, Mastercard and Visa) required the product to be kept absolutely secret before the public launch. I was a tech lead with developers working on Bank of America’s ATM client - which had firmware and software updates ahead of launch - and I found out about Apple Pay the day it launched. Across the aisle were developers who supported the debit auth platform and they had no idea either.

security by only obscurity is bad. Having both is better.

For example say I have a hollowed out wall that is hidden behind a painting.

Just putting my money in the hole is bad once it’s found it’s gone but if I put my money in a safe in the hole. Well now you need to find it and break the safe and a hidden safe is objectively better than just having a safe on the floor because you need to find it first.

Sure, if there's many paintings scattered around the house of various sizes, but if there's only one painting, in your office, behind the desk, mounted to cover a safe at standing height, then you might as well hang a neon sign saying "Look Here!" next to it.

Banks run a lot of code as a service. Most people never get to see the executable code. If the source code for those services were easily visible to employees that don't need to have access to it or external consultants and such, that would be monumentally stupid.

It's the most effective kind of security

I assume compiling the payment code as a library (w/o debug symbols) and making that available to the wider group wast allowed? Header files a problem?

Could you not have placed the code in a submodule and likited access to the submodule repo ?