Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Databases The Internet Google Microsoft Mozilla Oracle Technology News Your Rights Online

Key Web App Standard Approaches Consensus 143

Posted by Soulskill
from the apple-doesn't-count dept.
suraj.sun tips a report up at CNet which begins: "Browser makers, grappling with outmoded technology and a vision to rebuild the Web as a foundation for applications, have begun converging on a seemingly basic but very important element of cloud computing. That ability is called local storage, and the new mechanism is called Indexed DB. Indexed DB, proposed by Oracle and initially called WebSimpleDB, is largely just a prototype at this stage, not something Web programmers can use yet. But already it's won endorsements from Microsoft, Mozilla, and Google, and together, Internet Explorer, Firefox, and Chrome account for more than 90 percent of the usage on the Net today. 'Indexed DB is interesting to both Firefox and Microsoft, so if we get to the point where we prototype it and want to ship it, it will have very wide availability,' said Chris Blizzard, director of evangelism for Mozilla. ... Microsoft publicly endorsed Indexed DB on its IE blog: 'Together with Mozilla, we're excited about a new design for local storage called Indexed DB. We think this is a great solution for the Web,' said program manager Adrian Bateman."
This discussion has been archived. No new comments can be posted.

Key Web App Standard Approaches Consensus

Comments Filter:
  • by levell (538346) * on Saturday March 13, 2010 @01:28PM (#31465318) Homepage

    Personally the new web technology that I'm most keen to get my hands on is the pushState/replaceState [mozilla.org] stuff that is going to be in the next release of Firefox after 3.6. It makes it much easier to deal with forward/back in AJAX web apps

    More on topic, it is good to see Microsoft looking to implement new web technologies again.... if they implement much of HTML5 and they seem to be doing that now and this new Indexed DB stuff it looks like the Golden Age of the web will continue for some time.

    • by John Hasler (414242) on Saturday March 13, 2010 @01:40PM (#31465408) Homepage

      > ...it looks like the Golden Age of the web will continue...

      Provided that your definition of a Golden Age includes many new and exciting exploits.

      • > ...it looks like the Golden Age of the web will continue...

        Provided that your definition of a Golden Age includes many new and exciting exploits.

        The web isn't just for the enjoyment of users. Developers need to get their fix of fun, too.

      • Re: (Score:3, Interesting)

        by oztiks (921504)

        Exploits is the one of the many issues. How about change control, patching and schema changes, this has got catastrophe written all over it unless the API accounts for a lot more than whats written any serious database application reliant on it would require a strong set of change log rules, shifting data when needed, schema compliance checks before allowing access.

    • Re: (Score:2, Interesting)

      it looks like the Golden Age of the web will continue for some time.

      Dude, the web didn't even exist until about 18 years ago. We're still evaluating the impact that the internet is having on culture -- what with some countries defining it as an inalienable human right and others eager to all but destroy or censor the crap out of it, the "golden age" is not what I'd call this time period. I'd call it the friggin' dark ages -- a mish-mash of global entities all competing at cross-purposes, a thriving black market, and every week more of our technology becomes connected to it,

    • by user32.ExitWindowsEx (250475) on Saturday March 13, 2010 @02:19PM (#31465708)

      I read that pushState / replaceState link and it scared me. Note the following from it:

      Suppose http://mozilla.org/foo.html [mozilla.org] executes the following JavaScript:


      var stateObj = { foo: "bar" };
      history.pushState(stateObj, "page 2", "bar.html");

      This will cause the URL bar to display http://mozilla.org/bar.html [mozilla.org], but won't cause the browser to load bar.html or even check that bar.html exists.

      Why do I have a feeling that said effect can and will primarily be used for horribly evil purposes?

      • Sounds OK to me as long as the site portion remains the same. This isn't any different from other cross-site scripting or impersonation problems. For all I care sites can do whatever they want to the URL bar as long as the site-identificating portion remains constant.

        • by sjames (1099)

          Fine for you, but what about the millions who will be reassured by the url displayed and end up handing their banking credentials over? The url display is supposed to display the current url and has been that way since the very beginning. Suddenly redefining it to display whatever the server wants is a terrible idea and a fraud waiting to happen.

          • but what about the millions who will be reassured by the url displayed and end up handing their banking credentials over?

            What part of as long as the site portion remains the same did you miss? All you'll be able to change is the path portion within your site, which you already control anyway.

            Ever since AJAX and DHTML, sites have had full control over what pages actually display, regardless of the URL they were accessed through. Websites can already manipulate the URL bar at will through javascript, it's jus

      • I don't think this would be a problem. If you already own the website, then you already can change the URL at will to anything you want.

        The only reason this would be a bigger issue is XSS attacks - but those are already have way more important concerns than just spoofing the URL.

        Personally, I would love it. It would make it much easier to merge the mobile/AJAX/static structures of the website, allow end-users to access the same bookmarks from multiple devices, and provide a much cleaner look than we alrea

        • Currently, the real issue with AJAX-webapp links is that the server never gets the hash (fragment) portion of the URL. This makes it hard to serve the correct page to a mobile device, and completely impossible if the device does not support JavaScript.

          It also makes the server-side logs less and less useful, without introducing other kludges like calling "fake" URLs (via iframes or other tags) just to populate actual activity in the logs..

          • Server logs are logs of server activity. If no server activity is generated for certain user actions, why do you need logs? There's no fundamental difference between logs of user-visible URIs and logs of backend AJAX calls; in fact, AJAX API URIs can be made just as descriptive for server log purposes.

            If you want to track user actions, then obviously you'll have to add an explicit tracking bug, which negates some of the advantages of dynamic sites without necessarily triggering server activity for each user

            • Server logs are logs of server activity.

              you completely misunderstood my post. the point is that most platforms (gmail, for example) have moved to putting everything that would have typically lived in the query string behind a hash (#) because it's accessible in javascript. this stuff doesn't get sent to the server, of course, so doesn't show in logs.

  • This DB is simply tweaking the edge, nowhere near addressing the real fundamental problem of web app.
    • Re: (Score:3, Funny)

      by jo42 (227475)

      Just a little more duct tape will fix it. No need for a clean state redesign. With enough kludging, ever increasing performance of local clients and Internet connections, we'll make it work and look just like a local app did ten years ago. Some day.

      - T. Roll

      • by John Hasler (414242) on Saturday March 13, 2010 @01:49PM (#31465474) Homepage

        > ...look just like a local app did ten years ago.

        No, no, no. It will look completely different. It'll have rounded corners. Or something. I know! It'll have animated 3D shadows! How can anyone get any work done using a program that lacks animated 3D shadows?

        • i *especially* am amazed at the Mac's throbbing shadows when your program opens several dozen windows. The first few windows only deepen the shadow, which is reasonable even if a waste of effort. But at some point, it decides that deepening the shadow would make it too big, so the shadow starts throbbing instead. I haven't tried writing a custom program to open windows at various speeds to see what happens, but I suspect it is not actually decreasing the shadow for each window, rather setting an internal

      • by sopssa (1498795) *

        If there's any good side in it, it means you don't have to install some random untrusted applications on your computer but they just work on browser with HTML and JavaScript.

        • JavaScript downloaded from a Web site _is_ "untrusted applications". Soon HTML itself will be a full-blown progamming language.

          • by LiENUS (207736)
            JavaScript runs within a sandbox, so while it's untrusted it shouldn't be able to affect anything outside of its sandbox.
            • > ...it shouldn't be able to affect anything outside of its sandbox.

              Sure. Of course it shouldn't. And if it did, why that would be wrong.

      • Re: (Score:3, Funny)

        Just a little more duct tape will fix it. No need for a clean state redesign. With enough kludging, ever increasing performance of local clients and Internet connections, we'll make it work and look just like a local app did ten years ago. Some day.

        - T. Roll

        Apu: Please do not mock the power of duct tape. These are forces beyond the understanding of mere mortals.

  • by John Hasler (414242) on Saturday March 13, 2010 @01:34PM (#31465344) Homepage

    > ...Internet Explorer, Firefox, and Chrome account for more than 90 percent
    > of the usage on the Net...

    The Web is not the Net.

    • by sopssa (1498795) *

      Do they claim so? Browser usage is definitely what most people do on the Internet, so it might be either way. Especially as people moved from communication on IRC and IM to Facebook and other sites.

      • Re: (Score:3, Interesting)

        by John Hasler (414242)

        > Do they claim so?

        The browsers they list as having 90% of the Net have 90% of the Web. As there is more to the Net than the Web they are necessarily wrong.

        > Browser usage is definitely what most people do on the Internet...

        You forget spammers and botnet operators, both large and growing markets.

      • Re: (Score:3, Interesting)

        by raddan (519638) *
        It depends on what you mean by 'do'. There may be more people 'doing HTTP' on the net, i.e., more people actively involved in that application than any other, but at least half of all traffic on the net is currently BitTorrent, so by that measure, you could say that "BitTorrent is the net". I think that kind of thinking is wrong, though, no matter the dominant application. It's abundantly clear that the net is not one application, but many, many applications, and that a real strength of the current Inter
    • by tepples (727027)
      How do you find non-Web resources on the Internet other than through search engines on the Web? For example, to find a torrent file, one uses a search engine on the Web.
  • Apple (Score:1, Troll)

    by goldaryn (834427)

    Apple declined to comment about its support for IndexedDB.

    However, if IE, Mozilla, and Chrome support Indexed DB, and it becomes a W3C standard, it's likely Apple won't have much choice, because programmers will begin to use it.

    Happily for Apple, Google has detailed its approach in a Chrome design document and has begun checking Indexed DB code into WebKit, the open-source project that underlies both Safari and Chrome. That means Apple will be able to adopt a tested version of the technology relatively quickly.

    Browser OS/webapps isn't really their market.

    Personally, I reckon they are trying to work out who to sue.

    • > Personally, I reckon they are trying to work out who to sue.

      Just be careful never to call it iNdexedDB (or bdDEXEDnI).

  • by dirkdodgers (1642627) on Saturday March 13, 2010 @01:46PM (#31465454)

    Congratulations, you've developed a framework for client-server application development. Welcome to 1990. But wait, it's different this time because it's lightweight? Only it's not. Your framework runtime (the browser) consumes many times the resources that existing client-server applications ever did, and you still can't provide the same level of functionality.

    Progress in the software industry today looks like this:
    - 2003: Microsoft releases Office 2003
    - 2008: Google releases quirky, limited-functionality clone of Office 2003 that runs in the browser
    - 2016: Google releases quirky but fully functional clone of Office 2003 that runs in the browser, only it's progress because it's Web 5.0!!!

    Thanks but no thanks.

    • by raddan (519638) * on Saturday March 13, 2010 @02:26PM (#31465764)
      I think your comment is spot-on, and I think the reason is this: programmers hate network programming. They hate concurrency. CODER WANT SIMPLE.

      When you look at much of the development of platforms, a great deal of effort has been expended to make sure that the programming model is simple. E.g., from the perspective of a typical process running in a typical modern OS, the world still looks like a simple OS: your own flat address space and simple system calls to use to write to disk, etc. Generally, you don't have to deal with interrupts, shared memory, etc. But networking is where all of this breaks down. The location of your storage is important, because while hard disks are slow, network storage is really slow. Some parts of your application run here, and some run there, and here and there may even be wildly different platforms (e.g., 'there' could be a functional language running on a cluster, while 'here' could be a mobile web browser on a cellphone), so race conditions and slow network links and processors are a real problem.

      This constant shifting around is an attempt to find the right complexity balance. I don't know if there is a 'right' balance for all scenarios, but it doesn't look like that's going to stop people from trying to find it. Just look at all the iterations of RPC out there. They all suck, too (you just can't pretend the network doesn't exist!), but that does not stop them from being useful. Just look at NFS.
      • by HiThere (15173)

        Of course we hate concurrency. That doesn't mean we don't need it.

        Concurrency makes code nearly impossible to debug. We don't *like* Erlang. But without concurrency we can only execute in one hyperthread at a time, and that's slow.

        Now if you throw in delays for IP connections, handling sockets that might or might not be there, etc. .... now you're getting to a place where most applications are better off avoiding. Yeah, there are toolkits and frameworks to make dealing with it plausible, and to ensure t

        • by dkf (304284)

          Concurrency makes code nearly impossible to debug.

          Then you're probably doing it wrong. But I'd certainly not characterize it as being particularly easy. Key issues are that you need to avoid shared state (shared state concurrency is very difficult to debug) and you need to beware of global problems like deadlocks and livelocks; not everything can be solved just by looking at individual threads.

          But if you keep the level of separation between different concerns strong, with every piece of state having a clear single owner at a time, you avoid most problems.

          We don't *like* Erlang. But without concurrency we can only execute in one hyperthread at a time, and that's slow.

          O

          • by HiThere (15173)

            Erlang is slow compared to Python. And it doesn't have much in the way of graphics support.

            If you aren't using Erlang, and you segregate out all the timing dependencies carefully, then you've just eliminated most of the benefit of concurrency. Ideally you'd like to be able to execute most loops in parallel...but it's only really worth doing for loops that do a lot of calculation. So, with any normal language, you've got to refactor those loops into something that looks completely different. Etc.

            Go looks

    • It's kinda necessary because nobody will agree on a common runtime or at least common APIs. I'm sure intel and AMD are happy though.
    • The Web is better (Score:4, Insightful)

      by Geof (153857) on Saturday March 13, 2010 @03:39PM (#31466446) Homepage

      Your framework runtime (the browser) consumes many times the resources that existing client-server applications ever did, and you still can't provide the same level of functionality.

      I think you're wrong. Functionality is not the name of the game. Communication and content are. Look, I was doing client-server development in the 1990s: Mac Programmer's Workshop (C++), Unix sockets (C), Microsoft Foundation Classes (C++). I would never go back. True, your example does illustrate your point. There are whole classes of application, like word processors, for which the Web is not (currently). But those are mostly stable, well-defined categories. The Web is not a better way to write Word, but it is a better way to create other software we want even more.

      1. The Web is social. When you develop an application, communication between users is practically a given. Back in the day, client-server software was deployed within organizations and was focused on access to data or business processes. Communication was rare and tended to be limited.

      2. The web centers on content to which developers add various functionality. You may have to work harder on your applications controls, but HTML and CSS give you tremendous power. A framework like Flash or .NET may let you put things exactly where you want them, but this takes flexibility (e.g. text sizing) away from the user. And they are still missing significant chunks of what HTML+CSS can do.

      3. The Web is simple. The learning curve for web applications is dramatically lower than for the kinds of apps you are talking about. HTML gives you hyperlinks for free. It also gives you a history with forward/back buttons, bookmarkable URLs, and a world of users who have been trained to use them. Programmers who try to develop apps without these features loose out on core benefits of the Web (hello, Flash).

      4. The Web is relatively unified and transparent. I can view source on any page, or if that doesn't work use Firebug to break down the DOM. These days the standards are complex, but there are real advantages over a mess of competing frameworks. Browser implementations are inconsistent: but that beats writing client-server software that works on some mix of Mac, Windows, and assorted Unix flavors, then trying to persuade the wider world to install client software.

      5. Javascript doesn't suck. I was surprised too when I found this out. It has some real weaknesses for sure (dynamic scoping!). It's no Python or Ruby, but it is powerful and its idiosyncrasies pale beside, say, C++ or PHP. Perhaps its biggest flaw is the pathetically poor standard library.

      If you want to write a word-processor, the weaknesses of the Web compared to traditional client-server development may be very frustrating. You could still go with client-server, which seems like the right tool for the job. But you don't. The advantages of the Web are overwhelming. It's easier to be nostalgic about the benefits of client-server than to reinvent the benefits of the web.

      • Dynamic Scoping? (Score:3, Informative)

        by weston (16146)

        It has some real weaknesses for sure (dynamic scoping!).

        Of all the things to pick on... dynamic scoping? Javascript'd be a harder language to work in without it... you'd essentially be getting rid of closures.

        • by lennier (44736)

          Excuse my ignorance, but aren't closures by definition an implementation of static scoping?

      • by FlyingGuy (989135)

        I am not "nostalgic" about the benefits of client-server apps, they are what business needs for head-down handling of data in a manner that does not require a 50,000 line mashup of javascript, html, xhtml, xml and bloody css.

        Browser implementations are worse then inconsistent, they are insane. One does it just every so slightly different then the other and your app fails in the land of the web browser.

        But not to worry, the project for the application browser has begun. It will present a clean well defined

    • by Jenming (37265)

      For the most part, but Google Office has some advantages. Multiple people editing the same document at the same time can be really powerful.

  • Isn't local storage part of HTML 5?

    • by BlueBoxSW.com (745855) on Saturday March 13, 2010 @02:14PM (#31465672) Homepage

      Yes, and I've already written apps using it. Safari supports the html5 local storage pretty well, including in the iPhone.

      I, too, am unsure how this differs from other new local db storage techniques.

      What's missing, by the way, in my opinion, to make these REALLY useful, is a simple javascript call to determin if you are currently web connected, something like isNetConnected() found in some applications. This would let you customize the option you present to the user (ie, you can only sync your data when you're web connected).

      • I, too, am unsure how this differs from other new local db storage techniques.

        Since they couldn't decide on what version of SQL dialect to use for Web SQL they're abandoning it for this new and improved idea developed by someone at Oracle. With Oracle's attitudes about licensing how could this be anything but the perfect solution?

        What's missing, by the way, in my opinion, to make these REALLY useful, is a simple javascript call to determin if you are currently web connected, something like isNetConnected() found in some applications. This would let you customize the option you present to the user (ie, you can only sync your data when you're web connected).

        For this I generally use an XMLHttpRequest for a tiny file. If I get my "200" I'm connected, if I don't I'm not.

      • Re: (Score:3, Informative)

        by icebraining (1313345)

        Why? Just make a request to your webserver. Even if you are connected to the "Internet", if you can't access your server you won't be able to sync.

        • Why? 'cause while it is possible to do in javascript, the appropriate place for it is the application/browser.

          • Re: (Score:3, Informative)

            by icebraining (1313345)

            But the browser doesn't know how your app works! What about if your domain is accessible, but the URLs that provide the webservice your app needs isn't?

            You'd have to provide an URL anyway, so the abstracted code would be something like:

            function isNetConnected(url) {
            request.open("GET", url, false);
            request.send(null);
            return (request.status == 200):
            }

            I don't find this to be "REALLY useful".

            • I'll stick to my guns, having created apps using local data for mobile use. Having the ability to detect net connection would be really useful.

              While it's possible to hack this together in javascript, getting system status information from a try/catch type block executed in an asyncronous fashion leads to false positives, false negatives, and code that's generally difficult to debug.

              It's not important that it works for you, it's important it work in the field.

              A simple synchronous javascript API that allows t

      • Re: (Score:2, Informative)

        by Anonymous Coward

        What's missing, by the way, in my opinion, to make these REALLY useful, is a simple javascript call to determine if you are currently web connected.

        You mean something like
        var online = navigator.onLine
        as defined in http://www.w3.org/TR/offline-webapps/#related [w3.org] ?

  • so they have plenty of time to plan the (seemingly) minor but maddeningly frustrating ways they'll deviate from the standard.

  • by dirkdodgers (1642627) on Saturday March 13, 2010 @02:08PM (#31465620)

    And I see that our options as developers for interacting with this stunning new invention are still limited to one: Javascript.

    With application development increasingly moving to the browser, we as developers are going to find ourselves locked into a one language platform.

    The browser platform should standardize on a VM, not on a language. Say goodbye to traditional paths of evolution of programming languages driven by competition. Want to innovate by using a functional language to bring your solution to market faster? No can do. It's JavaScriptway or the highway.

    • Javascript is a functional language.
      • Re: (Score:2, Interesting)

        by PotatoFiend (1330299)
        Whoa there. Bolting a spoiler and ground effects onto a Prius doesn't make it a Formula One car. JavaScript is fundamentally a procedural (and therefore non-declarative) language. It has first-class functions and closures in addition to some superficial support for programming in a functional style, but the function is not the main focus of the language design and using it as a serious functional language is akin to ricing.
    • Re: (Score:3, Informative)

      by Homburg (213427)

      Want to innovate by using a functional language to bring your solution to market faster? No can do.

      That's not entirely true - you could write in Haskell and compile to JavaScript [haskell.org].

    • Re: (Score:3, Interesting)

      by Nadaka (224565)

      Not entirely true. Technically xslt is a programming language and is supported by many browsers. I know of at least one person writing an XML/XSLT CMS.

    • It's too late (Score:3, Insightful)

      by weston (16146)

      Want to innovate by using a functional language to bring your solution to market faster? No can do.

      If you're familiar enough with functional language F (and JavaScript) to be justifiably snobby about JavaScript's status as a functional language and suggesting a VM as a solution, you shouldn't have much trouble writing an F-to-JavaScript compiler.

      (If you do, then you likely fail the "justifiably" part of the snobby criteria, and you're also probably not likely to get a jump on that time-to-market measure, g

    • Re: (Score:3, Insightful)

      by patniemeyer (444913) *

      Maybe we could create a VM based language designed for networked applications, with a full blown security model down to the bytecode and performance as good as a static language.... And to make people comfortable we could name it something that sounds like JavaScript... I dunno... like Java.. Java... I can't think of one :)

      Oh, and then Microsoft can adopt it just enough to completely derail it and prevent it from becoming useful in the browser market... And Sun can let the UI and media implementations la

      • by bertok (226922)

        Maybe we could create a VM based language designed for networked applications, with a full blown security model down to the bytecode and performance as good as a static language.... And to make people comfortable we could name it something that sounds like JavaScript... I dunno... like Java.. Java... I can't think of one :)

        Oh, and then Microsoft can adopt it just enough to completely derail it and prevent it from becoming useful in the browser market... And Sun can let the UI and media implementations lag permanently 5 years behind because it doesn't help them sell more server hardware... And the whole thing can just fester until Google comes along and teams of the smartest people in the world waste years of their lives building a layer of sanity over the JavaScript mess that is acceptable enough to write apps for...

        Java had almost everything right, but failed utterly on two important fronts:

        - slow initial load time of the interpreter.
        - GUI designers for layout and graphical elements

        The first problem still hasn't be solved, and it's been more than a decade. When the Java plugin starts, everything grinds to a halt. What's even worse is that I have a fast dual-core CPU and a high-end SSD, and it still takes forever for that thing to load. Meanwhile, .NET apps and Flash both start instantly.

        The second problem is only now

        • - slow initial load time of the interpreter.
          - GUI designers for layout and graphical elements

          True... although third parties would have sprung up to take care of the GUI designer issue if there had been more demand. Sun did make attempts in this area, but they couldn't overcome their earlier mistakes.

          The slow startup issue could have been addressed earlier with a resident VM strategy... but they wanted to wait for an perfect isolation API... and they wasted a decade on that and it never mattered.

          The bigger problem though was going with a native AWT from the start instead of a mostly Java implementation like the current Swing. Netscape wanted a native look and feel so they caved and put out this mess that was the original AWT that didn't work consistently across platforms and wasn't truly extensible... and that was a lot of people's first exposure to Java. Then Microsoft froze progress there in their browsers and the rest is history.

  • by ThePhilips (752041) on Saturday March 13, 2010 @02:09PM (#31465626) Homepage Journal

    ... a vision to rebuild the Web as a foundation for applications

    The day I as user would not be able to resize browser window, adjust font size or copy-paste any random text from a page, will be the death of the web as I concerned.

    Indexed DB/etc is OK - but rest of the carp they do under the guise of making web seamlessly integrating with the desktop is a huge leap back.

    Some people has to sit for a moment and recall why web applications started winning over desktop applications.

  • The few times I've tried to pitch web apps to clients as a genuine replacement for desktop apps, they've glared at me like I was threatening to kill their favorite dog.
  • I know I'm a heretic, but all this stuff is way too complicated. Let's say that I code a little Python application I can give out to people. The hard part is they need to download Python (or I could freeze the app and they could download a multi-megabyte file). In any case, once it's downloaded, it's not my deal any more. I can explain to them where there files are, how to back them up, etc. It's perfect for little open source apps.

    But with this web stuff, now, if I want to persist data, I need to do

  • We have technologies, that are perfectly fine to create everything, that is neccessary...
    • make the webbrowser an X-Server and the webserver an X-Client (no, not vice versa - read about the server/client structure of X...)
    • make the webbrowser a Pulse Audio Server and the webserver a Pulse Audio Client
    • make the webbrowser an SSH Server and the server an SSHFS client, which mounts one of your local directories (that the webbrowser shares - this could be interfaced like the "download" dialog...)

    another idea

    • by FlyingGuy (989135)

      Damn and here I am with no mod points. +10^6 insightfull!!!!! You GO boy!

      • Damn and here I am with no mod points. +10^6 insightfull!!!!! You GO boy!

        Wow, here I was thinking I've been getting a lot of mod points lately - but you've got me beat by several orders of magnitude!

  • Probably it will go through the same paranora that people had over cookies and eventually most people will give up and accept how much can be tracked about themselves and their web browsing.
  • I have an idea. Let's create a lightweight desktop app that can browse the web and stream audio/video, upload/download files, and submit text for online shopping, and posting to Slashdot. Let's call it web... err... uhmm... web browser. Yeah, that's it. Let's call it a web browser.

    If we need to do anything more, develope a "helper application". Even better; an internet-enabled app that avoids screwing around with my browser altogether. I don't know about everybody else here, but I was around in the da

No user-servicable parts inside. Refer to qualified service personnel.

Working...