4 ms·

I assume one team is responsible for the home page, and another team is responsible for the banking portal, and they can't be bothered to coordinate with each o

I assume one team is responsible for the home page, and another team is responsible for the banking portal, and they can't be bothered to coordinate with each other.

gerdesj 9y ago
I agree. There is no technical reason behind this sort of bollocks. One day S&M will catch up and have a fit at the fragmented "front face" - quite right too. To be honest the board should also give a shit about their org's outward appearance. Bit of a fail all 'round, really.
- deleted 9y ago
  [deleted]
OliverJones 9y ago
True true true. I know of some banks where invest.examplebank.com and bank.examplebank.com are controlled by mutually distrustful organizations. They really should put their stuff into the public suffix list at https://publicsuffix.org/ https://publicsuffix.org/, because, session cookies. But that would assume they knew something about what they were doing.
- chc 9y ago
  How in the world is listing your corporate domain as a public suffix the most appropriate solution to two of the company's teams not working together?
- callalex 9y ago
  Are you talking about Schwab? I don’t see why you need to hide this bank’s identity.
nerdponx 9y ago
This makes sense but it seems to be bigger than that. For example, most companies with a major internet presence have a CDN on a totally separate domain, like "twimg.com", "chasecdn.com", etc. there must be a good technical reason for this, because everybody does it. Or is that an unrelated thing?
- Klathmon 9y ago
  That's an unrelated thing. By having CDN assets on a separate domain, you not only easily avoid accidentally sending any cookies along to the other domains (so if your CDN gets owned at least they aren't getting user credentials or session cookies), but it's also a small performance optimization as there are less things sent in the headers. The important distinction is that the user should never ENTER any information onto those domains directly. They should be for displaying static resources only, so there is no need to "build trust" for them.

I assume one team is responsible for the home page, and another team is responsible for the banking portal, and they can't be bothered to coordinate with each other.

gerdesj 9y ago

I agree. There is no technical reason behind this sort of bollocks. One day S&M will catch up and have a fit at the fragmented "front face" - quite right too. To be honest the board should also give a shit about their org's outward appearance. Bit of a fail all 'round, really.

deleted 9y ago
[deleted]

OliverJones 9y ago

True true true. I know of some banks where invest.examplebank.com and bank.examplebank.com are controlled by mutually distrustful organizations. They really should put their stuff into the public suffix list at https://publicsuffix.org/ https://publicsuffix.org/, because, session cookies. But that would assume they knew something about what they were doing.

chc 9y ago
How in the world is listing your corporate domain as a public suffix the most appropriate solution to two of the company's teams not working together?
callalex 9y ago
Are you talking about Schwab? I don’t see why you need to hide this bank’s identity.

nerdponx 9y ago

This makes sense but it seems to be bigger than that. For example, most companies with a major internet presence have a CDN on a totally separate domain, like "twimg.com", "chasecdn.com", etc. there must be a good technical reason for this, because everybody does it. Or is that an unrelated thing?

Klathmon 9y ago
That's an unrelated thing. By having CDN assets on a separate domain, you not only easily avoid accidentally sending any cookies along to the other domains (so if your CDN gets owned at least they aren't getting user credentials or session cookies), but it's also a small performance optimization as there are less things sent in the headers. The important distinction is that the user should never ENTER any information onto those domains directly. They should be for displaying static resources only, so there is no need to "build trust" for them.