Time to kill the web
Something is happening. People are unhappy. The ghost of civil unrest haunts our programming community.
For the first time, a significant number of web developers openly question the web platform. Here is a feature article and discussion . Here is another article . And one more . I could enumerate more, but if you are interested enough in programming to read this article, you probably have read at least one pompous declaration about the current state of web development this year. This article is not one of those. I can't compete in bullying the existing status quo with people who have to do web development every day. This is another article.
It's you, hacker front end
I want to reflect on whether it is possible to create such a good competitor to the web that it will eventually replace it and include it, at least for writing applications. The web has more problems like a document distribution system, but not so serious as to worry about them.
')
This is the first of two articles. In the first part, we will look at the deep, insoluble problems of the web platform: I want to convince you that abandoning it is the only option. In the end, it is impossible to solve a problem if you do not first analyze it. We will also briefly consider why it has now become politically acceptable to discuss such issues, although they are not something new.
In the second part, I will offer a new application platform that a small group of developers can create in a reasonable time, and which (IMHO) should be much better than what we have now. Of course, not everyone will agree with the latter. Agreeing to problems is always easier than agreeing to solutions.
Part 1. Let's go.
Web applications. What are they like, eh? I can list a bunch of their problems, but let's look at two.
Here's a nice post on Flux , the latest trendy web framework from Facebook. The author notes that Flux recreates the programming model used by Windows 1.0, released in 1985. Microsoft used this model because it was suitable for slow computers, but it was so inconvenient to program under it, so less than a decade had passed how a whole ecosystem of products (like OWL) grew, allowing to abstract from the underlying message system WndProc.
One of the reasons why React / Flux works this way is very slow web rendering engines. This is true, and the final user-visible result is only slightly more sophisticated than a Windows user could see 20 years ago:
Windows 98
Of course, the screen resolution has become more. The shades of gray that we like have changed. But the UI that you see at the top is quite similar in complexity to the UI that you see below:
Even the fashion for icons has not changed! Windows 98 introduced a new trend of flat icons in grayscale, while the previous ones were color, densely packed pixel images.
But Office 2000 was quite content with a 75 MHz CPU and 32 MB of memory, while Google Docs from the screenshot uses a 2.5 GHz CPU and almost ten times more memory.
If we received a tenfold increase in performance and functionality, it would be excusable, but we did not receive it. Development platforms in 1995, by default, had all of the following, just for starters:
Many of these features have appeared on the web platform only in the last few years, and often quite superficially. Web applications cannot use real sockets, so instead servers have to be translated to support “web sockets”. Basic things like UI components are silent horror . There is no serious Web IDE, but about mixing different programming languages ​​... well, you can try to compile everything in JavaScript. Sometimes.
Developers love to write web applications for one reason - user expectations for such applications are extremely low. You expect icons for Windows 95 applications, mouse dragging, undoing actions, associations with file extensions, normal hot key combinations, useful background activities ... and even offline work! But these are the simplest applications. Truly cool software could be embedded in Office documents or extend the functionality of Explorer, or allow extension of functionality with arbitrary plug-ins that are not originally known to the author of the program. Web applications usually do nothing of the kind.
All this accumulates. I feel much more productive when I write a desktop program (even taking into account the various "taxes" that you have to pay, like making icons for your file types). I also prefer to use them. And from conversations with others I know that I am not the only one.
I think that the web has become so, because HTML came out with quite intelligible design philosophy and tools as a platform for documents, but as a platform for applications, HTML had to be attached to snot, and nothing good has yet happened. Therefore, there are no very basic things like file associations. But in HTML5 there is a peering video streaming, because Google wanted to make a hangout, but Google’s priorities are important in what features to add to the standard. To avoid such a problem, we need a platform that was originally designed with the idea of ​​applications, and then, maybe, add documents from above, and not vice versa.
In the late 1990s, the terrible implementation of PL hung over the software industry: security vulnerabilities in C / C ++ programs ceased to be rare errors that can be fixed separately. They appeared everywhere. People began to realize that if you put C / C ++ code on the Internet, exploits will inevitably appear.
You can appreciate the innocence of that world, if you read the SANS report on the Code Red worm from 2001:
There were automatic updates on Windows, but if I remember correctly, they are disabled by default. The idea that a program could change without the user's knowledge was a taboo.
The first signs of Blaster infection
Gradually, the industry began to change, but with shouts and protests. At that time, Linux and Mac users often said that this was a purely Microsoft problem ... and their systems were created by some super programmers. So while Microsoft accepted the fact that it faced an existential crisis and introduced a “ life cycle of safe development ” (a giant retraining program and a new process), its competitors were practically inactive. Redmond added a firewall in Windows XP and issued certificates for code signing. Mobile code banned. When it became clear that security vulnerabilities run in an endless stream, they introduced the periodic patch release “Patch Tuesday”. Smart hackers continued to make discoveries, how to exploit previously known bugs that seemed to be safe, and how to bypass the protection against exploits that had previously seemed reliable. The Mac and Linux communities began to gradually get out of hibernation and become aware of the fact that they are not magically protected from viruses and exploits.
The last turning point was 2008, when Google released Chrome, an important project from the point of view that they spent a lot of effort on creating a complex, but completely invisible sandbox for the rendering engine. In other words, industry-leading developers have recognized that they are not able to write secure C ++ code no matter how hard they work on it . Such a thesis and isolated architecture became de facto standards.
Unfortunately, the web did not lead us to the blessed land of secure applications. Although web applications are in some way isolated from the parent OS, which is good, the applications themselves are hardly more reliable than the 2001 Windows code. Instead of permanently getting rid of inherited problems, the web simply replaced one type of buffer overflow with another. Desktop applications exploited vulnerabilities such as double freeing of the same memory (double free), stack integrity vulnerabilities (stack smash), memory use after freeing (use after free), and others. Web applications corrected them, but they presented their own similar errors: SQL injections, XSS, XSRF injections, header injections, mixing MIME types, and so on.
All this leads to a simple thesis:
Unable to write secure web application.
We will not be pedants. I do not speak literally about all web applications. Yes, you can write secure HTML Hello World, flag in hand.
I’m talking about real, decent-sized web applications written in realistic conditions, and this statement was not easy. Understanding came to me after eight years of working at Google. There, I watched the best and most talented web developers give out code with exploited bugs over and over again.
Google’s security department is one of the best in the world, maybe the best, and for the internal curriculum they released this useful guide listing the most popular web development mistakes . Here is their advice on how to safely send data for display in a browser:
. , , - Google, - .
, . HEIST -, . -. .
! ! REST/JSON — , -. ( ).
, -, , , . : -, , -, - .
:
— C, : XSS SQL , . , , . (escaping), , .
: : . - , . , , UI .
HTTP HTML . Authy, “../sms” SMS. , - Authy , . , HTML, . API «», .
REST , XML, XML JSON — , , .
: , REST — . REST — , HTTP , , . , , . . , - , RPC.
- — . :
SOP (same origin policy) , Netscape . . , 10 . , Netscape , , , . 10- .
, HEIST SOP, HEIST - , , , , , . , -.
: , . , . , .
, -, , , , .
HTML5 — . , -, . : , , , . . , , .
. , . Flash, Shockwave Java. , . — , : , , , , . . «-» . , Macromedia Flash — .
. , : HTML5, , . W3C , Google Microsoft, - . . JavaScript .
. : ?
For the first time, a significant number of web developers openly question the web platform. Here is a feature article and discussion . Here is another article . And one more . I could enumerate more, but if you are interested enough in programming to read this article, you probably have read at least one pompous declaration about the current state of web development this year. This article is not one of those. I can't compete in bullying the existing status quo with people who have to do web development every day. This is another article.
It's you, hacker front end
I want to reflect on whether it is possible to create such a good competitor to the web that it will eventually replace it and include it, at least for writing applications. The web has more problems like a document distribution system, but not so serious as to worry about them.
')
This is the first of two articles. In the first part, we will look at the deep, insoluble problems of the web platform: I want to convince you that abandoning it is the only option. In the end, it is impossible to solve a problem if you do not first analyze it. We will also briefly consider why it has now become politically acceptable to discuss such issues, although they are not something new.
In the second part, I will offer a new application platform that a small group of developers can create in a reasonable time, and which (IMHO) should be much better than what we have now. Of course, not everyone will agree with the latter. Agreeing to problems is always easier than agreeing to solutions.
Part 1. Let's go.
Why the web must die
Web applications. What are they like, eh? I can list a bunch of their problems, but let's look at two.
- Web development is slowly repeating the 1990s.
- Web applications cannot be protected.
Here's a nice post on Flux , the latest trendy web framework from Facebook. The author notes that Flux recreates the programming model used by Windows 1.0, released in 1985. Microsoft used this model because it was suitable for slow computers, but it was so inconvenient to program under it, so less than a decade had passed how a whole ecosystem of products (like OWL) grew, allowing to abstract from the underlying message system WndProc.
One of the reasons why React / Flux works this way is very slow web rendering engines. This is true, and the final user-visible result is only slightly more sophisticated than a Windows user could see 20 years ago:
Windows 98
Of course, the screen resolution has become more. The shades of gray that we like have changed. But the UI that you see at the top is quite similar in complexity to the UI that you see below:
Even the fashion for icons has not changed! Windows 98 introduced a new trend of flat icons in grayscale, while the previous ones were color, densely packed pixel images.
But Office 2000 was quite content with a 75 MHz CPU and 32 MB of memory, while Google Docs from the screenshot uses a 2.5 GHz CPU and almost ten times more memory.
If we received a tenfold increase in performance and functionality, it would be excusable, but we did not receive it. Development platforms in 1995, by default, had all of the following, just for starters:
- Visual UI editor with layout constraints and data binding.
- Advanced support for software components in many languages . You could mix statically typed native code and scripting languages.
- The executable files produced were so efficient that they worked on several megabytes of RAM.
- Support for graphing, thematization, 3D-graphics, socket programming, interactive debugging ...
Many of these features have appeared on the web platform only in the last few years, and often quite superficially. Web applications cannot use real sockets, so instead servers have to be translated to support “web sockets”. Basic things like UI components are silent horror . There is no serious Web IDE, but about mixing different programming languages ​​... well, you can try to compile everything in JavaScript. Sometimes.
Developers love to write web applications for one reason - user expectations for such applications are extremely low. You expect icons for Windows 95 applications, mouse dragging, undoing actions, associations with file extensions, normal hot key combinations, useful background activities ... and even offline work! But these are the simplest applications. Truly cool software could be embedded in Office documents or extend the functionality of Explorer, or allow extension of functionality with arbitrary plug-ins that are not originally known to the author of the program. Web applications usually do nothing of the kind.
All this accumulates. I feel much more productive when I write a desktop program (even taking into account the various "taxes" that you have to pay, like making icons for your file types). I also prefer to use them. And from conversations with others I know that I am not the only one.
I think that the web has become so, because HTML came out with quite intelligible design philosophy and tools as a platform for documents, but as a platform for applications, HTML had to be attached to snot, and nothing good has yet happened. Therefore, there are no very basic things like file associations. But in HTML5 there is a peering video streaming, because Google wanted to make a hangout, but Google’s priorities are important in what features to add to the standard. To avoid such a problem, we need a platform that was originally designed with the idea of ​​applications, and then, maybe, add documents from above, and not vice versa.
Web applications cannot be protected
In the late 1990s, the terrible implementation of PL hung over the software industry: security vulnerabilities in C / C ++ programs ceased to be rare errors that can be fixed separately. They appeared everywhere. People began to realize that if you put C / C ++ code on the Internet, exploits will inevitably appear.
You can appreciate the innocence of that world, if you read the SANS report on the Code Red worm from 2001:
“Representatives of Microsoft and the US security agencies held a press conference where they instructed users to download the patch from the Microsoft website and called the download of this patch“ civic duty ”. CNN and other news publications after the spread of Code Red warned users about the need to install patches on their systems. ”
There were automatic updates on Windows, but if I remember correctly, they are disabled by default. The idea that a program could change without the user's knowledge was a taboo.
The first signs of Blaster infection
Gradually, the industry began to change, but with shouts and protests. At that time, Linux and Mac users often said that this was a purely Microsoft problem ... and their systems were created by some super programmers. So while Microsoft accepted the fact that it faced an existential crisis and introduced a “ life cycle of safe development ” (a giant retraining program and a new process), its competitors were practically inactive. Redmond added a firewall in Windows XP and issued certificates for code signing. Mobile code banned. When it became clear that security vulnerabilities run in an endless stream, they introduced the periodic patch release “Patch Tuesday”. Smart hackers continued to make discoveries, how to exploit previously known bugs that seemed to be safe, and how to bypass the protection against exploits that had previously seemed reliable. The Mac and Linux communities began to gradually get out of hibernation and become aware of the fact that they are not magically protected from viruses and exploits.
The last turning point was 2008, when Google released Chrome, an important project from the point of view that they spent a lot of effort on creating a complex, but completely invisible sandbox for the rendering engine. In other words, industry-leading developers have recognized that they are not able to write secure C ++ code no matter how hard they work on it . Such a thesis and isolated architecture became de facto standards.
The turn of the web platform has come
Unfortunately, the web did not lead us to the blessed land of secure applications. Although web applications are in some way isolated from the parent OS, which is good, the applications themselves are hardly more reliable than the 2001 Windows code. Instead of permanently getting rid of inherited problems, the web simply replaced one type of buffer overflow with another. Desktop applications exploited vulnerabilities such as double freeing of the same memory (double free), stack integrity vulnerabilities (stack smash), memory use after freeing (use after free), and others. Web applications corrected them, but they presented their own similar errors: SQL injections, XSS, XSRF injections, header injections, mixing MIME types, and so on.
All this leads to a simple thesis:
Unable to write secure web application.
We will not be pedants. I do not speak literally about all web applications. Yes, you can write secure HTML Hello World, flag in hand.
I’m talking about real, decent-sized web applications written in realistic conditions, and this statement was not easy. Understanding came to me after eight years of working at Google. There, I watched the best and most talented web developers give out code with exploited bugs over and over again.
Google’s security department is one of the best in the world, maybe the best, and for the internal curriculum they released this useful guide listing the most popular web development mistakes . Here is their advice on how to safely send data for display in a browser:
. , (« »), , - , . -, XSRF, , , JSON . -, JSONPOST, <script>. -, , . — - ,])}while(1);</x>. , .
: . , , . , , ,/**/, . (: , -*/?)
. , , - Google, - .
, . HEIST -, . -. .
! ! REST/JSON — , -. ( ).
, -, , , . : -, , -, - .
:
- ,
- , ,
- (same origin policy)
— C, : XSS SQL , . , , . (escaping), , .
: : . - , . , , UI .
HTTP HTML . Authy, “../sms” SMS. , - Authy , . , HTML, . API «», .
REST , XML, XML JSON — , , .
: , REST — . REST — , HTTP , , . , , . . , - , RPC.
- — . :
… .
, - , JavaScript, .
, , DNS rebinding , .
SOP (same origin policy) , Netscape . . , 10 . , Netscape , , , . 10- .
, HEIST SOP, HEIST - , , , , , . , -.
: , . , . , .
, -, , , , .
HTML5 — . , -, . : , , , . . , , .
. , . Flash, Shockwave Java. , . — , : , , , , . . «-» . , Macromedia Flash — .
. , : HTML5, , . W3C , Google Microsoft, - . . JavaScript .
. : ?
Source: https://habr.com/ru/post/338880/
All Articles