Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:FUD (Score 1) 163

As for "buckets to put tracking information into" why bother relying on "buckets" on the client which may or may not exist, are limited in size, may change or be emptied at any time, etc, when you can buy as many "buckets" as you want server-side and store virtually unlimited data about them?

Mainly, caching and offline access. When I access Gmail from my Android phone, I can read my e-mail offline, and browsing my inbox is instantly responsive even if my connection is very slow. This is because it just caches my whole inbox, any other tags I tell it to, and all mail from the last few days. If the Gmail website did that, which it can using localStorage, I wouldn't have to wait ten seconds sometimes to flip to the next e-mail while it retrieves it from the server.

It's also just easier to use, if you're writing an application in JavaScript, because you don't have to bother with any server-side logic. You could even store data on a page that's totally static. Of course, that's not useful for anything important, but if you're storing transient preferences (e.g., "this menu should be collapsed") that only JavaScript will care about, there's no sense in storing them in cookies – they'll have to be sent on every HTTP request then.

Comment Re:Don't cookies do the same thing? (Score 1) 163

Folks, I thought this isn't new at all. Don't cookies do the same thing? I have a cookie that will 'never' expire unless I delete it. What am I missing?

That, in combination with html5 local databases, you can create cookies that cannot be deleted. Ever.

This is completely false. The Web Storage spec says:

If users attempt to protect their privacy by clearing cookies without also clearing data stored in the local storage area, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in all persistent storage features simultaneously.

In practice, this is what browsers do. Every time you clear cookies, you clear all persistent storage that the browser controls – leaving only things like Flash storage, and of course things that are stored on the server rather than the client. If you're referring to Evercookie, that has nothing to do with HTML5.

Comment Re:Don't cookies do the same thing? (Score 2, Interesting) 163

Genuine question - if people honestly don't care, then is it really a problem?

The problem is that users are given a tradeoff: either they enable cookies and let people track them, or disable cookies and break all the sites they use. Offered that decision, most people will rationally opt for the latter. The goal is to give them a third option: let sites work properly without privacy or security problems.

Web standards try to give apps as much power as possible without hurting privacy or security more than before, so you don't have to trade off here-and-now features to fend off abstract threats. Other application frameworks, like conventional binaries, don't even try: if you run the program, you have to trust it completely.

An example of one technology that tries this and gets it wrong is Android. You can decide what privileges to give an app before you install it, but popular apps often ask for lots of unreasonable privileges, so in practice most people ignore the risks and just install the things. On the web, applications can do the large majority of useful things Android apps can do (if you count cutting-edge standards that aren't widely supported yet), but few of the harmful things. This puts users in a much better position: they don't lose many features, but they're at much lower risk.

So, yes, it is a problem, and it is fixable, and the web is the only way forward toward fixing it. Others have tried, like Bitfrost, but only the web has enough momentum to build a real application base around the idea of totally untrusted applications that are still really useful.

Comment Re:Browsers... (Score 1) 163

Is the change that there is more space for cookies? up till now its been like a few 100 kbs right?

Roughly speaking, yes. Cookies are sent on every HTTP request, so they can't be longer than a few kilobytes in practice (100 KB is unlikely to work). localStorage and friends are typically more in the ballpark of a few megabytes per site, and since it's only accessible to local JavaScript rather than being sent over the network, it can really be unlimited. It's only kept to a few megs by default so that you don't get zillions of sites each storing a bunch of data and eating up your disk space. So without the new client-side storage mechanisms, you have to store the data on the server and ferry it back and forth if it's too big to fit in cookies.

Comment Re:Browsers... (Score 1) 163

It's a very similar problem to the privacy concerns over Flash about 6 or 7 years ago. When people realized you could store a lot of information separate from standard browser cache, people started taking advantage of the situation until it was patched. Similar things with HTML5, breeches will be discovered, then much later get patched after the damage is done.

It's not similar at all. The problem with Flash is that users who clicked "Clear my cookies", or even used their browser's privacy mode, would still not clear Flash's data – because Flash is a totally separate program. The HTML5 browsers are part of the browser and integrated into it, so clearing localStorage/sessionStorage/WebDB/etc. is no additional effort when you clear your cookies.

Try it yourself and see. On Chrome, for instance, it's wrench -> Preferences -> Under the Hood -> Clear Browsing Data.... The option to clear HTML5 storage is exactly the same as for cookies: "Delete cookies and other site data". Firefox also doesn't seem to even give a separate option, it's all seamlessly integrated.

Comment Re:How, Specifically? (Score 1) 163

What features does HTML5 include that let one server access any data other than that created by that server, or by the client user through the HTML GUI sent by that server?

None. The new storage mechanisms use the same access control as cookies, and browsers clear them as well whenever you clear cookies. Evercookie has nothing to do with HTML5. TFA is uninformed FUD.

Comment Re:The final version is not due for several years (Score 1) 205

Alright, it seems I spoke way too fast. I did some research on HTML (checked wikipedia) and it seems that updating HTML twice a year would be reckless. However, HTML4 was published as a W3C recommendation in 1997. Just to put that in perspective Windows98 and Napster were yet to happen. This is what AOL.com looked like at the time. I respect what we've been able to achieve on this platform, but I can't help but feel it is holding us back as well.

The reason for this is because the W3C got derailed by XHTML. Work was focused for years on impractical specs that browsers didn't want to implement, like XHTML 2 and XForms. HTML5 only started in about 2004, so that's about seven years of zero new standardized HTML features. If you look at it that way, we've seen pretty decent progress in the last few years. Most of the delay is is the implementation, not the actual standards-writing. The HTML5 editor is avoiding large additions while he waits for implementations of what's already specced – you don't have implementers twiddling their thumbs because they have no standards to implement.

Comment Re:This isn't the W3C. (Score 1) 205

...just a guy who happens to be part of the W3C stating his personal opinion. There is no official press release or publication on the W3C site itself--and, for that matter, not even any on this guy's personal web page or Twitter feed (when did he even say this?).

A guy who "happens" to be leader of the entire Interaction Domain, including HTML (and CSS, SVG, etc.). So, yes, it's not an official W3C statement, but Philippe Le Hégaret is not just "a guy who happens to be part of the W3C".

Comment Re:The W3C needs a big reality check. (Score 1) 205

I would bet on it. Look what Microsoft did with OOXML to damage ISO

The W3C is vastly smaller and less bureaucratic than ISO, and also more open. The HTML Working Group conducts its business exclusively on Bugzilla and the public-html mailing list, so if Microsoft were trying anything, everyone would see it. Nothing is done by vote in the HTMLWG, so Microsoft can't try to buy votes secretly. All decisions are made by either the editor (employed by Google) or the co-chairs (one employed by Microsoft, one Apple, one IBM). And everything is being overseen by the W3C administration; you can literally appeal directly to Tim Berners-Lee if you have a problem with the chairs' decision, and people have done that.

Nothing underhanded is going on here. Microsoft can mainly be faulted for not participating much, not for trying to subvert anything.

Comment Re:The W3C needs a big reality check. (Score 1) 205

What do you suppose are the chances that Microsoft itself is slowing down the W3C's progress, for exactly the reason you state?

Zero. Follow the proceedings of the HTML Working Group and see for yourself. You can criticize Microsoft's involvement on various grounds, but nothing they've done has the effect of slowing down progress much. The Working Group is proceeding on a timetable toward Last Call set by the three co-chairs, only one of whom is employed by Microsoft (the other two are Apple and IBM). Microsoft has no more say in the W3C than any other member, and all four of its competitors in the browser market participate more actively in the HTMLWG (and WHATWG) than it does. They wouldn't let it get away with anything even if it tried, which it hasn't.

Standards work always appears slow. With vendor-specific stuff, they don't design it until right before they intend to implement it, and you don't hear about it until the implementation is done. So it sounds like it appears out of thin air. With standards, the design is usually done long before all browsers have the resources allocated to implement it, so it looks like it's taking much longer: you can see the design from day one, and there's a big gap between design and full implementation. Malice has nothing to do with it.

Comment Re:Why not divide it? (Score 1) 205

If they can't write specs in less than several years, why not divide html 5 into its core components and concentrate the work on one piece at a time?

Because the spec is written. Go read it yourself. The editor cut back on adding new features a few years ago when it was clear that his feature-writing was outstripping implementers' ability to implement the features. He routinely replies to requests for significant new features by saying he's waiting for browsers to implement what's in the spec now before he adds more. The editing right now is almost all just that, editing – hammering out minor flaws that people discover and report. (There are some exceptions, like WebSRT.)

Comment Re:More evidence of the W3C's increasing irrelevan (Score 1) 205

In a work placement year I did the major electronics company had a couple of staff on the board for a standard -- it involved lots of XML and internet stuff, so it's not far from the kind of thing W3C does.

What took so long was working out whether technology that required infringing on each company's software patents should be "required" or "optional". In the end, Sony, Philips, Panasonic etc decided to pool their patents (their stuff is "required"), the patent troll companies were excluded by the big company's votes (so the neat technology they'd patented was "optional" or left out entirely) and the couple of small businesses or individuals who'd already got products running using the draft spec were ignored.

The W3C has a Patent Policy requiring that all its specifications be implementable royalty-free, so this is not an issue. No spec can be covered by any known patents at all unless those are irrevocably licensed royalty-free. I've heard this kind of bickering can suck up time at less enlightened standards organizations, though, which believe in unreasonable stuff like RAND (= let everyone on the standards committee rake in money by making sure some patent of theirs is required).

Comment Re:Flies in the Face of Common Sense Too (Score 1) 205

Your job is to write code, not to design a Sculpture to be admired throughout the ages. Designs are fluid, so is the code that implements them.

That's all very well, but when browsers change widely-used APIs, they break sites. Then users complain loudly and refuse to upgrade, because the old version works better than the new one for them if they use those sites. So all the browser implementers except Microsoft refuse to change behavior in ways that will break sites more than absolutely necessary, and Microsoft only pulls off such behavior changes because of its compatibility modes. Which means that once the APIs are widely used, they don't change, period. Browsers will not break content.

Comment Re:W3C is the problem (Score 1) 205

The spec hasn't changed all that much since then (although it has changed)

It seems that recently there has been a change on the set of methods that are supported by an HTML5 form, where PUT and DELETE are no longer supported.

Big Mistake.

There have been tons of minor changes like that, sure. HTML5 initially mandated PUT and DELETE be supported on HTML5 forms, which HTML4 didn't allow, but implementers are not likely to spend time on it without clear advantages that accrue to the average user or web author. You can still do PUT and DELETE from HTML via XMLHttpRequest, in clients that support script (the overwhelming majority), so it's not like it's a huge loss.

Slashdot Top Deals

"Don't drop acid, take it pass-fail!" -- Bryan Michael Wendt

Working...