Intel's Mark Bohr on the push into multi-chip solutions and issues at 5nm/7nm - <AUTHOR> https://semiengineering.com/intel-inside-the-package/ <comment><USER2> "Our 14nm delivers a logic transistor density of about 37.5 million transistors per square millimeter. Our 10nm technology delivers about 100 million transistors per square millimeter."

So go draw a square millimeter. For us US people, it's a little bigger than 1/32 of an inch (closer to 1/26th of an inch). If you do any woodworking, you can have a dovetail too big by that much and just wack it in. So it's sort of the allowable slop in a woodworking joint (in softwoods).

They've got 100 million transistors in that tiny amount of space? I know, it's not news, but wow, stop and think about the tech that they have to have to do the layout. Quite an accomplishment, especially considering that the transistor was invented in 1947. In 70 years we go from just having a transistor to having 100 million in a square millimeter.

Other than computer stuff, is there anything else that has seen that sort of scaling up?

<comment><USER3> The price of genome sequencing has actually been falling at a _faster_ than moore rate.

<comment><USER4> Yes, but not for 50 years. That's how long moores law is in effect already.

</comment></comment></comment><comment><USER5> > For the other companies just shipping 10nm, we expect what they call 10nm to > have a logic transistor density measured close 50 million transistors per > square millimeter, not the 100 million per square millimeter that we offer > on our 10nm. It's almost a full generation difference.

Something to keep in mind. I've read in multiple articles that other foundries have caught up with intel. Apparently not quite. Though it's probably closer than it has been for a while.

<comment><USER6> > I've read in multiple articles that other foundries have caught up with > intel.

This was 100% intentional market warfare by those other companies. Companies needed to make up the ideological gap and Intel took a bit of a stumble, so they decided to fudge the numbers and make it look like they somehow made up a whole generation's progress overnight - think "megahertz wars", only this time worse (basically, the numbers are completely meaningless market monikers now - you're forced to go read the spec sheets.)

Sadly, it's worked wonders...

<comment><USER7> I was under the impression the others hadn't quite caught up but were stuck at 14nm and 16nm. Are you saying the nm claims are wrong or is there somthing more complex here in the industry I'm missing? Sorry, I'm not a hardware guy and have lots to learn in the area.

<comment><USER8> Also not a hardware guy, but the issue seems to revolve around density, intel puts transistors on a chip "like this" the other guys do it "l i k e t h i s". They can make small things, but haven't worked out how to really pack them in next to each other and work reliably.

<comment><USER3> This isn't really true, there's a lot of marketing misinformation on both sides. Both with Intel and with TSMC/Samsung/GloFo.

The thing is that with "14nm/16nm", the front end of the line (FEOL) was with FinFETs at a "true' 14/16nm density, but the backend of the line (BEOL) and interconnects were at the older node.

But this doesn't necessarily mean that Intel has a moral high ground here, since they've had a lower than industry standard density from "32nm" and "40nm" and below.

TL;DR: "nm" node names are basically useless now, just know that TSMC 10nm isn't a production node and TSMC "7nm" ~= Intel "10nm"

</comment></comment></comment></comment></comment><comment><USER9> > _ARM is part of our foundry offerings now. We offer ARM IP, which can be put > on Intel chips and be part of an Intel chip, whether it's a 14nm or 10nm > chip. That's an IP block, not necessarily a separate chip._

Where would this be needed?

<comment><USER10> I don't know that this is what they're doing, but what I've wanted for several years is a dual power mode computer.

In powered up mode it would operate like a normal x86_64 chip, full power and full speed. But in low power or standby mode it could switch to an ARM chip or core and maintain access to RAM and disks to let it run updates and downloads in the background.

For example, right now to update Windows or Steam games or other software, I have to leave my computer running at full power. Generally depending on what I'm doing I want to throttle or stop the downloads so it doesn't interfere with my normal use. But I also hate leaving my desktop on at full power and with the fans running just so it can do downloads and background tasks.

Or an ARM core could run a simple file server, letting me access files and information stored on my desktop without leaving it on all the time.

TL;DR: I wish I could have an ARM core in my desktop to run background tasks like downloads and other things Raspberry Pi-ish levels of performance.

<comment><USER11> That's an intriguing concept, but it seems like it would be a headache to implement, from a software perspective. Unless I'm mistaken, if you wanted this low-power chip to perform windows updates, you would need MS to provide an ARM compiled program to perform x86_64 updates. Or you'd need a third party to do it somehow, which sounds messy. The same would apply for anything else you wanted to do that's more complicated than putting files in fixed locations. I suppose it could be relatively easy to just do the downloads, and leave installations/updates for when the main chip kicks in.

And the fileserver concept is pretty neat. Rather than having a separate low power machine that you send files to, your main PC could act as a fileserver using separate software while fully powered or in low-power mode. I'd buy that, if only for the novelty.

<comment><USER12> It is a fascinating idea. I'm wondering if something like an ARM build of Windows 10 S could already support an ARM to x86_64 handoff with the main kernel/OS/UWP apps running immediately available in low power scenarios and where it might pass things of to Win32 on ARM emulation instead pass things to an x86_64 core? Then from there build out more hand-off capabilities for power hungry processes or performance-hungry apps (like Xbox Game Mode)?

To some extent, I would be surprised if there aren't teams at Microsoft exploring such crazy hybrid notions already, if at least for options for future Xbox or Surface hardware. Recalls to mind Microsoft already experimented with a notification platform of a low power CPU screen coupled to a Windows device way back in the Vista timeframe [1].

[1] [https://en.wikipedia.org/wiki/Windows_SideShow](https://en.wikipedia.org/wiki/Windows_SideShow)</comment></comment></comment></comment>


Russia lifts ban on Telegram - <AUTHOR> https://apnews.com/1da061ce00eb531291b143ace0eed1c9 <comment><USER2> There's so much FUD here about how this must mean Telegram is now insecure, backdoored etc. I sure hope those voicing these opinions actually have used Telegram and understands how it works:

\- Telegram does log chats server-side _if you want them to_ (to be able to see your chat history across devices). You don't have to. Telegram supports end-to-end encryption ("secret chats") with no logging -- as far as I know there is no proof that these chats are untrustworthy.

\- Telegram groups have never been sacred and they are deleted if they spread illegal information. This is not the same thing as leaking someone's personal chat history, which to my knowledge has still never been done.

I'd be glad to be proven wrong on any of these counts, I use both Telegram and Signal and trust the latter more for obvious reasons (it's completely open source) -- but the fact that Telegram is not perfect in every way does not make it insecure by default.

<comment><USER3> The Pentagons guideline for secure military conversations allowed to chose between threema, whatsapp or signal - but they explicitly forbid usage of telegram.

At the time I knew about the voice call remote exploit in whatsapp due to their outdated hardfork, and I knew about the XSS RCE bug in signal's innerHTML mess... so my personal assumption is that telegram is the only messenger where five eyes has at least no protocol level access and have to exploit the OS it is hosted on.

You can meanwhile look that information up on vault7 or snowden leaks, so it's already publicly disclosed.

Anyways, if you feel safe using a stock Android ROM that isn't AOSP and is still using legacy 3.x or 4.x kernels... your general assumption on what is secure is wrong.

Having said that, I don't know whether palantir's gotham has access to telegram's servers. But given their workforce and sheer amount of RE they hire, the likeliness of telegram being a target is very high.

So with all that in mind I'd recommend telegram only with AOSP head and only with secret chats. You don't stand a chance if you are using the public clearnet routing protocols either way.

And this is assuming that you don't use Windows and something like a hardened Kali or Arch-based distro that is updated regularly and uses both a secure transport layer for pacman and doesn't allow "some random guy's" gpg signatures, aka you'd have to manually check every source from AUR. If you use Windows 10, you can forget security. If you use Ubuntu or Debian, you can forget security. If you use Steam, you can forget security. If you play any networked games on any of your machines, you can forget security.

Joyful times where private organizations with nearly unlimited resources "hack the planet" and seemingly get away with it.

<comment><USER2> > so my personal assumption is that telegram is the only messenger where five > eyes has at least no protocol level access and have to exploit the OS it is > hosted on.

This is a very strange assumption, you mean that the "Pentagons guideline for secure military conversations" is actually not a guideline for secure conversations, but exploitable conversations?

Why would the Pentagon tell their own people to use exploitable communications? There's no way of knowing if you are the only one with the capability.

In my eyes this information (which I haven't verified and don't have time to dig into) would rather indicate that the Pentagon believes Threema, WhatsApp and Signal to be secure while they are doubtful about Telegram -- maybe because they know something we don't, or simply because it's harder to audit.

<comment><USER3> The underlying question really is when the point is reached between "security through trust" and "security through audit".

I'm not anyhow claiming that Telegram is secure. But given the problems that legal courts have when the FBI and other three letter agencies want to get access to Telegram data (and the fact that the company moved their HQ around Europe every time a state wanted access) seems to me much more trustworthy than say, any Facebook software.

And I would also argue that given the fact that Gotham has full administrative access for anything Facebook sends and that the end-to-end encryption cannot be verified as both clients never actually connect directly would speak also contra WhatsApp when it comes to their security claims. (install a Firewall on Android and you'll see the whatsapp gateways/proxies).

To be honest, I doubt that the Pentagon would trust any software without having seen its source code or at least having full access to the data that's transferred. And I think that's a fair assumption.

The underlying issue is that the field of security has is actually that it's not a field of trust - but rather a field of mistrust. Currently I'm mistrusting the Pentagon more than some random dudes I've never seen; which might be the actual point of the discussion: Can we trust the Pentagon given their fuckups in the past?

</comment></comment></comment></comment><comment><USER4> The most likely reason is that Telegram is too convenient and too useful.

Every agency in the government has an official account. The president's spokesman uses it to communicate with members of the media. Most recently it was successfully used to disseminate guidance on COVID-19.

<comment><USER5> > Most recently it was successfully used to disseminate guidance on COVID-19.

Or propaganda, given the (credible) accusations against Russia on misinformation campaigns.

edit: I'm referring to the fact that Telegram is _the_ most popular service for German conspiracy myth spreaders (e.g. former stars Attila Hildmann and Xavier Naidoo), especially in regard to the COVID19 crisis. Unfortunately I'm unaware of decent English articles, but here's a good German starter: [https://www.br.de/nachrichten/netzwelt/messengerdienst- teleg...](https://www.br.de/nachrichten/netzwelt/messengerdienst-telegram-wo- die-verschwoerungstheorien-spriessen,S0HDUq1)

<comment><USER6> That's exactly _why_ you want to use something like Telegram if you're in the West: it's not controlled by a Western government.

I don't care much for the conspiracy nuts, but their ability to communicate with each other would surely have been terminated had they used WhatsApp.

It's fine to use WhatsApp to praise Obama, Merkel or anything else that is widely accepted in your society etc, but it's a terrible choice if you're on the shit list of the government.

<comment><USER5> You can do whatever you want using Whatsapp (it has a proven solid e2e encryption), the key difference to Telegram is it requires a phone number to use which instantly reveals your real identity to any snoop, snitch or government mole.

If it were that easy to influence Whatsapp, India would not have a real problem with Whatsapp-mobilized lynching mobs.

<comment><USER6> > You can do whatever you want using Whatsapp (it has a proven solid e2e > encryption), the key difference to Telegram is it requires a phone number to > use which instantly reveals your real identity to any snoop, snitch or > government mole.

Both Telegram and WhatsApp required a phone number last I checked, but you can install Telegram on a Desktop using a dumb phone for activation, you don't need to run the app.

> If it were that easy to influence Whatsapp, India would not have a real > problem with Whatsapp-mobilized lynching mobs.

India has no jurisdiction over WhatsApp. They can ask Facebook nicely, but that's about it.

To stop communication you don't need to read WhatsApp-chats. You just disable the accounts that you want silenced. And you can't do that if you don't have control over the service (hence Western extremists use of Telegram).

If you're Russian and you want to talk about how free yourself of Putin, use WhatsApp or Signal, that is: an American provider. If you're American (or living in an American province) and you want to talk about how to free yourself of Washington, you use Telegram (or a Chinese messenger). Even if none of them can ever read your chats, they can a) use the meta data and b) disable your ability to communicate.

This also applies if you're a common criminal: US cops will have a much easier time getting meta data on your communication from WhatsApp than from Telegram. It's generally a good idea to know your threat model. Unless you're a Russian Oligarch or Ex-FSB, the FSB is not your problem. But your local domestic intelligence service may be, if you ever step out of line.

<comment><USER7> > instantly reveals your real identity to any snoop, snitch or government > mole.

Yeah, WA isn't anonymous. The problem is with Telegram storing all your private messages on their cloud, by hacking the server, just knowing your username the state level attacker learns everything about you, metadata, and content, and because there's no forward secrecy, it will date back basically forever unless you're constantly deleting logs, and even then you can only hope Telegram also erases their backup tapes.

>If you're American (or living in an American province) and you want to talk about how to free yourself of Washington, you use Telegram

That's just stupid, why would you want less secure architecture to criticize Americans? NSA can trivially hack Telegram servers to see your criticism if they want. You want E2EE for your dissident group no matter what, thus Signal will always remain a better choice.

<comment><USER8> By default, Telegram does store all your messages on their server, whose encryption cannot be trusted.

By default, WhatsApp _uploads all your messages to Google Cloud in clear_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> One of the big reasons was also the fact that they failed to ban it. They could not enforce it at all, without blocking half of the websites, because of Telegram's clever networking shenanigans, so everyone was still been able to use it (without vpn or anything).

Even russian government officials have _official_ Telegram channels. All the "news" sources quote Telegram channels all the time. All pro-gov celebrities and stuff.

It was not a ban, but a farce that made the regime look like incapable fools. Not that they are not, but they don't want to emphasize that so much. Not that they don't, but at least not make it that obvious. Not that it isn't, but...

<comment><USER10> They couldn't block it even taking down half of all websites, including Github.

At the same time government officials kept using it, including those in charge of blocking it.

It was an "old man yells at cloud" travesty from the beginning.

</comment></comment><comment><USER11> Let's be honest the real reason to use Telegram wasn't security, I mean whenever the topic comes up here moxie (or his advocates) pops up and tells us it's trash and we should all use signal instead.

The real reason to use telegram is that it's miles away the best messenging program out there. It's as user friendly as whatsapp while having completely seamless desktop/mobile integration (something whatsapp and signal have failed to do), it only requires a phone number for the initial signup, and generally speaking it has all sorts of cool features and less bullshit than alternatives.

Then there are the little things - you can create multiple accounts and switch seamlessly, you can delete whatever message from whomever for everyone without leaving a trace (if it bothers you just switch to secret chats), all links are listed in each convo, you have pretty much unlimited and unrestricted cloud storage, etc.

Then you have all the gravy like cool tools for groupchat admin, channels, and bots of course. You can order a taxi or search up a book on scihub (bypassing countrywide blocking) with telegram. You can even do bizarre stuff like discover people around you or verify your identity on a service with telegram.

Yeah my texts are probably being read by the FSB. So what? Better that than the NSA, frankly. If I really want secrecy I'll use Tor or Signal.

<comment><USER12> > you can create multiple accounts

Only if you have multiple phones. One account per number.

> Yeah my texts are probably being read by the FSB. So what? Better that than > the NSA, frankly.

I can't tell if this is a joke. If it's not, it's fairly insulting to everyone who believes in a world with privacy and freedom.

<comment><USER13> If I am living in the USA and the FSB reads my messages, what can they do to me if they don't like what I say?

I personally think the NSA has a jurisdiction to do more to American citizens in the USA. I would be extra careful about the NSA if I was H1B.

<comment><USER14> > what can they do to me if they don't like what I say?

Leave a little nerve agent on your doorknobs.

<comment><USER13> Based on historical statistics, there's an approximately 5 in 8,000,000,000 chance of this actually happening, and if you've never talked to a Russian in your life, the statistic drops to 2 in 8 billion (those poor souls who were injured accidentally)

<comment><USER15> 30 million dead Ukrainians disagree with your statistic.

<comment><USER8> That is an inflated statistics of people in the USSR killed by the tyrant of their own country. If anything it supports the point made above.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> As a consequence, my website is now available in Russia. [https://isitblockedinrussia.com/?host=idiallo.com](https://isitblockedinrussia.com/?host=idiallo.com)

The issue was that to block Telegram they had banned a few IP blocks, around 10 million ips[1]. These blocks were used in both Digital Ocean and AWS. So if your website or service used any of these blocks, it wouldn't be available in russia.

[1]: [https://idiallo.com/blog/website-dont-work-in- russia](https://idiallo.com/blog/website-dont-work-in-russia)

</comment><comment><USER17> You guys aren't seeing the bigger picture.

TG LLC got 1.7 bil USD with two rounds of investment. US based investors are returned 72% of original fund. Those 28% are 500 mil USD.

It's rumored that TG CEO got 300 mil selling his share of VK, so in the end he returned all personal investment on TG development. Who's behind all those funds, private investors etc. How many of those are under US sanctions really?

And now, upon failing to submit the reasonable paperwork even thought they had quite expensive and experienced lawyers, Pavel suddenly calls for unban in Russia. Like a week later a legislation appears and almost immediately after that the deal is done.

Reconciliation happened unbelievably quick. Or his words have so much power now?

Just think Crypto AG serving the purposes of BND and CIA when you talk about Telegram.

<comment><USER18> So the most reasonable explanation is that Pavel is in a conspiracy with the Russian government and is living in exile as a cover huh?

Sounds pretty complicated when a simpler answer would also exist.

<comment><USER17> I don't feel like he's living in an exile.

For starters, the citizenship that was acquired for $ 250k something is from Saint Kitts and Nevis, known for it's abuse of human rights. To me it's a classical double standard behavior.

He's vocal on not being able to conduct business in Russia as he pleases and it's a clear violation in his purview. Never heard him being involved with fighting inequity of the new home country.

Second of all, Saudi Arabia, the unofficial Telegram HQ, is tax exempt for hi- tech, but don't quote me on it.

<comment><USER19> > For starters, the citizenship that was acquired for $ 250k something is from > Saint Kitts and Nevis, known for it's abuse of human rights. To me it's a > classical double standard behavior.

Blame the UK and EU who allow visa-free travel with SKN but not with Russia and don't sanction it.

It is a country with a population of 50 000 people. The only reason it is not extremely poor is because its business model is giving citizenship to businessmen to avoid taxes and allow them to travel freely.

Fighting an obviously lost fight against SKN and jeopardizing your whole life sounds even more stupid than fighting windmills.

<comment><USER17> My point is he's accustomed to cutting corners.

>>Fighting an obviously lost right against SKN and jeopardizing your whole life sounds even more stupid than fighting windmills.

He could've applied for maltese or cypriot passport.

</comment></comment></comment></comment></comment><comment><USER20> I would guess this means the gov't now has access to Telegram messages, one way or another.

<comment><USER21> There's quite popular conspiracy theory in Russia that says that Telegram was FSB-backed project from the start, and the whole failed ban was implemented to promote it. However, there's still no concrete proof that government has backdoor access to it, so if they do, they're being very careful about it.

<comment><USER22> The most obvious fact is that Mr. Durov is not walking with a hole in his head, as a double digit portion of anybody who had balls to be audacious about their opposition, and is not known to have an extensive security detail.

The mob has sent hitment to people whose offences were way lesser than that.

Their ways are unyielding, and uncompromising. Putin has a record killing people who grieved him more than a decade ago, keeping trying for years on end. People he killed some times survived 2-3, even 4, assassination attempts over years, just to be eventually killed by yet another one.

Knowing that, it's hard to explain how Telegram kept maintaining an office in Russia.

<comment><USER23> Sorry, but you managed to write both grotesque and extremely simplified description of Russian political practices.

There's absolutely no point in making any physical moves against Durov even if he was openly anti-Putin and supported opposition in any way. It's never done like that. He's already forced out of the country and is not considered a direct threat. He or his remaining actives may be considered a future asset, on the other hand.

<comment><USER24> > even if he was openly anti-Putin and supported opposition in any way

This implies he does not support opposition in any way. This is not true. He does support opposition rallies—when they are held to support his cause, true, but such is political climate in Russia that publically supporting those who vocally oppose the state policy is a domain for very few and quite brave.

When Libertarian Party of Russia was organizing a rally in 2017 to protest Telegram ban, Durov contacted the Party himself. (I'm a member of LP RU.)

I don't count on Telegram security but Durov's public image and actions are certainly noticeable and appreciated by opposition.

<comment><USER23> > This implies he does not support opposition in any way. This is not true.

It implied just that I don't know for sure and it does not change a lot. Even Khodorkovsky is not considered a threat worthy of eliminating - he much better serves the cause being a propaganda target. Durov has even more to offer to Russian gov't (digital technology is the new arms race) so he has even lesser chance of bodily harm.

</comment></comment></comment></comment></comment></comment><comment><USER25> Does this mean that now Telegram will give the Russian government whatever they want, if they think it is "extremist"?

<comment><USER26> Who knows. I personally don't think Durov will give his libertarian views up to the Russian government like that.

<comment><USER27> Blackmail.

</comment></comment></comment><comment><USER28> More than 550k of IPs are unbanned now:

[https://usher2.club/en/](https://usher2.club/en/)

Basically, 95% of the blacklist.

</comment><comment><USER29> Backdoor-ed successfully?

</comment><comment><USER30> > The company refused to hand over encryption keys, arguing that it would > violate users' rights to privacy and would not help weed out terrorists.

Take note on how it feels to read this line when it's about a country that isn't yours. When the United States pushes the same argument, the rest of the world's privacy is at risk.

This is why European governments increasingly try to keep their data on European soil, and to trust businesses bound to EU laws.

</comment><comment><USER31> Russia never actually intended to fully block Telegram. Otherwise they would just make Google kick it from Russian version of App Store and Google play, but they never did it.

I'm not for any of conspiracy stories, but we need to be clear about this ban story.

<comment><USER32> At least Apple rejected RKN request to block Telegram.

This is a random article (in a Russian) about RKN threatening to block App Store in Russia if they refuse to remove Telegram from the App Store.

[https://www.the-village.ru/village/city/news- city/313713-rkn...](https://www.the-village.ru/village/city/news- city/313713-rkn-vs-appstore)

<comment><USER31> Both Google and Apple do block apps for certain countries though especially those used for distriution of copyrighted materials. Russia certainly can force Apple to comply if there was wuch a goal. Or at least RKN can just break push notifications for everyone.

I'm not the one for conspiracy theories though. Most likely they never intended to actually block it simply because they are using it themselfs and that's just it.

<comment><USER32> > Russia certainly can force Apple to comply if there was wuch a goal. Or at > least RKN can just break push notifications for everyone.

Obviously, they are not mad enough to break everyone's phones just to block Telegram.

> I'm not the one for conspiracy theories though.

Yeah, that was my thought. You did not provide any evidence to the claim that RKN only pretended they want to block Telegram, while there's a lot of evidence they actually wanted to block: they blocked millions of IP addresses and they threatened Apple to block App Store.

> simply because they are using it themselfs

If they really wanted to use it themselves, they would not block AWS and DO.

</comment></comment></comment></comment><comment><USER33> Some of our game servers were impacted by this and we ended up having to do elaborate message forwarding for Russian players. I find it staggering that it took 2 years to be lifted given how much collateral damage it caused.

</comment><comment><USER34> It never was actually successfully blocked. I was in Russia while it was blocked - it worked OK, just seemed slower than usual. A lot of people use Telegram there, for both messaging and for reading the news outside the entirely government-controlled mainstream using "channels". Nowadays even some government agencies have their own channels on it, in spite of the "ban". There's a saying in Russia: the strictness of Russian laws is compensated by optionality of compliance.

<comment><USER32> > Nowadays even some government agencies have their own channels on it, in > spite of the "ban". There's a saying in Russia: the strictness of Russian > laws is compensated by optionality of compliance.

Technically speaking there was no law prohibiting telegram for citizens or government officials. "Optionality of compliance" does not apply here because no user of telegram broke the law.

</comment></comment><comment><USER35> What's the "12+" next to the date? Does that imply gov.ru also has NSFW subdomains?

\- Open up! Police! Your neighbours called.

\- Nu, so go next door. We didn't call for police, we called for ...

<comment><USER36> > What's the "12+" next to the date? Does that imply gov.ru also has NSFW > subdomains?

Might be a timezone? The most eastern part of Russia (cities such as Pevek, Anadyr) observes UTC+12.

<comment><USER37> Checking the source, the element has the id "age". Not sure what it implies one way or the other though.

<comment><USER38> Yes, probably the age rating.

[https://en.wikipedia.org/wiki/Russian_Internet_Restriction_B...](https://en.wikipedia.org/wiki/Russian_Internet_Restriction_Bill#Other_changes)

</comment></comment></comment></comment><comment><USER39> This is when I stop using it

<comment> iso-8859-1 Why are you stopping? Because you think they collaborate with the FSB more now?

<comment><USER39> There is one certain thing - they are getting something out of that and they want people to use it. I'm not sure what exactly. They either found a backdoor or a struck a deal. Things like that aren't a joke in Russia. Mass control and surveillance is a real thing, there are many reports of people being put in jail for writing something against the government on Facebook or other platforms.

</comment></comment></comment><comment><USER40> Could this be an attempt to baby step closer access to infiltrate to the Telegram team by presenting good will? As someone else commented this could have been agreed upon through blackmail. How are these systems ultimately safe guarded? Is it even possible while there are bad actors attempting to control?

<comment><USER4> Non-Russians often assume some sinister motive behind actions like that, but reality is much simpler.

The authorities failed to shut Telegram down while making active use of it themselves. So now they are giving up because there's not much point in continuing the efforts.

<comment><USER41> By doing so they would send the wrong message though "feel free to use it against us; we're neither closing nor monitoring it", which would be like shooting in their feet. Unless they're just pretending it. Every government fears what it cannot control, especially communications networks that could be used to subvert the status quo; this applies to all governments in all countries, including so called democratic ones. To me they're still actively monitoring it, and I'm 100% sure they have the means of shutting it down just in case of real necessity.

<comment><USER6> On the other hand: if you force people to use VPNs to use Telegram ... you're forcing people to learn to use VPNs.

And if you're afraid of people talking about stuff without you knowing, the last thing you want it large parts of the population (or at least those parts you're interested in) using more encryption. Basically: you can't stop it, trying to stop it has negative side-effects, so stop trying.

</comment></comment></comment></comment><comment><USER18> It's strange that whenever telegram comes up, there's an unfounded suspicion that it has some kind FSB/Russian government connection simply because it was developed by a Russian.

This is insane and like pretty bigoted - not a good look for HN.

Here's the guy that leads the company: [https://en.wikipedia.org/wiki/Pavel_Durov](https://en.wikipedia.org/wiki/Pavel_Durov)

>In 2011, he was involved in a standoff with police in St. Petersburg when the government demanded the removal of opposition politicians' pages after the 2011 election to the Duma.

He's living abroad because he's either not allowed or does not feel safe entering Russia. VK was taken from him pretty much over his principals not to do what HN just assume telegram does. Telegram was developed outside of Russia to avoid being beholden to them.

The fact that Russia was actively blocking telegram should be proof enough. The reason they stopped is because when they did, they would accidentally blocked other services and it was kind of a disaster. They simply don't have the expertise to run their blocking campaign. It looked bad so they stopped.

Russians are more than one-dimensional Putin-driven fake news generating bad guys.

<comment><USER42> > This is insane and like pretty bigoted - not a good look for HN.

No, you're just projecting. This mindset of untrustworthy until proven otherwise is universally applied to all chat apps, from any country, it happens under pretty much every discussion of Facebook's Whatsapp and Messenger and it happens in discussions about WeiBo (and similar).

</comment></comment><comment><USER43> Russia did not lift this ban because they changed their stance on encryption...

<comment><USER32> This in an unsubstantiated claim which does not help anybody.

</comment></comment><comment><USER44> Articles: Anything about Telegram Discussion: crypto baaad/all chats logged/insecure by default etc. etc.

Yes we got it you don't like telegram. Use whatever and move on. There is no need to constantly come up with the same BS. Cloud chats are in the cloud (which you probably hate too ryt?) and no, they are not e2e encrypted. Calling it a server side logging is just straight out FUD. Also pretty sure 99+% of all telegram user never use the secret chat feature because telegram is mostly so useful because of all the rest. And people use it for all the rest (large community groups/channels/bots/games). I'm sure more than 99% of my telegram messages go to groups that are public or semi public (like you would find the link on another platform if you are part of the community there). Its absolutely unwanted to have any kind of nonsense encryption for such groups. Yet all the feature telegram can provide because it does not have nonsense encryption, like fast server side search or link to messages visible on the web, are the reason I and other use it. Just like y'all use hacker news and don't mind that your comments are "server side logged".

tl;dr A tool isn't broken or insecure because it does not what you want it to do. It's just the wrong tool for you.

</comment><comment><USER45> That's because on 2020-07-01 there will be a voting on constitutional changes. And Putin would like to give us a (false) hope that our life is going to become better and put his government in a good light.

Context:

In Russia we have a limit of 2 terms for presidents. Putin and his mafia don't like it, so he decided to be nullified and get additional privilegies (e.g. after he decides to resign, he will be able to dismiss a president).

Putin has even already signed the changes because he knows we are too scared of jail to protest IRL: even if you are protesting alone, police will likely beat & fine you (even if you are a girl or just holding a BLANK board) for an unauthorized demonstration. In one video the election chief almost laughed while saying everything is already decided and legitimate and they just want our opinion.

But for additional legitimization Putin set the voting. Probably he doesn't want the situation as in Venezuela. And he wants to increase his ego (his ego is very high, just compare inauguration of him and Obama/Trump).

He paid many famous people for short videos where they support some part of the changes, typical example: "I will vote yes because I like animals!" although we already have laws for animals.

And none of those videos mention that Putin would be the president forever. Only half people are even aware of this change (and many are forced by employers to make a photo that they voted yes). Oh, and our constitution doesn't work at all anyway. Gov-t people laugh at you when you mention anything from it. And there were news several years ago that a journalist got a suspended sentence (условный срок) of 4 years for extremism because he quoted the constitution.

P.S. >97% of Russian IT people seem to hate Putin according to the comments I read everyday. And Durov should hate him much more because Putin's mafia stole VK (that's our Facebook with nice UI/UX and awesome search) from his control.

</comment><comment><USER46> Did they make an agreement? Now the government got access to everything that goes through telegram?

<comment><USER31>
       > Now the government got access to everything that goes through telegram?

Nothing in Telegram ever had end-to-end encryption by default so you shouldn't really expect anything but private chats to be secure.

<comment><USER46> I see. I read that somewhere but never checked to make sure it's really so.

</comment></comment></comment><comment><USER47> Translation ([https://translate.google.com/translate?sl=auto&tl=en&u=https...](https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Frkn.gov.ru%2Fnews%2Frsoc%2Fnews73050.htm)):

> About Telegram Messenger

> June 18, 2020

> We positively assess the readiness expressed by the founder of Telegram to > counter terrorism and extremism.

> By agreement with the Prosecutor General's Office of the Russian Federation, > Roskomnadzor removes requirements to restrict access to the Telegram > messenger.

> We are ready to cooperate with all Internet companies operating in the > country to quickly suppress the spread of terrorist and extremist > information, child pornography, and the promotion of suicide and drugs.

> Currently, jointly with leading Russian and foreign Internet companies, on > average weekly materials are removed:

> \- propagandizing suicidal behavior 2,500;

> \- extremist and terrorist nature 1,300;

> \- propagandizing drug use, about places of their purchase 800;

> \- with pornographic images of minors - 300.

</comment><comment><USER48> We changed the url changed from [https://rkn.gov.ru/news/rsoc/news73050.htm](https://rkn.gov.ru/news/rsoc/news73050.htm). We have deep respect for other languages, but HN is an English language site, and submissions here need to be in English so people can read what they're discussing.</comment>


Fasting and Programming - <AUTHOR> http://mahdiyusuf.com/2016/11/12/fasting-programming/ <comment><USER2> > For those of you not familiar with Ramadan it's an holy for the month for > Muslims where they fast from sunrise to sunset

Tying it to sunrise and sunset makes the duration different at different latitudes.

In Iceland, for instance, the length of the day during Ramadan reaches 22:28. Muslims deep into the Southern Hemisphere, on the other hand, get short fasts.

That's for recent past and near future Ramadan fasts. It's based on a lunar calendar, and so the dates drift through on the solar calendar. Eventually Iceland will get short fasts and those far south will get long fasts.

It's even more interesting for Muslims who happen to be at a place like McMurdo Station, Antarctica. I believe that Muslim scholars have said that Muslims there should fast on the schedule of their home country.

Muslim astronauts could also have problems, although I've read that being on the International Space Station is considered to be traveling, and people who are traveling are not required to fast.

</comment><comment><USER3> I've been eating one meal a day for the past 3 years, usually lunch, and occasionally fasting for a day or two. At first, I would be feel very hungry at dinner and breakfast time, and I'd feel starved by lunch. (I kept going because I kind of liked the feeling when eating that one meal; food tasted so good. Also, I liked the extra time I would have, which I would otherwise spend on preparing food and/or eating.)

My body slowly adjusted, and after the first year or so, it became so normal that I no longer feel hungry at all until my daily meal, and at that time I would feel comparable hunger as before mealtime when I used to eat three meals a day.

It's much easier to delay eating now then it was before. I can easily go 2 or 3 hours after my normal eating time without any build up of hunger at all.

When I hear about how hard it is to fast, and how people have to get "ready" by eating like a pig before their fasting time, I cannot relate to this anymore. I think there is a very universal and very deep mental idea instilled into modern people that they must eat so much. It's ridiculous when you think about how nourishment fits into evolutionary pressure. We wouldn't be able to compete against other species if our bodies and mental capacity weren't equipped to go without food for many days and still perform.

Also, the fact that it took a year before I started to feel normal doing this, makes me think how a human being adjusts itself to different environments, gene expression and all that. My body feels tougher, I have as much energy as I did before, but I'm calmer and less stressed. It's like my body streamlined where it put energy into, so I could still perform just as well as before. Looking back, before I did this, energy was spilling into every random thought and emotion, and I had much more anxiety and angst. Now I can choose to ignore things which before I would obsess over.

<comment><USER4> I would say eating like a pig is just about the absolute worst way to prepare for a fast.

</comment></comment><comment><USER5> An interesting reflection on fasting while trying to work. Curiously, I have had the opposite experience of working while fasting, though it may be very different to fast for one day at a time. Still, I fast between dinner on Sunday and dinner on Monday, which usually amounts to about a 18-19 hour fast. I allow myself all the water I want a a few cups of coffee in the morning.

I'm motivated by a hypothesis of mine that biologically our bodies have spent the last 100,000 not consuming regular high quality, high-calorie meals every day. I am a distance runner, and I've been experimenting with my diet for some time now to see what works best now. My subjective experience so far has been fantastic. I generally feel mentally sharper, and my fast-day runs are usually more focused and satisfying than on days when I eat.

</comment><comment><USER6> I do roughly a 16:8 split most days 16 hours fasting and 8 hours feeding window. Generally stop eating sometime between 6:30 PM and 8 PM in the evening and don't eat again until noon or later the following day. So some days the fast gets as long as 18 or 19 hours.

I do intellectual work both fasted and during the feeding window. After doing this for 3 years or so it feels completely normal. It is also very possible to exercise intensely (weight lifting and running) after fasting 15 or 16 hours.

I believe that this approach helps me maintain the body weight and fitness levels that I desire without being particularly difficult to do.

</comment><comment><USER7> My $0.02 on fasting and programming ...

I've been intermittently fasting over the last month or so by not eating from dinner until lunch the next day, every day. I read about a number of health benefits and figured it would be a good way to lose weight for my personality type.

I'm only suffering half the time that the author is (I sleep through the other half) and I drink unlimited water and tea during that time but I find it really helps me focus during that time. I have two big hunger peaks: about an hour after waking up and about 2 hours before lunch. During those times, I find it important to be really plugged into something (usually programming, sometimes writing).

I wonder if eating a lot in the morning kind of primes the body for more food throughout the day, making it worse? I've found I eat a lot less total calories during the day, as though the lost meal makes me use to less food overall. I ea a big lunch but a regular-sized dinner, then the "fast" starts. 100% conjecture.

</comment><comment><USER8> Question: How bad is it to sleep during most of the day (except for perhaps when praying) and then simply eat and work at night? I realize that the point of Ramadan is humility and not finding loopholes, and that it might be impractical when there are very few hours where the sun isn't up. But is it otherwise wrong to be a nocturnal muslim?

If the most sane solution to The Ramadan Pole Paradox [[https://wikiislam.net/wiki/The_Ramadan_Pole_Paradox](https://wikiislam.net/wiki/The_Ramadan_Pole_Paradox)] is to simply use the schedule of a person's country of origin, then at what geographic point should that happen? And what if a person is born near the poles, or even in outer space?

</comment><comment><USER9> I'm two coffees away from fasting between sunrise to sunset while programming.

</comment><comment><USER10> Good conclusions! Fasting and trying to do any kind of work it's like trying to drive a car with the tank empty.

Also fasting and sports do not mix. Fasting is putting a strain on your body and mind so if you are fasting you are already doing hard work and you will not be able to do anything else.

This also puts in perspective all the perks you get at big companies. They are not perks. They are how you write great code.</comment>


At 14, is PHP Finally Growing Up? - <AUTHOR> http://phparch.com/c/news/view/4/At_14__is_PHP_Finally_Growing_Up_ <comment><USER2> Some arbitrary "best practices" don't make up for the language's general inadequacies (nor do any existing libraries). You might be able to write slightly less bad code, but you still aren't writing expressive code.

<comment><USER3> I would like to argue the C language argument here. If I want to shoot myself in the foot, the language should let me. If I want to paint the Mona Lisa, the language should let me.

PHP does that.

<comment><USER4> PHP will let you paint the Mona Lisa at favicon resolution.

<comment><USER3> Fine. I call you on this.

Full size: [http://williamriggins.com/mona.php?x=400&y=571](http://williamriggins.com/mona.php?x=400&y=571)

Favicon Size: [http://williamriggins.com/mona.php?x=10&y=10](http://williamriggins.com/mona.php?x=10&y=10)

Code (minus base64'd image constant): <http://pastie.org/506643>

<comment><USER2> I think you missed the metaphor.

</comment></comment></comment></comment></comment><comment><USER5> No content in this article. And even phparch voters only rate this article 2.5 out of 5 stars.

—PHP user

</comment><comment><USER6> Although the article didn't cover any specifics of the language, I think PHP has definitely improved. For what it lacks in elegance, it makes up in ease of deployment and scalability. Overall, the improvements made to PHP over the past few years and the upcoming changes in PHP 5.3/6.0 and the variety of excellent frameworks to choose from, make it a very good language to keep in your web development toolkit. It doesn't do everything extremely well, but it does many things well enough.

<comment><USER2> It is amazing that people are willing to sink thousands of hours into programming around PHP's problems (probably without noticing) because they are afraid to run "cpan -i Some::Modules" and cut-n-paste a FastCGI configuration into their web server's config file.

Ease of deployment is nice, but deploying other languages is not much harder, and it's significantly easier to actually write a reliable application.

</comment></comment><comment><USER7> PHP is not a language. It's a template engine gone berserk.

<comment><USER8> Couldn't agree more... But it does still do a good job...

<comment><USER7> Never said it didn't. ;)

</comment></comment></comment><comment><USER9> I wouldnt say its growing up, more like jumping the shark.</comment>


Bye Bye PCs? PCs Being Pushed Aside in Japan by Array of Gadgets With Similar Power - <AUTHOR> http://biz.yahoo.com/ap/071104/bye_bye_pcs.html

<comment><USER2> I think what's important to most users is what they can do with the machine, not the technical specs. There's not much you can do with a brand new midrange computer that you can't with a midrange computer from three years ago. Graphics-intensive games are the only mainstream consumer application that comes to mind. Until a year ago, my main computer was a laptop made in 2000. The main limitations that prompted me to replace it were its low screen resolution (1024x768) and maximum RAM (512M).

</comment><comment><USER3> One of the biggest reasons any non-geek in the US gets a computer is for email. In Japan they _all_ have phones with email. I think long-term it's probably a real problem for Japan that an awful lot of people aren't PC users.</comment>


Show HN: Containerum – open source container platform for Kubernetes - <AUTHOR> https://github.com/containerum/containerum <comment><AUTHOR> The platform is built with Go. Currently we are working on important features like revision control, integration with major CI/CD tools (currently GitLab and Travis are supported), and a bunch of other useful functions.</comment>


Steve Jobs Travel to Liver Transplant Mecca Shows Organ System Flaws - <AUTHOR> http://www.bloomberg.com/apps/news?pid=20601103&sid=au6imqRi7UHE <comment><USER2> Roundtrip SFO->MEM is ~$500. In comparison to the costs of a liver transplant it is miniscule (even if you go 6x). Most middle income people could do the same thing if they:

A) have savings and B) think the situation demands it

Supplemental insurance companies could also probably cater to this need.</comment>


Python 3.5.2 is released - <AUTHOR> https://www.python.org/downloads/release/python-352/ <comment><USER2> Those seem like a lot of big changes for a patch release.

<comment><USER3> That list is for the 3.5 release, not the 3.5.2 patches</comment></comment>


PlanBlock - <AUTHOR> http://planblock.com

<comment><AUTHOR> Updated daily, its an events site full of places, people, and events around Boston and Cambridge! started initially as a pet project, its about time i let this puppy into the wild</comment>


Nock, Hoon, etc. for Non-Vulcans (Why Urbit Matters) - <AUTHOR> http://www.popehat.com/2013/12/06/nock-hoon-etc-for-non-vulcans-why-urbit-matters/

<comment><USER2> Clearly I'm the only one on HN that is fascinated by Urbit, oh well :)

<comment><USER3> Not the only one - I just read this - and it fitted so well into some stuff I have been playing with using multiple micro processor boards and sensors - that now I just have to dive into it and see where it takes me.</comment></comment>


Show HN: SketchDeck - build slides faster - <AUTHOR> http://sketch-deck.com

<comment><USER2> Just signed up for the beta! This seems absolutely ideal for my workflow when putting a talk together. I love writing and sketching long-hand to structure my talks just right, but hate the process of then converting those sketches to a deck.

Looking forward to your next beta round, and good luck with the project!

<comment><AUTHOR> Thanks emhart! In the companies I've worked at, I've always sketched first. It's exciting to remove the middle painful bit.

Looking forward to seeing what you think of the beta :D

</comment></comment><comment><USER3> This will be awesome</comment>


Ask HN: How do you handle DDoS attacks? - <AUTHOR> For owners of small websites running on DigitalOcean, GCP or AWS, how do you handle DDoS and DoS attacks?
For context, while exploring the load testing tool Siege running on a VPS, I was able to bring down multiple sites running on shared hosting, and some running on small VPS by setting a high enough concurrent number of users. This is not a DDoS, but it goes to show how easy it is to cause damage. Note: I only brought down sites that I own, or those of friends with their permission.
What tools are useful in fighting DDoS attacks and script kiddies? Mention free and paid options.
What are the options to limit damage in case of an attack? How do you limit bandwidth usage charges?
There was a previous discussion on this topic 6 years ago https://news.ycombinator.com/item?id=1986728 <comment><USER2> I've faced DoS attacks for years as I run internet forums.

The simple advice for layer 7 (application) attacks:

1\. Design your web app to be incredibly cacheable

2\. Use your CDN to cache everything

3\. When under attack seek to identify the site (if you host more than one) and page that is being attacked. Force cache it via your CDN of choice.

4\. If you cannot cache the page then move it.

5\. If you cannot cache or move it, then have your CDN/security layer of choice issue a captcha challenge or similar.

The simple advice for layer 3 (network) attacks:

1\. Rely on the security layer of choice, if it's not working change vendor.

On the L3 stuff, when it comes to DNS I've had some bad experiences (Linode, oh they suffered) some pretty good experiences (DNS Made Easy) and some great experiences (CloudFlare).

On L7 stuff, there's a few things no-one tells you about... like if you have your application back onto AWS S3 and serve static files, that the attack can be on your purse as the bandwidth costs can really add up.

It's definitely worth thinking of how to push all costs outside of your little realm. A Varnish cache or Nginx reverse proxy with file system cache can make all the difference by saving your bandwidth costs and app servers.

I personally put CloudFlare in front of my service, but even then I use Varnish as a reverse proxy cache within my little setup to ensure that the application underneath it is really well cached. I only have about 90GB of static files in S3, and about 60GB of that is in my Varnish cache, which means when some of the more interesting attacks are based on resource exhaustion (and the resource is my pocket), they fail because they're probably just filling caches and not actually hurting.

The places you should be ready to add captchas as they really are uncacheable:

* Login pages

* Shopping Cart Checkout pages

* Search result pages

Ah, there's so much one can do, but generally... designing to be highly cacheable and then using a provider who routinely handles big attacks is the way to go.

<comment><USER3> Uh, stupid question but how do you cache a website like for example this comment thread on hackernews? Suppose a DDoSer calls this comment thread a lot of times. The request has to go through to the server because when I hit F5 or post a comment myself, I see the comments in realtime. How do you handle that exactly? Does caching for a few seconds help already, or does the backbone push updated sites to the CDN server? I have no experience in DDos mitigation.

<comment><USER2> Cache everything a guest accesses for 5 minutes or more. Vary on the specific cookie that represents a signed-in user.

None of my guests have noticed this, and it has increased most of my analytics numbers as my pages are faster too.

The signed-in users, they get the dynamic pages.

But now the cookie that identifies the user is what you use to correlate any attack traffic, the attacker is forced to (somewhat) identify themselves and you can then revoke their authentication status or ban the account.

Finally you captcha and/or rate-limit the login page.

This is effectively what I do on my sites, the pages themselves and the underlying API all cache if the cookie or access token is absent.

This is trivial to do within the code, but can be harder to do with the CDN/security layer (who need to support a "vary on cookie" or "bypass cache on cookie" or equivalent).

</comment></comment></comment><comment><USER4> My startup's site gets DDOS'd about once a week. We have seen a huge range of attacks from UDP floods, to wordpress pingback attacks, to directed attacks on our services.

We have many layers of protection:

* We run iptables and an api we wrote on our ingest servers. We run failtoban on a separate set of servers. When fail2ban sees something, we have it hit the api and add the iptables rules. This offloads the cpu of failtoban from our ingest servers.

* We block groups of known hosting company IP blocks, like digital ocean and linode. These were common sources of attacks.

* Our services all have rate limits which we throttle based on IP

* We have monitoring and auto-scaling which responds pretty quickly when needed. And has service level granularity.

* Recently moved behind cloudflare because google cloud did not protect us from attacks like the UDP floods which didn't even reach our servers.

EDIT: formatting

<comment><USER4> One other thing to add:

If they attackers are persistent, there is really no way to guarantee zero down time. THEY WILL FIND A WAY. Just make sure your stake holders know you are doing everything in your power to resolve the issues, and then actually do those things.

An anecdote:

We had been seeing DDOS attacks for a few weeks, so we had most everything locked down and working. But then suddenly one of the most important parts of our site started going down under load. That part is a real time chat system. We looked for which chat room had the load and it was one which did not require a user be registered. We switched the room into registered users only mode and thought we had solved it.

About 5 minutes later the attack came back with all registered users. We were amazed, becuase there is no way the attackers could have registered that many accounts in 5 minutes because of our rate limiting on that. Turns out that they had spend the past week or so registering users in case they needed them :)

<comment><USER5> Great tips and examples. Makes me wonder what site/service you work on that attracts attackers like that.

<comment><USER4> [https://www.stream.me/](https://www.stream.me/)

We have some controversial users...

<comment><USER4> I guess some people just really hate kittens :)

[https://www.stream.me/kittendorm](https://www.stream.me/kittendorm)

</comment></comment></comment></comment></comment><comment><USER6> I work at a large CDN that also sells DDoS mitigation.

Firstly, we are built to endure any DDoS the internet has yet seen on our peering, backbone, and edge servers for CDN services. This is quite important when you are tasked with running a large percentage of the interweb but probably not practical for most organizations, mostly due to talent rather than cost (you need people that actually understand networking and systems at the implementation level, not the modern epithet of full stack developer).

But, it is critical to have enough inbound peering/transit to eat the DDoS if you want to mitigate it -- CDNs with a real first party network are well suited for this due to peering ratios.

Secondly, when you participate in internet routing decisions through BGP, you begin to have options for curtailing attacks. The most basic reaction would be manually null routing IPs for DoS, but that obviously doesn't scale to DDoS. So we have scrubbers that passively look for collective attack patterns hanging on the side of our core, and act upon that. Attack profiles and defense are confirmed by a human in our 24/7 operations center, because a false positive would be worse than a false negative.

Using BGP, we can also become responsible for other companies' IP space and tunnel a cleaned feed back to them, so the mitigation can complement or be used in lieu of first party CDN service.

In summary, the options are pretty limited: 1) Offload the task to some kind of service provider 2) Use a network provider with scrubbing 3) you've hired a team to build this because you are a major internet infrastructure.

</comment><comment><USER7> We need to divide DDoS here in two categories:

-DDoS you can handle (small ones). That anything up to 1 or 2Gbps or 1m packets per second.

-DDoS you can not handle. Anything higher than that.

For the smaller DDoS attacks, you can handle it by adding more servers and using a load balancer (eg. ELB) in front of your site. Both Linode and DigitalOcean will null route your IP address if the attack goes above 100-200Mbps, which is very annoying. Amazon and Google will let you handle on your own (and charge you for it), but you will need quite a few instances to keep up with it.

For anything bigger than that, you have to use a DDoS mitigation service. Even bigger companies do not have 30-40Gbps+ capacity extra hanging around just in case.

I have used and engaged with multiple DDoS mitigation companies and the ones that are affordable and good enough for HTTP (or HTTPS) protection are CloudFlare, Sucuri.net and Incapsula.

-CloudFlare: Is the most popular one and works well for everything but l7 attacks (in my experience). You need to get their paid plan, since the free one does not include ddos protection - they will ask you to upgrade if that happens.

-Sucuri.net: Not as well known as CloudFlare, but they have a very solid mitigation. Have been using them more lately as they are cheaper overall than CloudFlare and have amazing support.

-Incapsula: I used to love them, but their support has been really bad lately. They are on a roll trying to get everyone to upgrade their plans, so that's been annoying. If you can do stuff on your own, they work well.

That's been longer than what I anticipated, but hope it helps you decide.

thanks,

<comment><USER8> Worth noting that Incapsula had _multiple_, _world wide_ outages back in March. Akamai is a more expensive, but more reliable/proven alternative.

[http://www.bauer-power.net/2016/03/incapsula-had-major- world...](http://www.bauer-power.net/2016/03/incapsula-had-major-worldwide- outage.html#.V8MrDJMrLMU)

<comment><USER7> Yep, we suffered through it.

To be fair, they all have some downtimes from time to time.

</comment></comment></comment><comment><USER9> We (Baqend) use an approach that is somewhat different from what has been proposed here so far:

\- Every one of our servers rate limits critical resources, i.e. the ones that cannot be cached. The servers autoscale when neccessary.

\- As rate limiting is expensive (you have to remember every IP/resource pair across all servers) we keep that state in a locally approximated representation using a ring buffer of Bloom filters.

\- Every cacheable resource is cached in our CDN (Fastly) with TTLs estimated via an exponential decay model over past reads and writes.

\- When a user exceeds his rate limit the IP is temporarily banned at the CDN- level. This is achieved through custom Varnish VCLs deployed in Fastly. Essentially the logic relies on the bakend returning a 429 Too Many Requests for a particular URL that is then cached using the requester's ID as a hash key. Using the restart mechanism of Varnish's state machine, this can be done without any performance penalty for normal requests. The duration of the ban simply is the TTL.

TL;DR: Every abusive request is detected at the backend servers using approximations via Bloom filters and then a temporary ban is cached in the CDN for that IP.

<comment><USER10> I'm sorry, I know it's irrelevant, offtopic and I'm a horrible person but... "Baqend"? Who came up with this name? Was there some brainstorming involved and that was the best candidate? What does the branding say about your business? How is it pronounced?

<comment><USER9> It's pronounced "Backend" ;-)

And since we are in the Backend-as-a-Service market, the name is not all that unfitting. Although it cannot be denied that from time to time some people think we are French an spelled "Baquend".

</comment></comment></comment><comment><USER11> I use and recommend hosting with OVH if you are worried about DDOS and serving a Western market. No affiliation, just a happy customer.

OVH include DDOS protection by default[0] and they have a very robust backbone network[1] in Europe and North America that they own and operate themselves (this is how & why anti-DDOS is standard with them).

For quick side-projects I still fire up a DigitalOcean instance or two because their UX is so slick and easy. If I needed huge scale and price didn't matter I would probably go with AWS (their 'anti-DDOS' is their vast bandwidth + your ability to pay for it during an attack). For everything else, I put it on OVH.

[0][https://www.ovh.com/us/anti-ddos/](https://www.ovh.com/us/anti-ddos/)

[1][http://weathermap.ovh.net/](http://weathermap.ovh.net/)

<comment><USER12> Have you been DDoSed while on OVH? I've heard there are a bunch of providers who claim DDoS prevention, but what that means in practice is just "we'll take your site offline right away and not charge you for the incoming bandwidth!". Super helpful.

<comment><USER13> I've had several attacks hit my services on OVH. Not once did they null route, and as far as I could tell the majority of attack traffic was filtered with only a minor service interruption before mitigation kicked in. Granted these were shitty $10 booter services hitting me and not a "real" DDoS.

Be careful using services like game servers or VOIP or anything else using UDP though, since UDP is subject to much more stringent filtering at OVH and may get affected during mitigation.

</comment></comment></comment><comment><USER14> I work at a CDN/Security engineering company, but this is just my view.

First off you need to determine where the attack is coming from. You could redirect based on IP/request headers in a .htaccess file or apache rules.

Your next bet is to distribute/auto-scale your application if possible.

You need to setup a web application firewall that sits in front of your web servers and analyzes the requests/responses that hit the web servers. A lot of the ddos campaigns are easy to identify based on the request headers/IP/Geo and requests/second.

It's not hard to write a small web server/proxy to do this, but it would be best left to someone who knows what they're doing because you don't want to block real user requests. You can use ModSecurity's open source WAF for apache/nginx, but again you have to know what you're doing.

When I faced this issue, I wrote a small web server/proxy here that you can start on port 80:

[https://github.com/julesbond007/java-nio-web- server](https://github.com/julesbond007/java-nio-web-server)

Here I wrote some rules to drop the request if it's malicious:

[https://github.com/julesbond007/java-nio-web- server/blob/mas...](https://github.com/julesbond007/java-nio-web- server/blob/master/src/main/java/com/nio/http/filter/RequestFilter.java)

</comment><comment><USER15> AWS informs us that an ELB with HTTP/HTTPS termination takes care of all problems except application level attacks. Traffic ingress is free, so it shouldn't be expensive?

For static content there is always CDN. Costly, but it works in a pinch, while you're planning you other moves.

The one thing left to worry about is dynamic content. Depending on the application you could restrict all requests to authorized users only while under attack.

This isn't a complete solution by any means, but reduced the attack surface considerably.

[https://d0.awsstatic.com/whitepapers/DDoS_White_Paper_June20...](https://d0.awsstatic.com/whitepapers/DDoS_White_Paper_June2015.pdf)

</comment><comment><USER7> To summarize the discussion here so far:

1- For small attacks you can optimize your stack, cache your content and use a provider that allows you to quickly scale and add more servers to handle the traffic. Do not use Linode or Digital Ocean as they will null route you.

OVH, AWS and Google are the ones to go with.

2- Use a DDoS mitigation / CDN provider that will filter the attacks and only send clean traffic back to you.

The ones recommended so far:

[https://cloudflare.com](https://cloudflare.com)

[https://sucuri.net](https://sucuri.net)

[https://incapsula.com](https://incapsula.com)

</comment><comment><USER16> There are many services for HTTP protection, but when you have a custom protocol for a RT service like a game, you are kind of screwed. It's even worst if your game is UDP based.

I used to get attacked huge a load of corrupt UDP packets for a few seconds and that used to hang the main server, wich in 1 or 2 minutes disconnected all my players.

Solution: separate your UDP services from your TCP services in separate applications and servers, also use different type of protection services for each.

The attack still hanged the UDP services, so I started thinking about making a plugin for snort to analyse the traffic and only allow legit protocol packets. I haven't done any of this last idea because the attackers stopped since they noticed that no one was being disconnected.

BTW, for TCP and HTTP I just used any tiny service that protects me from SYN Flood, like Voxility resellers.

<comment><USER7> That's a good point. CloudFlare, Sucuri and friends only handle HTTP/HTTPS/DNS traffic.

If you have custom protocols, you have to get a full /24 mitigation and so far nobody can beat Arbor into it. Very expensive, but works well if you have BGP.

</comment></comment><comment><USER17> [https://www.cloudflare.com](https://www.cloudflare.com)

<comment><USER18> You mean the biggest MiTM on the web?[0]

The only reason why they're not constantly called out by serious infosec folk for their _scam_ is because they hire guys also involved in DefCon/BlackHat planning (try to sneak a hostile talk against Cloudflare past REDACTED[2] who btw is also advising Mr. Robot). It's lobbying at its finest.

[0] [https://scotthelme.co.uk/tls-conundrum-and-leaving- cloudflar...](https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflare/)

[1] [https://blog.torproject.org/blog/trouble- cloudflare](https://blog.torproject.org/blog/trouble-cloudflare)

EDIT: [2] redacted name since there is more than one, please duckduckgo by yourself.

<comment><USER17> Yes, I'm well aware that cloudflare is mitm, yet for my needs I've decided that this is not a problem.

I can see that you are not happy with what they provide. Luckily theirs service is not forced on you. Neither do you have to use it, nor visit server that use it.

</comment></comment></comment><comment><USER13> Most DDoS attacks are volumetric. There isn't a way to defend against this other than simply having a huge pipe, or paying someone with a huge pipe to be in front of your site.

Non-volumetric attacks like SYN or HTTP floods can be mitigated with appropriate rate limiting or firewalling.

Some providers like OVH have decent network-level mitigation in place, but you're not gonna find that on a $5 VPS where they're more than happy to null route you to protect their network.

<comment><USER7> Depending on the size of the syn flood or HTTP flood, there is no way you can handle it locally.

Some syn floods can generate millions of packets per second, which is way more than a dedicated linux server can handle.

Good video on the topic:

[https://www.youtube.com/watch?v=pCVTEx1ouyk](https://www.youtube.com/watch?v=pCVTEx1ouyk)

</comment></comment><comment><USER19> AWS DDoS defense techniques summary

[https://d0.awsstatic.com/whitepapers/DDoS_White_Paper_June20...](https://d0.awsstatic.com/whitepapers/DDoS_White_Paper_June2015.pdf)

AWS DDoS defense using rate based blacklisting

[https://blogs.aws.amazon.com/security/post/Tx1ZTM4DT0HRH0K/H...](https://blogs.aws.amazon.com/security/post/Tx1ZTM4DT0HRH0K/How- to-Configure-Rate-Based-Blacklisting-with-AWS-WAF-and-AWS-Lambda)

</comment><comment><USER20> +1 to CloudFlare and Incapsula. Content delivery networks inherently distribute traffic and most have security enhancements specific to Distributed Denial-of-Service mitigation.

DDoS protection providers offer a remote solution to protect any server / network, anywhere: [https://sharktech.net/remote-network-ddos- protection.php](https://sharktech.net/remote-network-ddos-protection.php)

</comment><comment><USER21> A) have enough servers so when one gets null routed, it's not a huge deal

B) make sure your servers don't fall over while getting full line rate of garbage incoming (this is not hard for reflection or synfloods, but is difficult if they're hitting real webpages, and very difficult if it includes a tls handshake)

C) bored ddos kiddies tend to ddos www only, so put your important things on other sub domains

D) hope you don't attract a dedicated attacker

</comment><comment><USER22> Disclaimer: I work for a hosting company, but these views are my own personal opinions which I held even before working where I currently do.

This is one of the reasons I would consider managed hosting as opposed to AWS, Digital Ocean, etc. With any good managed hosting provider, they are going to take steps to help deal with the DDoS. Depending on your level of service and the level of the attack, of course. But they will have an interest in helping you deal with and mitigate the attacks.

The reality is that true DDoS solutions are expensive, and if you have a "small website" then you're probably not going to be able to afford them. But if you're at a good sized hosting provider, they're going to need to have these solutions themselves and can hopefully put them to use to protect your site.

</comment><comment><USER23> 1\. Have a big enough pipe; if you are getting a DDoS attack of 2Gigabits/second and your uplink is 1Gigabit there is nothing you can do except look for someone else to filter your traffic. (They have to basically take on the 2gig ddos; filter it and then pass back the valid traffic to you).

Verisign and others offer this service; typically using DNS. However often they support BGP

2\. Add limiting factors; if you have an abusive customer rate limit them in nginx. If you are expecting a heavy day rate limit the whole site.

3\. Stress testing and likely designing your website to withstand DDoS attacks.

You can cache or not cache; that's not really the question. Handling a DDoS means what can you do to mitigate the extreme amount of traffic and still allow everything else to work.

<comment><USER24> We got hit by one about a month ago that was over 20Gb. Even a 10Gb pipe has limits.

</comment></comment><comment><USER25> I've found this very useful:

[http://www.linuxjournal.com/content/back-dead-simple-bash- co...](http://www.linuxjournal.com/content/back-dead-simple-bash-complex-ddos)

</comment><comment><USER12> Don't piss anyone off

<comment><USER26> That is excellent advice, in combination with other tactics.

If you do piss anyone off, keep records of everything. Make sure you know who they are, and where they live, before you start doing business with them. This lets you send the police after they hire someone to DDoS you. Bad people need to be removed from the pool to reduce these sorts of attacks. Record 100% of your phone calls. Android has free apps to do this for you automatically. If you're in a state that requires 2-party authorization, move to a state that offers 1-party authorization. Sanity in laws = freedom of citizens.

<comment><USER15> Talk to a lawyer first re phone call recording. Seriously, you will be glad that you did.

</comment></comment></comment><comment><USER27> You pay blacklotus a big pile of money and giggle at attackers.

[http://www.level3.com/~/media/files/brochures/en_secur_br_dd...](http://www.level3.com/~/media/files/brochures/en_secur_br_ddos_mitigation_proxy.pdf)

</comment><comment><USER28> Cloudbric offers free DDoS protection.

[https://cloudbric.com](https://cloudbric.com)

<comment><USER29> They don't have any cdn in China, so it doesn't work for this market.

<comment><USER30> They let me choose cdn in Singapore.

</comment></comment></comment><comment><USER31> I colocate and rent services from providers who offer DDoS filtering and put all my websites behind CloudFlare. OVH's protection is actually an excellent value, when I used to help run a game server provider they were mitigating 20 gbit/sec and larger volumetric floods almost daily.

</comment><comment><USER32> Most of the responses here deal with bandwidth floods. Is that really the most common DDoS?

Thinking like an attacker, wouldn't the most effective DoS be to find a CPU or memory intensive part of an application and use a small amount of bandwidth to create a large impact?

<comment><USER6> Attacks that are heavy on L1-4 are the hardest to protect against because of the need for large fixed infrastructure (peering/transit).

L7 attacks can be scrubbed by the same infrastructure. Beyond that, it's all a matter of detection. The computational expense of L7 inspection can be mitigated by sampling or scaled with ECMP. You may see a "WAF" (Web Application Firewall) enter the picture at this level.

</comment></comment><comment><USER33> Depends on your needs, if you are in control of your network, etc. Two options here:

[http://cloudflare.com](http://cloudflare.com)

[http://defense.net](http://defense.net)

<comment><USER7> Surprised to see anyone mention defense.net.

How has been your experience with it?

</comment></comment><comment><USER34> Hey, I worked for game developing company and the attack was hitting some backend services. We tested voxility.com, it worked out fine after all was integrated.

</comment><comment><USER35> Cloudflare. It's been a real life saver for us.

<comment><AUTHOR> Could you elaborate? Which plan are you on? What was the size of the DDoS attack?

</comment></comment><comment><USER36> To be honest, that was the only reason why I migrated from DigitalOcean to OVH.

</comment><comment><USER37> Post was too long [http://pastebin.com/48J9Ufdd](http://pastebin.com/48J9Ufdd) :<

Random "wisdom", not in any particular order more like do's and dont's that I picked up with dealing with and executing DoS/DDoS attacks.

Testing, testing, testing, regardless of how you choose and what you implement your mitigation test it and test it well because there are a lot of things you need to know.

Know and understand exact effect that the DDOS/DoS mitigation has, the leakage rate, what attacks can still bring you down, and the cost of mitigation.

Make sure you do the testing at different hours of the day if not you better know your application and every business process very well because I've seen cases where 50GB/s DDoS would do absolutly nothing except on tuesday and sunday at 4AM when some business batch process would start and the leakage from the DoS attack + the backend process would be enough to kill the system. Common processed that can screw you over are backups, site to site or co- location syncs/transfers, various database wide batches, pretty common times for this anything in early morning, end of weak, end of month, end of quarter etc.

If you are using load or stress testing tools on your website make sure to turn off compression it's nice that you can handle 50,000 users that all use GZIP but the attackers can choose not too.

Understand what services your website/service relies on for operation common things are services like DNS, SMTP etc. if I can kill your DNS server people can't access your website, if i can kill services that are needed for the business aspect of your service to function like SMTP I'm effectively shutting you down also.

If you are hosting your service on Pay As You Go hosting plans make sure to implement a billing cap and a lot of loud warnings, your site going down might not be fun, but it's less fun to wake up to a 150K bill in the morning, if you are a small business DoD/DDoS can result in very big financial damages that can put you out of business.

Understand exactly how many resources each "operation" on your website or API costs in terms of memory, disk access/IOP's, networking, DB calls etc, this is critical to know where to implement throttling and by how much.

If you implement throttling always do it on the "dumber" layer and the layer that issues the request for example if you want to limit the amount of DB queries you execute per minute to 1000 do it on the application server not on the DB server. This is both because you always want to use "graceful" throttling which means the requesters chooses not to make a request rather than the responder having not to respond, and it also allows you to implement selective throttling for example you might want to give higher priority to retrieving data of existing users than to allow new users to sign up or vice versa.

Do not leak IP address this is both in regards to load balancing and using scrapping services like Cloudflare. When you used services like cloudflare make sure that the services you protect are not accessible directly, make sure some one can't figure out the IP address of your website/API endpoint by simply looking at the DNS records. Common pitfalls are www.mysite.com -> cloudflare IP while mysite.com/www1.mysite.com/somerandomstuff.mysite.com reveal the actual IP address. Another common source is having your IP address revealed via hard coded URLs on your site or within the SDK/documentation for your API. If you have moved to cloudflare "recently" make sure that the IP address of your services is not recorded somewhere there are many sites that show historic values for DNS records if you can it is recommended to rotate your IP addresses once you sign up for a service like cloudflare and in any case make sure you block all requests that do not come through cloudflare.

When you do load balancing do it properly do not rely on DNS to for LB/round robin if you have 3 front end servers do not return 3 IP addresses when some one asks whois www.mysite.com put a load balancer infront of them and return only 1 IP address. Relying on DNS for round robin isn't smart it never works that well and you are allowing the attacker to focus on each target individually and bring your servers one by one.

Do not rely on IP blacklisting and for whatever reason do not ever ever ever use "automated blacklisting" regardless of what your DDoS mitigation provider is trying to tell you. If you only service a single geographical region e.g. NA, Europe, or "Spain" you can do some basic geographical restrictions e.g. limit access from say India or China this might not be possible if you are say a bank or an insurance provider and one of your customers has to access it from abroad. Ironically this impacts the sites and services that are the easiest to optimize for regional blocking for example if you only operate in france you might say ha! I'll block all non-french IP address but this means that what an attacker needs to do is simply use IP spoofing and go over the entire range of French ISP's and you blacklist all of France this only takes a few minutes to achieve! If you are blacklisting commercial service provider IP's make sure you understand what impact can it have on your site, blacklisting DigitalOcean or AWS might be easy but then don't be surprised when your mass mail services or digital contract services stop working. If you do use some blacklisting / geoblocking use a single list that you maintain do not just select "China" in your scrapping service, firewall, router, and WAF all of them can have different Chinas which causes inconsistent responses, use a custom list and know what is in it.

Do not whitelist IP! I've seen way too many organizations that whitelist IPs so those IPs would not go for example through their CDN/Scrapping service or would be whitelisted on whatever "Super Anti DDoS Appliance" the CISO decided to buy into this month. IP spoofing is easy! drive by attacks are easy! And since a common IPs to whitelist are things like your corporate internet connection nothing is easier for an attack to do than to figure those out. They simply need to google for the network blocks assigned to your organization if you are big enough and or were incorporated prior to 2005 or send a couple of 1000's of phishing emails and get do some sniffing from the inside.

Understand collateral damage and drive by attacks. Know who (if) you share your IP addresses with and figure out how likely they are to be attacked, yes everyone would piss some one with keyboard access these days but there are plenty of types of businesses that are more common as targets, if you are hosting in a datacenter that also provides hosting for a lot of DDoS targets you might suffer also. For drive by attacks you need to have good understanding of the syndication of your service and if you are a B2B service provider your customers. If you provide some embedded widget to other sites if they are being DDoSed you might get hit also if it is a layer 7 attack. If you are providing service for businesses for example an address validation API you might get hammered if one of your clients is being DDoSed and the attacker is hitting their sign up pages.

Optimize your website; remove or transfer large files things like documents and videos can be moved to various hosting providers (e.g. YouTube) or CDN's, if you are hosting large files on CDN's make sure they are only accessible via the CDN, infact for the most part it's best if you make sure that what is hosted on the CDN is only accessible via the CDN this prevents attackers from accessing the resources on your own servers via selecting your IP instead of the CDN. A common pitfall would be that some large file is linked on your website as cdn1.mysite.com/largefile but it's also accessible directly from your servers via www.mysite.com/largefile.

Implement anti-scripting techniques on your website, captcha, DOM rendering (makes it very expensive for the attacker to execute layer 7 attacks if they need to render the DOM to do so) and make sure that every "expensive" operation is protected with some sort of anti-scripting mechanism. Test this! captchas that are poorly implemented are no good, and I don't mean captchas that are somehow predictable or easy to read with CV's if you have a services that looks like this LB>Web Frontend>Application Server>DB make sure that the captcha field is the 1st thing that is being validated and make sure it's validated in the web frontend or even in the LB/Reverse Proxy. If you hit the application server validate all the fields do the thing and just before sending it to the DB you validate the captcha this won't help to protect you against DoS/DDoS as well if at all.

When you implement any mitigation design it well and understand leakage and "graceful failure", it's better for the dumb parts of your service to die and restart than it is for the more complicated parts. For example if after all of your mitigation you still have 10% leakage from your anti-ddos/scraping service to your web frontend and from it there is a 5% leakage to to your DB do not scale the web frontend to compensate for the leakage from your scrapping service to the point of putting your DB at risk. A web server going down is mostly a trivial thing as it would bring itself back up usually on its own without any major issues, if your DB gets hammered well it's a completely different game you do not want to run out of memory or disk and to have to deal with cache or transaction log corruption or consistency issues on the DB. Just get used to the fact that no matter what you are going to do and implement if some one wants to bring you down they will, do what you can and is economical to you do mitigate against certain attacks and for the reset design your service with predicted points of failure that would recover on their own in the most graceful manner and shortest period.

<comment><USER38> Why would you turn off compression? A given amount of requests is more burdensome on the CPU when decompression is to be performed.

<comment><USER39> Assuming the remote is actually decompressing, and the origin isn't dynamically compressing for each request.

<comment><USER37> Even if the remote is decompressing it doesn't matter a botnet owner or some one who compromised a few AWS accounts doesn't care it won't really slow them down. CPU's are pretty fast at compression and when a site is easily 3-4 times the size when not served compressed you are going to hit your network cap limit faster than exhausting the CPU even with dynamic compression and no caching under most circumstances.

</comment></comment></comment></comment><comment><USER40> * Don't buy service from a single CDN. It's a recipe for disaster because even Akamai have outages, and having a traffic management setup that lets you move partial/entire traffic to a different CDN will let you not only mitigate their outages, but also move traffic to a cheaper/better provider.

* If you can't CDN all your traffic, a CNAME with low TTL that can quickly switch to a CDN/WAF endpoint can be helpful.

* AWS, Azure and GCP all have mitigations for L3 attacks built into their infrastructure. Because you don't know how they operate, or when, don't rely on them. Accept they may break your service and be prepared to have downtime or the means to shift your product quickly if an attack is big enough or presses enough secret buttons.

* Identify and remove all potential means of amplification both at networking/infra and application. This means not exposing your own nameservers or NTP servers publicly, for L7 this is more complicated as it'll depend on how your APIs and products interact with themselves and each other.

* Load test your products often to know what breaking point is and when performance regressions arise with a given amount of resources allocated. Fixing these early may mean you can ride out a DDoS without needing to do anything if it's small enough and your application efficient enough.</comment>


Google Unveils its Search Algorithm Secrets - <AUTHOR> http://www.epurplemedia.co.uk/article_zone/Google-Unveils-its-Search-Algorithm-Secrets.html The mystery behind the Google Algorithms is finally disclosed partly though. Google opens up its closely guarded search algorithm formula to the world. <comment><USER2> Spam!</comment>


Notion Ink developer program opens - <AUTHOR> http://developers.notionink.com

<comment><USER2> While that is a pretty page everything I click on gives me an error message.

</comment><comment><AUTHOR> found via slashgear : [http://www.slashgear.com/notion-ink-adam-developer- program-o...](http://www.slashgear.com/notion-ink-adam-developer-program- opens-19108742/)</comment>


What really is sin? - <AUTHOR>

<comment><USER2> An easier explanation is:

Sin is destructive behavior that brings intentional harm to yourself, others, society and those representing others or God.

1 John 3 4 Everyone who sins breaks the law; in fact, sin is lawlessness. 5 But you know that he appeared so that he might take away our sins. And in him is no sin. 6 No one who lives in him keeps on sinning. No one who continues to sin has either seen him or known him.

Mark 12 28 One of the teachers of the law came and heard them debating. Noticing that Jesus had given them a good answer, he asked him, "Of all the commandments, which is the most important?"

29 "The most important one," answered Jesus, "is this: 'Hear, O Israel: The Lord our God, the Lord is one.[e] 30 Love the Lord your God with all your heart and with all your soul and with all your mind and with all your strength.'[f] 31 The second is this: 'Love your neighbor as yourself.'[g] There is no commandment greater than these."

The sum of the law is love - of God, yourself and your neighbours.

If sin is lawlessness, then sin is the opposite of that - hate towards God, yourself and others.

</comment><comment><AUTHOR> It is said that one cannot sin, and if one sins he is of the devil and he never saw Jesus nor even saw Him;from 1 John. Then iam confused and really want to know what sin is.

</comment><comment><USER3> the intended meaning of "sin" in its original language can be interpreted as "missing the mark". What is that "mark"? According to the Bible, the mark is the Truth, God's Word, or to simply put, living according to the Word of God, or living the life that Jesus commanded us to live.

Therefore, all acts of "sin" as postulated by the society (e.g. immoral behaviour, adultery, murder etc), according to the Word of God are merely the symptoms of sin.

Therefore, real sin or the root sin is the very fact that we are not living according to God's ways, but "missing the mark" and going on our own ways.</comment>