4 ms·

Flash used some unusual methods of authorizing network access (like crossdomain.xml [1]) which are significantly different from standardized HTTP cross-domain p

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
- simcop2387 6y ago
  Because people wanted it and nobody thought too hard about it at the time.
- afiori 6y ago
  because the web sucked in terms of functionality then, especially as an application delivery medium. There is a parallel universe somewhere where Javascript was designed as a Turing incomplete basic interactivity template and now node runs ECMAFlash2019
wdb 6y ago
Ain't this because crosdsomain.xml came before CORS?
- duskwuff 6y ago
  Partially yes. Partially because the developers at Adobe didn't fully think through the implications of their "XML sockets".

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

simcop2387 6y ago
Because people wanted it and nobody thought too hard about it at the time.
afiori 6y ago
because the web sucked in terms of functionality then, especially as an application delivery medium. There is a parallel universe somewhere where Javascript was designed as a Turing incomplete basic interactivity template and now node runs ECMAFlash2019

wdb 6y ago

Ain't this because crosdsomain.xml came before CORS?

duskwuff 6y ago
Partially yes. Partially because the developers at Adobe didn't fully think through the implications of their "XML sockets".