7 ms·

It's not always possible to get that to work, depending on the tech. In the case of Flash one of the most annoying and difficult parts is that it requires acce

It's not always possible to get that to work, depending on the tech. In the case of Flash one of the most annoying and difficult parts is that it requires access to the rest of the world on the internet to function properly a lot of the time. It's because of that lack of security that it was so useful and made a lot of good things possible back then (and also a lot of bad things too).

ryanlol 6y ago
I have a hard time understanding why network access would be so annoying and difficult. It should be easy for an emulator to implement user-adjustable restrictions on that.
- Someone 6y ago
  User-adjustable restrictions work for only a small fraction of the population. That fraction gets smaller the more fine-grained you make them.
  - ryanlol 6y ago
    I don’t see the problem here, just have reasonable defaults. (e.g. port 80,443, perhaps deny private networks by default)
- duskwuff 6y ago
  Flash used some unusual methods of authorizing network access (like crossdomain.xml [1]) which are significantly different from standardized HTTP cross-domain policies, and which can authorize some forms of network activity which are never otherwise permitted to web content (like connecting to arbitrary ports and transmitting arbitrary data, or sending HTTP requests with forged headers). [1]: https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html https://www.adobe.com/devnet/articles/crossdomain_policy_fil...
  - londons_explore 6y ago
    Worst case, you can use a helper server... The flash content tries to do an HTTP request, the container intercepts that, sends it to a proxy somewhere on the web, which does the request and pipes the response back. Sure, someone has to run that proxy, but I'm sure flash games sites wouldn't have trouble doing so.
    - duskwuff 6y ago
      Flash sockets don't transport HTTP requests. You might be able to tunnel them through WebSockets, but that'd turn the "helper server" into what would amount to an open network proxy -- it'd be trivial to abuse. It's kind of a moot point, though; I doubt that the networking servers that these games depended on are still online. That's a whole separate preservation problem.
      - ZenPsycho 6y ago
        The worst part of that preservation problem is, that as a DRM measure, some games will "phone home" to download a swf component that implements some critical path of the game. If the server goes down, those games are dead in the water unless you can reimplement the missing pieces.
      - efreak 6y ago
        No need to make it an open server. For applications that require a limited number of resources, you can implement a whitelist--only allow connections to certain IPs or addresses. Inspect the connections if you have to. For everything else? Make the user run it locally, have your runtime try to connect to a local instance before connecting to a remote instance. Alternatively, figure out a way to ship remote dependencies alongside the swf file, and define a patch format that allows replacing network requests. All of this is more work to do, but all of it is also workable solutions.
  - krferriter 6y ago
    Why was this ever allowed to be a browser plugin
- mwfunk 6y ago
  I'm sure there's a more scientific explanation involving cognitive bias and rationality and so on, but all I know is that few phrases send more chills down more spines of experienced developers than "it should be easy, why don't you just..." It's up there with "ship it now, we'll fix it later" and "if we can't agree which way to go, let's just make it an option in the prefs" on the Mount Rushmore of famous last words in software development. I've been burned by it so many times, I literally have to catch myself when I hear those words coming out of my mouth (or anyone's mouth, but I can only be responsible for myself), which they still do sometimes, because I'm just as subject to human nature and cognitive bias as anyone.
  - TheDong 6y ago
    "why don't you just" is called out in Evan's "The hard parts of open source" [0] talk. He goes into some of the reasons it's a bad phrase and some of the problems behind it. I'd recommend the talk. [0]: https://www.youtube.com/watch?v=o_4EX4dPppA https://www.youtube.com/watch?v=o_4EX4dPppA
    - a1369209993 6y ago
      Well, "why not just..." is only bad if it's rhetorical; sometimes it's a genuine question: "why not just?"; there usually is a reason, and it's important to find out what that reason is, rather than repeat someone else's mistakes.
  - tomc1985 6y ago
    Hey now, the preferences panels of yore were glorious outposts of customization and power-user-centric software. Computing was way more fun back then. Don't lump anti-option sentiment in with those other, far more worrisome things.
    - _jal 6y ago
      That approach to preferences tends to cause combinatorial explosions in your QA department. You can do it if you're careful, but being careful is the opposite of the "then just make it a preference" approach.
- ori_b 6y ago
  And what adjustment should you do when it makes a request to, for example, ` https://mms.cnn.com/aaldXQhJ0VycCFqfnQhcGp1fkojSDwxbG5ueiJ5IWp0b0g-PUMxbG17SCF9InAxfXBxcH19cH1IMX5wfn50enlqfXBxcH19cH1IMX5wfn50enlqeHB-fmxycGpueiJ5IUg7MXUjSD05Ozk8PDxAMW5vbkgkdHlveiQ5an57ajl4fnI5anR5IXB9eWx3OW5vbjwxc31wcUhzISF7fjA-TDA9UTA9USQkJDlueXk5bnp4MD1RMW56eX5weSFgYFRPSCJ5b3BxdHlwbzEhMEBNI3B9IXRubHcwQE9IeXAkfg== https://mms.cnn.com/aaldXQhJ0VycCFqfnQhcGp1fkojSDwxbG5ueiJ5I... `?
  - ryanlol 6y ago
    Why should you need to do any adjustment? Web browsers allow such requests by default.
- sergeykish 6y ago
  Oh, it is easy - just bundle server together with application. The same way we bundle static dependencies (resource files). For that you need server snapshot, that should be easy - just require it (maybe with source) to be provided with each application that use network. But some servers aggregate data from several users. That's easy too - require it to be possible to deploy by user on some generalized network architecture.
  - sergeykish 6y ago
    So technically it is easy, but as society we select other priorities. Personal gain, time to deploy versus stable platform and culture preservation. It is not impossible - early internet was non profit only. We have same conversation again and again - The Right to Repair, Internet Archive, Open Source. Flash was part of that rhetoric too - that's why it is so polarized. Brilliant tool, so much creativity and yet closed source, poorly supported, bug ridden. It was a public stance - if Flash become standard it would be new IE once again.
j45 6y ago
Is that a function of flash, or how the creator using Flash implements with it? It's easy to make a mess in many things, and it's true Flash has it's share due to it's sheer ability to create beginners in the realm of digital experiences.
- kmeisthax 6y ago
  There are a few features of Flash that require either filesystem access or TCP/UDP sockets, which we are never going to be able to support while interoperating with native Flash Player. We can at least hypothetically emulate RTMP and some peer-to-peer functionality by wrapping it in WebSockets or WebRTC, but that only allows communication with Ruffle-aware servers and Ruffle peers (or a patched version of Lightspark). Local Shared Objects can be emulated with cookies but we cannot share LSOs with Flash Player, which stored everything in a separate Flash-specific cookie jar. Flash also had it's own cross-domain policy mechanism, which we could technically support with the extension, but for security reasons we're probably going to just use standard CORS fetches and hope any websites that need it are updated or proxied to support it. We obviously also cannot support any of Flash Player's DRM features, not for any particular technical reason, but because we (and likely Adobe) are legally restricted from shipping a pure-web decoder for that DRM. We probably could proxy to an Adobe-provided EME plugin, but that would require cooperation with Adobe and major browser vendors for a 0.01%er preservation use case. We also cannot proxy early Flash video as no browser appears to expose native/hardware H.263 or VP6 decoding, so we'll have to ship software codecs that will probably perform like hot garbage on HD video. Fortunately, I don't think there's a lot of SWFs or FLVs with HD video in those codecs anyway. Flash also allows you to enumerate device fonts, which used to be possible on the Web but isn't anymore. I don't think anyone will miss it. However, the web sandbox is so large and all-encompassing nowadays that all of the above seems like small caveats. The vast majority of Flash content that people actually want to use is either standalone movies (Newgrounds, Albino Blacksheep, other portals) or static websites (e.g. Homestar Runner, Homestuck). The big hurdles for that are AVM2, dynamic text & inputs, and Stage3D. All of those are almost-perfectly enclosed within the web sandbox. Most of the sandbox-prohibited stuff is necessitated by websites which likely either have executed a transition plan to web standards (and thus won't be using Ruffle) or are willing to put up with whatever extra wrappers or steps we require to make these old APIs work.

ryanlol 6y ago

I have a hard time understanding why network access would be so annoying and difficult. It should be easy for an emulator to implement user-adjustable restrictions on that.

Someone 6y ago
User-adjustable restrictions work for only a small fraction of the population. That fraction gets smaller the more fine-grained you make them.
- ryanlol 6y ago
  I don’t see the problem here, just have reasonable defaults. (e.g. port 80,443, perhaps deny private networks by default)
duskwuff 6y ago
Flash used some unusual methods of authorizing network access (like crossdomain.xml [1]) which are significantly different from standardized HTTP cross-domain policies, and which can authorize some forms of network activity which are never otherwise permitted to web content (like connecting to arbitrary ports and transmitting arbitrary data, or sending HTTP requests with forged headers). [1]: https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html https://www.adobe.com/devnet/articles/crossdomain_policy_fil...
- londons_explore 6y ago
  Worst case, you can use a helper server... The flash content tries to do an HTTP request, the container intercepts that, sends it to a proxy somewhere on the web, which does the request and pipes the response back. Sure, someone has to run that proxy, but I'm sure flash games sites wouldn't have trouble doing so.
  - duskwuff 6y ago
    Flash sockets don't transport HTTP requests. You might be able to tunnel them through WebSockets, but that'd turn the "helper server" into what would amount to an open network proxy -- it'd be trivial to abuse. It's kind of a moot point, though; I doubt that the networking servers that these games depended on are still online. That's a whole separate preservation problem.
    - ZenPsycho 6y ago
      The worst part of that preservation problem is, that as a DRM measure, some games will "phone home" to download a swf component that implements some critical path of the game. If the server goes down, those games are dead in the water unless you can reimplement the missing pieces.
    - efreak 6y ago
      No need to make it an open server. For applications that require a limited number of resources, you can implement a whitelist--only allow connections to certain IPs or addresses. Inspect the connections if you have to. For everything else? Make the user run it locally, have your runtime try to connect to a local instance before connecting to a remote instance. Alternatively, figure out a way to ship remote dependencies alongside the swf file, and define a patch format that allows replacing network requests. All of this is more work to do, but all of it is also workable solutions.
- krferriter 6y ago
  Why was this ever allowed to be a browser plugin
mwfunk 6y ago
I'm sure there's a more scientific explanation involving cognitive bias and rationality and so on, but all I know is that few phrases send more chills down more spines of experienced developers than "it should be easy, why don't you just..." It's up there with "ship it now, we'll fix it later" and "if we can't agree which way to go, let's just make it an option in the prefs" on the Mount Rushmore of famous last words in software development. I've been burned by it so many times, I literally have to catch myself when I hear those words coming out of my mouth (or anyone's mouth, but I can only be responsible for myself), which they still do sometimes, because I'm just as subject to human nature and cognitive bias as anyone.
- TheDong 6y ago
  "why don't you just" is called out in Evan's "The hard parts of open source" [0] talk. He goes into some of the reasons it's a bad phrase and some of the problems behind it. I'd recommend the talk. [0]: https://www.youtube.com/watch?v=o_4EX4dPppA https://www.youtube.com/watch?v=o_4EX4dPppA
  - a1369209993 6y ago
    Well, "why not just..." is only bad if it's rhetorical; sometimes it's a genuine question: "why not just?"; there usually is a reason, and it's important to find out what that reason is, rather than repeat someone else's mistakes.
- tomc1985 6y ago
  Hey now, the preferences panels of yore were glorious outposts of customization and power-user-centric software. Computing was way more fun back then. Don't lump anti-option sentiment in with those other, far more worrisome things.
  - _jal 6y ago
    That approach to preferences tends to cause combinatorial explosions in your QA department. You can do it if you're careful, but being careful is the opposite of the "then just make it a preference" approach.
ori_b 6y ago
And what adjustment should you do when it makes a request to, for example, ` https://mms.cnn.com/aaldXQhJ0VycCFqfnQhcGp1fkojSDwxbG5ueiJ5IWp0b0g-PUMxbG17SCF9InAxfXBxcH19cH1IMX5wfn50enlqfXBxcH19cH1IMX5wfn50enlqeHB-fmxycGpueiJ5IUg7MXUjSD05Ozk8PDxAMW5vbkgkdHlveiQ5an57ajl4fnI5anR5IXB9eWx3OW5vbjwxc31wcUhzISF7fjA-TDA9UTA9USQkJDlueXk5bnp4MD1RMW56eX5weSFgYFRPSCJ5b3BxdHlwbzEhMEBNI3B9IXRubHcwQE9IeXAkfg== https://mms.cnn.com/aaldXQhJ0VycCFqfnQhcGp1fkojSDwxbG5ueiJ5I... `?
- ryanlol 6y ago
  Why should you need to do any adjustment? Web browsers allow such requests by default.
sergeykish 6y ago
Oh, it is easy - just bundle server together with application. The same way we bundle static dependencies (resource files). For that you need server snapshot, that should be easy - just require it (maybe with source) to be provided with each application that use network. But some servers aggregate data from several users. That's easy too - require it to be possible to deploy by user on some generalized network architecture.
- sergeykish 6y ago
  So technically it is easy, but as society we select other priorities. Personal gain, time to deploy versus stable platform and culture preservation. It is not impossible - early internet was non profit only. We have same conversation again and again - The Right to Repair, Internet Archive, Open Source. Flash was part of that rhetoric too - that's why it is so polarized. Brilliant tool, so much creativity and yet closed source, poorly supported, bug ridden. It was a public stance - if Flash become standard it would be new IE once again.

j45 6y ago

Is that a function of flash, or how the creator using Flash implements with it? It's easy to make a mess in many things, and it's true Flash has it's share due to it's sheer ability to create beginners in the realm of digital experiences.

kmeisthax 6y ago
There are a few features of Flash that require either filesystem access or TCP/UDP sockets, which we are never going to be able to support while interoperating with native Flash Player. We can at least hypothetically emulate RTMP and some peer-to-peer functionality by wrapping it in WebSockets or WebRTC, but that only allows communication with Ruffle-aware servers and Ruffle peers (or a patched version of Lightspark). Local Shared Objects can be emulated with cookies but we cannot share LSOs with Flash Player, which stored everything in a separate Flash-specific cookie jar. Flash also had it's own cross-domain policy mechanism, which we could technically support with the extension, but for security reasons we're probably going to just use standard CORS fetches and hope any websites that need it are updated or proxied to support it. We obviously also cannot support any of Flash Player's DRM features, not for any particular technical reason, but because we (and likely Adobe) are legally restricted from shipping a pure-web decoder for that DRM. We probably could proxy to an Adobe-provided EME plugin, but that would require cooperation with Adobe and major browser vendors for a 0.01%er preservation use case. We also cannot proxy early Flash video as no browser appears to expose native/hardware H.263 or VP6 decoding, so we'll have to ship software codecs that will probably perform like hot garbage on HD video. Fortunately, I don't think there's a lot of SWFs or FLVs with HD video in those codecs anyway. Flash also allows you to enumerate device fonts, which used to be possible on the Web but isn't anymore. I don't think anyone will miss it. However, the web sandbox is so large and all-encompassing nowadays that all of the above seems like small caveats. The vast majority of Flash content that people actually want to use is either standalone movies (Newgrounds, Albino Blacksheep, other portals) or static websites (e.g. Homestar Runner, Homestuck). The big hurdles for that are AVM2, dynamic text & inputs, and Stage3D. All of those are almost-perfectly enclosed within the web sandbox. Most of the sandbox-prohibited stuff is necessitated by websites which likely either have executed a transition plan to web standards (and thus won't be using Ruffle) or are willing to put up with whatever extra wrappers or steps we require to make these old APIs work.