Twitter granted patent on Twitter-like services - <AUTHOR> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=8401009&OS=8401009&RS=8401009 <comment><USER2> I realize that we all have strong opinions about the topic of software patents, but in an effort to radiate more light and less heat, I think it is important to understand the official Twitter position on this topic as well.

Introducing the Innovator's Patent Agreement

Note: Emphasis is mine.

"We will implement the IPA later this year, and it will apply to all patents issued to our engineers, _both past and present_." [1]

"The Innovators Patent Agreement (IPA) is a new way to do patent assignment that keeps control in the hands of engineers and designers. It is a commitment from a company to its employees that patents can only be used for defensive purposes. The company will not use the patents in offensive litigation without the permission of the inventors. This control flows with the patents, so if the company sells the patents to others, the assignee can only use the patents as the inventor intended." [2]

[1] [http://engineering.twitter.com/2012/04/introducing- innovator...](http://engineering.twitter.com/2012/04/introducing-innovators- patent-agreement.html)

[2] <https://github.com/twitter/innovators-patent-agreement>

<comment><USER3> And how do they plan on enforcing that?

<comment><USER4> The same way lawyers already enforce contracts? If I had to guess. That and having publicly made the statement, they would see a mass exodus of users if they broke their own promise. (Think GoDaddy)

<comment><USER5> Contracts require (amongst other things) counter-parties who also sign and the exchange of goods or services between the parties ("consideration"), neither of which unilaterally signing some random document has.

In law, it is very difficult for individuals to bind their future selves. You generally need another party to create obligations that _they_ can enforce against _you_. So for example counter-parties to a contract, trustees and beneficiaries, employers and employees, fiduciary agents and their clients etc etc. All of these require distinct legal persons to work, if you you combine them into a single legal person the obligations evaporate.

Because when it's you vs you the law pretty sensibly throws its hands in the air and says "well what the hell do you want the courts to do? Hop in a time machine and drag past you into court?"

IANAL, TINLA.

</comment></comment></comment></comment><comment><USER6> I haven't read the patent. But it seems to me that prior art would be CompuServe's CB Simulator -- from the early 1980s. That's what I thought of when I first encountered Twitter. <http://en.wikipedia.org/wiki/Cb_simulator>

<comment><USER7> >> _TennesseeBunny_ was dialed in with a laptop and a 2400 baud modem and broadcast the event play by play

And there we have the invention of live-tweeting an event!

</comment></comment><comment><USER8> This is disgusting and immoral. It also seems to have been filed before they made their patent promise thing public. Assholes.

<comment><USER9> as noted above:

"We will implement the IPA later this year, and it will apply to all patents issued to our engineers, both past and present." [1]

emphasis on _past_

[1] [http://engineering.twitter.com/2012/04/introducing- innovator...](http://engineering.twitter.com/2012/04/introducing-innovators- patent-agreement.html)

</comment></comment><comment><USER10> The independent claims all explicitly codify the follower/following mechanic. So if you want to show prior art, you'll have to find something where a user was subscribing to receive broadcast messages from other explicitly-defined _users_ , as opposed to subscribing to a channel, group, mailing list, etc.

The heaps of similar methods that don't include follower/following is a good reminder of how easy it is to avoid infringing on this patent: just skip the follower/following mechanic.

<comment><USER11> afaik, LiveJournal (i.e., Brad Fitzpatrick) invented the follower/following pattern, except they just called it "friends of" & "friends".

LJ was the direct inspiration for Twitter, at least according to this interview: [http://latimesblogs.latimes.com/technology/2009/02/twitter-c...](http://latimesblogs.latimes.com/technology/2009/02/twitter- creator.html)

<comment><USER10> Friends is bi-directional, no?

Or did LiveJournal have a way for me to be your friend without you being mine?

<comment><USER12> > Friends is bi-directional, no?

Not in Livejournal lingo - remember, this is pre-Facebook.

Livejournal's 'friend' and 'friend of' worked exactly the same as Twitter's 'following' and 'followers'.

<comment><USER10> That would seem to be prior art for that element then, depending on the dates. Though now we'd have to dig into the rest of the elements.

And apparently I'm getting downvoted for not being familiar with LiveJournal, so that's something someone else would have to do.

</comment></comment></comment></comment></comment><comment><USER13> Is this because someone forgot to patent the cc feature of email? We've been doing similar point to multi-medium translation of messages for decades. Email to email+text pager for doctors in hospitals. Surely there's a strong prior art case that invalidates this, but this is also obvious enough that it really shouldn't get through in the first place.

I am just too thick to understand IP law.

<comment><USER14> Or BBS, or IRC status bloomberg terminals etc etc etc.

Whole thing sucks. I'm not going to read the patent.

</comment></comment><comment><USER15> If the guy that invented sms patented 140 char messages there would be no twitter. Or irc messages, or smoke signals, or X where one people sends a text message to others. Patents are a bureocratic perversion that do not acomplish any progress to humanity, they just perpetuate the bureocratic system itself.

<comment><USER16> Many of these humans are caught within a system which incentivizes personal interests over those of society. Those in higher power are aware of this, but too cowardly to do anything about it, sadly, and the lower amongst us are forced to at least protect themselves from a broken system. But the thing is, the more they protect themselves, the more this corrupt system becomes reinforced and innovation becomes even more endangered. We need to wake up and say enough is enough already. Do we really want this paralyzing system to dictate us and future humanity?

<comment><USER17> There is always a choice.

<comment><USER16> What good is a choice when they've got a gun to your head? Do most of us have to die before we finally get it?

<comment><USER17> A gun...over patents? I think you may be diluting the topic for some reason.

<comment><USER16> I'm not diluting nothing. Patents shoot down competition.

</comment></comment></comment></comment></comment></comment><comment><USER18> You have got to be kidding me. This just shows how broken the US patent system is for software.

</comment><comment><USER19> The patents involves routing messages with emphasis on followers. Everything previous I'm aware of has been multicast based or address based, like email or mailing lists. Most internet and application-layer protocols are destination based. Where is a protocol that says "Route this message based on who is interested in the source."? All I find is "send this message there, based on X, or, send that message here, based on Y"; both destination based. Would be interesting to know or hear of past protocols which are more similar to twitter's patent.

<comment><USER20> _Everything previous I'm aware of has been multicast based or address based, like email or mailing lists._

As others remarked, IRC is follower-based. You follow a bunch of channels by sending subscription message ( _JOIN #channel-name_ ) to central authority (IRC server). The server keeps track of who follows which channel, and brokers any _PRIVMSG #channel message_ messages to the followers, until the person does _PART #channel-name_ or disconnects. Aside of that, a direct person-to- person mechanism exists just as well, also via the _PRIVMSG_ command.

The _USER nickname_ command provides, among other, list of (public) channels the named person follows, which some IRC clients use to allow user to follow the same channels.

Yes, there is a difference between an IRC channel and a singular persona, but it is not as clear-cut as it may seem on its face. On one hand, some channels are muted, and only admins, or just a single admin, can post. On the other, Twitter handles often stand for multiple persons, speaking for one organization, team etc.

* * *

As an IRC user, I am ashamed and appalled of how low our industry has fallen -- somebody applies for a patent for what (after cursory read seems to me) a copy of well-known and long-established functionality.

<comment><USER19> IRC has no such long-established functionality. You can MSG a #channel or a user and that's it. User's can't follow each other and there are no lists. These followers and lists are how twitter routes messages, not a channel.

Such a simple difference makes all the difference. In this case, enough to file a patent.

If they didn't file a patent someone else would have.

<comment><USER5> > _If they didn't file a patent someone else would have._

And Twitter would have been in a position to object it to death.

</comment></comment></comment></comment><comment><USER21> What does this mean for the likes of Identica, StatusNet, OStatus, etc?

<comment><USER22> [http://www.wired.com/wiredenterprise/2012/04/twitter- patent-...](http://www.wired.com/wiredenterprise/2012/04/twitter-patent-ipa/)

</comment></comment><comment><USER23> This is almost definitely a direct result of the recent legislation that changed patents from a 'first to invent' to 'first to file' system. Basically, Twitter had to file a patent on twitter-like services, or someone else could come along, patent it, and force Twitter to 'license' the tech.

The law went into effect on Monday.

<comment><USER24> It has nothing to do with the recent legislation. The patent was filed in 2008, so is under the old "first to invent" regime.

</comment></comment><comment><USER25> Ridiculous, surely sth like Jabber could be shown as prior art ?

</comment><comment><USER26> Does this mean I have to take down all of my Ruby on Tails Twitter-like tutorial apps?

<comment><USER27> If you don't care about your websites(eg. Hobby projects, projects that aren't doing well) or care a lot(eg. Your site is the next facebook) approach a Patent lawyer and have your site reviewed. If he/she finds something amiss, approach twitter and ask them if they are ok with your website. If your site infringes the patent and you don't care about your site and you do this, you end up helping people understand where twitter stands on the issue of patent abuse and trolling. If you care a lot about your website and you do this, you are safeguarding your interests.

However, if you care just enough for your website(eg. Your site makes enough money to pay for itself and then some), I would advice against approaching twitter. Chances are twitters lawyers will ask you to shut your project, if you approach. And if you don't, chances are your project might be small enough and remain unharmed(security by obscurity?) if twitter goes a-trolling.

</comment></comment><comment><USER28> How did Twitter get the patent on BizTalk? The description sounds much more like BizTalk than Twitter to me.

</comment><comment><USER5> I'm the in the middle of patenting an actual protocol (unrelated). In case you're wondering, yes: patentese is always vague and difficult to follow. I wrote a few thousand words to describe my protocol to the level you'd find in an RFC, and it blows out to tens of thousands of words of dense verbiage and a bunch of diagrams with hundreds of reference numbers.

</comment><comment><USER29> There is prior art for this. I've seen forums that permit turning on notices for all posts by specific users, which in itself looks to satisfy every claim, since they also include a "what's new" feed which is basically just a dumping of posts anywhere on the site into 1 place. They behave like a miniature twitter in that regard.

IRC clients also notify the user when messages targeting them (via your handle, similar to @handle) are received, and I've seen scripts that pull comments from specific users from any open channels, and the opposite (namely blocking users) has been present in countless applications, which indicates the concept of paying special attention to a specific user isn't a new one.

On top of this, I don't feel like there's anything that's innovative at all in this patent. Since when did the innovation step stop being a requirement?

</comment><comment><USER30> I read through the first claim, here's a summary I built as I went along (IANAL so I'm probably wrong).

Their first claim is the following:

A way to communicate between computers (1:many) where users can designate by computer to follow someone else.

Where users are identified by accounts where following is an account config.

Where users can be notified of messages that they are not explicitly told about (but follow).

Where another user is marked as the sender (we have their followers, so that is implicitly marked too).

Where the first user is one of the followers.

Where the first user has devices ("endpoints") that they'd like to recieve messages from (phone/etc), this patent applies to sending each message to each of the endpoints in their appropriate format.

Points 2-8 are about:

\- Different ways to send the message.

\- per-following subscription preferences.

\- Message preferences set up in weird ways. (3. I'm not too sure on this)

\- Broadcasting through an aggregator that sends data through batched messages.

\- Translating messages from/to UTF-8/etc.

\- Delivering messages at specific times.

\- Sending URLs to messages

At a glance, claim 9 is about storing the data for a message.

Claims 10-15 are about:

\- Different ways to trigger the message that this data can represent.

\- Per-following subscription preferences (I'm starting to think this is Twitter group subscriptions)

\- Per-following subscription preferences including time periods.

\- Messages that have no explicit recipient.

\- Aggregated message delivery.

\- Sending URLs to messages as the message

At a glance, claim 16 is about building the system that does this.

Claims 17-22 are pretty much the same as 10-15

EDIT: Wow, I didn't realize HN uses a variant of Markdown. (Good, good)

</comment><comment><USER31> Relevant prior art, publicly disclosed on or before February 2001, which quite explicitly includes the "follower/following" mechanic:

(The blog article was written in relation to a different patent, but the prior art is most directly related to a Twitter-like service.)

[http://thinkinghard.com/blog/PossiblePriorArtForKootolPatent...](http://thinkinghard.com/blog/PossiblePriorArtForKootolPatentDated2001.html)

[http://web.archive.org/web/20010223204516/miski.sourceforge....](http://web.archive.org/web/20010223204516/miski.sourceforge.net/miski- white-paper.html)

</comment><comment><USER22> Well at least they have this: [http://www.wired.com/wiredenterprise/2012/04/twitter- patent-...](http://www.wired.com/wiredenterprise/2012/04/twitter-patent-ipa/)

<comment><USER32> At least they have... what? A shill-ish, apologetic article on Wired that doesn't offer anything except "we _pinky_ promise not to troll"? There is still absolutely nothing stopping them from using this however they please.

<comment><USER22> If one of their employees invented it, then they can stop the legal proceedings.

Still, this patent can probably easily be invalidated with prior art.

</comment></comment></comment><comment><USER33> And people wonder why innovation is being stifled. If you create something great that works, another bigger company already has a patent on it.

</comment><comment><USER34> Don't hate the playa, hate the game.

They are using other people's money -- given the current system, they had a fiduciary responsibility to do this, unfortunately.

Maybe the lesson is to not take other people's money, but investment really does allow grand things happen that would not happen otherwise.

Patent system is fucked and fucked corrupts absolutely. At least, that's my take away.

</comment><comment><USER35> It doesn't have an issue date, so I presume it's not granted and it's too early to lament how broken USPTO is.

The claims require service to have concept of explicit following of other users and receiving messages not explicitly addressed to them, so it's not like CC: in e-mail or Jabber chats.

<comment><AUTHOR> Other press are stating the patent was issued yesterday, if this is correct perhaps the uspto website isn't updated daily.

</comment></comment><comment><USER36> Another one "non-evil" empire...

</comment><comment><USER37> Who's to say this isn't just for meant defense? I imagine Twitter is a huge target for trolls given their deep pockets. Calm down, everyone.

</comment><comment><USER38> So, this has been granted? Claim 1 looks incredibly broad to me.

</comment><comment><USER39> There are 22 claims.

Would something have to meet all 22 claims to be infringing?

<comment><USER40> No, just all the elements of any one of the claims.

</comment></comment><comment><USER41> I will now patent web pages.... follow by making a bookmark.

</comment><comment><USER42> American companies had patented many famous varieties of rice[1] and other corp. Not to mention many medicinal plants that is being used in India not for centuries but millennia. USPO granted them all that. Luckily Indian Govt showed some ball at that time(which is remarkably rare), and they directly told the patent holders to stuff it up their a __e.

Matter was settled.

Can't sth like that happen in computers and Internet?

(BTW, it seems either USPO is very corrupt or very negligent. Or maybe they don't give a damn!).

[1]<http://en.wikipedia.org/wiki/Basmati#Patent_battle>

<comment><USER43> I doubt very much that the USPTO is getting kickbacks to pass patents through. As I understand it, "number of patents granted" is the metric they use for success, which puts a lot of pressure on the patent examiners at the bottom rung to do very basic research before pushing things through.

Basically, there is no incentive for them to do a diligent job, so they don't.

</comment></comment><comment><USER44> Invalid, trivial prior art everywhere.

IPv4 multicast with IGMP and any system built on it are the most obvious, not to mention any IM software where people can set their status and have it broadcasted to all contacts.</comment>


Please Don't Block Our Ads. Here's How to Block Ads in iOS 9 - <AUTHOR> http://www.wired.com/2015/09/content-blocking-apps/ <comment><USER2> > Before you start downloading, there is one very important thing to > understand: By blocking ads, you are depriving content publishers (like us, > hello!) of advertising income and insights into what readers want.

It's subtle, but basically, I'm being asked to _buy_ Wired in some way.

For the paper magazine (does it still exist?), the plea would be: By not buying our magazine, you're depriving us of money.

Wired and everyone else is leaving copies of their magazine everywhere, and then asking us to donate money, in the form of time, resources, privacy and safety.

Wired and everyone else, please feel free to notice that I'm blocking ads, and refuse to serve me content. Or factor in however many freeloaders like myself take you up on your generous offer to let me view your content for free, and charge more for your ads.

Or talk to AOL about resurrecting their paywall, and take shelter there.

Whatever you do, I'm not giving you unblocked access to my machine or my life, and I doubt many other people who use a blocker will go back.

</comment><comment><USER3> Ah, online content publishers versus the internet now... I feel sorry for Wired. Here's how I see it:

\- Text ads on websites

\- People use adblockers,

\- Apple introduces the iPhone without ad blocking

\- Website revenue goes up. Many websites use very invasive ads to the point of blocking access to their own content,

\- Each ad is marginally valuable, so content producers keep adding more; Competitors need to remain valuable, so they follow the trend,

\- Mobile experience gets broken, so Apple introduces ad blockers,

\- Websites lose revenue,

\- And start using DRM to prevent external modification of their websites. Maybe we'll even have laws against website alteration...

It's all over on a massive scale, which prevents alternatives like individual ethics, begging, donations, etc. I'm not sure there will be a winner, in fact I believe we'll reach the same sad state as television.</comment>


How to know which Trump impeachment polls to believe - <AUTHOR> https://qz.com/1729426/how-to-know-which-trump-impeachment-polls-to-believe/ <comment><USER2> Ah, these are the days that xkcd's browser-replacements really pay off.

My browser renders the title as "How to know which Trump impeachment psychic readings to believe" :-)</comment>


Makisu – CSS 3D dropdown concept - <AUTHOR> http://soulwire.github.com/Makisu/ <comment><USER2> This is a really cool effect. The demo page doesn't say much, but there are parameters for speed, overlap, shading, and perspective. It would be cool if the first thing you see on the demo page is an unfolding menu that has clickable items to see other demos that show off these parameters a bit more.

The only other thing I'd note is that if you click the toggle button while the animation is loading, the animation snaps to the start of the next state and begins the animation. It doesn't fold up/down from its current position. That might be a tough thing to add, but it could go a long way.

Overall, I enjoy this effect. Nice work!</comment>


Microservices Weekly (Issue #15): This week's news/articles on microservice - <AUTHOR> http://www.microservicesweekly.com/issue/15 <comment><USER2> You should provide an RSS feed, so we can include in feedly.com

<comment><USER3> This comment should be deleted. There are many more rss services, and 'more' free than feedly.</comment></comment>


Twitter urges users to change passwords after computer 'glitch' - <AUTHOR> https://www.reuters.com/article/us-twitter-passwords/twitter-says-glitch-exposed-substantial-number-of-users-passwords-idUSKBN1I42JG?il=0 <comment><USER3> Actual twitter post: [https://blog.twitter.com/official/en_us/topics/company/2018/...](https://blog.twitter.com/official/en_us/topics/company/2018/keeping- your-account-secure.html)

"Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again."

Exact same thing that github did just recently.

<comment><USER4> So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?

<comment><USER5> nah, that just makes the "hashed password" the equivalent of the cleartext password. Whatever it is your client sends to the server for auth is the thing that needs to be protected. If the client sends a "hashed password", that's just... the password. Which now needs to be protected. Since if someone has it, they can just send it to the server for auth.

But you can do fancy cryptographic things where the server never sees the password and it's still secure. like the entire field of public key cryptography, diffie-hellman key exchange, etc.

<comment><USER6> "Since if someone has it, they can just send it to the server for auth" unless it's only good for a few moments (the form you type it into constantly polling for a new nonce).

<comment><USER7> The server would not be able to verify a changing hash without knowing the password

</comment></comment></comment></comment></comment><comment><USER8> A couple of steps you can take to reduce the chances of accidentally putting sensitive information in a log.

1\. Make a list of all sensitive information that the test users in your test environment will be giving to your application.

As part of your test procedure, search all logs for that information. This can be as simple as having a text file with all the sensitive information, and doing a 'grep -F -f sensitive.txt' on all your log files.

2\. If you are working in some sort of object oriented language, make separate classes for sensitive data, such as a class Password to hold passwords, a class CardNum to hold credit card numbers, and so on.

Make the method that whatever you use for logging uses to convert objects to strings return a placeholder string for these objects, such as "Password", "Credit Card Number", and so on.

<comment><USER9> Probably better than 2 is to use actual privilege separation between sensitive data and as much of your service as possible. Handle passwords and password changes in a separate microservice which exchanges it quickly for a session cookie, so that the bulk of your application logic doesn't have passwords in memory at all. For credit card numbers, do something like what Stripe does where one API endpoint exchanges the card number for a token and every other endpoint just needs the token, which means that Stripe can route that one URL to services they pay extra attention to.

This assumes that passwords and credit card numbers are more sensitive than session cookies or tokens, which is usually true because people tend to share passwords across sites and definitely share credit card numbers across sites. So the risk of logging cookies/tokens is much lower. Also, you can revoke all cookies and token much more easily than you can force everyone to change passwords or credit card numbers.

<comment><USER10> While good advice, your proposal is not necessarily better than #2 because #2 is something that happens automatically once the password hits your object model.

If rather than a naked string you have a Password class with literally no way to extract the plain text password then you can be positive that any code that uses it will never accidentally log the password.

In contrast, if you rely on microservice tokenization you can still accidentally log your password before your tokenization happens, just like people are accidentally logging passwords before they are bcrypted.

Both proposals have a problem of logging raw requests or raw service calls (outside of your object model).

Where plausible it would probably be best for microservice calls to only take already bcrypted passwords, and error out if it detects one that isn't, so there is zero chance of accidentally logging a plain text password when calling a microservice.

Again, an actual object (e.g. HashedPassword) shines here, because your code can automatically detect bad values the instant it hits your object model, and refuse to properly log or give access to anything that looks like it isn't already hashed.

<comment><USER9> You have to get the password _into_ the object model first, though—and your object model can simply not contain a Password type in this process (and only in the password-handling one). You shouldn't pass the password on as a naked string and then drop it—you should prevent the password from getting past the auth service at all.

I think the risk of logging raw passwords in the auth service model is lower because logging in a password-specific microservice is an intuitively dangerous thing to do, so both code authors and code reviewers will pay heightened attention to it. Meanwhile, "log all requests" is a common thing to want to do and will raise fewer alarms in a primarily-business-logic service. (In fact, another usually reasonable thing to do is "log all requests that don't parse properly and return 500...")

</comment></comment></comment></comment><comment><USER11> I highly recommend using a password manager. I finally bit the bullet and started using 1Password a few weeks ago, and I haven't looked back since. It's just so much better than having to remember a thousand different passwords.

Besides securely managing passwords, you can also use a password manager to secure your digital legacy. 1Password has a feature where you can print out "emergency kit" sheets that has the information required to access your password vault. I printed out two of these sheets and gave them to trusted family members in sealed envelopes. In the event that I become incapacitated, they will be able to access my accounts.

<comment> racer-v I keep all my passwords in a text file. I can't imagine remembering them all. I suppose I should keep that file encrypted and synced to multiple devices with rsync or so. Would a password manager give me any advantage over this scheme?

<comment><USER12> No, that's basically what they do, but in a more user-friendly format.

<comment><USER13> Well if he's not keeping that text file encrypted, I'd argue that there is a very significant difference in his methodology vs 1Password et al.

</comment></comment></comment></comment><comment><USER14> The Tweet from the Twitter CTO on this: [https://twitter.com/paraga/status/992135139994943488](https://twitter.com/paraga/status/992135139994943488)

"We are sharing this information to help people make an informed decision about their account security. We didn't have to, but believe it's the right thing to do."

The "we didn't have to" is a little jarring given the scale of this.

<comment><USER15> Well, nothing ever left Twitter's servers. The logs themselves would probably be uninteresting to outside parties and inaccessible.

<comment><USER16> Last year a contractor deleted the president's account.

The fact it didn't leave Twitter doesn't mean everything is good. There are still a LOT of people who may have had some kind of access to this data.

<comment><USER17> > Last year a contractor deleted the president's account.

The fact that they undeleted it is strong evidence that he didn't have discretion in how he performed his job, and thus was actually an employee and not a contractor.

<comment><USER18> I'm not sure how that follows. Are you suggesting they don't keep backups or use a "deletion" flag temporarily, e.g. as part of spam account removal?

<comment><USER19> Indeed. I deleted my Twitter account recently, there was a message that data is retained for 30 days to facilitate un-deletion. I assume their internal process is the same.

</comment></comment></comment></comment></comment></comment><comment><USER20> Back in my younger, move naive days when I first started using a password manager and such a practice was not as widespread, I had the same question I think most other people have: "If my computer gets hacked or infected, won't the attacker instantly grab all the passwords from the manager?"

I chose to use a manager anyway, with the logic that if my system was compromised I was owned either way; memorizing passwords provided very little, if any, "softening" of the damage.

It's funny looking back on that fear now. Password managers have become more mainstream, and we, collectively as users, have learned something interesting. One of the assumptions of that hacking fear was that it was more likely for a user's machine to become compromised than it was for the service's the user uses to be compromised.

Well, as it turns out, the opposite was true and the fear was unfounded. The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises.

Perhaps that makes sense in retrospect. But it wasn't obvious a decade ago. Back then viruses and malware were rampant on the internet. In many ways they still are, but not like it was back then. Those were the days of pandemics like the Blaster worm. So it made sense to be more afraid of your own machine being compromised.

But the tides have turned. The landscape of OS security has improved dramatically. The single points of failure offered by servers are far more valuable now than the unwashed masses of networked user computers.

Just a funny retrospective that I thought I'd share.

<comment><USER21> > The vast majority of password leaks we've seen over the past decade have > been due not to malware but rather server compromises.

Something to consider is that malware-based compromises of personal systems don't raise as much brouhaha as corporate-level compromises.

<comment><USER20> My statement is based not on frequency of news, but rather on my understanding of the provenance of passwords in password lists. The vast majority of passwords in password lists are sourced from service hacks; not from user malware. And that makes sense. Malware events net maybe thousands of user passwords? On a good day maybe 100k. But hacks of major services like LinkedIn ... those yielded hundreds of millions of passwords. The two just don't compare in magnitude. Remember that HIBP's list is sitting at something like half a billion password combos right now.

<comment><USER9> One thing to note is that a remotely-compromised computer gets you access to the actual browser session and not solely to the password. In fact, most of the time the user has already logged in, and so the session is accessible but the password isn't (users without password managers have no persistent store, and password managers try to keep the secrets encrypted except when the master password has been recently typed).

So it's not often useful to take a password from an individual user and put it in a password list, but it _is_ often useful to maintain persistence on their machine. Tools for doing that (RATs) are definitely common, both from random internet attackers and from e.g. angry exes with physical access to your device. But those aren't the attacks that e.g. HIBP is interested in, so if you're looking at data from people interested in password compromises, the effect is that you'll undercount client-side compromises.

</comment></comment></comment></comment><comment><USER22> Stupid question department:

W3c and IETF or other similar clever folks really like security stuff and do lots of clever things to make us safer. So why couldn't we create a http browser/server authentication method that has something closer to a nonce- based challenge/response mechanism? If it were standardized, the browsers could even do some clever hashing of some peer addresses or other things that we think should be static. All of the browsers could still present a "username/password" field that looks remarkably similar to existing forms but never reveals the plaintext password to the peer.

As long as I could type my password into other browsers on other computers and still get the same result, it seems like it's moving things forward. It would be opt-in, traditional username/password forms would continue to live on for decades to follow.

So what am I missing? Presumably something like this was considered and ruled out?

EDIT: yes, of course, I forgot about the existing HTTP authentication mechanism(s) in RFC 2069. I don't know why it never caught on but the fact that the browser uses modal dialogues for these means a significantly different context/user experience.

<comment><USER23> These challenge response mechanisms still require a shared secret. This means the server still needs to know either your password or a hashed version of it. TLS covers the problems a challenge-response method is supposed to solve. That is, TLS prevents replay attacks because the shared secret is sent under encryption.

Really, the solution to exposing passwords to the endpoint is to do key- derivation client-side, with a server-provided salt.

<comment><USER24> > Really, the solution to exposing passwords to the endpoint is to do key- > derivation client-side, with a server-provided salt.

That sounds a lot like Secure Remote Password protocol: [https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)

</comment></comment></comment><comment><USER25> I've seen this scenario unfold before:

      1. User provides username/password.
      2. An exception occurs somewhere.
      3. The stack trace from the exception is logged.
      4. The stack trace includes the credentials.
      5. The exception ends up in a ticketing system (Trac, JIRA, etc.)
      6. Nobody notices for years.

<comment><USER26> As a bonus, sometimes the stack trace will be returned to the user, and maybe it'll contain server-side secrets, too!

</comment></comment><comment><USER27> These comments are everything from eliminating passwords (good luck) to "congress should fix it with law" (lol).

Having been in the identity space for a while and seen how various companies think about it, these kinds of problems will keep coming up...mostly at companies for whom identity is commodity. These companies will always give account security the minimum requisite attention. No one at Twitter gets excited about working on the login form.

I know OpenID was a bust and everyone hates Facebook Connect, but as an industry we need to figure out how platforms that view account security as a necessary evil can vendor that to people who take it seriously. Trying legal avenues to get people to take it seriously or finding alternative methods is what we've been trying for the last 15 years and it hasn't worked.

<comment><USER28> Security Keys are often used as a second factor, but the original vision was that they could also be a primary factor in lieu of a password. Humans are bad at passwords, but they carry around house keys every day. Why not also carry around computer keys on their keychain?

For the average person (not worried about a megacorp or nation state attacking them), TouchID is also a possible "password replacement" for the primary authentication factor, although it comes with the disadvantage of not being rotatable.

</comment></comment><comment><USER29> At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point

<comment><USER30> Maybe you should explain them there is a reason why passwords input is hidden in terminals: to avoid them being kept in ~/.bash_history.

It is exactly the same problem.

<comment><USER31> There's another argument that might work in GP's case. A fair share of successful attacks were successful not because the attackers actually broke something on their well-guarded target. But because they used credentials obtained from other poorly defended systems.

</comment></comment></comment><comment><USER32> Twitter's CTO had an odd tweet about this disclosure (emphasis mine):

> We are sharing this information to help people make an informed decision > about their account security. We didn't have to, but believe it's the right > thing to do.

[https://twitter.com/paraga/status/992135139994943488](https://twitter.com/paraga/status/992135139994943488)

<comment><USER33> "I should not have said we didn't have to share. I have felt strongly that we should. My mistake."

[https://twitter.com/paraga/status/992146630232043520](https://twitter.com/paraga/status/992146630232043520)

<comment><USER34> Felt strongly that [Twitter] should have... "said we didn't have to share"? "shared"?

Parag needs a Comms director to handle is Twitter account.

<comment><USER35> Pretty obviously "shared" given the context.

</comment></comment></comment></comment><comment><USER36> >Due to a bug, passwords were written to an internal log before completing the hashing process.

Hate to speculate, but it sounds possibly like perhaps a debug statement/log level had been enabled for testing and forgotten about?

<comment><USER37> You wouldn't even need that -- just a request log that included the request body without sanitizing it first :)

<comment><USER38> That would have never happened to me. Not ever!

</comment></comment></comment><comment><USER39> The reuters article is pretty succint.

Here's the tweet about it: [https://twitter.com/TwitterSupport/status/992132808192634881](https://twitter.com/TwitterSupport/status/992132808192634881)

which links to that blog:

[https://blog.twitter.com/official/en_us/topics/company/2018/...](https://blog.twitter.com/official/en_us/topics/company/2018/keeping- your-account-secure.html)

</comment><comment><USER40> They don't say what the timeframe for this issue is. Have passwords been logged for the last 6 months? Last 3 years? Was this a bug found and fixed last year, and only now are they reporting it?

<comment><USER41> The article does say:

> that they were exposed for "several months."

<comment><USER42> Same as Github it seems.

I wonder what library was used, and which other companies use it which hasn't told their users. That'd let us know who isn't as transparent...

</comment></comment></comment><comment><USER43> Are Github & Twitter using the same logging tools/service? Btw, Happy World Password Day!

<comment><USER44> For context: [https://www.zdnet.com/article/github-says-bug-exposed- accoun...](https://www.zdnet.com/article/github-says-bug-exposed-account- passwords/)

</comment></comment><comment><USER45> This seems like the sort of problem that typed programming can vastly reduce. In a language where string representation is controlled by the data type itself, one could protect against emitting passwords in plaintext accidentally. You'd still be vulnerable until deserialization happens, but that's a lot less surface area to worry about.

</comment><comment><USER46> Twitter hasn't figured out how to properly handle passwords after over a decade of its existence? No, I'm not changing my password, I'm deleting my Twitter account for good.

I'm tired of big shot Internet companies getting away with such bland disregard of basic security and privacy rules.

<comment><USER47> Its a mistake , it happens. Software is hard. Change your password.

<comment><USER46> It would be fine, but people who claim to be pro in software and are being paid premium refuse to learn from mistakes, neither from their own nor from others'. They just mitigate the fallout by saying things "It's was a mistake, sorry about that, it happens, software is hard".

Brain surgery is hard. Mistakes happen. But after a few mistakes you probably should stop doing brain surgery altogether. At least the patients will get a higher chance to survive your surgeries by avoiding _you_.

In terms of security, handling passwords should be considered analogous to brain surgery. A single mistake undermines the whole thing. If you can't handle that, stop doing it, and let people do it who can handle it better.

<comment><USER48> Paying people more doesn't prevent mistakes.

If you banned every developer the first time they made a mistake their wouldn't be any developers.

<comment><USER46> No, it doesn't. And that's not the issue. It's OK to make mistakes if you learn from them to prevent them from happening twice or trice. But apparently even if paid premium they don't. There were soooo many password db hacks and cracks in the recent years, I can't believe people still defend bad software engineering as if mistakes is a natural occurrence which cannot be prevented. You can't prevent singular mistakes, but you well damn can make it hard to exploit them!

If you keep and let bad developers in software security even if they made the same mistakes (and mistakes of others) repeatedly there won't be any _security_ left. So what's the point?

<comment><USER49> Would you relax? If what Twitter says is true (and there's no reason to think it's not), these were passwords which were logged to plaintext logs, which only people internal to the company can read.

We're not talking about a massive password breach, a bunch of script kiddies who found a database of plaintext credit cards by going to /admin.php and logging in with "admin / admin", or anything like that. We're talking about a mistake Github themselves made (and if you think Github doesn't know what they're doing in terms of security, I question your judgement).

Furthermore, _when_ was the last time there was a major security breach at Twitter? You're claiming they're "keeping" bad developers and not learning from their mistakes as if this was a regular occurence for them.

And coming from me, I don't usually defend security breaches and malpractice. This doesn't really qualify. They made an official announcement, notified _all_ users, even unaffected ones, both by email and on first login; that's more than you can ask them to do.

What bothers me about reactionary posts like yours is they give negative feedback to companies who actually do right by their breaches, which as is well known in the security field, _is a matter of when, not if_.

</comment></comment></comment></comment></comment></comment><comment><USER50> Why should I change my "passwords"? I only have one entry for Twitch in my password manager.

It's 2018, no sane person would reuse their passwords across multiple sites which can and do get hacked.

<comment><USER51> > It's 2018, no sane person would reuse their passwords across multiple sites > which can and do get hacked.

All of my family does this :(. I think it's really common outside of tech savvy people. I've tried pushing them to use a password manager on their phone, or writing them down so they can use multiple passwords, but they'd rather just use a single one.

Years of bad advice didn't help either:

        - Never write your password down
        - Make sure you use at least one symbol!
        - Make sure you use one capital letter!

[https://xkcd.com/936/](https://xkcd.com/936/)

<comment><USER50> That's an awesome xkcd, thanks.

</comment></comment></comment><comment><USER52> Changed mine, just logged back in to this warning:

Keeping your account secure When you set a password for your Twitter account, we use technology that masks it so no one at the company can see it. We recently identified a bug that stored passwords unmasked in an internal log. We have fixed the bug, and our investigation shows no indication of breach or misuse by anyone.

Out of an abundance of caution, we ask that you consider changing your password on all services where you've used this password. Learn more

</comment><comment><USER53> > The glitch was related to Twitter's use of a technology known as "hashing" > that masks passwords as a user enters them by replacing them with numbers > and letters, according to the blog.

Sigh. They appear to have confused hashing with asterisks.

> A bug caused the passwords to be written on an internal computer log before > the hashing process was completed, the blog said.

So "related" in almost no way whatsoever, then? The state of technology reporting in the mainstream press really makes me despair sometimes.

<comment><USER54> _The state of technology reporting in the mainstream press really makes me despair sometimes._

The problem is that the mainstream press writes for mainstream users, and the state of science/technology understanding in the general public is the real problem.

<comment><USER53> I hear what you're saying, but I think — in this case — the article's just giving too much irrelevant information. I think most mainstream users I know would understand it if it were written something like:

> A bug caused passwords to be written on an internal computer log, the blog > said.

<comment><USER55> I'm not sure many users would understand the issue from just that - <USER2> perfectly reasonable (albeit inaccurate) reaction to that would be "Of course Twitter store my passwords - otherwise how can I log in?".

</comment></comment></comment></comment><comment><USER56> A honest question from a hardware guy:

Why isn't the password hashed and salted client-side, with the salt being sent from server to client?

I understand that hashing in the client side would only substitute the user password for a new one. This alone sounds like a win to me, as it at least contains the damage somewhat in case of leakage, specially if salted.

EDIT:Sorry, I just found the exact same discussion in this thread.

</comment><comment><USER57> It would be nice if they forced a password reset for all affected users and submitted the old passwords to the Pwned Passwords list.

I have trouble believing _no_ passwords have been misused by insiders - sure, there wasn't any large-scale misuse but I am sure someone poaching a few passwords here and there for later mischief (once everything has settled down) would have gone unnoticed.

<comment><USER58> Agreed. I am assuming they will not do it for the same reason yahoo didn't. They are simply afraid of losing too many active users.

Yahoo's case was worse though, since it was hacked.

<comment><USER57> If the previous breaches are of any indication, it's that users don't give a shit - many major websites have leaked passwords ([https://haveibeenpwned.com/PwnedWebsites](https://haveibeenpwned.com/PwnedWebsites)) and they're still alive and kicking; for the ones that have gone down the drain (Yahoo!) it was more because the service itself faded into irrelevance.

Based on that I'd say it would be pretty safe to disclose a breach and reset all passwords; if your service is relevant your users will stay with you, and if not then not disclosing a breach will only buy you time before the inevitable happens anyway.

<comment><USER49> I suspect by "Losing active users", GP meant losing people who get confused or stuck throughout the password reset phase. Twitter is used by a _lot_ of computer novices.

Twitter did disclose this, through email and on first login. Anyone they'd lose because of the breach is long gone and I also think it's probably next to nobody.

<comment><USER58> Yes, I'm purely talking about losing people if they forced a password reset.

</comment></comment></comment></comment></comment><comment><USER59> I once had configured a mail server to log passwords while I was figuring out how to set it up. Then, I turned on logwatch and started using it "for real". Sometime later, while reading through the logs that logwatch was sending to gmail, I discovered that I had been emailing myself login credentials via plain-text emails.

</comment><comment><USER60> Can't we reduce the risk of these accidental disclosures by using public/private key encryption? Ie:

\- server publishes a public key on a fixed url

\- your JS framework (react/angular/form handling/whatever) is modified to, whenever you query the value of a input[type=password], to return a value encrypted with the private key. (as close to the reading of the field as possible, except for eg. 'repeat password' handling)

\- your serverside code decrypt the password as close to their 'VerifyPassword' and 'UpdatePassord' implementation as possible. and fail if they receive an unencrypted password.

This would make it very hard for intermediate steps (middleware, RPC/REST/JSON decoding) to accidentally spill the password, even if they fully log the traffic, and is something frameworks should be able to help you enforce.

</comment><comment><USER61> I don't understand why servers don't just store passwords as a public/private key schema. A private key is algorithmically generated from a password with the public key stored on the server. When logging in the server sends a one- use-only 'challenge' as an encrypted blob to the person logging in. Locally they use the algorithmic private key generated from their password to decrypt the blob and send the response back. And you're logged in.

Seems like a pretty simple system and absolutely nothing that has to be secured is stored server side. Is there some clever reason I'm missing that this system fails?

\----

Even better you can also salt the password->key schema based on something like the username, making table based attacks infeasible.

</comment><comment><USER62> Naive question - wouldn't a lot of these issues be much better if passwords were (on top of server side processing) salted and hashed client-side? Then in principle you couldn't do these cross-site attacks where people reuse their passwords.

<comment><USER63> Cool idea, I like it.

</comment></comment><comment><USER64> So why are they not invalidating exposed passwords like Github did the other day?

At the very least they should have a security alert at the top of your feed or something.

Edit: Looks like they are alerting users.

<comment><USER42> Github didn't invalidate passwords. They sent an email to affected users (or just everyone?) with a generic password reset link ([https://news.ycombinator.com/item?id=16972050](https://news.ycombinator.com/item?id=16972050) )

<comment><USER64> I got forced logged and and required a password reset. That was an invalidation.

<comment><USER42> Oh, then we must have gotten different emails (the one I got was in the linked thread). I didn't know some people got something else!

<comment><USER64> Same email I got. Strange if not everyone was logged out.

</comment></comment></comment></comment></comment><comment><USER65> Might just be a weird coincidence, but at 2:14 PM today I got an e-mail from Twitter with the subject "Security alert: new or unusual Twitter login". I hadn't heard anything about the Twitter bug at that point (was it even public at 2:14?) but I changed my password as a response to that e-mail.

Now I'm wondering if I need to change it _again_... does anyone know what time the bug was patched?

</comment><comment><USER66> Thanks Twitter for making it easy to change my password. Took me all of 10 seconds to do that and review apps with twitter privileges.

</comment><comment><USER67> I think asymmetric encryption would solve all problems. The sever only ever stores the users public key and uses challenge-response to prevent replay attacks.

This is a bad idea, but if you are required that your uses have passwords, you could use their password to seed an elliptic curve private key to create the user key on the fly.

<comment><USER68> So you go to a site, you enter your password, but then javascript creates a private key and public key based on the userid and password (which is a unique tuple). The key will always be the same regardless of the password.

When you first set your password, it sends the public key to the server, which is then stored. If that key was intercepted, it's not a problem.

Then the server challenges by sending a random code, which the client uses the private key to encode, sends back, the server then decodes with the public key. That guarantees that the private key is known by the client, and thus the password is known, but the private key never leaves the machine.

The second time you go to the site, you get the challenge, and respond. Neither private nor public key is transferred.

Do I understand that right?

<comment><USER67> > "The key will always be the same regardless of the password." The keypair is > different for each userid and password. Everything else is correct.

</comment></comment></comment><comment><USER69> No amount of entropy will protect against plain security goofs. "It would take a computer about 115 OCTILLION YEARS to crack your password" some analysis tells me. Guess how many engineers it takes to downgrade any password's strength to "123456".

</comment><comment><USER70> I have two-factor authentication with Twitter and wherever else I can using authy. Isn't that enough for me to not change my password? It truly gets bothersome. Maybe I'll need to break down one day and finally get a password manager. :(

</comment><comment><USER71> I haven't actively logged into twitter in almost a year. Does this affect me?

<comment><USER72> Tinfoil in me says this is exactly the point - to bring people like you back for a second chance.

<comment><USER73> Or get people to accept some change in toc/pp by/after signin-in, possibly due to GDPR pressure.

</comment></comment></comment><comment><USER53> If this happens in a month's time, will they have to pay out $96,000,000 via the GDPR? This came up at my place of work the other day: are data leaks as a result of bugs breaches of the act?

<comment><USER74> IANAL: No, there is a process of stuff before you will get fined. A human error does not suddenly lead to heavy fines, if you can prove that you put everything you can to prevent this from happening, i.e. follow all the processes GDPR defines like data processing agreements with third party processors, technical and organizational measures to protect against privacy violations, documentation of personal data stored with type of processing, type of consent, and such. what example would a data privacy agency set to fine a company that is fully compliant? I imagine you could even get court to side with you on not having to pay a fine.

data leaks of course are always a breach and must be reported. that doesnt mean you get a fine though.

<comment><USER55> Specifically, you'd look to Article 83[1]. It being an unintentional act (83(2)(b)), otherwise following best practices (83(2)(d)), taking steps to mitigate the damage (83(2)(c)), and that Twitter announced the breach (83(2)(h)) weigh heavily in favour of the fine being minimal, or there being no fine at all. Article 83(1) also notes that fines must be "proportionate and dissuasive" \-- there is nothing proportionate about imposing the maximum fine for a simple error, nor dissuasive about fining a company that is otherwise compliant and following best practices.

[1] [https://gdpr-info.eu/art-83-gdpr/](https://gdpr-info.eu/art-83-gdpr/)

</comment></comment></comment><comment><USER47> Announcement is underplaying the situation. Absolutely change the password..anyone could have seen it. Just because there ia no evidence of log reading does not mean anything.

</comment><comment><USER75> I think it's ridiculous that Twitter still allows users to reset their passwords through SMS. How long are they going to pretend that SMS is secure?

</comment><comment><USER76> The partial answer to this is to dump detailed logs after a few days or weeks. That way, even if disaster strikes like this, it can be somewhat contained.

</comment><comment><USER77> Why even hash the password on the remote side, shouldn't some challenge- response hashing be more secure?

The most likely downside is that without JS it won't work.

<comment><USER78> If you hash the password on the client, the hash made on the client is now the password. It's easy enough to send the hash directly, and the server is none the wiser.

That's not to say it's a bad idea, though. I have used client-side hashing in the past to allow passwords of arbitrary length while using finite network resources.

<comment><USER79> That's not true if you ask the client to hash both the password and a one-time token you just send. Knowing both the password/key (which was send during registration) and the token, you can calculate the hash. Otherwise you can't. Password/key is never transmitted. You can also use asymmetric encryption. I always cringe with amateur devs sending plaintext.

<comment><USER80> Your scheme requires the server to store the password in plaintext, and it's transmitted at least during registration.

<comment><USER79> It does. You can do the same with with the salted hash of the password and not the password the user entered. It's still worse than real authentication protocols where you don't store the shared secret at all, but better than those diy schemes described earlier.

Also you can't get away from sending the shared secret during registration. Even with asymmetric cryptography you have to rely on the TLS to make sure you exchange the real untampered public keys.

</comment></comment></comment></comment></comment><comment><USER81> We need a regulatory rulebook codified in law by congress that fines companies that make these "mistakes". Enough of a fine will force companies to take these "mistakes" seriously.

In Yahoo's case, that might have forced Marissa to actually keep a cybersecurity team and not cut them when she knew the systems were in danger of being compromised. We aren't getting any jail time, but hefty fines that don't stifle growth, just punish negligence and carelessness that are codified and don't need long court hearings to pass are a must.

<comment><USER82> "Technology by legislation" \- that's the new trend it seems. How about replacing passwords with something technologically superior instead?

<comment><USER83> It isn't a new trend.

Section 508 of the Rehabilitation Act legislated that the government purchase accessible software.

HIPAA legislated that your medical data be kept secure.

Minnesota, Nevada, and Washington have enshrined some or all of PCI DSS into law: [https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...](https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard#Mandated_compliance)

A little farther afield, seat belt technology has been legally mandated to be included in most automobiles sold in the United States since 1968: [https://en.wikipedia.org/wiki/Seat_belt_laws_in_the_United_S...](https://en.wikipedia.org/wiki/Seat_belt_laws_in_the_United_States)

<comment><USER82> Those are great examples of regulations that actually benefit the user. When the regulation however addresses the wrong problem, then it becomes burdensome and dumb. If the user uses a simplistic password, his account will be hacked even if it's never leaked. Studies show that bad passwords and phishing are more destructive than leaks.

</comment></comment></comment></comment><comment><USER84> Did not GitHub do the exact same thing yesterday?

</comment><comment><USER85> Exactly the same thing happened with GitHub couple of days back. Funny both faced the same issue within days of each other.

</comment><comment><USER86> Wouldn't you have to be an employee of the company to get the passwords since you need access to the log files?

</comment><comment><USER87> So why arent they hashing passwords on the user side?

Can't leak a password if the only thing you have to begin with is a hash...

<comment><USER88> Asked and answered in the thread above:

[https://news.ycombinator.com/item?id=16990570](https://news.ycombinator.com/item?id=16990570)

</comment></comment><comment><USER89> It's really hard to avoid logging passwords when there's a parse error on structured data that includes a password, for example if there's malformed JSON in the authentication HTTP request. A weird error like that is exactly when verbose logs are essential, but it's also a time when your system doesn't know what it's logging. Amazon has a machine-learning based service to try to deal with this.

</comment><comment><USER90> Legitimate, non-cynical, non-opportunistic question. Will this boost Twitter's monthly active users?

</comment><comment><USER91> must be the same logging library/framework as github. I want to know which library it is.

<comment><USER42> And which other companies use(d) it, so then we know whom to trust (i.e. those who came forward after finding it).

</comment></comment><comment><USER92> How exactly does one manage in a major company to set up an app in production that spits passwords, or even less sensitive customer data, to a logfile?

Is that the state of infrastructure engineering? The cynic in me wonders if it's related to the trend to take developers with some systems knowledge and turn them into Ops/SA's.

</comment><comment><USER93> While you're in there, enable 2-factor authentication if you haven't already.

<comment><USER94> it seems like they only offer SMS 2fa which is a bummer.

<comment><USER93> That isn't true. I use Google Authenticator with them.

</comment></comment></comment><comment><USER95> This will be my excuse of simply logging everything :-)

// logger.log(request.payload);

</comment><comment><USER96> And I thought first hashing done at browser level.

</comment><comment><USER97> Did GitHub's post make them realize this?

</comment><comment><USER98> That is just to force users to accept their f __k __g rules. S __k my d __k b __*h Twitter!

</comment><comment><USER99> if they can leak these, god knows what else they leak and where and for how long

</comment><comment><USER100> For the thousandth time, can we be done with passwords and move to physical tokens please?

</comment><comment><USER101> Reminder that none of this would be necessary if nobody reused their passwords.

<comment><USER102> Sure it would. People using Twitter still need to change their password even if it is the only place they use their password.

<comment><USER101> To defend against what? That some guy at twitter who saw the logs can login and change somebody's status?

Anyway, I guess you're right, I simplified. It is kind of a valid point, although if I was this paranoid then I would never leave the house. I just wanted to say that if the web wouldn't have been built on a giant piece of s __ __ __ __*, for example password authentication, none of this would have been necessary.

</comment></comment></comment><comment><USER52> "We are very sorry this happened," the Twitter blog said.

<comment><USER103> That stuck out to me too. They skirt admitting blame with that carefully crafted apology.

</comment></comment><comment><USER104> The "right" way to handle this is to revoke access to all logged-in devices, revoke all previous passwords, send an email notifying users of the revocations, and force a password change upon next login. But Twitter won't do that because a non-trivial percentage of their user base would never jump through the hoops to get things up and running again and Twitter's MAU numbers would sink.

<comment><USER105> This doesn't make a big impact in the end because of how prevalent password reuse is.

<comment><USER106> This is an opportunity to run Troy's filter on the new password.

</comment></comment></comment><comment><USER107> How is something like this even possible?

It just sounds so incompetent.

<comment><USER108> seriously? pretty easily. somebody probably left a debug log message in place or something. guaranteed that this happens all the time and most people don't report it.

<comment><USER109> I doubt anyone left something that logged the plaintext password. No reasonable architecture necessitates holding onto a plaintext password for more than one line of code.

One possibility is an HTTP server on the request path after TLS termination. But then why is an HTTP server logging the request body?

My guess would be some sort of instrumentation process was blindly reading data in memory without distinguishing _what_ the data was, but produced logs that incidentally included passwords.

<comment><USER26> In my experience, I've seen both of the following scenarios:

POST request comes in from the client. Full URL and request body is logged. Sometimes for simply troubleshooting, sometimes for security reasons (e.g., wanting to know all data coming in so that it's possible to identify security holes after they've been exploited).

POST request comes in from client. Frontend server makes a GET request to a backend server, and the password ends up in the standard request logs. In one case, I've seen this happen because the developer thought path variables were cool, so every API they wrote looked like /a/b/c/d/e. Sigh.

</comment></comment></comment></comment><comment><USER110> > Due to a bug, passwords were written to an internal log before completing > the hashing process

This isn't a bug, it's incompetence. Remember folks, never, ever use the same password for two different websites. Assume all websites store your password in plain text even if they hash it at some point. With logging and tracking on steroids these days, I expect "bugs" like this to be commonplace.

</comment><comment><USER72> This smells like an attempt by Twitter to get as many users as possible to log in to Twitter so they can report XXXX% increase in monthly active users. With the added bonus of perhaps converting some who gave up on Twitter back into actual active users going forward.</comment>


95% of climate models are not wrong. - <AUTHOR> http://blog.hotwhopper.com/2014/02/roy-spencers-latest-deceit-and-deception.html

<comment><USER2> [http://journals.ametsoc.org/doi/abs/10.1175/MWR-D-12-00352.1](http://journals.ametsoc.org/doi/abs/10.1175/MWR-D-12-00352.1)

Of course, to draw any conclusion at all assumes that actually have "data" in their output, and haven't been sloppy with their floating point arithmetic - especially how re-ordering calculations (due to parallel processing) is _non- transitive_ in FP.

anybody writing a big, comples model needs to know about fp:

[https://randomascii.wordpress.com/2013/07/16/floating- point-...](https://randomascii.wordpress.com/2013/07/16/floating-point- determinism/)

[http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.ht...](http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html)

</comment><comment><USER3> "lie in plain sight"</comment>


List of dead Google products, services, and devices - <AUTHOR> https://killedbygoogle.com/ <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=18513030](https://news.ycombinator.com/item?id=18513030)

Related discussion (lots of comments): [https://news.ycombinator.com/item?id=18509735](https://news.ycombinator.com/item?id=18509735)

</comment><comment> B-Con "killed" implies it ceased to exist, so I think it's misleading to include rebrandings or relaunches where functionality gets folded into another product.

At a glance...

* Nexus wasn't killed, it was re branded into Pixel. Nexus had been trending toward premium and the Pixel switch cemented that.

* Googles was more-or-less replaced by Lens. Not a pure rebrand, but two products with the same idea.

* Google Now has essentially been folded into the expanding behemoth that is Assistant. I don't care for that kind of feature, but AFAICT they're fairly similar.

* Quickoffice was an acquisition that was promptly folded into Docs/Sheets/etc.

<comment><USER3> Nexus was never "premium". Quite the opposite it was developed-oriented and amazingly affordable. Unsubsidized it cost around 50% of what other flagship phones cost. Pixel changed that by effectively doubling the price.

Given the quality issues google had with Nexus phones (which was real), I could absolutely not justify spending twice the money on fake premium phones which seemingly still suffered those issue, based on reports after the Pixel 1 launch.

<comment><USER4> My Nexus 6s cost me $649. Nearly the same price of the latest iPhone at the time. How does that square with "amazingly affordable"?

<comment><USER3> That was the last and also most expensive Nexus of them all. Definitely not representable.

In comparison my Nexus 5X (launched at the same time) cost me around $350. I could _literally_ have bought two of these instead of one iPhone (or Samsung Galaxy).

</comment></comment></comment></comment><comment><USER5> Building products/features and then killing them when they don't work is generally fine. And renaming/merging/consolidating them isn't really killing them. But…

> Sparrow was an email client for OS X and iOS. They acquired and then killed > it. It was over 1 year old.

Buying then killing is sad. Acquihire I guess?

> Google Reader was a RSS/Atom feed aggregator. It was over 7 years old.

These are the ones that feel like they hurt the internet. That was seven critical years for RSS/Atom. Investing time/money in building feed aggregators/readers meant competing against the might of Google and a $0 price point.

<comment><USER6> Lots of acquihire indeed. And in the case of sparrow and a lot of others, it was a secret. So one could wonder who is to blame; Google for acquihiring companies to fulfil hiring needs, or those companies that accept to get acquihired depiste having a (sometime) successful product that people are paying for.

<comment><USER6> I can't edit. I meant "it was NOT a secret".

</comment></comment></comment><comment><USER7> The list is very long. I really wish a rebranding or renaming or merging of services was somehow listed or displayed separately. This would give a better idea of the services actually killed.

</comment><comment><USER8> Most of these haven't been killed but just rebranded

</comment><comment><USER9> Why does this keep resurfacing? Yes, Google tries some things out, they make value assessments and move forward with what they believe will benefit them. It seems the general consensus is that Google 'hates' or 'doesn't care' about its users when it cancels a project/product.

Sometimes even with almost unlimited resources (Windows phone) the plan just doesn't work out. I don't get why the tech community in general likes to harp on them for it.

<comment><USER10> Because they call the entire community to invest themself hard in their new baby, but don't want to do the same commitment themself.

</comment></comment><comment><USER11> By the way killing products and thus accepting failure is usually necessary for innovation.

<comment><USER12> I just finished Peter Druker's classic "The Effective Executive" and he really strongly emphasizes the need to throw out the old:

"The first rule for the concentration of executive efforts is to slough off the past that has ceased to be productive. Effective executives periodically review their work programs—and those of their associates—and ask: 'If we did not already do this, would we go into it now?' And unless the answer is an unconditional 'Yes,' they drop the activity or curtail it sharply."

Drucker, Peter F.. The Effective Executive (Harperbusiness Essentials) (p. 115).

</comment></comment><comment><USER13> I'm still bitter about the Google Inbox death. It's been my favorite iOS Gmail client by far.

</comment><comment><USER14> > Google Allo is an instant messaging mobile app by Google. It will be > rebranded as Google Chat.

Does not sound like it was killed if it will continue to live with a new name.

</comment><comment><USER15> I dony see what the issue is they are doing technical debt right.

The ones that worry me are aws, their technical debt would be hugggee with all those services and they keep piling it on, now maintaining their own elastic search repo!

Eventually some of the older service have to give and with there lock-in not lock-in it will hurt some -just a thought

</comment><comment><USER16> I think when they killed Google Reader is when I realised that I don't want to count on Google any more.

</comment><comment><USER17> Google+ and goo.gl are currently being archived by the ArchiveTeam, goo.gl as part of the URLTeam and G+ in a dedicated project. My warrior already uploaded over 100GB of content and in total the project has saved 149TB of data from google's endless thirst for killing things.

</comment><comment><USER18> In a somewhat disingenuous site, the webmaster left out the granddaddy of them all: Google Search[0]

[0] [https://news.ycombinator.com/item?id=19387010](https://news.ycombinator.com/item?id=19387010)

</comment><comment><USER19> This reads more like a dedication to R&D than a list of shame.

I understand why / how people are pissed, I got pissed at some of those too, yet I do also accept my overall quality of digital life is improved by these bold moves in the long run.

</comment><comment><USER20> Google Wave was a lot of fun back on the day, they were just experimenting with real-time editing that ended up in Docs, but it sure led to some crazy conversations :)

</comment><comment><USER21> In cases where there's no merging with another product, what happens to the codebase, assuming it's not open-sourced?

<comment><USER22> rm -rf <productname>

Jokes aside, I am also curious about this. I could imagine them splitting it up and reusing the useful functionality in other products?

<comment><USER23> Pretty sure most of it gets deleted. Every piece of existing code needs some sort of occasional maintenance to remain functional or useful.

</comment></comment></comment><comment><USER24> Still use Google Desktop today. It is much, much, much better than Windows search in term of speed and functionalities.

</comment><comment><USER25> This was an really unexpected loooong list!</comment>


Become an Official Software Freedom Conservancy Supporter - <AUTHOR> http://sfconservancy.org/supporter/ <comment><AUTHOR> "Conservancy assists FLOSS project leaders by handling all matters other than software development and documentation, so the developers can focus on what they do best: improving the software for the public good."

All of their projects: [http://sfconservancy.org/members/current/](http://sfconservancy.org/members/current/)

<comment><USER2> I would donate but only if 100% of the money goes toward the projects and not social causes such as teaching x/y/z to code or an outreach program for demographic a/b/c (looking at Gnome Foundation and Mozilla here).

<comment><AUTHOR> Not sure about their financials, but they're pretty transparent overall. Some of their internal policies (linked from that support page) are in their git repo [https://gitorious.org/conservancy/policies](https://gitorious.org/conservancy/policies) and their list of services seems pretty clear: [http://sfconservancy.org/members/services/](http://sfconservancy.org/members/services/)

<comment><USER3> Their tax filings are at [http://sfconservancy.org/about/filings/](http://sfconservancy.org/about/filings/) and a couple explanatory posts [http://sfconservancy.org/blog/?tag=filings](http://sfconservancy.org/blog/?tag=filings)

One of the organization's staff (but not as an official activity, afaik) has a repository of filings of many free/open type organizations, [https://gitorious.org/floss-foundations/npo-public- filings/](https://gitorious.org/floss-foundations/npo-public-filings/) which is useful for comparison purposes, and welcomes contributions of info (most of it is available elsewhere on the web, but can be hard to find). Perhaps ought to be a website.

</comment></comment></comment></comment><comment><USER4> It really pains me to be critical of what is a good thing, but I do wish that they would hire a designer for their website.

There seems to be a rejection of design in OSS (less so these days, I admit). I really like the idea of judging software solely on how it stands alone, but people don't do that, and to many this will just come across as amateur.

<comment><USER5> I'm afraid they cannot hire a designer, but maybe they could accept a few pull requests? (Unfortunately, I failed to find their site on githib, but probably they have a repo somewhere.)

<comment><USER3> [https://gitorious.org/conservancy/website](https://gitorious.org/conservancy/website)</comment></comment></comment>


The diversity of various tech companies by the numbers - <AUTHOR> http://pxlnv.com/blog/tech-company-diversity-stats/

<comment><USER2> I wish they would have included demographics for the Bay Area, not just the USA. From Wikipedia - 52.5% White, 6.7% non-Hispanic African American, 23.3% Asian, 10.8% from other races, 5.4% from two or more races, 23.5% Hispanic or Latin. (Incidentally, this almost exactly matches Apple's numbers, except for Hispanic). Comparing tech worker demographics to Bay Area demographics, It's kind of a chicken vs egg about whether the demographics precede the jobs or vice versa, but given how geographically concentrated the tech industry is, this seems like a bad oversight.

So compared to the US, the Bay Area is -27% white, -6% African American, +18% Asian, +8% Hispanic. This makes the representation of white tech workers expected, Asian less overrepresented, African American less underrepresented, and Hispanic even MORE underrepresented.

In non-tech, it's white slightly overrepresented, African American slightly underrepresented, and Hispanic still very underrepresented.

In leadership/executive, white captured most of Asian overrepresentation, and African American are similar to tech workers.

2\. SF vs Peninsula/South Bay companies would have been another similar distinction.

3\. Curious how MSFT compares to Seattle Metro.

4\. I'd also be curious to see how it would look if they broke out demographic numbers by location - e.g. how different is Google Mountain View from Google NYC, and how do tech worker demographics outside of the Bay Area compare to their host cities?

</comment><comment><USER3> >>Gender Diversity in Non-Tech Positions

and Twitter is 50% Male and 50% female!That;s like they aimed at 50% and achieved that!

</comment><comment><USER4> SV diversity: 1) workforce is 50% Indian, 50% Chinese. 2) Hiring from both mainland China _and_ Taiwan. 3) hiring from all over India, not just Bangalore.

</comment><comment><USER5> [http://do-better.herokuapp.com/](http://do-better.herokuapp.com/)</comment>


Extreme Scale Computing - <AUTHOR> http://blog.irvingwb.com/blog/2010/02/extreme-scale-computing.html#

<comment><USER2> A lot of random thoughts came to mind when the author referenced mainframes.

My father and I argue/discuss this sort of thing often. Mainly because we're from two different worlds. He comes from a Mainframe (z/TPF) background and usually laughs at what we think is high-performance or a heavy load on our web servers. (He also likes to ask when I'm going to learn a real programming language like assembler.)

Just last night I was asking him why web companies don't run companies of just one of these juggernauts mainframes. The price of the hardware seems to be the biggest hurdle. But there's also the fact that if you want 'feature x' with how you store data... well you write it yourself so that it runs as fast as possible. You won't find VISA running distributed MySQL instances anytime soon. The mainframe mindset seems to be that you build the system EXACTLY how you need it. No More, No Less! The way I think of it is like Lego blocks.

Today we take a companies like Twitter who think "We have a lot of different kinds of blocks, how can we make them fit together and do what we need."

Mainframe developers think "We need to handle tens of thousands of transactions per second doing X. So lets make our own blocks that fit together perfectly and do exactly that."

This means you end up having to re-invent a lot of things. But you re-invent exactly what you need and leave out the rest. I wonder if the future is in a hybrid of these two types of systems. Perhaps we need to put Mainframes in the Cloud and let people purchase time on them like Windows Azure & AWS. I would certainly like to play with that kind of horsepower. Or perhaps the future is in something that doesn't exist yet which the author seems to suggest.

<comment><USER3> What you are suggesting was called Time-sharing (1960s). <http://en.wikipedia.org/wiki/Time-sharing>

</comment></comment><comment><USER4> Supercomputing is a moving target. Irving Wladawsky-Berger has given a nice summary of how supercomputers are scaling (we are beginning to see petaflop machines) and what the challenges for the scale up to exascale computing will be and the significant changes to predictive modeling that they will enable.

In case you have not noticed, supercomputing (at least at the teraflop level) has become mainstream. We are beginning to see monolithic supercomputers, that is, machines primarily dedicated to a particular application or sub- application, in a variety of production situations. Often these monolithic supercomputers are constructed of standard commodity servers; some use hardware accelerators to substantially improve throughput or real time performance by exploiting unrealized parallelism. Specialization by an accelerator can improve throughput by significant factors, often an order of magnitude or two.</comment>


DNA Data Storage: A Solution for the Digital Dark Age? - <AUTHOR> https://macleodsawyer.com/dna-storage <comment><USER2> Huh, I have always been slightly worried about what happens to information when it stops being maintained, maybe this could help?</comment>


Ask HN: What conferences to attend as an engineering manager in 2016? - <AUTHOR> <comment><USER2> Lead Developer was great last year [http://theleaddeveloper.com/](http://theleaddeveloper.com/)

<comment><AUTHOR> thanks, looks promising!</comment></comment>


Done Playing Microsoft's Corporate Game - <AUTHOR> https://www.software-engineering-unlocked.com/episode-10-no-corporate-games/ <comment><USER2> I also hated the games played at the large corporations I worked for. Another thing that really bugged me is the lack of control. If they make a decision somewhere above you, the only thing left for you is to jump.

<comment><AUTHOR> I also prefer working for startups or smaller companies nowadays: working closely with the management team helps to understand strategic decisions first-hand.

I also found people at smaller companies to be more motivated , and eager to bring their own ideas to the table. Often, because they feel valued by the founders and see the direct impact they make on their customers.</comment></comment>