Re:Layoffs at Watson Health Reveal IBM’s Problem with AI
by sushid on Tuesday June 26, 2018 @01:44AM
(#17398164)
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.
Re:Layoffs at Watson Health Reveal IBM’s Problem with AI
by not_kurt_godel on Tuesday June 26, 2018 @03:35AM
(#17398586)
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.
Re:Layoffs at Watson Health Reveal IBM’s Problem with AI
by HelloNurse on Tuesday June 26, 2018 @04:59AM
(#17398928)
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.
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.