Slashdot Mirror

What has HTTP/HTTPS to do with HTML?

The Secure Contexts spec, currently a W3C Candidate Recommendation, deprecates use of some web platform features over cleartext HTTP. Attempting to use certain methods in a document served over cleartext HTTP will instead produce a SecurityException.

using https over tor is just stupid.

I can see two main reason why a site operator might try using HTTPS to connect to a web server over an otherwise secure channel, such as a hidden service on Tor or I2P.*

One reason is that not all parts of all browsers are aware that hidden services are secure channels. The W3C has published a spec titled Secure Contexts, which recommends that web browsers block use of sensitive JavaScript APIs by non-secure sites. Even script-free sites cause the browser to show a warning about an insecure context if a document contains a form, such as a login form or an editing form. Until user agents start treating hidden services (*.i2p and *.onion) as potentially trustworthy origins, sites using these APIs must use HTTPS to build a secure context.

Another reason relates to typosquatting. If a user mistypes a hidden service's hostname, such as facebookcorewwwi.onion, the user might end up connecting to a server controlled by an entity other than Facebook. To fight this, some certificate authorities have begun to offer Extended Validation certificates that apply to hidden services, assuring the user of the real-world identity of a hidden service's operator.

* The I2P community refers to hidden services as "eepsites".

As I recall, there was a clear standard: https://www.w3.org/TR/1999/REC... and Microsoft choose to ignore it.

No, it's not standard. addEventListener is described here: https://www.w3.org/TR/domcore/...

As you can see, there's no "passive" property to be found. It was instead described in a Mozilla- and Google-owned fork that's still not standardized by the larger body of W3C members.

They've been doing this a lot recently. Specifically, Anne van Kesteren is cancer.

You can use html character entities - Ü gives Ü

> But the only language I learned to actually hate is Javascript. Talk about a steaming pile of shit.

That's because Brendan was a fucking idiot. JavaShit was designed and implemented in 10 days -- which would be impressive if he actually put some _thought_ in it. In contradistinction it was like almost every shitty thing about Basic was embraced and NOTHING about writing type safe programs from the past 40 years was used.

* Accidentally misspell a variable? That's nice -- we will just magically use it! Undefined FTW.
* Want misspelt variables to be flagged at run-time? Use the hack magic string

"use strict";

* Want to turn it off? Nope, sorry, no can do.
* Want to include files? Bwuahaha. What do you think this is? A programming language?
* Arrays and Strings are half-assed. What would you _think_ the result of

"" + [1,2] + [3,4];

should be? There are 3 possibilities:

1. [4,6] = Vector or Matrix addition
2. [1,2,3,4] = Array concatenation, aka [1,2].concat( [3,4] );
3. undefined = Exception thrown for mixing types

So what does JavaShit do? It uses an idiotic 4th choice!

4. "1,23,4" = String Concatenation WTF!?

More examples of how fucked up JavaShit is

Both JavaShit (JS) and PHucked Up (PHP) languages were designed by morons. At least other languages have _some_ sanity.

At least ES5 doesn't suck (as much).

https://www.w3.org/2005/10/Pro...

See 3.3 Concensus. I imagine a Formal Objection was part of the process. https://www.eff.org/pages/drm/... would seem to be that objection. Also at https://dev.w3.org/html5/statu...

https://www.w3.org/2005/10/Pro...

See 3.3 Concensus. I imagine a Formal Objection was part of the process. https://www.eff.org/pages/drm/... would seem to be that objection. Also at https://dev.w3.org/html5/statu...

this is not the same as when the corporate 'leaders' left trump's stupid panel thing, forcing it to dissolve itself. w3c isn't going anywhere.

On the contrary. The w3c is making itself irrelevant by forcing issues. Their own charter states:

Consensus is a core value of W3C

Well, guess what. They just threw their own core value away.

The web isn't suddenly locked down and all browsers must be closed source now. If you don't want to use DRM, then don't go to DRM enabled services like Netflix. You are not entitled to anything Netflix, Hulu, etc has to offer.

That's not even half the problem. The W3C's own mission statement states that:

The social value of the Web is that it enables human communication, commerce, and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.

I run Linux on PowerPC and can see everything that complies to standards on the net just fine. Who is going to port their DRM to Linux let alone PowerPC?! I can't watch Flash stuff but it's also not an open standard. However, with the EME I cannot watch several platforms despite complying with every standard.

I have zero problem with those companies withholding their services from me but I object to mere suggestion that they should be able to claim that they are complying with open standards. There is no standard interface or format for CDMs which is a problem because the EME is specifically designed for them.

Why is it just up to Tim Berners-Lee to decide yes or no on this?

Who would you have decide this? A standards organization, and a standards committee, headed by a person who has the responsbility to announce the decision? With an appeals process?

Ok. The W3C. The Advisory Committee on Encrypted Media Extensions. Tim Berners-Lee, the person who pretty much set up the the involved standards. With an appeals process and W3C member vote.

Not that you care about any of that. Any process that doesn't produce the outcome that you want is the product of death and appointment to Godhood, it appears.

I read the W3C spec page for CSS3 media queries. But I couldn't find a media feature for "an input device more precise than a finger-operated touch screen is in use" or "the device has a physical keyboard" or "the connection is metered". Can any web dev point me in the right direction for these features?

Patents support innovation

Why doesn't the Internet Protocol require royalties? Why doesn't TCP require royalties? Why doesn't HTTP require royalties? Why doesn't HTML require royalties? Why doesn't PNG require royalties? Why doesn't baseline JPEG require royalties? Why does the W3C Patent Policy require that all web standards be royalty-free?

How much innovation do you believe would have happened on the web if you had to pay rent on every layer of the stack?

What's special about video that it can't conform to the established norms of web standards? There's nothing special about it. VP9 achieves it and AV1 will achieve it. HEVC does not.

Firefox losing market-share, Thunderbird increasingly abandoned, but, at least, Mozilla — after squeezing out that no-good hater — is socially just.

Replacing the inventor of JavaScript with someone from marketing made the world a better place. Rejoice!

U2F... 2.0 is also know as "Web Authentication: An API for accessing Public Key Credentials" https://www.w3.org/TR/webauthn...
Appears to be on it's way to a real standard

FYI, Mozilla and Microsoft are currently working on U2F in Edge and Firefox

Yes, WebAuthentication, but not the standard currently implemented in Chrome, which is what everybody is using until the replacement is done. Until then it is Chrome only.

U2F... 2.0 is also know as "Web Authentication: An API for accessing Public Key Credentials" https://www.w3.org/TR/webauthn...
Appears to be on it's way to a real standard

FYI, Mozilla and Microsoft are currently working on U2F in Edge and Firefox

The FSF can't win this one. There is too much money on the other side.

If all that matters is who has more money this issue would have been quashed in the early 90's. Today the question on the table for W3C today would be mandatory laser scanning of eyeballs or mandatory browser APIs to give websites with too much money ring0 access to everyone's systems.

You have Google, Netflix, every major web browser, Microsoft, and even the inventor of the web himself. What is going to stop that kind of support?

Before commenting further please review W3C's member list.
https://www.w3.org/Consortium/...

Also review open principals that W3C advertises adherence to.
https://open-stand.org/about-u...

There has to be "Broad consensus" ... simply voting or allowing those with the most money to win violates W3C's own rules.

The open internet was a quirk of history. It was doomed from the start. It may have started as a wild west, an open digital frontier, but control over it is being re-established step by step by step.

It's never been cheaper or easier to communicate globally with billions of people. Source code for systems, networking and application stacks are readily available to anyone who wants them for FREE. Those bitching about being doomed and helpless need to get their heads examined.

It's only been 28 years since Tim Berners-Lee proposed a method of information storage and retrieval for exactly this purpose. His work was done in the wake of the Fleischmann-Pons Cold Fusion announcement in 1989, which saw scientists sending faxes of faxes of faxes of the draft journal paper to each other so they could try to replicate their experiment. He figured there had to be a better way. His proposal grew into the World Wide Web, as seemingly everyone adopted and embraced it except scientists publishing papers - the very people Berners-Lee had in mind when he created it. In the intervening 28 years, we've even seen a new company whose sole purpose is to provide people with real-time spot-rankings of citation links created under that proposal, grow into one of the most powerful in the world - Google.

Why are you encrypting traffic within your own private network?

To avoid loss of functionality once the Fullscreen API becomes limited to secure contexts. Browsers no longer support sensitive JavaScript APIs over cleartext HTTP. There are plans to make Fullscreen API unavailable over cleartext HTTP because of demonstrated phishing attacks. Without the Fullscreen API, streaming video from a home NAS will be limited to a window.

I think that has something to do with browser publishers deprecating the Fullscreen API on cleartext HTTP sites to make it harder for a man in the middle to impersonate your device's operating system. (Search keyword "secure contexts".). Do the pages an where embedded YouTube video falls to go full screen use HTTPS or cleartext HTTP?

I think it's trying to be IE6 for the new century. Has everyone already forgotten what a terrible idea browser specific language extensions are?

This is not a browser specific language extensions. CSS Grid Layout is currently a Candidate Recommendation by the CSS Working Group of the W3C. As long as browsers keep up with updates made to the proposal while it moves towards becoming a completed W3C Recommendation, I see no problem with implementing it now.

In the W3C's own words: "at this step, W3C believes the technical report is stable and appropriate for implementation."

If you encrypt it, that means you don't want that information known to everyone to begin with. Which means it shouldn't be on a system whose entire reason for existence is the sharing of information.

I don't care if I can't view your encrypted crap, but for those that do: EME does not mandate that encryption be avaiable to every device. As the CDM or Content Decryption Module: may or may not separate the implementations of CDMs or treat them as separate from the user agent. This is transparent to the API and application This would seem to permit an EME to use an external program / plugin for decrypting content. If so, then the entire purpose of having EME is rendered completely pointless. The vendor can simply choose not to provide a CDM for the given platform / browser.

Where we get into problems with security is this: All messages and communication to and from the CDM, such as between the CDM and a license server, MUST be passed through the user agent. The CDM MUST NOT make direct out-of band network requests. All messages and communication other than those described in Direct Individualization MUST be passed through the application via the APIs defined in this specification. Specifically, all communication that contains application-, origin-, or content-specific information or is sent to a URL specified by the application or based on its origin, MUST pass through the APIs. This includes all license exchange messages. The "all license exchange messages" part. Virtually guarantees that people / groups like the MAFFIA will say that a browser that implements EME could be used to sniff the license keys (see Common Key Systems for why this info can be leaked. Spoiler: It must pass the keys though the browser.) and therefore must be protected by the DMCA and it's other applicable laws elsewhere. This would effectively make a web browser a legal black box. A black box that is currently being used as literally the world's OS. All of those web applications that we use everyday would then become uninspectable for bugs or defects. Security researchers would not be able to examine them nor release information about their findings to the public without approval from the developer. Making us all less safe online. (See all of the stories here on /. about how a bug that was known for 90 days never got fixed by the manufacturer even when it was known to be in use in the wild by malware packages. These stories would become illegal if EME gets implemented.)

I'm sorry if TBL wants a universal system. I can empathize with that, but what he is suggesting is neither universal nor in the world's best interests. What he suggests is contradictory to the purpose of system he helped implement to begin with. I'm sorry if he can't think ahead and see how his desire for a universal encryption system would be abused by those demanding it to the determent of the world. None of this is progress. It's a step back to prop up an obsolete business model because of an industry that has no desire to modernize itself.

This is bad, and you will not convince those demanding EME to step into the modern era. You will have to drag them kicking and screaming. Bowing down to their demands hurts all of us, and it's time we cut our losses and move on without them. They are not worth the damage that they want to inflict on all of us, and if you say that they are, you have absolutely no right to complain if you get hacked, loose all of your data, or are unable to fix something without the blessing* of the manufacturer. Why? Because you asked for it, you supported it, and you got it.

*"Blessing" typically meaning using only their parts and services at a huge markup.

If you encrypt it, that means you don't want that information known to everyone to begin with. Which means it shouldn't be on a system whose entire reason for existence is the sharing of information.

I don't care if I can't view your encrypted crap, but for those that do: EME does not mandate that encryption be avaiable to every device. As the CDM or Content Decryption Module: may or may not separate the implementations of CDMs or treat them as separate from the user agent. This is transparent to the API and application This would seem to permit an EME to use an external program / plugin for decrypting content. If so, then the entire purpose of having EME is rendered completely pointless. The vendor can simply choose not to provide a CDM for the given platform / browser.

Where we get into problems with security is this: All messages and communication to and from the CDM, such as between the CDM and a license server, MUST be passed through the user agent. The CDM MUST NOT make direct out-of band network requests. All messages and communication other than those described in Direct Individualization MUST be passed through the application via the APIs defined in this specification. Specifically, all communication that contains application-, origin-, or content-specific information or is sent to a URL specified by the application or based on its origin, MUST pass through the APIs. This includes all license exchange messages. The "all license exchange messages" part. Virtually guarantees that people / groups like the MAFFIA will say that a browser that implements EME could be used to sniff the license keys (see Common Key Systems for why this info can be leaked. Spoiler: It must pass the keys though the browser.) and therefore must be protected by the DMCA and it's other applicable laws elsewhere. This would effectively make a web browser a legal black box. A black box that is currently being used as literally the world's OS. All of those web applications that we use everyday would then become uninspectable for bugs or defects. Security researchers would not be able to examine them nor release information about their findings to the public without approval from the developer. Making us all less safe online. (See all of the stories here on /. about how a bug that was known for 90 days never got fixed by the manufacturer even when it was known to be in use in the wild by malware packages. These stories would become illegal if EME gets implemented.)

I'm sorry if TBL wants a universal system. I can empathize with that, but what he is suggesting is neither universal nor in the world's best interests. What he suggests is contradictory to the purpose of system he helped implement to begin with. I'm sorry if he can't think ahead and see how his desire for a universal encryption system would be abused by those demanding it to the determent of the world. None of this is progress. It's a step back to prop up an obsolete business model because of an industry that has no desire to modernize itself.

This is bad, and you will not convince those demanding EME to step into the modern era. You will have to drag them kicking and screaming. Bowing down to their demands hurts all of us, and it's time we cut our losses and move on without them. They are not worth the damage that they want to inflict on all of us, and if you say that they are, you have absolutely no right to complain if you get hacked, loose all of your data, or are unable to fix something without the blessing* of the manufacturer. Why? Because you asked for it, you supported it, and you got it.

*"Blessing" typically meaning using only their parts and services at a huge markup.

If you encrypt it, that means you don't want that information known to everyone to begin with. Which means it shouldn't be on a system whose entire reason for existence is the sharing of information.

I don't care if I can't view your encrypted crap, but for those that do: EME does not mandate that encryption be avaiable to every device. As the CDM or Content Decryption Module: may or may not separate the implementations of CDMs or treat them as separate from the user agent. This is transparent to the API and application This would seem to permit an EME to use an external program / plugin for decrypting content. If so, then the entire purpose of having EME is rendered completely pointless. The vendor can simply choose not to provide a CDM for the given platform / browser.

Where we get into problems with security is this: All messages and communication to and from the CDM, such as between the CDM and a license server, MUST be passed through the user agent. The CDM MUST NOT make direct out-of band network requests. All messages and communication other than those described in Direct Individualization MUST be passed through the application via the APIs defined in this specification. Specifically, all communication that contains application-, origin-, or content-specific information or is sent to a URL specified by the application or based on its origin, MUST pass through the APIs. This includes all license exchange messages. The "all license exchange messages" part. Virtually guarantees that people / groups like the MAFFIA will say that a browser that implements EME could be used to sniff the license keys (see Common Key Systems for why this info can be leaked. Spoiler: It must pass the keys though the browser.) and therefore must be protected by the DMCA and it's other applicable laws elsewhere. This would effectively make a web browser a legal black box. A black box that is currently being used as literally the world's OS. All of those web applications that we use everyday would then become uninspectable for bugs or defects. Security researchers would not be able to examine them nor release information about their findings to the public without approval from the developer. Making us all less safe online. (See all of the stories here on /. about how a bug that was known for 90 days never got fixed by the manufacturer even when it was known to be in use in the wild by malware packages. These stories would become illegal if EME gets implemented.)

I'm sorry if TBL wants a universal system. I can empathize with that, but what he is suggesting is neither universal nor in the world's best interests. What he suggests is contradictory to the purpose of system he helped implement to begin with. I'm sorry if he can't think ahead and see how his desire for a universal encryption system would be abused by those demanding it to the determent of the world. None of this is progress. It's a step back to prop up an obsolete business model because of an industry that has no desire to modernize itself.

This is bad, and you will not convince those demanding EME to step into the modern era. You will have to drag them kicking and screaming. Bowing down to their demands hurts all of us, and it's time we cut our losses and move on without them. They are not worth the damage that they want to inflict on all of us, and if you say that they are, you have absolutely no right to complain if you get hacked, loose all of your data, or are unable to fix something without the blessing* of the manufacturer. Why? Because you asked for it, you supported it, and you got it.

*"Blessing" typically meaning using only their parts and services at a huge markup.

The problem is that HTTP is a shitty protocol. It uses an unique TCP connection for every request. For each page of text and every image, HTTP requests a new TCP connection and tears it down after transfer. This causes a lot of latency, partly because TCP is designed to start slow and ramp up to the available bandwidth and partly because of the extra signalling for new TCP handshakes, authentication tokens, encryption renegotiation, etc. As a result, your web browser spends way more time than it should just waiting for data transfers to start. In response to HTTP's limitations, web browser make parallel server connections to conceal some of that latency. Users on slow or congested links may find it beneficial to tweak their browser settings for fewer concurrent connections and/or longer timeouts. HTTP2 fixes many of these problems, but server support has been slow to roll out.

https://www.w3.org/Protocols/H...

There is an RFC for HTTP 1.1 which suggests a maximum of 2 connections per client. A feature for a browser to dynamically modify its connection behaviour based on bandwidth would not be a bad thing.

Thus the inclusion of WebRTC and Fullscreen in the Secure Contexts proposal, currently a W3C Candidate Recommendation, is one big handout to domain registrars. Ten million homes with NAS devices means 10 million domains that need to be registered and renewed annually, to the tune of $100 million a year for registrars. At least it's not quite as bad as it'd be without Let's Encrypt, in which it would have been a handout to both the registrar racket and the CA racket.

Stop introspecting the device within the browser framework

That's my preference, too.

It's interesting to look at the history of this API, particularly early documents for the "System Information API" drafts that the Devices and Sensors WG produced, such as this one, and the discussions on the mailing list leading up to it.

The justification seems to have been, gee, why can't web apps do everything native apps can? Who cares whether there's a use case?

Of course this was in keeping with the historical moment. This stuff originated in 2009 (yes, seven years is a typical invent-implement-despair-deprecate cycle for web standards), when lots of people were cheering on "rich Internet applications" (gah) and there wasn't much research into browser side channel exposure. The earliest reference I found to side-channel attacks on browsers (specifically) was a 2010 Schneier post about a paper by Chen et al.. (Schneier mentions in passing extant research on side-channel attacks on SSL, but it's not clear what he's referring to - whether it's channels exposed by the browser as such or SSL implementation errors like the 2003 Boneh & Brumley timing attacks.) So it might be claimed that browser side channel vulnerabilities weren't widely recognized in the industry before 2010 or so, and so might reasonably not have been on the WG's radar.

However, we still have the basic objection you voiced: many users don't want web apps to have native-app access to the machine. Period.

From the actual spec (emphasis mine):

4. Security and privacy considerations

The API defined in this specification is used to determine the battery status of the hosting device. The information disclosed has minimal impact on privacy or fingerprinting, and therefore is exposed without permission grants. For example, authors cannot directly know if there is a battery or not in the hosting device.

From now on, let's just assume that any information can be mis-used and not send it without explicit permission, okay?

Web Bluetooth as currently defined by W3C may introduce unexpected data leaks such as location, and personally-identifiable data

The leaks aren't unexpected, all new web technologies are being designed that way on purpose. When advertisers make up the standards body, this is what we get.

The ability to decode the font is also still proprietary.

AOSP is free software. Does AOSP lack support for color emoji?

It's not an ability inherent in any widely adopted font format.

W3C published a specification for scalable fonts whose glyphs include color information five years ago, titled SVG Fonts. Whose fault is it that this specification has failed to become "widely adopted"?

Where are the new features that people actually need? Like for example being able to watch a live video stream in a browser without being a web guru and relying in complex server infrastructure.

Have you even looked at the "video" tag? It is exactly that simple.

W3C's description of the <video> element states:

The HTML5 specification does not specify a particular streaming method. It is expected that HTTP 1.1 progressive streaming is at least supported. Adaptive/live streaming may be supported as a UA extension.

A Google search for HTTP 1.1 progressive streaming led to this page, which equates it with seeking in a prerecorded stream using HTTP range requests. But CptLoRes was referring to live streams, not prerecorded streams. The same page also states that not all non-Apple browsers support Apple's HTTP Live Streaming spec.

Extracting a portion and embedding it in your content without quote or citation does not seem like fair use, it actually seems like plagiarism.

Let me add that a link is a citation .

Wrong. The link is not visible to the casual reader, it is buried in the HTML source. Hence it does not count.

A link is not the content, a link is a reference to the content.

In a "programming" sense (to use the word "programming" very loosely), not in a "inform the reader" sense. Hence it does not count.

(Again, read Berners-Lee's document. He is the creator of the hyperlink, and he makes this point very clear.)

Apparently not clear enough, you seem to misunderstand it. Note how he repeatedly refers to linking to a *page*. A link to a complete page is something very different than an embedded link to a fragment of a page's content. It is only the former being discussed here, and the plagiaristic nature of unmarked unidentified (from the reader's perspective, not the html client's perspective) embedding of someone else's work. Keyword: "embedding", that is something different than "linking", taking a reader to someone else's web page.

Extracting a portion and embedding it in your content without quote or citation does not seem like fair use, it actually seems like plagiarism.

Let me add that a link is a citation . A link is not the content, a link is a reference to the content.

(Again, read Berners-Lee's document. He is the creator of the hyperlink, and he makes this point very clear.)

I notice that in the same document, Berners-Lee stated that

We cannot regard anyone as having the "right not to be referred to"

But when the EU established its Right To Be Forgotten, it chose to disregard this fundamental design principle for The Web. So, I suppose the EU feels that it can disregard the other design principles, too!

March, 1989

https://www.w3.org/History/198...

By "the spec", are you referring broadly to the W3C's EME spec or more narrowly to the spec of how Firefox implements EME?

Using HTML storage.

The javascript emulator would have access to https://www.w3.org/TR/webstora...

[Appliances on a home network with a web-based administration interface] are not servers and don't need to serve https

The article "Deprecating Non-Secure HTTP" by Richard Barnes begins: "Today we are announcing our intent to phase out non-secure HTTP." Not only Firefox but also Chrome has announced plans to deprecate HTTP. This includes making new web APIs, such as Service Worker, available only to a "secure context". The list of such APIs includes Service Worker, Geolocation, Notification, Fullscreen, Pointer Lock, and Media Stream (camera and microphone).

A secure context is available only if all documents holding references to objects in that context come from a "potentially trustworthy origin", as defined in the W3C's "Secure Contexts" spec. As of right now, web browsers are treating only the 127/8 netblock (that is, localhost) and origins using the https or wss scheme as potentially trustworthy origins. The spec allows a web browser to allow the user to mark other origins as potentially trustworthy, but the present draft doesn't suggest how the web browser might expose this functionality to the user.

as you'll connect on a trusted network - your own, and your own only. Wired or encrypted WiFi.

A web browser cannot tell the difference between my encrypted Wi-Fi network at home and the encrypted Wi-Fi network of the coin laundry near me. For this reason, the RFC 1918 private netblocks 10/8, 172.16/12, and 192.168/16 are by default not treated as potentially trustworthy without the https scheme, unlike 127/8.

[Appliances on a home network with a web-based administration interface] are not servers and don't need to serve https

The article "Deprecating Non-Secure HTTP" by Richard Barnes begins: "Today we are announcing our intent to phase out non-secure HTTP." Not only Firefox but also Chrome has announced plans to deprecate HTTP. This includes making new web APIs, such as Service Worker, available only to a "secure context". The list of such APIs includes Service Worker, Geolocation, Notification, Fullscreen, Pointer Lock, and Media Stream (camera and microphone).

A secure context is available only if all documents holding references to objects in that context come from a "potentially trustworthy origin", as defined in the W3C's "Secure Contexts" spec. As of right now, web browsers are treating only the 127/8 netblock (that is, localhost) and origins using the https or wss scheme as potentially trustworthy origins. The spec allows a web browser to allow the user to mark other origins as potentially trustworthy, but the present draft doesn't suggest how the web browser might expose this functionality to the user.

as you'll connect on a trusted network - your own, and your own only. Wired or encrypted WiFi.

A web browser cannot tell the difference between my encrypted Wi-Fi network at home and the encrypted Wi-Fi network of the coin laundry near me. For this reason, the RFC 1918 private netblocks 10/8, 172.16/12, and 192.168/16 are by default not treated as potentially trustworthy without the https scheme, unlike 127/8.

This is what the specification has in the introduction:

"The Battery Status API can be used to defer or scale back work when the device is not charging in or is low on battery. An archetype of an advanced web application, a web-based email client, may check the server for new email every few seconds if the device is charging, but do so less frequently if the device is not charging or is low on battery. Another example is a web-based word processor which could monitor the battery level and save changes before the battery runs out to prevent data loss. "

https://www.w3.org/TR/2016/CR-...

Remember when Colin Powell got up before the UN and said Iraq had WMDs? I do because that was the day I lost all respect for Powell.

Berners-Lee had his Colin Powell moment when he said DRM should be part of the HTML standard. I agree with his points about network neutrality, but he no longer has the moral standing to champion the ideals of the open internet.

There's little reason for a web browser to access anything but the profile and its download directory.

Looking through the permissions that Chrome for Android has, I can see a few little reasons:

• Obviously, a web browser needs to access the Internet.
• WebRTC requires microphone and camera access but allows things like voice search, product lookup by barcode, reverse image search, and voice and video chat.
• Geolocation API requires location access but allows not having to key in your street address every time when looking for stores near you.
• Web Notifications requires receiving cloud to device messages but allows a user to choose to let a web application get the user's attention.

A picture viewer doesn't need to write to disk

Unless it offers a feature for the user to rotate an image by 90 degrees and save the fact that it was rotated. (The cosine transform used in JPEG allows lossless rotation of images whose size is a multiple of the macroblock size, usually 16x16 pixels.)

Newlines and whitespace in HTML/XML attributes are explicitly allowed. Javascript also has semicolon insertion rules that can make whitespace meaningful (e.g. in the case of `return`). See here and here for the definitions.

Newlines and whitespace in HTML/XML attributes are explicitly allowed. Javascript also has semicolon insertion rules that can make whitespace meaningful (e.g. in the case of `return`). See here and here for the definitions.

Does the caching proxy discriminate between domains? Does the ISP require websites (note: not the ISP's "users"; I'm talking about the party at the other end of the connection) to "partner" with it to opt-in to being cached?

If the answers are "no," then there's no problem.

If the answers are "yes," but all you have to do to "opt in" is something like setting your HTTP cache-control header to "public" then that's fine too.

If the answers are "yes," and you have to manually call up the ISP and ask them to manually enable it for your site, that starts to be a problem (because it's unreasonable to expect every website operator to manually coordinate with every ISP). That's what's wrong with Binge On.

If the answers are "yes" and the ISP expects each website operator to pay it for the privilege (the Comcast/Netflix extortion model), then that's totally and completely unacceptable.

It's kind of funny, it's a bit like websites many, many years ago. Every business is like: we want a website. What do you want to put on the website ? What is your audience ? What would you like to communicate ? Euh... I don't know. LoL.

You already mentioned it, but I think it goes deeper: a place on the home screen. Which is limited real estate. Something a browser bookmark to home screen could do too, which was harder to do in older browsers but more and more people are finding it now it has become easier in browsers.

Probably the biggest reason apps got such a jump over web is because of off-line support in browsers. HTML5 had offline support, but it didn't work well.

And maybe performance, but current new phones have no problems with that. CPU/GPU, etc. is not the most taxing part of a phone. It's networking and powering the screen.

Their is a new API which is now supported by all the latest browsers:
https://jakearchibald.github.i...
http://caniuse.com/#feat=servi...

Let's see if they got it right this time.

And people now know they don't want to install sketchy software. They even understand they don't want plugins any more on their desktop/laptop.

The biggest missing part of mobile web is: it's not easy to do payments. In many countries people can't use the app store either (no credit card).

Maybe this will happen: https://www.w3.org/Payments/

The decision demonstrates considerable ignorance on a number of levels. "Phonograph" is a common noun, but more to the point there are more phonographs than one. In common parlance, the term "Internet" refers to the one and only Internet. True, you can have separate internets and lowercase them if you wish (and it even seems desirable to distinguish them from the Internet). In the term "Internet Protocol(s)", the capital letters are also fully justified by the fact that IP(s) are proper names.

As for the Web, it is obviously and even more emphatically one and unique. Otherwise Tim Berners-Lee would not have chosen to call it "the World Wide Web". Since he also chose to give it away free, rather than sucking vast profits from it, I think we can afford to honour his decision - the more so as it is eminently logical and sensible. If anyone has not read TBL's own explanation, see https://www.w3.org/People/Bern...

I cannot help feeling that the rush to lowercase these terms reflects little more than fashion. There is a trend to lowercase words and phrases that obviously should be capitalized, including proper names. We should not allow that modish trend to lead us astray, as we are more interested in the true meaning of words than in their superficial appearance.

I can see how this decision fits in with modern fashion. The whole idea of a proper noun seems to grate - perhaps it clashes with the pervasive inverted snobbery of our culture. Many people's forum handles lower-case ordinary names, subtly suggesting that they are more sophisticated than old-fashioned upper-cased names.

As others have pointed out, there is in practice only one Internet: so it should be "the Internet". There are of course many intranets, and you can talk about different partial internets; but if they are not part of the Internet, the usage is merely confusing; and if they are part of the Internet, why use the same name for the whole and a part of it?

As for the Web, it was invented and freely given to the world by Tim Berners-Lee and his colleagues at CERN. Sir Tim has always emphasized that it should be both unique and world-wide, hence the proper name "the World Wide Web".

Here is his authoritative explanation:

Q: How in fact do you spell World Wide Web?

A: It should be spelled as three separate words, so that its acronym is three separate "W"s. There are no hyphens. Yes, I know that it has in some places been spelled with a hyphen but the official way is without. Yes, I know that "worldwide" is a word in the dictionary, but World Wide Web is three words.

I use "Web" with a capital W to indicate that it is an abbreviation for "World Wide Web". Hence, "What a tangled web he wove on his Web site!".

Often, WWW is written and read as W3, which is quicker to say. In particular, the World Wide Web consortium is W3C, never WWWC.

Q: Why did you call it WWW?

A: Looking for a name for a global hypertext system, an essential element I wanted to stress was its decentralized form allowing anything to link to anything. This form is mathematically a graph, or web. It was designed to be global of course. (I had noticed that projects find it useful to have a signature letter, as the Zebra project at CERN which started all its variables with "Z". In fact by the time I had decided on WWW, I had written enough code using global variables starting with "HT" for hypertext that W wasn't used for that.). Alternatives I considered were "Mine of information" ("Moi", c'est un peu egoiste) and "The Information Mine ("Tim", even more egocentric!), and "Information Mesh" (too like "Mess" though its ability to describe a mess was a requirement!). Karen Sollins at MIT now has a Mesh project.

https://www.w3.org/People/Bern...