Yeah, but who or what is going to be able to read the disks a decade after your death and what is going to understand the binary format of the video files in 100 years?
Look at the 1980s BBC Domesday Project, an attempt to make a modern version of the 1080s Domesday Book -- a recording for the doom's day of everything important in England. The BBC product used reasonably archival LV-ROM discs. But the archivalness of the disks was not matched by the archivalness of LV-ROM readers. I have never in my life seen an actual LV-ROM disc or reader, only the related LaserDisc for movies discs and systems. And we all know how common those are.
You are probably preaching to the choir here. I doubt this crowd was ever clamoring to create Flash web programs.
Elijah
------ kinda liked Flash as an animation media, but not for serious interfaces
There's a little-known but much worse set of preservation issues for early movies. I only know about it because I was part of a team developing a film catalog for the Imperial War Museum, which needed to record physical film information as well as the obvious stuff like title, location, date, subject, cameraman etc. The tricky studd included:
- film width.
- frame aspect ratio
- sprocket position, spacing and number of rows used
- substrate (what the base material of the film was - several used including cellulose nitrate, wich has several failure modes ranging from disintegration the spontaneous ignition
- the photosendsitive chemicals used
- monochrome or colour
- if colour, the process used
At the time we did this the big issue was the cellulose nitrate and its state.
Its also worth reading Vannevar Bush's "As We May Think"
formatting link
303881/
which was written in 1945 and describes what is effectively hypertext at a time when there were only two working electronic computer designs in the world (Colossus and ENIAC).
That's only the interactions you see, there's server side HTML injection going on that you never see anything of.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Well if we're comparing costs, mine runs on a pair of jails on my FreeBSD NAS and uses a commercial delivery provider's free sample service for outgoing relay (I could use my ISPs relay but it's less reliable). The only real cost is my domain subscription and the tiny quantity of resources it consumes.
There are free services available on the internet that don't make their money by selling your attention to advertisers. Mostly they're samplers for much larger scale commercial users, there are some other business models. I get my DNS servers, backup MX and outgoing mail relay that way.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
It is not an injection. The server can not inject anything in clients HTML unless there is something in the HTML that would pull the "injection" and this is most likely the JavaScript code. Statements like yours confused me in the beginning. AFAIK the Web is still request/response based, so something is doing the request and getting the response on your client PC. I have not studied the newer web push notifications, but I doubt it would be different. I guess it would be a piece of code inside the browser that is requesting the information from the server and displaying notification if you have opted in.
I wasn't, only taking a pot shot at the hidden costs, partly non-monetary, of "free" offers. I spend several hours every week on editing my sites, what is less than 100 eypos per year for something taking up a slice as large as that in my life?
--
/ \ Mail | -- No unannounced, large, binary attachments, please! --
Disagree. A server extension can do almost anything it wants to an HTML page before it is sent including, but not limited to, fiddling with CSS settings and adding Javascript, PHP, links and text to the page the server is about to send.
Try reading the manual for one of the web servers: Apache, Ngnx, etc. Pay attention to their possible extensions. You may be surprised at what's possible. And, while you're at it, take a look at what PHP and Javascript can do if run server-side.
Since all this can be done in the server, you need to know what the page looked like before it was selected for transmission in order to know if it has been modified by the server.
I run the Apache HTML server to serve reference material, etc on my LAN.
Yes, but you're assuming on zero evidence that a web page as sent is identical to what the HTML server read from disk.
While that's true for most personal websites, it isn't the case for pages sent by internet search engines, online shops, banks and Wikipedia (their periodic appeals for donations are certainly not part of the page as stored in the data centre). Pages sent by these sites are built or modified on demand by code running in the web server or in an application process that the web server calls to build the page.
No sir. A browser ONLY displays information contained in the page it was sent by the HTML server. If the page contains HTML tags that reference external items such as images and videos, these are read and displayed where they appear in the page. If the server has injected links to adverts these are also fetched and displayed: the browser doesn't know what such a link points to, only whether it can be displayed or not.
This is exactly the same process the browser uses to display pictures and videos that the page's author wanted to show you: all are referenced by HTML tags in the page body.
Of course this assumes you're not running an ad blocker: all these do it to recognise advertiser URLs in a page and prevent them from being accessed or displayed.
Once you're out of the "server" things still aren't safe and solid ...
There's injection into what the server *originally* sent *before* it gets to the client. Look up the furore around "BT Phorm", part of which involved BT (as an ISP) injecting profiling and other stuff into pages that had nothing to do with them.
Some of this shows up when a web developer can't understand why stuff works for some users, but not others -- and the common feature becomes an ISP tampering with the data in transit (adding or editing the HTTP on the fly).
--
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk
| It is not an injection. The server can not inject anything in clients HTML | unless there is something in the HTML that would pull the "injection" and | this is most likely the JavaScript code.
That's what ASP and PHP are for. I use PHP to customize the webpage for IE vs other browsers, for example. The page code you'd see would be the version for your browser. That's very common. These days a lot of sniffing often goes on. That's what much of the privacy problem is about.
Javascript can do some of that. For example, an iframe with script calling in google/doubleclick can check your ID against Google's spyware booty, set a cookie, retrieve cookies, and decide whether to show you an ad for golf balls, shoes, kayaks, or jewelry. But the server-side includes, if any, happen first. The javascript is client-side.
There also seem to be a lot of pages generated on the spot from backend databases. And there are operations like Wix where the page you get is little more than a JSON shopping list, requiring javascript, which then calls the Wix servers to build out the page.
So there's all of that. But there's certainly a lot of server-side includes that are neither push nor pull. They're at the GET level.
I think you're right, though, in general. It's the script in the page that's making the mess when you visit Yahoo. I use a HOSTS file, CSS customizing in Firefox userContent.css, and I generally disable script. I never see ads or moving elements. I've never blocked ads. I just don't allow the script that shows them, nor do I allow connections to the servers. (But I don't block includes. That's not possible, except insofar as spoofing things like userAgent can get you a different page.)
But you also need to be honest with yourself. It's not honest to say Yahoo's crap is of no use to the consumer. Yahoo is not making webpages for your sake. They're trying to make money. Without the ads there's no Yahoo. The real question is why are you using spyware, freebie webmail in the first place? You can't afford a few dollars a month for a domain or real email? It's your choice. But you only fool yourself if you use that spyware crap and then complain about it.
| Once you're out of the "server" things still aren't safe and solid ... | | There's injection into what the server *originally* sent *before* it gets to | the client. Look up the furore around "BT Phorm", part of which involved | BT (as an ISP) injecting profiling and other stuff into pages that had | nothing to do with them. | | Some of this shows up when a web developer can't understand why stuff | works for some users, but not others -- and the common feature becomes | an ISP tampering with the data in transit (adding or editing the HTTP | on the fly).
That's an interesting case, but probably very rare. The only thing I've ever seen is some ISPs intercepting a 404 to inject their own ad page. In general an ISP is the least of your worries.
But there can be unexpected adulteration. For example, in the US a large percentage of webpages are actually coming from Akamai, used as a load balancing service even by such big compaines as Microsoft. Several years ago Akamai decided to start double dipping by selling traffic data. It's like a moving company that decides to copy and study the contents of desks that it moves in order to profile their customers and sell that data to realtors and kitchen remodelers in the destination city. In other words, the content and customers' data are actually none of their business in any way that could be construed, yet it's apparently not illegal. And good luck blocking Akamai. They're a sleazeball built into the backbone. As far as I can tell, a sniffer can see that your browser is contacting them, but the connection is somehow direct through the target site and doesn't go through DNS. In other words, your browser loads index.html from acme.com and it comes from an Akamai server, but the browser doesn't know that and never did a DNS lookup for Akamai.
formatting link
The full article is now blocked. Essentially what it says is that Akamai carries 15-30% of Web traffic (as of 2010) and in 2008 started offering spyware services to clients, tracking browsers' activity. The article goes on to say that Akamai doesn't track if people delete their cookies, but that excuse makes no sense. They don't need a cookie. That's the whole point of their "pixel-free" method. They can track without tracking devices because they're serving all the webpages!
Indeed, and IIRC Javascript can be used the same way - I use a bit of PHP but avoid JS as, so far anyway, PHP plus HTML has let me do exactly what I've needed to do.
Sadly I need it ALL. JS is mostly to patch up issues in the way browsers work...Its just a better control over the 'user experience'. Example being a TV viewer I built, where it was necessary on clicking the channel to open up an ajax call to the sever and inject the stream into the browser, so it didn't need a page refresh, and then to manipulate the video and sound to prevent ugliness on startup and glitching and to shut the stream down gracefully if another channel was selected. These days whole sites are written in impenetrable JavaScript. By wankers who cant code.
--
Of what good are dead warriors? ? Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory ? The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.
However, I've also noticed that some excellent players for audio, video, stills and other, less usual, formats (.igc or .kml) can be, and are, written in Perl, Java or even C. Unlike many, I'm more than happy to use desktop applications to play these, whether from local files od streamed from a server.
The Logitech Media Server, written in Perl and capable of playing most audio formats through TCP/IP-connected audio devices and emitting HTML so it can use a web browser as its user interface is an excellent example of what can be done, though I prefer to write Java, if only because of its large and excellent standard class library and the huge number of FOSS
3rd party packages. Another nudge in that direction and away Javascript is my preference for strongly typed languages, but of course ymmv about this.
You still do not understand? HTML can be static or dynamic. The latter is generated on the server. It doesn't matter what extention is used to generate the code. HTML code can not inject anything by itself.
Perhaps you ask me if I have read it first, but anyway you misunderstood the point.
Still misconception of what is happening in reality.
So what?
I assume yes, because it is how it should work. You get exactly this in the browser what the server is sending to you. It is HTML with embedded CSS and JavaScript and who knows what else, but you get it from the server right?
Why should it be modified? It assumes the author of the site does not know what is provided to the customer with the site. It is not like this. The one organization or company (A) running the web sites signs a contract with another company (B) to track customers activities. B provides A with (usually) a javascript code that A embeds into the code of the web site (be it static or dynamic). At the end the customer (browser) gets the HTML from A with the embedded code from B and all win. They all win, because the customer willingly participates in this game.
The server can not inject anything without being told to. You are making up a story as if there is some external force adding something to a web page. It is the author of the web page doing this.
I am not sure you understand correctly how all this works. Just to reach some common ground, I learned HTML in 1998 as part of university studies. Later I worked a lot with servers, compiled php extentions and learned php around 1999 and 2001. Last thing I learned few years ago was the Symfony Framework. I don't pretend to be an expert in web development, but I think at least I know how it works and where it is going.
I always have a problem with those 3rd party packages - you download a jar and you never know what is inside it and then you complain about injections :D But I must admit I've used some also. I tried to check the code of some, but it is virtually impossible or at least very time consuming. This is why I choose Symfony Framework - not that it does not have the same problem with
3rd party, but at least they are not binary code packed in jar.
I never download 3rd party jarfiles - only source. This has advantages: (a) I get to read the source, (b) I KNOW which compiler it was compiled with. I'm currently on OpenJava 1.8 (c) I get to generate a set of javadocs from the source and link them to my local Java Documentation web page along with the official docs and javadocs for my own support classes.
The thing that pisses me off most with 3rd party code is how much of it is either undocumented or very poorly documented.
IMO if you're going to publish your own packages you're just waving two fingers at anybody who downloads it if you haven't documented packages, classes and methods to at least the same standard used in the standard classes and packages and, equally important, taken the time to generate javadocs from your code, read the output to check that it makes sense as well as correcting any errors, omissions and typos in the comments.
I know its easy to do all that and still write something that may not make sense to others, but the least you can do then is to treat any queries or error reports as sufficient reason to correct the code and/or comments, retest any code changes (I maintain a set of regression test scripts for my support classes - do you?) and release an updated version in a reasonably timely fashion.
As a simple example, the periodic begging stuff added to the top of a Wikipedia page IS NOT PUT THERE by the page's author. It is added by HTML extensions written and controlled by Jimbo and his acolytes whenever they think the coffers are getting empty.
This is no different to the way that ads get added by anybody who chooses to inject them from a web server that control. They are generally NOT added by the web page's author: rather the opposite: try adding your own ad stream to your pages if they're served by Google or anybody else who supports a 'free' webserver by flogging ads supplied by their clients and see how quick you'll by kicked off.
Thats exactly the same situation that Epic Games when they tried to accept a revenue stream direct from Fortnite instead of running it through Apple and Google's appstores: they just got banned from those appstores for breaking their terms of service.
We're beginning to lose ourselves into semantics here. The page's author is the one who wrote that which leaves the server and arrives at the browser: the HTML, CSS, JS etc. Whether he wrote static code or a program generating it only a question of tools. If I decide to quote a poem of Goethe's on one of my web pages, that doesn't make Goethe the page's author. If the "free" servers work as you say, I wouldn't know, then you are not the author of the page, but its true author generously allows you to add a bit of prose of yours to *his* page.
--
/ \ Mail | -- No unannounced, large, binary attachments, please! --
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.