4 ms·

At the large company I worked at, it was solved by frequent code audits to any team given subdomain of the company's company.com domain. We were explicitly told

At the large company I worked at, it was solved by frequent code audits to any team given subdomain of the company's company.com domain. We were explicitly told to ensure that anything not related to interoperability between company properties was to be set on the ourdomain.company.com subdomain. The team in charge of it had heuristics they used to monitor for unapproved infringements on that policy. If I decided I wanted to visit one of our offshore dev teams, I could book a first-class ticket anytime I wanted to with no approval necessary. If I wanted $2m for some dev effort, I could have the necessary approvals in a day or so. But if I wanted to write 50 bytes to a .company.com cookie, that was weeks of meetings where I needed to justify my team's existence, the value of the feature we were building and prove there was no other way to implement it.

sushid 8y ago
To be fair, it seems like your organization's solution was to make it very difficult to do so, which is kind of a non-solution (aside from trnctng chars, which is a practice even a small ad tech startup that I was at did). Admittedly it is a better practice than continuing to stuff you cookie and direct users to a strange page once in a while.
- not_kurt_godel 8y ago
  How is that a non-solution? It should be very hard to introduce cookie bloat. Preferences can and should generally be stored server-side. I can't stand it when I lose settings on an account simply because my cookies are on another machine.
  - HelloNurse 8y ago
    Adding cookie data should be a big deal because if everything in the cookie is important valid reasons for needing more data (or less data) imply major architectural changes. For example, after a merger in which two company websites should be integrated you might start with one simple cookie, transition quickly to two independent cookies on two domains, then use a cookie with two keys when the two sites have separate backends but the same domain, then eventually a cookie with a single key again after extensive replacements and reimplementations.

sushid 8y ago

To be fair, it seems like your organization's solution was to make it very difficult to do so, which is kind of a non-solution (aside from trnctng chars, which is a practice even a small ad tech startup that I was at did). Admittedly it is a better practice than continuing to stuff you cookie and direct users to a strange page once in a while.

not_kurt_godel 8y ago
How is that a non-solution? It should be very hard to introduce cookie bloat. Preferences can and should generally be stored server-side. I can't stand it when I lose settings on an account simply because my cookies are on another machine.
- HelloNurse 8y ago
  Adding cookie data should be a big deal because if everything in the cookie is important valid reasons for needing more data (or less data) imply major architectural changes. For example, after a merger in which two company websites should be integrated you might start with one simple cookie, transition quickly to two independent cookies on two domains, then use a cookie with two keys when the two sites have separate backends but the same domain, then eventually a cookie with a single key again after extensive replacements and reimplementations.