Hacker News new | past | comments | ask | show | jobs | submit login
Silent Circle's warrant canary is out of date (silentcircle.com)
148 points by scotchmi_st on Dec 25, 2014 | hide | past | web | favorite | 107 comments

First off I have no standing here, and I am nobody. I am a customer of Silent Circle though. (or so I claim)

I am sure that StavrosK is well known by the community and it is my fault that I dont know his connection with SilentCircle. His profile points to stavros at stochastic dot io.

But more importantly HackerNews is not a very secure platform.

We have no real way of knowing StavrosK is StavrosK, or if ThinkBeat is the same ThinkBeat as last week. Using Hackernews or any social media as a platform to "override" a warrant canary is ill advised. In fact I think it makes matters worse.

Properly signed messages through the announced channel is the way to go.

Yep, this is definitely true. The only way to get this resolved is to update the canary. I can prove I work there, but it's irrelevant.

I also want to note that I didn't try to override anything, dang helpfully tried to temporarily hide this post to avoid causing a panic while we get this resolved, but that doesn't change the fact that this is still a problem we need to resolve.

I think this needs an additional safeguard, such as the destruction of the private key associated by the messages and a defined 'grace period' (defined up front, not after the fact) in case of a missed update as well as a very good procedure to update and check that the update has indeed been made.

What sort of grace period do you mean? For which?

Missed updates, which is what this thread is all about. So say you define up front that you're going to update your canary once weekly but that you reserve the right not to update it for up to three weeks before you consider the canary to be in a state where you can't revive it. This adds a bit of leeway in case someone sleeps in and because you define it up front you can let your users determine if they are comfortable with the period specified as 'uncertain'. Any time beyond that grace period and you're definitely compromised, any time between the normal interval and the grace period and you're in 'degraded' mode and as long as you are within the normal interval you're good.

Personally I think the grace time should be much smaller than your normal update period for the system to continue to work without appearing incompetent after all if you can't be bothered to update the canary you probably should not be trusted with critical data. It's not as if it is a large amount of work and it's not as if checking whether it is done or not is a large amount of work either. In fact, the update should be manual but the check could easily be automated and a 'canary out of date' text message could easily be sent to all the people working for companies such as silent circle if they take their job seriously.

I build a grace-period into the warrant canary that I publish by a very simple method: I issue each canary early. Each canary has a stated expiration date that is either the 15th or the last of the month (the lazy man's bimonthly), but the scheduled reminder to update it goes out the 13th and third-to-last day. Usually I take care of it immediately, so a new canary is issued e.g. the 13th that expires the 31st.

So, I essentially have a built-in grace period of two days before the canary expires, and users know that a canary issued on the 13th or 14th is also fine. I really don't see any downside to this method except for the fact that it extends the effective interval between canaries up to two days (the same as a two-day grace period would, but with less reduction in confidence). And in my application that interval varies based on the length of the month anyway, so you can see that I'm not particularly concerned about the length of the interval so long as there is a clearly defined date after which users should worry.

That's clever! And elegant too, no added uncertainty.

Right. This goes back to the coercion issue, which I don't personally believe is valid. If one can be coerced to update a canary, then all bets are off. If they can't, there's no need to institute a grace period, as a canary won't ever be completely invalidated.

Obviously, the longer a canary stays outdated, the better the explanation should be, and I wouldn't trust a daily canary that started getting updated after six months, but I think missing one or two updates isn't that farfetched.

In Silent Circle's case, specifically, I don't think a NSL would have much utility, since we retain almost no customer data at all (only username/password, and optional email/name). I like the idea of automating the canary check message, though, and will write a script to do that right now, thanks.

> Obviously, the longer a canary stays outdated, the better the explanation should be, and I wouldn't trust a daily canary that started getting updated after six months, but I think missing one or two updates isn't that farfetched.

I don't see any factual difference between the two but I realize that humans are fallible. Note that you are still assuming that the only way a canary could be updated is by coercion, a keylogger installed at the right moment would allow one to update the canary absent the original updater just as well and as such I think canaries are of limited use.

But if you do have one it should simply work as advertised.

Isn't the real value for such monitoring in the future traffic and traffic analysis rather than the content or the customer data?

A grace period for the case that you forget to manually update the canary. Say you forget it, but after x amount of days you (or someone else) notice, then you update and continue.

That grace period needs to be well defined, announced and properly used. Having a grace period of almost 3x the announced update rate (5 -> 25th of December) is IMHO not acceptable.

Doesn't that introduce too much ambiguity into what is supposed to be an unambiguous signal?

It definitely increases the risk but whether or not that is acceptable or not is up to the users of the service. Hence my insistence that such a grace period should be an up-front thing. A service provider that starts out with 'we'll update this canary once per week, maybe, and if not maybe once per month' would not be deserving of my trust. One that says 'we'll update it once per week +- 12 hours on monday at noon' would be much more credible. It's just as much about confidence and competence as it is about the canary principle to begin with. If you're going to dilute that principle then err on the side of caution but recognize that humans are fallible. Better still, overdeliver and update it every 6 days if you promise 7, it's not that hard to make an agenda item out of it and do some automated alerts around the process of the update (not the update itself, obviously).

Ok, so from a conspiracy perspective:

Lets say there was a good reason for the canary not being updated.

I the FBI or whichever law enforcement agency was involved in the process noticed that updates were missing, (or saw it because it was pointed out on a well trafficked website)

Could the law enforcement agency then compel the employees to post a note that it was just a mistake and it will be rectified soon? And then have them update it?

Since not updating it when asked would equal disclosing that the event had taken place, which under certain laws might be illegal?

This hurts my head.

Or, since Silent Circle partakes of extremely misleading marketing and claims you can make encrypted calls all over the world, LE can just go tap the VoIP providers they use. Legally, or, since almost all VoIP is unencrypted, just by tapping Ethernet. Seriously, go read the press release for the BlackPhone and tell me you'd trust their CEO at all. Even Mr Zimmerman admits the entire business relies on LE not coming into their office with guns.

What? Where is this claimed? As far as I know, all claims are that OCA calls are encrypted to the server.

It sounds like you're confusing the PSTN calling offering with the Silent Phone service itself, which is encrypted peer to peer.


"enables Silent Circle members to make and receive encrypted, private voice calls through the company's Silent Phone service to non-Silent Circle subscribers in 79 total countries"

The PR goes on and in about how "disruptive" this is, even though it's much more expensive than Skype, and about as secure.

It's highly misleading. The PR obviously wants people to buy this product for security and encryption, but it can't deliver. It's about as good as using SIP+TLS/SRTP, Skype, or a VPN. Yet given the high cost (12 cents a minute) plus the marketing, it makes users believe they're getting actual encrypted calls. You guys should clearly state in the marketing and in-app that the call gets a first hop encrypted, then dumped unencrypted out to the Internet/PSTN (which nowadays are rather intermingled, sometimes when least expected).

Other stuff like "100% dedicated network – no sharing or leasing" sounds like it's probably untrue, or uses a special value of 100%. Either way, such statements should be backed with clarification.

Finally, there was a PR with Mike Janke, linked here on HN about a year ago. I can't seem to find it now, but he says a bunch of misleading/false things while writing off competition and makes SC come off rather slimy. Y'all shouldn't let him talk for the company as it makes the engineers look bad. (Not to mention the whole thing about Blackphone - a closed source fork of Android with a few 3rd party apps, no mention of the baseband processor issue, yet billed as some amazing breakthrough and it's own OS.)

SC should lower the hype and be transparent about things. Overall, I get the distinct impression it's a marketing joint bankrolled by a non technical founder, who hired some good names and provided a commercial vehicle for zRTP. Which by itself is fine, but the execution feels more marketing than technical.

PS, if you're using FreeSwitch, then I gotta ask: where are all the CVEs? Are you fixing them privately, publicly without announcement, or are you using FS without a security audit? (The only reason I mention this is SC often seems a major sponsor of ClueCon.) If not FS, what is your VoIP platform, and in what language is it written?

Yes, they could. A federal judge can compel people to do many, many things.

I would be worried about that long after I'd be worried about people simply striking a deal in some trumped up criminal lawsuit after being suitably intimidated.

Is a warrant canary even legal? If it isn't, what's the point of having them?

From http://en.wikipedia.org/wiki/Warrant_canary

The US security researcher Moxie Marlinspike states that "every lawyer we've spoken to has confirmed that [a warrant canary] would not work" for the TextSecure server.

Direct link: https://github.com/WhisperSystems/whispersystems.org/issues/...

The main worry for TextSecure is that Google upon receiving a NSL will send you a targeted update for the TS client and GAPPS framework that sends all your msgs to a three letter agency before being encrypted and sent as usual. So Google would need a canary for the play store

Except for the fact that Google does not have the signing keys that are used for the TextSecure binaries. They cannot silently distribute a binary that has been tampered with. This distributed trust system is one of Android's strengths:


To clarify, so Google can distribute a binary that has been tampered with, but it'd be trivial to prove that they had in fact done that?

That's correct. Android will warn you if the signatures don't match too. Even if we're in the full-on conspiracy theory territory of Google disabling that core security feature, impersonating a third-party developer, and dropping a binary onto a single user's phone, they still couldn't fake the signature.

They could simply disable the warning. It's android giving the warning, not the app.

Unless you have a phone still vuln to the Android signature bug, which is millions of devices still running unpatched carrier builds.

But they own the OS, so I guess they can intercept whatever they want before it even reaches the app.

Though don't they control the code that does the signature checking?

If you're concerned about that threat vector, you wouldn't be using GAPPS/Play. Except that's the only way they'll distribute TextSecure.

The EFF quote in your link suggest yes.

Reading this canary has me worried, it doesn't actually say that "no warrants have been served, nor have any searches or seizures taken place", it only says that a declaration stating that will be provided.

Compare this to rsync's (http://www.rsync.net/resources/notices/canary.txt), which this seems to have been based off of. It explicitly states "No warrants have ever been served to rsync.net, or rsync.net principals or employees. No searches or seizures of any kind have ever been performed on rsync.net assets, including:..."

You're right, it looks like the wording is a bit unclear. I'll talk to the guys to see if we can get it updated, thanks.

Maybe they were indeed slapped with an NSL. What a nice christmas present, huh!?

If they failed their own canary - how could you believe them in terms of their warant canaray setup ever again? Not so much at all, I'd say.

The entire purpose of a canary is to get manually updated. Automating it would defeat the purpose. If the person (or people, but you'd want to keep them as few as possible) was sick, unavailable, etc, it obviously wouldn't get updated.

A canary also fails open by design. There's no way for the canary to fail on the side of getting your data compromised. If we forget to update it, you should just be more cautious, until we update it again (if we do).

I may be persuaded that the individual tasked with signing and updating the canary got drunk over the Holidays and forgot.

Nobody is going to convince me that same individual went on a twenty day bender and sobered up on Christmas morning.

Of course it needs to be manually. Fail open? A warrant canary system setup for the sole purpose of telling the whole world (and the clients, of course) that they were hit by not posting "a declaration that, up to that point, no warrants have been served, nor have any searches or seizures taken place".

Can there really be a fail-open or fail-safe here?

Edit: "not posting" fixed.

Yes, forgetting to update the canary = safe. If you had a system that signed stuff until you stopped it, it would fail unsafe, i.e. it would keep telling people they're safe when they weren't.

You realize, that forgetting to update the canaray gives the same message as "we were hit by a big fucking NSL, don't trust us and our software and systems ever again as their security has been compromised."?

From the outside, there is just no way of knowing that it was just a forgotten update or if it was a strong message.

Hey, I'm not any happier about this than you are. I'm just saying that at least it doesn't lull users into a false sense of security, which would have been disastrous.

What's your threshold to "disastrous" in terms of a missing warrant canary then? 3 weeks? 1 month? 2 months? longer?

Not missing the canary when you were served an NSL.

So it looks now, that the canary got updated. No other information given, at least not within the canary itself.


[DELETED, wait for an official company response or canary update]

That's pointless. It's like allowing an alarm to ring without cause. Next time it rings the canary won't be trusted until you personally vouch for the fact that it wasn't an accident, and if that's the new channel the canary has lost its value.

False alarms are lethal for something as important as this.


"That's pointless. It's like allowing an alarm to ring without cause. Next time it rings the canary won't be trusted until you personally vouch for the fact that it wasn't an accident, and if that's the new channel the canary has lost its value."

That's not really true.

The canary is only "dead" and that channel is only useless until a new one is published. Unless the operator of the canary has decreed in advance that a particular time period elapsed should be considered "dead" regardless of future updates, then the canary is alive and well as soon as a new update comes out.

Here's the thing - a warrant canary is, by definition, a manual process. It should never be automated. A human has to resign and republish (or they are doing it wrong). And this means that sometimes they get published late.

In the 9 years that we (rsync.net) have been publishing our canary, we've probably missed our normal Monday morning publish 10 or 15 times. But as soon as we publish, with the affirmative canary and it's signature and language, etc., it's alive and well again.

Obviously this changes if someone is months late with an update.

That's pretty accurate. So now you need to figure out what a reasonable time is. Once you get public postings about your canary being dead without having made an update it is in beyond repair territory for me. A day late, maybe. More than the normal interval between updates late: too late. In between: debatable, but not looking good either. It's like making a promise and then not keeping that promise.

By how much did you miss your Monday morning deadlines? Did you ever go a whole week without an update? Is someone tasked with doing it and someone else tasked with checking that it has been done (which is the way this should be set up, preferably with more than one person for the second role backed up with an automated process that sends out messages of impending aviary demise).

"Obviously this changes if someone is months late with an update."

That's what I was asking before - what is a reasonable timeslot for being "late"? Is it "months" or "weeks" or the <deltaManualUpdateT+1d> of canary x? In this case, SC was almost 3 times their weekly update rate late (December 5th to December 25th).

When we have been late, it's been 8-12 hours.

Once it gets to weeks, I think something else is going on.

That's what I exactly tried to convince the parent before and I even got downvoted for it. So it sure looks like, someone has to explain everyone here why Silent Circle has a warrant canary and how we should interpret it....

I suspect you got downvoted more because of the tone than because of your intended message. But don't sweat it, I got downvoted more than once in this thread too. What matters is that silentcircle realizes that missing such self-imposed deadlines is something that matters and that everybody is on the same page. Shouting 'you don't have a clue' and 'resign' doesn't help at all, when clearly it is mostly a matter of interpretation.

I'm not trying to tell you that it's okay that this happened, I just saw this post while waiting for a deployment and figured I'd comment. Now I'm kind of regretting that.

I'm sure you're aware of why it is called a canary, but on the off chance that you or anybody else reading this is not: It's a reference to mine gas detecting canaries, the canary would die when an otherwise invisible gas was present which would kill the people later than it would kill the canary. So when the canary keeled over it was well past the time to leave the mine pronto. Now that your canary is dead you are going to have a hard time to revive it for that particular entity, silentcircle is - as far as I'm concerned - dead. From now on you'd have to assume the site has been compromised and any remarks by you or others that there is nothing going on here should be interpreted as having been coerced. See, if you were outside of the reach of LE then you could have done without the canary to begin with, the fact that you decided to set it up means that you are essentially saying: 'my words can't be trusted, but you can monitor the canary, if it ever fails that's the clue that something is going on which I can not reveal'.

That signal has now gone off and I have no clue how you could put the genie back into the box without a time machine.

In my PERSONAL opinion, I see the canary as something saying "this is the last time we were known secure". If it gets updated, then things are fine. If this weren't the intended use, they'd have archiving systems so you could go back and see if someone missed an update.

Then again, I don't know if the US can make you lie and coerce you to sign the canary. If so, then what you say makes sense.

'DannyBee, who is a lawyer, has written comments on HN that pretty convincingly rebut the idea that the USG could make you lie on their behalf.


Ah, thanks. Yeah, then it stands to reason that if a canary gets updated, things are fine. As I commented on a sibling, if the USG could compel you to lie, canaries would be completely useless as a concept.

> Yeah, then it stands to reason that if a canary gets updated, things are fine.

I don't think that conclusion is warranted. If the canary gets updated it could be any one of a number of things, one of which is that things are fine. But saying that the canary being updated is the same as you being compelled to lie misses out on a few critical options:

- presumably you set the time interval between updates short enough that your key or passphrase could not be compromised in that timeframe, so any interval longer may indicate a compromised private key

- it's only fine if the canary specs as defined up-front have not been violated (which in this case they have)

- canaries may be useless as a concept anyway because lawyers are human and hence fallible.

(That last one is a stretch, but with stuff like this it's either 1 or 0, not something in between and I don't see an iron clad guarantee there, merely an informed opinion.)

This is my understanding too. Real canaries die in the wild for reasons unrelated to the signal it intends to send. The canary in this case is basically a date of claim.


"If the canary has not been updated in the time period specified by the host, users are to assume that the host has been served with such a subpoena."

That seems pretty clear to me.

Sure. The question is what happens when it starts getting updated again. If a LEA can't force you to update it, the only reasonable explanation is that there was an unrelated failure in updating it, and that everything is fine after all.

When it gets updated again users are still to be under the assumption that you have received a warrant or NSL. That's the whole idea. I fear we're going around in circles here.

If you trust canaries AT ALL, you trust that an LEA can't make the owner sign it under duress. Otherwise they don't work, since the owner could just be forced to sign it without missing any window.

Then, it stands to reason that if the canary gets updated again, you trust that everything is fine again, and that the owner didn't get served with an NSL. Therefore, it follows that if you trust canaries at all, you cannot stop trusting them if they fail to be updated for a time, except for that specific duration.

Please correct me if my reasoning is wrong anywhere.

The failure modes of canaries are safe because they die, the fragility is the whole point.

Once dead they tend to stay dead. If you then prop up the canary afterwards and say it wasn't really dead, we just forgot to feed it for three weeks you're risking credibility at a minimum.

So either the operator is incompetent (which makes them a bad choice for trusting them with critical data) or the canary is now potentially under control of another party.

The problem I have with the whole setup is less one of whether or not this is a 'fixable' issue and we should redefine warrant canaries and give them a re-incarnation option, it's that if you think the chances of getting slapped with a NSL or warrant are large enough to have a canary system to begin with that you're dealing with customers that are - or should be - paranoid enough that any tampering with the system other than behavior as explicitly stated up-front should be un-acceptable.

Otherwise it becomes a question of where do we draw the line? A few weeks, a month or a year, what point is there to feed the canary at all if you can revive it at some arbitrary point in the future. After all the canary is a channel with very specific conditions attached to it, it now seems as though you are trying to redefine those conditions after the fact and that is the one property a thing like a warrant canary does not have.

If silent circle would have stated up front we will feed the canary weekly + a potential month in which we will take a holiday and everything is fine, otherwise we have been served with a warrant then you could call this operating within allowed parameters.

But I don't think you should be able to tack on such a clause afterwards.

Not if the text of the canary is "we have NEVER received." That is the point. Otherwise intra-period of updating you wouldn't know either.

But you'd still be in defined territory. Once you let the canary send out its signal any conditions you attach after that fact contradict the signal by design and that is exactly the way it is not intended to work. You set it up with a set of rules and then you stick to those rules.

The intra-period but within defined parameters risk is a different one from the post canary has given its signal one.

The way I understand the whole system to work is that you set up a fragile, fusible link that will blow exactly once to give its signal, and any further signals are suspect. Otherwise why agree on a protocol to begin with if you can then break that protocol at will?

I can see a case for changing the protocol assuming the previous one was not broken but once you violate the protocol I can't see a way to un-do that without making the whole concept meaningless as a result.


You're welcome to your own definition of what a warrant canary is and how it should be used but the specifics are defined pretty clearly and leave no room for your particular interpretation. It really would help if everybody would stick to the same definition for important stuff like this.

Where are the specifics defined? What you posted above leaves room for interpretation. You can say "if you don't hear from me in a month, I'm probably dead", and I can indeed assume that if you're gone, but if you return I won't say "sorry, I already assumed you're dead, tough luck".

Similarly, the above defines what the assumption is while the canary is not being updated. Nobody is arguing with that.

But that's not what was said... what was said was: If we do not update this canary file in x days you are to assume that we have received a warrant of sorts that we are not allowed to talk about.

Yes, and if it gets updated again, that assumption was false. It doesn't imply "assume it forever, no matter what else happens".

I'd like to see a cryptographically signed assertion on this forum that says that the company has not been compromised by a foreign government entity, that you have not been served by an NSL from the US or similar from another country, and that Silent Circle "simply" forgot to update.

I don't care for all this "I'm 99% sure" and "blah bah bah."

Make an affirmative assertion, and back it up, please.

That completely defeats the purpose of the canary. If you trust cryptographically signed assertions over the canary it had no reason to exist in the first place.

Good point. I Don't suggest the assertion would refute the inferences from the canary death, but I'd like to see some non-repudiable assertion, as it would lead them to make some position.

All this non-sense about their "offices being closed" is just silly.

My conclusion is that they've lost the trust of the public, and their reputation and credibility is tarnished, perhaps irreperably.

Then you should wait for an official response. I never said I'm in charge of the canary (I specifically said I'm not) or that I know what happened or why, I just happened to see this and tried to get some more info. My comments here shouldn't be taken as official at all.

Does the US Patriot Act even apply to them anymore? They moved to Switzerland this year. Still, they should probably look into doing the same kind of thing for Swiss laws.


If the warrant canary is out of date, though, I wonder if they moved to Switzerland because the US government tried to get to them, and it wasn't just a forward-thinking action.

As long as you have a single server in the US, the Patriot Act applies to that server and its administrators, regardless of where they are located.

Even if there are no servers in the US, are any of the principals or employees US citizens? If so, then they're as immune as they have the resources to fight off an assertion by the USG that they're not.

Think of Microsoft's current fight over giving up email from one of their Irish servers. Microsoft has the resources to fight this off, and that's the only reason they're still fighting and not complying. Someone small would have to fold or go to jail.

If you're small, it doesn't matter if the law is on your side if the USG overwhelms you before the question even gets a hearing.

Which they have, and they even have offices there.

$> whois

The purpose of the canary is to provide the issuer with a way of saying "I am no longer trustworthy". Since the canary has not been updated, nothing that can be said in favor of Silent Circle should be trusted. When the canary is again updated, it will be Silent Circle saying "I can be trusted again" (subject to the limitations about coercion as described in the canary message).

For now, do not trust that Silent Circle has not been compromised despite anything you may read in this thread. When the canary is updated, then you may return to the state that you had before: you can speculate that they are being coerced into lying about the canary, or that they are trustworthy. That choice is an has always been yours to make.

I disagree that the state post a future update of the canary is equal to the state before it failed. New canary, same as the old does not apply, the alarm has rung, it can't be 'un-rung'.

The warrant canary is not an alarm that an NSL/etc has been served precisely because NSLs do not allow for any such alarm to be raised. The canary is an assertion that this event has not happened up to a certain date, and so one issued at any point whatsoever is as valid (up to its issue date) as any other.

It's not practical to release new canaries constantly, so there is always an interrim period between one and the next where it is unclear if the situation has changed. A due date/release schedule is a guideline to users for that interrim period. Last canary within one normal scheduled interval? Everything is normal. Last canary longer back? Now we must worry that the situation has changed, because if it hadn't the canary should have been updated.

The release schedule is only that, though, a guideline for deciding during the period since issuance. It changes nothing about the fundamental nature of the canary as a claim up to the specified date. A new canary, early, on time, or late, makes the exact same assertion as each of the older canaries. It being late just prevents user confidence about the state of the service in the time period between 'expiration' and new issuance, the new issuance brings back this confidence.

Releasing a canary late is a sin because it creates a time period in which the state of the service is in question, and frequent/lengthy/otherwise egregious incidents should reduce user trust in a service. That time period ends when a new canary is issued, though, as the protection of the canary is once again in place.

But perhaps I simply misunderstand your ideas. Could you explain what you mean by a means other than analogy (which is honestly not particularly useful here, as the nature of signed text is different than the nature of birds)? Or a better question, if a new canary is issued, but late, then what is the actual scenario that users are not protected against?

That depends on how late 'late' is. A bit late, maybe. Weeks late: indefensible. That leaves room for creative interpretations such as deals being struck and compromised identity.

We need a canary monitor service or something to that effect, I imagine of the alarm wasn't raised here then this situation could have gone on for much longer still. Makes you wonder what the value of the canary is if nobody is actively monitoring it.

Oh yes, sorry. Definitely do not take my comments as trustworthy. The canary is the only thing to watch for.

We're back on page one. This is exactly what some of us have said hours ago already and others have been doing: they watched the canary "die" (in terms of the mining analogy).

I hadn't heard of Silent Circle before so I looked at their offerings. Is it any different than what you get from TextSecure and RedPhone for free?

It seems to me that a warrant canary being updated after public notice is the most definitive proof we have that Silent Circle hasn't been served with an NSL.

If the NSL had the ability to force an update, the canary would have been updated before anyone noticed it was a problem. If the NSL didn't have the ability to force an update, the canary would still remain un-updated.

"As of Thu Dec 25 19:07:56 2014 UTC, here are the current headlines"

So it's up again?

Yeah, my guess is that someone at the site saw this and realized that they need to update it.

That or they were forced to by law enforcement due to all of the attention this was getting. Turns out warrant canaries are mostly useless.

Based on a critical reading of the 'Thu Dec 25 19:07:56 2014 UTC' update I'd say it has served its purpose and delivered its only message as loudly and clearly (or absently and morbidly, as the analogy may go) as it can.

ps anyone got a link to any previous canary update, or even a copy of the public key?

pps the update I read (including signature) had sha1sum 790b9817923137c68bd0a818456f2b47ff25719f

Does that mean they've been served a warrant?

Either that or they forgot to update it.

[DELETED, wait for an official company response]

Well, some folks obviously watched out "for not updating it" during the last couple of weeks.

From far away, the warrant canary served its purpose well.

Yeah, I agree. I think we update it every Friday (it's another team that does it), but I wonder why we missed the last two. Maybe there's just stuff I don't know about.

For nearly three weeks. They might just be on vacation or something, but promising weekly updates and letting it go this long is more than a simple oversight.

Good catch :)

That canary sits in direct reach of a LE (Law enforcement) of the US.

$> whois


Edit: Typo law enforcement.

I'm not sure what a LAE is, but the server doesn't matter much, since we sign the file itself.

As long as it's a false alarm, we'll demote this story.

Edit: Ok, we restored it with a question mark. That's a more balanced way to handle these; I just forgot about it.

Edit 2: Now that I think about it, there's no need for a question mark on a factual statement. Sorry—I'm a little distracted right now! (We can change "is" to "was" if they update it, but someone will have to let us know.)

I'm going to detach this subthread now so it can go to the bottom as off-topic.

I'm pretty tired of sensationalist NSA stories here on HN, as well, but I think you're really wrong here.

First of all, it is a factual post, nothing sensationalist.

Second, it is obviously on topic (warrant canaries and their failure modes have been discussed here several times, and usually very civilly).

Third, just because "some guy" tells you "hey, everything is fine" doesn't make it true. You just declared that you're satisfied with the explanation, which I can understand, but demoting the story means that you don't believe that someone can rationally think otherwise. That's unfair, IMO.

Fourth, if you're posting a warrant canary and fail to update it, you deserve the suspicion and discussion. That's kind of the whole point. So: working as designed. :-)

Yes - dang, plesae put that discussion back up where it belongs.

Canaries die only once, consider this an obit. A revived canary is worthless, it's only sitting on the branch because it's been nailed there.

The warranty has been now updated and a google search turns up nothing in the interim. We are in agreement regarding the obituary of the said warranty. Curious as to how you read the messages (regardless) given that it promises a "declaration" that it does not make. Did they ever make a declaration?

I'm not so sure if the demotion is valid for this story.

The sole issue of a warrant canary is to either feed it weekly (their own decision) or retire it.

Not feeding the updates weekly means something... telling everyone false alarm doesn't make me happy.

Maybe I'm paranoid. But if is an NSL he obviously couldn't say anything. If really nothing happened the answer should have been shit i'll update it straight away.

Everything else would completely defeat the purpose of the canary.

Edit: the only thing i'll accept here is an explanation signed with the same PGP key As long as that hasn't happened something happened. Period.

Well, not exactly. I'm not in the US, so I can't be served an NSL (or don't really give a crap about them), and I can't update the canary myself. I've messaged both the security officer and the person who updates it (well, I messaged the entire company, really), and I was assured we'll update it ASAP.

Sorry man. Obviously you don't understand how canaries are supposed to work, otherwise you wouldn't have posted in this thread to begin with.

I used NSL as a generic term. I'm not american either, doesn't change anything.

But seriously please stop posting. You're doing more harm than you help. You can't know IF something happened. Posting a public statement that nothing happened just puts the people that might know under more pressure. There is a good reason you can't update the canary yourself. Because if you could, it wouldn' work.

I cannot take your company serious that way.

Next time send the SMS without any public statement please.

Right. He has no clue on how the warrant canary setup works normally.


"A warrant canary may be posted by the provider to inform users of dates that they have not been served a secret subpoena. If the canary has not been updated in the time period specified by the host, users are to assume that the host has been served with such a subpoena."

No, you have no clue on what I'm talking about. How many people's data will get compromised if someone forgets to update a canary? Zero. The only way for a canary to fail catastrophically is for the owner to update it after the servers have been compromised, thus revealing sensitive data.

I'm not talking about trust in a company or how this makes one look. I'm talking about protecting people's data, and failing to update a canary doesn't compromise that.

> He has no clue

> No, you have no clue

Come on, lads.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact