Slashdot Mirror

The Google Chrome engineer who posted this ask to the W3C mailing list ( https://lists.w3.org/Archives/... ) also made a social media poll, https://twitter.com/estark37/s...

Essentially, they're reinforcing their own echo-chamber effect to only listen to confirmations of their conceived notion of correctness rather than truly encouraging discourse on the matter. Her poll options are, "yes" and "yes" -- and several Twitter replies have been deleted.

Personally, it seems they are an engineer looking for a problem to solve to help justify their job... and that's just sad in itself.

No, "ping" isn't in the official HTML specification. What /. linked to is the Google's unofficial fork of HTML.

I have to assume it's because everyone working on the HTML5 stuff is too young to have learned anything from the first time around

Wow that's incredibly naive. The people who wrote HTML 5 spec are keenly aware of the first time around. Pretty much anything Web is made for commercialization. If people solely wanted information distribution, we would have implemented a copyleft version of something like Gopher. While Tim Berners-Lee may have originally made the web in the pursuit of wide distribution of information, those who have been entrusted to steer the W3 since mid 1990s have had a single goal in mind. How do we write a commercial friendly spec?

Case in point, notifications. The spec and API for notifications once upon a time was called as such from JS.

{ window.webkitNotifications.createNotification('icon.png', 'Notification Title', 'Notification content...'); } else { window.webkitNotifications.requestPermission(); } } //dot dot dot

Now just go look at the Notifications spec here. If you look at how it goes, you'll see pretty much the Notification API in the HTML spec is just the Webkit Notification API with "webkit" removed as the prefix for each method. That's not a mistake, Google pretty much wrote the HTML spec for Notifications. I mean shit, if you roll down to the bottom there in the "Acknowledgements" most of the names there are Google engineers. And you'll see that a lot on a lot of HTML5's different technical specs. HTML 5 was written to make Google and Apple better at what they want to serve to you. Shit, just look up what internally happened in W3 when XHTML 2 was being tossed around. You don't write a spec that no one will use and no one will use a spec if money is not to be found there or the legacy isn't completely entrenched.

The people steering the W3 now are writing a sepc that's specifically tailored to the services that they want to serve. So yeah, they looked back at how once upon a time annoying notifications were shoved into people's faces and learned how to create a spec that makes it difficult to filter out trash from notifications all the while attempting to prevent client options for wide scale ignoring notifications and remaining in spec. That's the key here, Firefox is free to implement whatever the fuck they want to combat notification spam, but that is constrained by the fact they'd like to keep a "standards compliant" browser.

Standards committees aren't altruistic entities, they're there to create a standard that will be used first. With fair to all somewhere long after the other goals. If the majority of folks implementing a spec are doing so for a profit or to drive a service that will net them profit, then the spec becomes profit driven. That's how every standards committee since formal standards outside the world of academia (and even then that doesn't make it immune, see the U and Gopher protocol) works. The web and the standards committee driving it are doing so at the behest of those who want to use a standards compliant client to drive profit. Hells bells, some of the voting members just let the private companies write the spec and then they just go vote yes for whatever they were handed. Thinking the web or W3 or anyone else is doing something different is ignoring reality for idealism. It is time for those who think the web is for something outside the world of profit to finally accept that the web exists only for profit and all other perceived functions are merely riding the coattails here or said person is conflating the terms Internet and Web.

This is like a proprietary, non-distributed version of the Annotea project (circa 2001): https://www.w3.org/2001/Annote...

Your right. . . only IE isn't supporting shadow dom (v0 was experimental, v1 is used now):
Shadow Dom Support

Now it is being included in the standard Dom/Html/CSS/Event W3C specs.
W3C


So yes, YouTube (ie Google) provided a hacked "pollyfill" and/or javascript version to emulate what was spec by W3C but not implemented by IE.

Who created and implemented those drafts [of HTTP/2]?

Google. But who should have created and implemented them, if not Google?

As I understand it, the .dev constraint is enforced in chrome's source code, not in any DNS record

The same is true of other ICANNverse domain names whose owners have set the HSTS preload bit. If you were to create a site called google.com in your air-gapped private parallel internet, the major browsers would force HTTPS on that as well.

Who do you think will define HTML5? It isn't going to be W3C. Or Google saying all http is 'not secure'

"Secure Contexts", a policy to block JavaScript from doing sensitive things on cleartext HTTP sites, is in fact a W3C Candidate Recommendation. Besides, Firefox has similar behavior. Visit some random cleartext site, and to the left of the URL bar, you see a lock with a red slash through it. Click it to show the warning: "Connection Is Not Secure / Logins entered on this page could be compromised."

I don't recall Microsoft's implementation violating any of the published specifications. It didn't conform to what the advertisers wanted (opt-out implementation with the default being "allow to be tracked"), but it doesn't violate the spec. To quote from the spec (Tracking Preference Expression W3C Editor's Draft 07 March 2016):

A user agent MUST have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the user's decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as SuperFred, but might imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred.

Microsoft's browser is advertised as having this preference set by default, so the decision to use it by a user, knowing what the default was, would imply they wished to have DNT set by default. That this would result in less tracking than advertisers wish... doesn't seem to me to be within the scope of the standard. Every time users (as opposed to advertisers) have been surveyed, the results seem to heavily support an opt-in model where tracking is not permitted unless a user opts in to tracking (similar to the results for email where users heavily favor a model that does not permit email contact unless the user opts in to email contact).

Tab is supposed to allow navigation while ctrl+m is for inserting tab characters - https://www.w3.org/TR/wai-aria...

The summary probably wasn't written with a technical audience in mind, and it leaves much to be desired.

The main contribution here is the concept of linked data: that the relationship between media objects should be exposed through a standards-based interface. This is an old idea, but it is seldom practiced. Linked data is a natural extension of Sir Berners-Lee's original hypertext protocol, which provided for hyperlinking between documents.

The linked data protocol encourages the development of distributed applications. For example, one can host a photo on one server, but comments about that photo could be distributed among many others. Linked data is used to describe what refers to what. In this model, contributors are expected to retain more control over their contributions. This will likely scale OK for small groups... but if you attract hundreds of comments, you might be in trouble.

Is this useful? Maybe. It appears to fill much the same space as existing "social networking" websites, which provide both identity and methods for "limited sharing." It does not appear to address the needs of

• Very personal data like healthcare information, which must be stored only in highly secure, trusted environments; OR
• Very public data, which one might wish to store immutably, indefinitely, and have it be highly discoverable

Worse, where are we going to put these "Solid PODS?" On our home PCs? Most homes are not blessed with high uplink speeds, 99.9%+ SLAs, uninterruptible power, or redundant data centers. The answer for most people is likely going to be "in the cloud." Economies of scale dictate that low-cost cloud computing resources will be concentrated into the hands of relatively few organizations with both the capital and the experience to provide them.

All will be well and good until the cloud service providers realize that they can simply peer into these PODS and extract all the data that they ever wanted.

not the new and bogus "https means it's legit, everything should be https" line of thinking, re Google

That's not even the thought process from Google. Here is the proposal from way back when. Relevant section:

We all need data communication on the web to be secure (private, authenticated, untampered). When there is no data security, the UA should explicitly display that, so users can make informed decisions about how to interact with an origin. Roughly speaking, there are three basic transport layer security states for web origins: Secure (valid HTTPS, other origins like (*, localhost, *)); Dubious (valid HTTPS but with mixed passive resources, valid HTTPS with minor TLS errors); and Non-secure (broken HTTPS, HTTP).

Emphasis mine. And if you are wondering about the wording there, the exact definition can be found on the W3 site here. Which says if you trust the site then you can be assured that the information you transmit to the site has done so securely, that you can trust that they received the information that you sent them.

At no point can any standards body or web vendor indicate how compromised or fully functioning the host you are sending your data to is. At no point has any web browser maker (Apple, Google, Microsoft, Mozilla, et al) indicated that "Secure Host" == "Non Compromised Host". They have only indicated transmission "Secure Transmission to host" == "Non Compromised Transmission to host". What the host does with it, be it to send your data to some gulag in Siberia, to your bank for processing, or both is completely dependent on the remote host.

Nobody is stopping you from disabling JavaScript.

A well thoughout progressive web app can (and some argue should) also progressively degrade and continue to render content in some fashion (especially if it is public, and not behind authentication).

Although, I suspect you may be fighting a losing battle. HTML + JS (Web Assembly) + CSS (and other exciting agreed upon technologies) is a platform. Scripting is here to stay.

8) Never, ever incorporate popular extensions into the core product for efficiency. Blocking ads and better security should be the end users task to learn about, decide, and implement. If you *must* implement something like the "do not track" button, be sure to be extremely careful not to piss off advertizers: implement it by default "off", so that users can choose.

Unset was actually the required default state in the DNT spec, when Microsoft decided to violate it there was a lot of discussion about how it would be valid for advertisers to ignore DNT for IE users. (Microsoft later changed IE to require the user to change the setting).

What is needed is a good Open Social Media protocol.

It exists.

Needs a bit of open user ids as well.

That too.

And which browesrs are we supposed to test with, apart from Chrome?

https://validator.w3.org/nu/

http://jigsaw.w3.org/css-validator/

And which browesrs are we supposed to test with, apart from Chrome?

https://validator.w3.org/nu/

http://jigsaw.w3.org/css-validator/

In a well-engineered system, [obtaining a FQDN through a DDNS service] would be excusable.

No it wouldn't. Not without asking consent first.

"If you do not consent, return this product to the seller per the seller's return policy."

Security for a device like HDHomeRun is rather pointless. Nobody is asking for HTTPS certificates.

Several JavaScript APIs are available only to HTTPS scheme or localhost (127/8, not 192.168/16) per the Secure Contexts specification. Among JavaScript APIs related to video recording or streaming, the Presentation API is already restricted to secure contexts, and browser makers plan to restrict the Fullscreen API similarly to deter phishing attacks that involve spoofing the window manager and browser.

To send encrypted all it needs is a TLS stack and a root certificate. It doesn't need an FQDN or any such bullshit.

Obtaining the certificate needs an FQDN. The CAB Forum's Baseline Requirements forbid issuing in private TLDs, such as .local used by mDNS. Otherwise, you'll have to run your own CA, issue a certificate to the device, and install your CA's root certificate into the web browser on every device from which you plan to view. Some popular mobile browsers don't make that very convenient.

I'd prefer to use a TLS client certificate, but the user interface for those in widely used web browsers needs a serious redesign before that can be practical.

First, the browser needs to make the button to select a client certificate more obvious. Second, split the list of available client certificates into three groups: anonymous (no certificate), certificates used on the same domain (ordered by most recent), and certificates used on other domains. Third, browsers' built-in password/bookmark/history synchronization mechanisms need to make synchronizing client certificates across devices painless. Might WebAuthn (a W3C Candidate Recommendation generalizing FIDO U2F) be a step in the right direction?

'Web' is an abbreviation of WorldWideWeb. CERN did not invent the Web, Tim Berners-Lee and Robert Cailleau invented it by publishing the WorldWideWeb proposal. Note that it says "HyperText" right in the title. GOPHER was an Internet service, but it was not hypertext and not part of the Web.

HTML was not the first hypertext format, and probably won't be the last. But HTML is certainly the most widely used to date.

I'd like to note that ViolaWWW beat Mosiac by about a year. But was not portable and only ran on X Windows, so Mosiac won by being easier to port. A bit of the same story for an the even earlier browser Nexus, which was tightly coupled to NeXT's system.

I think the only "first" that Mosiac has is that it was the first HTML browser with images to be ported to MS Windows. Seems less impressive when stated that way. But it was wildly popular back in its day, and launched the career of Marc Andreessen of Netscape fame. And it's important to note that Netscape's IPO is what triggered the crazy tech speculation of the 1990's and lead to the dot-com bubble. Everyone wished they were part of that original Netscape IPO and did everything they could to not miss out on the next great IPO, that cycle churned through Silicon Valley for nearly a decade before coming to a grinding halt.

According to Tim Berners-Lee:

Where does Mosaic fit in?

A: "As I understand it, Marc Andreessen at NCSA was shown ViolaWWW by a colleague (David Thompson?) at NCSA. Marc downloaded Midas and tried it out. He and Eric Bina then wrote their own browser for unix from scratch. Later, several other folks at NCSA joined the team to port the idea to Mac and PC. As they did, Tom Bruce at Cornell was writing "Cello" for the PC which came out neck-and-neck with Mosaic on the PC.

Marc and Eric did a number of very important things. They made a browser which was easy to install and use. They were the first one to get inline images working ..."

The inline images such as the world/book icon and the CERN icon, would have been displayed in separate windows, as it didn't at first do inline images.

There are already dozens of such programs that use the ActivityPub protocol, and it is intended to work much like you described. Fun fact: Facebook, et al were involved in developing ActivityStreams, the basis for the ActivityPub protocol, and they abandoned it because newsflash: their zero-sum business models only work if they have all the users and they are locked in.

Indeed... this is how it is recommended to get implemented...

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

From the beginning.

https://www.w3.org/Daemon/Implementation/HTLog.c

It is not broken. You just don't understand how it works and how it has always worked.

What do you expect? Magic pixies to deliver your content?

multiple CSS style sheets, one of them being the default
https://www.w3.org/TR/html401/...

Alternatively, they don't. The user configures user-specific style overrides in their UA and the UA applies them depending on sensor output.

With what UI control in each major browser does the user so configure it to apply one of "multiple CSS style sheets, one of them being the default" during high ambient light and the other during low?

If a website operator deliberately makes a public website inaccessible to users with disabilities, it risks a lawsuit from National Federation of the Blind or foreign counterparts.

Tim Berners-Lee made his opinion about this perfectly clear in a 1997 document. The bottom line is simple: if you don't want something linked to, don't put it on the World Wide Web.

'Myth: "A normal link is an incitement to copy the linked document in a way which infringes copyright".

'This is a serious misunderstanding. The ability to refer to a document (or a person or any thing else) is in general a fundamental right of free speech to the same extent that speech is free. Making the reference with a hypertext link is more efficient but changes nothing else.

'When the "speech" itself is illegal, whether or not it contains hypertext links, then its illegality should not be affected by the fact that it is in electronic form.

'Users and information providers and lawyers have to share this convention. If they do not, people will be frightened to make links for fear of legal implications. I received a mail message asking for "permission" to link to our site. I refused as I insisted that permission was not needed'.

https://www.w3.org/DesignIssue...

Summarizing my list of unresolved axes to grind:

We're already on a decentralized web.

The Decentralized Web is actually a specific concept. It used to be referred to as ReDecentralized, because, you're right that the inherent design of the web is decentralized. What it refers to is the concentration of 'broadcasters' like television instead of the decentralized thing it was intended to be.

You don't get to pick the algorithms that sites you visit use.

You do by choosing the aggregation software you use, whether you pay for it from a provider, or host your own (there's 100's of open source options). It terms of social feeds (which is what we are talking about, Facebook), you create connections to friends and then pull the raw feeds (similar to the old RSS), and your software does the sorting into a master feed. For now, most packages only have 1 or a handful of algorithms, but that will change as more people wake up to this possibility. For now, your choice lies mostly in picking which software you want to use, and they all federate. Right now the size of this decentralized social web is kind of 'small' relatively. Only about 2.5 million daily users. Nothing compared to behemoths such as Facebook, but it's growing.

https://w3.org/TR/ActivityPub

are you saying that it is a problem if your printer config page says "not secure" in the browser bar?

I'm saying it's a problem if I can't, for example, view media that I have stored on my NAS box because its presentation in the browser relies on JS APIs that are reserved for secure contexts.

There is no requirement stating when an image must be downloaded.

Where does it say a browser must immediately render a replaced element with it's content when it's downloaded?

You started whinging about standards compliance but now you've stopped referencing standards.

Please enlighten me, I must have missed something.
Also, HTML5 compliance does not require a browser supports Javascript, so scripting being on or off has nothing to do with it.
In reference to JavaScript/ECMA262 "User agents are not required to support the languages listed above."
https://www.w3.org/TR/2014/REC...

You should really know what the fuck you're talking about before ranting and calling people "fucktards"

https://www.w3.org/TR/2017/REC...

Actually, if they are designated as "supporting the suggested default rendering" they are required to:

In the absence of style-layer rules to the contrary (e.g., author style sheets), user agents are expected to render an element so that it conveys to the user the meaning that the element represents, as described by this specification.
An element is being rendered if it has any associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling languages.

- https://www.w3.org/TR/2017/REC...
- https://www.w3.org/TR/2017/REC...

Actually, if they are designated as "supporting the suggested default rendering" they are required to:

In the absence of style-layer rules to the contrary (e.g., author style sheets), user agents are expected to render an element so that it conveys to the user the meaning that the element represents, as described by this specification.
An element is being rendered if it has any associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling languages.

- https://www.w3.org/TR/2017/REC...
- https://www.w3.org/TR/2017/REC...

W3C's official replacement for lowsrc= is to use formats that support incremental loading, delivering a low-detail image early in the file and the difference between low- and high-detail images later. JPEG has progressive refinement, and PNG has Adam7 interlacing. But not all formats support this; for instance, I don't see a way to make it work for an SVG illustration or for anything animated.

What other replacement did you have in mind, if any?

https://www.w3.org/TR/2003/REC-PNG-20031110/#11IHDR

Bit depth and sample depth are synonyms, and "sample" is a synonym for channel in this context. So not only does it support 32bpp (8-bit samples; RBGA), it also supports deep colour. 48-bit RGB and 64-bit RGBA. These would easily encompass any other potential meaning of 32bpp supposing that you didn't mean "with the alpha channel."

Tim Berners-Lee, creator the Word-Wide Web, settled this question over 20 years ago.

https://www.w3.org/DesignIssues/LinkMyths.html

In particular, he pointed out that it is "a serious misunderstanding" to think that "A normal link is an incitement to copy the linked document in a way which infringes copyright". But here we are, 20 years later, and people are still making the same argument. Will it never end?!??

The W3C get to define the standards

Is this one?

Specifically this part: 7.4. Restricting Legacy Features

First sentence: "This section is non-normative"

The W3C get to define the standards

Is this one?

Specifically this part: 7.4. Restricting Legacy Features

First sentence: "This section is non-normative"

The W3C get to define the standards

Is this one?

Specifically this part: 7.4. Restricting Legacy Features

The W3C get to define the standards

Is this one?

Specifically this part: 7.4. Restricting Legacy Features

The W3C get to define the standards

Is this one?

If the Standard call for a feature to work on Both HTTP and HTTPS, and you implement only HTTPS, then is not an standards compliant implementation...

Nor does an implementation comply if the browser implements it over cleartext HTTP but the standard specifies that it shall not work over cleartext HTTP. A growing number of web standards specify such, citing things like the W3C Candidate Recommendation "Secure Contexts".

Those heavy-handed tactics could work when your market share was about 50%, but not anymore...

That'd be a good comeback if plurality browser Chrome weren't also doing it.

I assume the logic is that if a web platform feature is at Candidate Recommendation status at the start of beta, it's likely to be at least a Proposed Recommendation once beta ends.

I assume the logic is that if a web platform feature is at Candidate Recommendation status at the start of beta, it's likely to be at least a Proposed Recommendation once beta ends.

Aside: When did links stop working?

Based on the curly quotes and en.m.wikipedia.org hostname I see on that link's href attribute value in View Source, links in your comments stopped working roughly when you enabled automatic curly quotes on your iPhone or iPad or upgraded your iPhone or iPad to a version of iOS that enabled automatic curly quotes by default. Quoted attribute values in HTML5 must use Basic Latin quotation marks, be they single or double.

Anyone who knows anything about TLS also knows about digital signatures and checkhashes.

What browsers will accept a cipher suite containing only key exchange and HMAC (the "digital signatures and checkhashes") without bulk encryption?

There's even a year-old W3C spec called Subresource Integrity that addresses this problem.

Even if it works for images, style sheets, and scripts, it won't work for the HTML document itself because it's subresource integrity, not mainresource integrity. In addition, Mozilla's page about SRI doesn't mention the ability for an HTTPS document to use SRI to verify cleartext subresources in order to avoid restrictions imposed by browsers' Mixed Content and Secure Contexts policies. Nor does W3C's spec, though section 5.1 "Non-secure contexts remain non-secure" thereof (wisely) suggests not trusting SRI when the main document is cleartext.

Anyone who knows anything about TLS also knows about digital signatures and checkhashes.

What browsers will accept a cipher suite containing only key exchange and HMAC (the "digital signatures and checkhashes") without bulk encryption?

There's even a year-old W3C spec called Subresource Integrity that addresses this problem.

Even if it works for images, style sheets, and scripts, it won't work for the HTML document itself because it's subresource integrity, not mainresource integrity. In addition, Mozilla's page about SRI doesn't mention the ability for an HTTPS document to use SRI to verify cleartext subresources in order to avoid restrictions imposed by browsers' Mixed Content and Secure Contexts policies. Nor does W3C's spec, though section 5.1 "Non-secure contexts remain non-secure" thereof (wisely) suggests not trusting SRI when the main document is cleartext.

I can't find a language spec for "web technologies"

In the context of browser extensions, the relevant specs are ECMA-262, CSS, HTML Living Standard, and WebExtensions API.

http (IP on private network) = secure

How so? When your laptop or phone is on restaurant or public library Wi-Fi, you don't know who has 192.168.123.45. This is why the definition of a "potentially trustworthy origin" in the W3C candidate recommendation "Secure Contexts" includes localhost but not RFC 1918 private IP addresses.