Hacker News Reader

Hacker News

Comment by openplatypus | Hacker News Reader

Parent Full thread

openplatypus

What's the most interesting in this whole write-up is this: > Security update hidden from search engines

Slack is selectively and deliberately limiting public access (discoverability) to the security breach announcements.

View on HN

I work for Slack, opinions my own.

As far as I can tell, Slack's not trying to hide this news.

Slack communicated about the breach here: https://slack.com/blog/news/slack-security-update

There is no `noindex` tag on that page (check the source).

There is a `noindex` tag on an alternate "en-gb" version of that page: https://slack.com/intl/en-gb/blog/news/slack-security-update

This is to be expected — it's presumably SEO equivalent to specifying a canonical URL.

Very doubtful on SEO and/or alternate content. BleepingComputer also notes the August 2022 notice, which is 'noindex' on all versions.

This is most definitely to burry the notices.

Slack communicated the incident on the 31st of December. That day is typically used by politicians to bury bad news, as attention to news is quite low on that day. It might be coincidental, however, the little cynic voice in me is left wondering.

They detected the incident on the 29th of December. I kinda think that regardless of what day they disclosed, from that day to today, people would find various reasons to complain- "to soon to know what happened", "the day before New Years", "the day after New Years", and "too long after the event". In snark I will suggest that's a pessimist voice you're hearing- the cynic in me wonders if there's any time to disclose that won't receive a complaint.

Slack probably has a lot of large - and very demanding - enterprise clients who absolutely require their non-trivial service suppliers to have infosec policies with a maximum of 72-hour notification window for security breaches. And I can guarantee that no company wants to have client-specific notification window policies in place. That way lies road to madness, missed commitments and nasty litigation.

It's a good practice, in all honesty. The time window is for the initial notification, after that there will be subsequent notifications when actual investigations complete.

That's not the standard SEO way of flagging a canonical URL.

Who defines this standard?

You may argue it's not common, but I'd expect a standard to be determined by an authoritative and fairly representative body. Not by HN forum or a private company in isolation.

Sure - there's an RFC - https://www.rfc-editor.org/rfc/rfc6596

Technically the parent’s point still stands - this is an informational RFC, not a standard.

It's also documented in Section 4.6.7 of WHATWG's HTML 5 standard if that makes you happier - https://html.spec.whatwg.org/multipage/links.html#linkTypes

Doesn’t really make me happier or unhappier, was merely making a point that RFCs come in different flavors, only one of which is a “standard” [1]. Not sure why it touched a nerve with so many people.

1. https://www.ietf.org/standards/rfcs/

In practice, all RFCs are standards documents.

There are no standards here - the world of SEO is a weird place of guesswork and testing what works. I think the Google recommendation [1] is still to use rel=canonical however who knows why this noindex is added to alternative duplicate pages - it might be that the SEO person at Slack knows what they are doing.

I think the accusation of foul play is somewhat overblown given there is a version that does not contain noindex.

[1] https://developers.google.com/search/docs/crawling-indexing/...

Forget about all that; you can just check Google to see if the page is indexed. It is.

Using this query:

site:slack.com inurl:/blog/news/slack-security-update

https://www.google.com/search?q=site%3Aslack.com+inurl%3A%2F...

There explicitly is a standard here, which is used by Google, Yahoo and Bing - see appendix A of RFC 6596.

I understand that, but what I’m saying is that SEO itself is often based on what actually works. This noindex of non canonical resources is likely to be that not an attempt to hide things from Google.

That article is NOT listed on news site https://slack.com/intl/en-gb/blog/news Yes, your direct link works, but the article is not listed.

https://slack.com/blog/news

Not gonna guess why, but if you play with the region in the footer:

English (US): it's listed

English (UK): not listed

English (India): not listed

Slack aka salesforce

Right. Salesforce does a good job of keeping major security incidents out of the news. I suspect that practice also applies to all their acquisitions.

> marked with 'noindex'

How do they even provide a plausible excuse for this? very bad look.

it's totally plausible. and best practice.

If you have a localised blog for multiple regions you will probably have your main blog set up to be indexed and your regional blogs set up to be no-indexed so that Google isn't indexing the same stuff twice.

Not best practice at all. Multi-language blog posts should be handled via canonical or rel=”alternate” (own google recommendation)

No that's not best practice. You think only English should be indexed in Google?

The point as I understood it was that if en-US is indexed, it makes no sense to index en-GB too.

Not only does it make no sense, it hurts you from an SEO standpoint since the content is probably identical.

that's why you use rel=canonical and rel=alternate. Read the google recommandations. Nowhere it is said to add noindex. Just the rels.

> For starters, this "news" item doesn't appear on the company's international news blog aside other articles, at the time of writing.

From the linked article.

They likely published it as soon as they could and translations will be a couple of days behind. Other blog posts will be pre-planned and pre-translated. The noindex on non-us versions is probably also related to it not being fully translated. Check in a few days to see if I'm right

In a "few days", well we have the August 2022 precedent!

> In August 2022, Slack reset user passwords after accidentally exposing the password hashes in a separate incident. Unsurprisingly, that particular notice is also marked with a 'noindex' (both the U.S. and international versions).

Here all versions have the noindex. And it's 4 months after.

> BleepingComputer further observed that the "meta" tag containing the "noindex" attribute was itself placed towards the bottom within the page's HTML code, in an elongated line that overflows without breaking.

Placing meta tags at the bottom, out of sight ... an _interesting_ choice given the nature of the news.

That might just be a limitation of the CMS

Agree. While I'm pretty sure this is to bury the articles in search, that part is probably just technical reasons (or, even more credible, technical laziness).

> Check in a few days to see if I'm right

Or, you know, to see if they change it in response to the article or the discussion here.

> it's totally plausible. and best practice.

Best for what (except PR)? It's hostile towards users which in this case involves a lot of corporate ones.

Reply on news.ycombinator.com