Yeah, Google's SSO is fine unless the first logged-in account (/u/0) is one with a redirect to a company portal login. At which point you have to manipulate the URL to get to a different account.
I've been considering buying a Lenovo ThinkPad Extreme X1 Gen 2 as my 2015 MBP has simply outlived its good years, and I can't wait or bet on a first gen Apple MBP replacement, especially not with the extremely poor decision making they've had over the past few years with those keyboards...
The biggest turn-off really is the nVidia graphics chip (which I really don't want, but all models seem to have) and gen 9 processor (which is probably why they don't offer the machine without a discrete GPU). The price is also a little on the higher end of what I'd like to spend, but on the flip side of that, Lenovo has an excellent warranty program including battery replacement and accidental damage replacement options - as it's likely the trend of me holding on to laptops for longer periods of time will continue, that's a really nice to have selling point.
And sadly, for me, that's as close as I can get to a machine I find acceptable... which is why I haven't pulled the trigger on buying one yet. It feels awful walking into a compromise purchase simply because laptop manufacturers have completely given up on you. So awful I just haven't been able to bring myself to do it, despite my Macbook Pro's decrepit state.
Many customers on AWS have contracts that guarantee discounted rates given sufficient volume. People have commented on hn about negotiating them, and you can see some examples from recent IPO filings. Amazon (the non-AWS parts) are yet another customer of AWS, and wherever possible you should expect them to operate like one. They even buy RIs!
I think OP was asking if Amazon is calculating their savings based on the public AWS service pricing or their own cost for running on those AWS services (there's obviously a good chunk of margin on what it costs to run AWS and what the listed service prices are for those services).
I can't say either way, but they mention the average person saves even more than they do (90% vs the 60% Amazon saw). This was due to their Oracle license being much cheaper than normal Oracle customers. So if you extrapolate, even if they did get some discount being Amazon, the discount they were getting on Oracle probably makes the savings comparable to if they weren't getting large discounts on each side (regular customers of Amazon/Oracle).
I don't recall how user data was stored or accessed, but I'm certain there will have been separate fields, or at least a flag indicating whether the person opted out from being targeted by their phone number.
That being said, it will have been incredibly easy for a single engineer to make this mistake (code review probably should have caught it? But maybe it looked just close enough to the right data source), and it would have been extraordinarily difficult to discover.
Not a chance. It's never a single engineer, code gets the PR checked by another engineer and the Jira will be specific with any PII, probably written by committee, all of whom know the importance of the data. Don't conflate this crap with blaming a single nebulous engineer.
I've not worked in years at a place that wouldn't understand the importance of PII. Not that it doesn't happen, but let's not mince words here - this was wilfully done.
Your comment made me audibly laugh at the notion that most companies would have a committee checking PR and Jira tickets for PII. I've worked at plenty of companies, even ones at the scale of Twitter and larger, that don't approach anything even remotely close to that level of sophistication. I've seen audits uncover precisely what the GP comment is talking about. IME, it's not at all uncommon for someone to send an email saying "hey can I get a dump of usernames and phone numbers" and some naive engineer dumps it into a CSV file and sends it to whoever. Hell, most of the places I consulted at don't even consider phone numbers to be protected PII.
I don't mean to defend Twitter in any way, but I could easily see this being an oversight or a mistake.
I bet if we could get a hard percentage of companies that have strict access rules for engineers around even just sensitive data in general, let alone PII, that would easily be <50%.
It's entirely feasible to me that this is was a mistake, I think people who assume this was deliberate are ironically putting more trust in tech companies than they should.
Most of the world is being held together by duck-tape, fastened by people who don't understand the systems they're fixing or maintaining. I don't think that tech companies are an exception to that rule.
fwiw, Google at least has policies around how to handle PII in support tickets, as well as how to handle PII in bugs reported against public-facing-ish software (like Chrome). That's not to say there can't be bad actors or lapses due to poor training or inappropriate behavior, but the tools & policies exist.
I get your perspective and skepticism, I really do. I have no incentive to defend Twitter. I cannot say whether this was done deliberately or not, but it absolutely could have been a mistake by a single engineer at Twitter.
The JIRA will just have been something vague like "add support for phone number matching to tailored audience matching pipeline" likely created by a manager on the ads infra team. Context will have already been assumed. Given that these are simple data pipelines there likely will not have been a design document specifically calling out the fields to match against for this task.
At Twitter it was also possible to deploy these Hadoop jobs without checking in code. They would require to be run as the main ads system service accounts, but most ads engineers should have had the ability to deploy such a job.
As I mentioned earlier, the fragility of this part of the ads infrastructure I observed in 2015 makes me believe that a mistake is entirely possible here.
Example: Hadoop job writes some output file to HDFS, a different job reads files from a particular location on HDFS and processes them. If no files exist there must not have been anything to process right? But it could have also been the case the first Hadoop job failed which nobody noticed subsequently.
Anyways, it could have been an engineer by mistake, an engineer trying to get promoted and increasing revenue numbers, or an action at the direction of management. Don't rule out the first option though...
Bollocks. A phone number is an ideal identifier to match on, they've done exactly the same as FB - pretended it's something for security then gone 'oops'.
I've never worked on the same scale as FB or Twitter and I know that this is a no-go area.
" we have addressed the issue that allowed this to occur and are no longer using phone numbers or email addresses collected for safety or security purposes for advertising. "
Does this mean the matches they've already made on these identifiers are still active?
Any advertiser that made the match previously will likely have that stored somewhere and will also probably have that identified with the twitter handle, so yeah those identifiers are still active, just not within Twitter.
