TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Why are law documents (GDPR) so difficult to understand?

71 点作者 evervevdww221大约 7 年前
As much as I want to comply to GDPR, I think its articles difficult to understand, like many other law documents.<p>https:&#x2F;&#x2F;gdpr-info.eu&#x2F;<p>As an engineer, I found it is very difficult to translate from the regulation text to code, to actual implementation.<p>Taking the following statement as an example:<p>https:&#x2F;&#x2F;gdpr-info.eu&#x2F;art-5-gdpr&#x2F;<p>&gt;&gt;&gt;<p>(Personal data shall be) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).<p>===<p>&quot;In a manner&quot;. In what manner?<p>What&#x27;s &quot;appropriate security&quot; and &quot;appropriate technical measures&quot;? How to interpret it? There seems to be much flexibility?<p>Every website has some security measures to protect data to certain degree. How do I know if that&#x27;s &quot;appropriate&quot; or enough to meet GDPR?<p>Do I need symmetric encryption? Or Do I need asymmetric encryption? Which kind of crypto hash is considered &quot;appropriate&quot;? What if I use a database which is insecure by flaws, but I don&#x27;t know or don&#x27;t have the technical strength to know it? What if encryption on my backend caused performance penalty? What if I run a hosted, non-profit BBS based on certain open source BBS program that might be insecure? Should I patch the server with OS Update JKB8948, which is known to fix a security hole but opens another? is it an &quot;appropriate measure&quot;?<p>I found this regulation put too much burden on small businesses. Just to understand this GDPR text may require consulting cost. What if this law will be abused as a tactic to attack business competitions? I&#x27;m worried.<p>How do you understand this &quot;security appropriateness&quot; of the above text? How can you be sure your understanding is correct?

32 条评论

eldavido大约 7 年前
This might sound a little mean, and I don&#x27;t mean it to be this way, but this is a really naive viewpoint.<p>Look at any profession -- accounting for instance -- and they have all sorts of stuff like this. As an example, there&#x27;s a concept in accounting of &quot;materiality&quot; - basically, something that&#x27;s big enough to matter. Materiality is what lets fortune 500 companies present their financial statements rounded to the nearest thousand dollars. When you&#x27;re talking about tens&#x2F;hundreds of millions, individual dollars just don&#x27;t matter.<p>Whether or not something is &quot;material&quot; is a matter of professional judgment, to be made in the context of a large body of professional knowledge, history, prevailing industry standards, economic&#x2F;cost considerations, etc, basically that thing called &quot;experience&quot; that we so often toss under the bus in SV.<p>Perhaps the biggest difference between law and code, which are in many ways quite similar, is that law is <i>highly</i> reliant on context. For a court to determine whether &quot;appropriate security&quot; and &quot;appropriate technical measures&quot; are followed, they would solicit testimony from experts in the field (people like us) to determine whether they felt whether someone took &quot;appropriate security&quot;. So ultimately it&#x27;s a matter of opinion, but one made with context and expertise.<p>It works surprisingly well.<p>EDIT: For really complicated stuff, implementation is often delegated to an agency, such as the FCC, to create specific guidelines like you want. But this is the job of executive action, which is easy to change, not statute (on-the-books laws), which is much harder to modify once passed.
评论 #16660159 未加载
评论 #16660026 未加载
评论 #16661261 未加载
michaelbuckbee大约 7 年前
FWIW I recently attempted to translate literally the entirety of the GDPR into Plain English (albeit for a technical audience). It&#x27;s at:<p><a href="https:&#x2F;&#x2F;blog.varonis.com&#x2F;gdpr-requirements-list-in-plain-english&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.varonis.com&#x2F;gdpr-requirements-list-in-plain-eng...</a><p>In general I think legislatures putting out goals&#x2F;guidelines instead of detailed specifications is a feature not a bug. Tech moves faster than they can possibly keep up with and to call out things down to the patchnote level just isn&#x27;t feasible.<p>Try to think of it more like: &quot;jury of your peers&quot;. If a dozen fellow sysadmins &#x2F; devops &#x2F; programmers would consider what you&#x27;re doing to be reasonable then you&#x27;re probably ok.<p>One big caveat to that with GDPR is that the legislature is very purposefully pushing for what many would consider fairly innocuous &quot;personal data&quot; to be treated more how many developers today would treat something like credit card numbers or banking info including pins and passwords.<p>If the format&#x2F;style of the article feels familiar to you, it&#x27;s probably because you read &quot;AWS in Plain English&quot; which I also wrote and which periodically blows up on HN.
评论 #16660056 未加载
评论 #16659951 未加载
评论 #16660442 未加载
Tomte大约 7 年前
You don‘t really expect a law to specify which hash algorithm you‘re supposed to use, do you?<p>The answer is simple: the law will stand for a long time, and legislators know their limits. Unlike many engineers, unfortunately.<p>Having courts interpret laws, with help from experts, is not a bug, but a feature!
评论 #16659851 未加载
评论 #16659972 未加载
评论 #16661303 未加载
评论 #16660161 未加载
codingdave大约 7 年前
I did one semester of law school before deciding I didn&#x27;t really want to go that route, and while I&#x27;m not going to comment on how to read this law, I can tell you my most effective technique for really breaking down the language of legal documents:<p>Treat every paragraph like a great big chain of boolean logic. The confusing parts of law are normally due to long paragraphs of &#x27;and&#x27; and &#x27;or&#x27;, all mingled together. Parsing those in legal documents isn&#x27;t any different than parsing them in code. But we normally don&#x27;t have to think that way when reading, so it feels more confusing than it really is.<p>Try re-reading it specifically looking for the ands&#x2F;ors, and envision how they really operate on the words of the paragraph, and legal reading will suddenly become far more clear.
chomp大约 7 年前
Regulations like this usually draw from other sources for inspiration. So if your company is subject to other regulations (like PCI-DSS), then these really vague sentences start to seem more concrete.<p>1.) Make sure your software has all vendor-supplied patches.<p>2.) When personal data is being processed, keep it in RAM.<p>3.) When personal data is at rest, ensure that it&#x27;s on a locked-down system and safe. Encryption at rest is called out in GDPR, but it&#x27;s not required. (The definition of &quot;locked-down&quot; can fill a couple paragraphs, but consider it like SOX - only give access to employees that need it as part of their job title. Block off all access for everyone else - network, physical, logins).<p>4.) Make sure that all systems that store&#x2F;receive&#x2F;transmit personal data are audited and logged, and do not give out access to people unless they absolutely require it. (Anonymize data for BI, developers, business reports when able)
josaka大约 7 年前
For the same reason the control problem is so hard in AI. It&#x27;s difficult to anticipate how intelligent agents will behave in a reasonably complex environment. To address this challenge, some legal propositions are intended to be clear cut rules, but many are intended to kick the can down the road with less than clear language to be interpreted with the benefit of specific scenarios at hand and experience.
Thespian2大约 7 年前
As others have said, the law isn&#x27;t a technical spec. it describes what you should do, not how you should do it. The concept of &quot;due care&quot; <a href="http:&#x2F;&#x2F;www.businessdictionary.com&#x2F;definition&#x2F;due-care.html" rel="nofollow">http:&#x2F;&#x2F;www.businessdictionary.com&#x2F;definition&#x2F;due-care.html</a><p>comes in to play here. GDPR, at its core, is about legally requiring businesses to care for customer data. It gives customers increased control over how their data is used, and how it should be protected.<p>In answer to OP&#x27;s question &quot;how do I know it is appropriate,&quot; as a first pass, how would <i>you</i> feel if your most important personal data were being treated that way? As a developer, if that makes you uncomfortable, that&#x27;s probably a warning sign.
misthop大约 7 年前
Legislators don&#x27;t (and shouldn&#x27;t imho) get into the specifics of how an industry should abide by the laws they make. That makes the law flexible for the future. In the US, at least, if you were brought up on charges of violation, they would use the reasonable person test. That means that a reasonable person in your position (with the expected knowledge of the industry&#x2F;field&#x2F;underlying tech) would have done it in the way you did. The reasonable. person in hashed out by the jury based on testimony by experts on both sides of the case. Basically if you are using best practices, you should be ok. Qualification: I am a non-practicing attorney
评论 #16660331 未加载
kodablah大约 7 年前
Others are giving an optimistic interpretation. Here&#x27;s my pessimistic one (at least in the GDPR&#x27;s case): they want the wiggle room to subjectively apply these rules on companies they don&#x27;t like. The intention may be valid, but with the boundaries vague you can bet that enforcement won&#x27;t be uniform. It never is and history has shown how ambiguities in law can be bent for targeted application based on political will.<p>Also, most comments will say this is just how it has to be because the law cannot be very specific on highly technical matters. I believe that part is true, but it is not just how it has to be. The other option is the absence of the law and alternative measures to tackle this problem (e.g. education&#x2F;awareness, encouragement of alternatives, public equivalents or assistance w&#x2F; caveats, etc, etc).
评论 #16660305 未加载
kuschku大约 7 年前
EU law is written so it can apply for many decades – when the precursor of the GDPR was written (1995), MD5 was considered secure.<p>So, you should expect the &quot;appropriate&quot; part to mean the current state of the art to keep something secure.<p>An &quot;appropriate&quot; hashing algorithm today would be bcrypt, scrypt, or potentially still a salted SHA512 with many rounds.<p>An &quot;appropriate&quot; protection against unauthorised access would probably be a strict permissions setup in your AWS rules, proper firewalling, and potentially at-rest encryption.<p>An &quot;appropriate&quot; encryption would be AES 256 GCM.<p>&quot;Appropriate&quot; always just refers to the current state of the art for what is considered secure.
评论 #16659581 未加载
matthewmacleod大约 7 年前
<i>I found this regulation put too much burden on small businesses.</i><p>It&#x27;s not. You are wrong.<p><i>What if this law will be abused as a tactic to attack business competitions?</i><p>Why would that happen?<p><i>How do you understand this &quot;security appropriateness&quot; of the above text? How can you be sure your understanding is correct?</i><p>You use your knowledge or regulation to read and make decisions. If you don&#x27;t have the required experience, you hire a consultant or a lawyer. Just like you do when complying with any other piece of legislation.
评论 #16659568 未加载
评论 #16662039 未加载
评论 #16659584 未加载
Cthulhu_大约 7 年前
That&#x27;s up to you - what techniques do you know that allows you to process personal data which ensures it&#x27;s secure? It&#x27;s a law, not a specification or an implementation detail.<p>More general, it&#x27;s difficult to understand because it&#x27;s in legalese, which is aimed at people that studied it for years - it&#x27;s the English programming language. And like code, there&#x27;s lots of holes in it that it doesn&#x27;t cover, despite lots of manyears of effort.
nynno大约 7 年前
My favorite website is this: <a href="https:&#x2F;&#x2F;ico.org.uk&#x2F;for-organisations&#x2F;data-protection-reform&#x2F;overview-of-the-gdpr&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ico.org.uk&#x2F;for-organisations&#x2F;data-protection-reform&#x2F;...</a><p>They have explained GDPR in reasonably everyday language, with checklists and examples. That site should be your first choice.<p>If you are a developer, you should check <a href="https:&#x2F;&#x2F;github.com&#x2F;gdprhq&#x2F;GdprHq.Io.ClientSdk" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gdprhq&#x2F;GdprHq.Io.ClientSdk</a> - you can find interfaces and default implementations. For example, to implement the right to erasure (to be forgotten) in your app, you&#x27;ll need to erase personal data and to inform an individual that you&#x27;ve done so. Even though actual erasure might be tricky, at least you know what you need to implement to be compliant. However, note that having the app GDPR compliant isn&#x27;t the same as having the business compliant; primarily, GDPR is a set of rules and processes that apply to organizations.
pwtweet大约 7 年前
Every Data Protection Office in the EU Member states has published guidance for business and individiuls. Here&#x27;s the British ICO: <a href="https:&#x2F;&#x2F;ico.org.uk&#x2F;for-organisations&#x2F;guide-to-the-general-data-protection-regulation-gdpr&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ico.org.uk&#x2F;for-organisations&#x2F;guide-to-the-general-da...</a>
ThePhysicist大约 7 年前
Okay, let me try to translate that legalese for you (I&#x27;m not a lawyer BTW but I regularly deal with GDRP and data protection issues):<p>&quot;In a manner&quot; means that you&#x27;re absolutely free to use whichever means (i.e. technologies, systems, ...) you want to do your data processing with, as long as you make sure you keep the data secure.<p>&quot;Appropriate security&quot; is indeed a very vague term, but it is vague on purpose: As you probably know firsthand, technologies change rapidly these days, and what&#x27;s considered &quot;state of the art&quot; today might be a &quot;legacy system&quot; in five years. Therefore, laws often do leave the interpretation of terms like the &quot;appropriateness&quot; above open to interpretation by the executive branch. In case of the GDPR, this means that at the highest level it will be the European Court that will decide if a given measure&#x2F;technology was appropriate or not. In practice we can&#x27;t (and do not want to) fight out each definition in court of course, so in addition to that last instance the member countries try to release guidelines that should help companies to judge what measures are appropriate. Unfortunately, there&#x27;s not always consensus between individual countries here so you will have to find a compromise or look at the guidelines of the country you&#x27;re based in (as that&#x27;s where complaints about your company will be handled in the first instance). For Germany, the BSI (Bundesamt für die Sicherheit in der Informationstechnik) would be the relevant instance to look for guidance when it comes to IT security best practices, and the standard that they define will (usually) be followed by the federral data protection agencies.<p>As a final remark, what helped me a lot in understanding the intent behind the law is to read the &quot;motivations&quot; section, which is where the lawmakers write down the actual intent they had when creating a given law. These are used by courts to interpret laws in case of ambiguity and can (in my opinion) greatly help to gain a better understanding of some of the more cryptic articles. Here&#x27;s the link:<p><a href="https:&#x2F;&#x2F;eur-lex.europa.eu&#x2F;legal-content&#x2F;EN&#x2F;TXT&#x2F;?uri=celex%3A32016R0679" rel="nofollow">https:&#x2F;&#x2F;eur-lex.europa.eu&#x2F;legal-content&#x2F;EN&#x2F;TXT&#x2F;?uri=celex%3A...</a><p>If you have any specific questions about appropriate measures or the GDPR please feel free to reach out to me (contact info in my profile), I&#x27;m always eager to learn about your problems and will be glad to give you free advice wherever I can.
onion2k大约 7 年前
<i>I found this regulation put too much burden on small businesses.</i><p>There&#x27;s a very simple way around that problem - don&#x27;t ask for your user&#x27;s data.<p>The GDPR is about making sure you do your best to protect what they share with you. If they don&#x27;t need to share anything then there is no burden on you to protect anything. In my opinion this is the ideal outcome. If you gather their data then there really should be a burden on you and your business to do the necessary work to make sure you&#x27;ve done at least the minimum to protect what they&#x27;ve shared, especially if you&#x27;re profiting from that data.
评论 #16660370 未加载
评论 #16659727 未加载
vorticalbox大约 7 年前
There is a good guide for developers here<p><a href="https:&#x2F;&#x2F;techblog.bozho.net&#x2F;gdpr-practical-guide-developers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;techblog.bozho.net&#x2F;gdpr-practical-guide-developers&#x2F;</a>
TXV大约 7 年前
The GDPR isn&#x27;t a set of technical specs. It purposefully sets out broad guidelines and leaves the implementation to each data-handling organization. Obviously the requirements and challenges of a hospital are much different than those of an e-commerce. Therefore, it is the organization, or more precisely its DPO, that has to define what is &quot;appropriate&quot; to their business.<p>Then, according to your interests&#x2F;knowledge&#x2F;SOW, you can act as a security consultant who gives proactive advice, or as a contractor that develops a solution from a set of specs.
Kalium大约 7 年前
GDPR is basically written as something to be hashed out in court. The question is not &quot;Are you compliant?&quot;. The question is &quot;Can you use what you&#x27;ve done to tell a convincing story that you&#x27;re compliant enough that you shouldn&#x27;t be punished after a breach? When someone at the regulator&#x27;s office might be looking to make their career over the corpse of your company?&quot;.
mongol大约 7 年前
It is amazing with the confusion that is arising with GDPR. I have to participate in a negotiation on a data processing agreement with a vendor because of GDPR. The material data they have to handle for us (the reason we buy their services) has very little personal data in it, so I thought this will not be a big deal. But it turns out that we can (not that we do, but that we can) transfer more or less anything to them in their support &#x2F; incident channel, which is implemented with email. So we spend hour after hour to discuss how to regulate the case that emails might end up on various devices in their organisation. Completely unstructured data where mentions of names or addresses might occur.
philiphodgen大约 7 年前
The magic phrase you want for Mr. Google is “legislative drafting”. In fact there is a long-existing methodology in government for writing laws and regulations. Here, for example, is the US House of Representatives’ guideline document: <a href="http:&#x2F;&#x2F;legcounsel.house.gov&#x2F;HOLC&#x2F;Drafting_Legislation&#x2F;Drafting_Guide.html" rel="nofollow">http:&#x2F;&#x2F;legcounsel.house.gov&#x2F;HOLC&#x2F;Drafting_Legislation&#x2F;Drafti...</a><p>Chesterson’s Fence.<p>Having said that, I am a tax lawyer and I view the output of the Federal government as astonishingly bad. Poorly-written laws cause millions or billions of dollars of friction to taxpayers.<p>There are many reasons for why laws are written so poorly:<p>- the people are stupid or malicious or lazy (appealing but this conclusion reveals more about its holder than its object)<p>- the task of writing the law is impossible<p>- the people writing the law are technically deficient in this style of writing<p>I’m sure you can think of others.<p>There is another factor. After you have been a lawyer for a long time, you see the folly of believing it is possible to write binary yes&#x2F;no rules to govern human behavior. Politicians believe this. An economist would call this a belief in a static economic model.<p>Thus, politicians think “we will impose this tax and collect a lot of money”. Then they are shocked because people change their behavior and avoid paying the tax. I do not mean maliciously. I mean like a toll-road. Imposing a toll for driving on a road will affect the traffic patterns and fewer people will drive on the road. Less money will be collected. Economists think that way. Politicians are not as . . . astute. (That statement reveals more about me than it reveals about politicians as a group). :-)<p>Back to why laws are so badly written. There is a second reason and it is mentioned in another comment. Lawyers and judges are comfortable with ambiguity. In tax law, we often ask for penalties to be waived for “reasonable cause”. WTF is that? Yet it (more or less) works. At the margin, some people get away with stuff that “should” be penalized. And some people are penalized “unjustly”.<p>This discovery in law is the result of centuries of evolution. It works. So if you see ambiguity, understand that it is a feature, not a bug.<p>But for tax law, quite often I think of the rules as a broken set of algebra rules written by teenage sociology majors while drunk, for bribes. Over decades. Again, this reveals more about me than the United States Code and the Treasury Department.
evervevdww221大约 7 年前
Also, is hackernews complied to GDPR? I didn&#x27;t seem to see a &quot;delete account&quot; button? As I know GDPR asks that users&#x27; data can be deleted at anytime?
评论 #16660114 未加载
评论 #16660005 未加载
A_No_Name_Mouse大约 7 年前
&gt; I think its articles difficult to understand<p>AINAL, I am a security&#x2F;privacy consultant. I have a strictly technical&#x2F;security background but didn&#x27;t find the GDPR that hard to understand at all. Actually, I was pleasantly surprised that the text itself was quite easy to read, even though really understanding the consequences requires a bit of background research. A year ago, I got CIPP-E certified in a month just by self-study.<p>&gt; I found it is very difficult to translate from the regulation text to code, to actual implementation<p>Well yeah, I&#x27;m with you on that one. I think it is not because the text is too vague, but rather because it was written in a way that allows companies to implement it in a way that fits their size and the sensitivity of data. Art. 32 is the most important one for security&#x2F;technical protection. It allows you to implement security controls the way you see fit, as long as you can demonstrate that you made an appropriate decision based on the risk of the data. I think that is the strength of it, not its weakness: A small company doesn&#x27;t need formal authorization processes if they can show that the user administrator knows all personnel personally and issued the correct authorization profiles for the roles. Telephone numbers from contacts don&#x27;t need to be protected in the same way you need to protect medical data.<p>The advantage of the wording is that the controls just need to be &quot;good enough&quot;. The disadvantage is that there is no checklist of security controls to take, and hence, you never know for sure whether good is really good enough until you had a visit from the data protection authorities. That remains a problem, but I think if you can explain your reasoning, they might disagree, but if the reasoning is solid enough they won&#x27;t fine you for it because you can demonstrate you acted in good faith. Therefore it is important to document the reasoning behind your decisions.<p>&gt; I found this regulation put too much burden on small businesses.<p>For a small company, setting up the &quot;records of processing activities&quot;, doing a basic risk assessment and setting up processing agreements can be done in a couple of days. I don&#x27;t think that&#x27;s too much a burden. For many of my clients it helped them to identify weak spots in their security, which is a win-win for both the company and their customers.
Maybestring大约 7 年前
When reading a regulation your first priority always needs to be, answering the question, &quot;Who does this apply to?&quot;<p>If the rule applies to people who do x, and you encounter a requirement that is clearly burdensome, then you should reevaluate whether or not your really want to do x.<p>ie... The new liquor regulation is 10^100 pages long, but page 1 says we dont have to read the rest if we just serve wine and beer.
billconan大约 7 年前
I have 2 concrete questions to ask on this topic:<p>1. is email address considered personal information?<p>2. is cookie, in a form of random hash code, be considered personal information?
评论 #16662705 未加载
jakeogh大约 7 年前
Same reason large tax preparation companies lobby against simplification of rules. They need you to need them.
edibleEnergy大约 7 年前
The GDPR explicitly does not set out to specify implementation details because of the reasons here: <a href="https:&#x2F;&#x2F;gdpr-info.eu&#x2F;recitals&#x2F;no-15&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gdpr-info.eu&#x2F;recitals&#x2F;no-15&#x2F;</a> (Technology neutrality)
s73v3r_大约 7 年前
Because you don&#x27;t have the training and knowledge level that they were written for. Assuming you&#x27;re a developer, imagine taking a programming language spec and giving it to a layperson. Would you expect them to perfectly understand it? I wouldn&#x27;t think so.
oliwarner大约 7 年前
I won&#x27;t beat about the bush. If you don&#x27;t understand the laws, or don&#x27;t know how to keep your stack secure, <i>YOU SHOULD NOT COLLECT PERSONAL DATA!</i><p>Ignorance isn&#x27;t an excuse.<p>It <i>is</i> a burden. It&#x27;s <i>supposed</i> to be a burden. It&#x27;s supposed to make it harder for companies to amass toxic dumps of sensitive data, that go onto get hacked. And to stop the Facebooks of the world weaponising every anecdote they can link to you.<p>It&#x27;s a good set of measures. It&#x27;s just going to be a cock to comply with some times. I get that. I&#x27;m going to have to comply with it. But I&#x27;m happy that companies I deal with will also have to deal with it, for <i>my</i> sake, as a consumer.
Xeoncross大约 7 年前
Lawyers find code hard to read as well.<p>I guess the difference is that the law doesn&#x27;t have to implement code. Code has to implement the law.
akerro大约 7 年前
There are a few summaries online, search for &quot;GDPR for developers&quot;
评论 #16659613 未加载
nannePOPI大约 7 年前
Most laws of this kind are made so that they can exclude small players from the market.<p>If something goes wrong, Facebook can easily hire an army of lawyers and &quot;prove&quot; that they &quot;processed [data] in a manner that ensures appropriate security&quot;.<p>But a small player can&#x27;t do that. This has the follow advantages for big corps and governments:<p>1. Big companies can use the laws to destroy small companies (they just need to push the enforcers of regulations in the right direction, maybe with a little gift or something wink wink) 2. People don&#x27;t even try to create a small company, because it&#x27;s too risky, so big companies don&#x27;t have to face any competition at all 3. Governments and other institutions can use the laws to stop people who spread informations or products that go against their interest. In fact the main reason for GDPR is stopping the spreading of true informations about the current political situation in Europe (what they techinically call &quot;fake news&quot;). It&#x27;s much easier to control the web if you only have Facebook, Youtube and other channel you can easily manipulate. Good luck instead controlling hundreds of thousands of small blogs, mailing lists, chat rooms, etc