83% of browser features are used by under 1% of top websites(theregister.co.uk) |
83% of browser features are used by under 1% of top websites(theregister.co.uk) |
Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps.
- Sites: HTML + CSS, Javascript if at all only for presentation purposes (like DHTML over a decade ago). Can be viewed with a radically stripped-down web browser. All you need is the layout engine and components for display and networking. No WebGL, no sound API, and no shenanigans like ambient light sensors or vibration (wtf!). Think of Google's AMP.
- Apps: The whole package that is offered nowadays. We can even go past this and rethink the division between web and native apps. Why can't a web app use sockets? Why can't a native app use the HTML layout engine or live in a tab? Google is planning to blur the gap between web and native with their new "instant apps".
Whichever side you're on, browser vs. native, the sheer frequency of this discussion proves that at least a clear distinction IS needed. Continuing the status quo of web/browser/standards bloat cannot be good.
Somebody really needs to set down some global rules of thumb. I think that when your webpage starts needing sidebars and subwindows and popups and notifications (yes, looking at you, Facebook) then at that point it should just be a native app.
Let the web and its browsers focus on "sites" and "pages" and let the OS do "apps." After that it's up to the operating systems to make discovering and accessing apps as easy as typing in a website's address.
As a user, I want to sign in just once on each of my devices (iCloud/Apple ID lets me do that), and just type in an app's name (say Cmd+Space and "facebook") and then start using it right away as the OS begins downloading it incrementally, just as a browser does a website, except with full access to the OS's features, efficient use of my hardware and battery, and instant access to all my data without a separate login.
[1] https://news.ycombinator.com/item?id=11735770
One problem is that some interactive news articles can make very impressive use of WebGL, like the interactive climbing map that accompanied an article about the Dawn Wall freeclimbing record: http://www.nytimes.com/interactive/2015/01/09/sports/the-daw...
Like Lynx?
In terms of sites versus apps, I think the browser vendors are responsible for making this happen. Adobe AIR was the closest effort I saw of marrying web technologies with apps.
Sadly AIR never took off and whilst I appreciate the intention, it left a huge looming question of what do we actually do with all this new web technology?.
One answer I came up with in recent years was what you suggested: of partitioning off the people who want to work with the technologies and keep them separate from the text+image+CSS based web we've all grown to love.
Similar to how the demo-scene was an offshoot of game development...
So we're mostly lacking the site-only aspect. To some extent that can be achieved with addons that strip or block certain APIs.
It doesn't cost anything to keep these features around, why kill them off? Code is cheap, it doesn't cost you, the user, anything to have the features in your browser...
It is a nice study showing how far these niche new features have reached, but that shouldn't affect how we are working on the new ones (except perhaps improving the security models of these).
I wouldn't necessarily agree that the conclusion is to just rip stuff out of the Web platform, though (although there is plenty of stuff I'd love to drop). Rather, we need to implement the features in a secure way. This isn't rocket science. Notice, as usual, that the majority of these security issues are straightforward memory safety issues† in C++: e.g. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+svg
† Food for thought for those claiming that "modern C++" solves these problems.
Around a billion.
1% would mean 10 million websites are using each possible feature. Okay, it's not quite that even, and a lot of popular sites (like many news sites) stick to the most basic features, but all these browser features are there for the other various cases. Like aforementioned web apps. Various tech demos. Sites with very specific use cases.
In other words, it's because the internet is massive and varied.
99% of the world doesn't use Calculus. Maybe we should stop teaching it in school.
Lame article.
It reminds me of Sturgeon's law https://en.wikipedia.org/wiki/Sturgeon's_law
If 99% of everything is crap, you can bet a sizeable wager the 1% wheat from the chaff are using HTML5 and Javascript APIs.
Also if a content silo counts as a 'top website' then this is an outlier and not to be included. Facebook is a walled garden and not indexable. Facebook is parasitical to the web. Twitter and Google are not the web either.
The hard part of any design is knowing what features can be removed not added. HTML 5 and JavaScript is fluff for most websites.
PS: HN even uses <table id="hnmain"... o the horror.
Yeah but HN can be progressively enhanced and it's also one of the few exceptions to the rule.
<table id="hnmain"..
Worth noting the small eco-system of HN redesigns which all leverage HTML5+JS in some way :)
All sites should be like an electric stairs: the stairs still works when the power is cut off, but to the inconvenience of the users.
I mean, a similar study would probably find "top 10,000 apps don't use 80% of OS features." Just because not a lot of people use a feature doesn't mean it shouldn't exist.
Can someone give me a good, non-gimmicky example of what this would be used for?
A great example that comes to mind is the drm component that Netflix require to deliver html5 instead of that spotlight .. thing. I cannot think of any other site that has needed it - or at least, any other site I visited before it was available, that suffered for it.
And still, I consider it a requirement. That feature that I require for exactly one site.
In other words, its how often these popular blocking extensions prevent the JS APIs from firing.
Its not blocking SVG, its blocking (mostly fingerprinting) JS libraries from running SVG JS methods
So its not that extensions block SVG directly, its that AdBlock Plus and Ghostery block a bunch of libraries, and those libraries use the SVG methods to finger print (and do other stuff)
Obviously, we could prune the execution of some of the JS which is backwards compatible to the early 90s, and some of the html which is based on IBMs 1960s.
My super high-level first pass optimization rec for the w3c: If a feature exists for 3 years and a random sampling of 100,000 websites has usage stats of less than < 1% it is automatically deprecated. If it is >1% but less than 5%, it is automatically phased out in 2 years of the spec.
There's some good reasons to want this, in fact.
>It doesn't cost anything to keep these features around, why kill them off?
This is also why the features list of a basic Windows or Office install is miles long. Once developed, there's no cost other than maintenance of those features (updates, security, etc).
I think its hard to argue against complexity in software. The ultra-complex usually win for rational market reasons.
Most speculatively, imaging the environment with compressive imaging[1]. One might be able to flash some patterns on the screen and look at light sensor output to take a picture.
Giving web browsers access to sensors on our devices is sort of scary.
[0] http://arstechnica.com/tech-policy/2015/11/beware-of-ads-tha... [1] http://arxiv.org/pdf/1305.7181.pdf
If we stopped adding new capabilities to JavaScript even as new sensors and w/e go mainstream we'd start needing Flash all over again.
Not saying it's the most important case ever, but it would be important if you needed it
[0] NaN === NaN returns false?. 0.0001 + 0.0002 !== 0.0003? weird.
NaN means "no idea what we've got here". When you get to say that phrase, would you expect it to be used for exactly one thing and one thing only? To me "I have no idea" means the possibilities are endless (infinite). We can only compare for equality when we know what we are looking at, otherwise it's just "status unknown". Yes, it might be equality - the chances are infinitely small though.
If you take the argument a step further and say "but I got the two NaNs that I compare doing the exact same operation, so even if I don't know what I've got from a mathematical point of view whatever it is it should be equal". In that case you are not actually comparing the NaNs but the path(s) that got you there.
I must say I find the whole NaN, null, 0 vs. undefined interesting on so many levels. There is a world of a difference between knowing you've got nothing (null or 0) and not knowing what've you've got at all.
"null": I have no bank account. "0": my balance is 0. "undefined" or "NaN": I lost my memory after yesterdays binge drinking and don't know who I am and if I got a bank account or not. Knowledge vs. no knowledge.
I cannot support this.
> ... even though fairly close to Gecko-based browsers like Mozilla Firefox in the way it works, is based on a different layout engine and offers a different set of features. It aims to provide close adherence to official web standards and specifications in its implementation (with minimal compromise), and purposefully excludes a number of features to strike a balance between general use, performance, and technical advancements on the Web.
[0] https://thestack.com/security/2016/02/03/chromodo-browser-di...
Reminder that we've been issuing so many CVEs last year we had to upgrade the numbering spec to allow for more than ten thousand a year.
Edit: those were meant to be satirical, but apparently exist.
2. We are not talking about experimentation, we are talking about deployment into production.
The joke was, of course, surrounding the Mozilla incedent where Brendan Eich stepped down from his position as CEO apparently because of a perception that he was promoting inequality. This characterization was due to his support of prop 8 (a bill about marriage equality, or lake there of).
To completely ruin the joke's punchline[1], was that the "problems he had with equality" were actually his understanding of types and language development and are evident in javascript.
Of course that is untrue, was a joke, and Brendan Eich is a legendary programmer whose contributions I am grateful for.
[1] Joke's punchline could be ruined by it being both a bad joke needing an explanation, being in poor taste, and generally just not being a funny joke.
I thought it was damn funny. There was definitely an unintended outburst at my desk.
But then...... I also thought it was spectacularly hypocritical of Mozilla to fire him for having what amounted to... ideals. Which is what Mozilla supposedly works to protect.
They didn't fire him for having ideals. One, because they didn't fire him, and, more significantly, because the problem was not him having ideal, but him being unable to determine or unwilling to take the steps necessary to effectively manage a major PR incident affecting Mozilla's relationship with users, employees, and other important stakeholders. (Or, given that he actually resigned, maybe he was quite able to determine and willing to take the necessary steps, but those steps were inconsistent with him remaining as CEO.)
1. Brave won't "sell ads", that's not how it works. Marketers buy space for ads and spend to create the ads themselves. Websites or publishers sell space for ads, sometimes directly to brands/agencies. If ads use no tracking and host the ads' images and other assets on a non-blocked domain, no problem.
2. Where we propose to do better is with "indirect" or programmatic ads. These are so out of control, publishers make money from them but disclaim responsibility when a piece of ransomware malvertisement places in the offered space. We aim to put tracker-free, sandboxed ads in these spaces and share revenue (equal shares to the user and to Brave: 15%) with the bulk of the revenue (55% direct, 70% in total per the default settings) to the website.
We're thus working to align incentives in the system that currently work against the user's interest.
We also support pure ad/tracker blocking, if you prefer.
On top of either mode, we're buildling an anonymous system for micropayments as well as aggregated ad metrics, so no one can re-identify a Brave user from a revenue stream.
Of course, we're not yet doing anything more than blocking all third party / indirect ads and trackers. To get better user-aligned revenue models in place, we'll need to scale up and win over some top publishers for trial/testing purposes.
So if you want the fastest (native code wins in perf and mem use) browser that blocks ads by default, I hope you will give Brave a try.
Longer answer: we would be selling anonymous ad spaces based on matching tags (like standardized keywords) on-device/in-browser against a set of tags for ad deals whose buyers sign up to pay us only when those ads perform (have anonymously confirmed viewable impressions).
The tag matching is private -- no cookie or other identifier comes out of the device/browser, no tags out either.
The (few, three or four) tags for each ad space come from local inference, weak AI, running on-device. The goal of this AI is to work for you on your device, studying your data, to pick the best small set of tags for the ad space. Only a few, even just one, spaces per page might be filled. The ad serving is async as well as sandboxed, so it doesn't delay page load.
This private and device-local inference uses the sum of your browser state, which is a superset of what remote trackers see via cookies and fingerprinting. Think of tab opener relationships, absolute viewability/visibility, evolution from search and social interactions to browsing sites to buying. As with browser history, you can clear the summaries inferred from your data.
We are building cross-device, client-private-key-encrypted sync (as other browsers offer, although not always client-encrypted). To handle inevitable key loss, as with user multisig wallets, we will rely on a separate Key Recovery Service. So we won't have keys for your data or the results of inferences made from it. But you will have the benefit of inference studying all your browsing on all your devices, as they sync and the inference runs incrementally.
If we pull all of this off, we'll have built a private data platform where our users own their own data cross-device, along with valuable results from analyzing their data on their devices. Kind of an upside-down, individuated, private Google.
You're seeing movement toward "segment of one" marketing tech (companies who track you as an individual, across apps and even offline credit card purchases). These trackers may run afoul of regulators, as they zero in on PII.
We think Brave's way of defending your data on device is better: more precise and of course more private. Clustering among users and sync'ing with non-browser data can come later, and via ZKP protocols like the one we're using for the Brave Ledger (see https://brave.com/blogpost_3.html).
We also see IoT (home, car, internal/wearable computing) as a field in need of our "anti-cloud" approach. Of course backup is important, and some transacting with cloud services wins, but giving all your data away from the start puts you at a permanent disadvantage. It also accrues rising privacy and security risks.
Users won't get paid fairly for their attention and time (never mind their location and health data!) until they defend all such data from trackers. We're building a system for doing this, using a browser as first line of defense. (There will be other lines of defense.) Anonymous ads are just one way to get users their fair share.
Our principle of users getting their fair share means we take the same ad revenue cut as our users get, and pass the bulk on to the publisher or website (or account, if YouTube or the like). We'll follow this principle for other possible revenue including from search, if we can work that out.
Your data, on your devices, with a fair share to you, are key points of the brand value we hope to build.
The number of APIs available should be orthogonal to the issue of system performance. If it is not in particular cases, it's via bad overall system design, not the existence of the API in general.
Correct, however periodically adding features by committee and backwardly processing and parsing tags and internal api implementations that are unused certainly must hamper performance. To some extent, I would assume the v8 or chakraCore engines are developed around interpreting javascript which includes languages pieces that have developed because of its close ties with the dom. So between the underlying interpreter engines, and all of the parse tooling for dom rendering and tag identification and css applications, I can only assume if it had 80% less overhead to expect, it could be faster.
So to the point > The number of APIs available should be orthogonal to the issue of system performance. If it is not in particular cases, it's via bad overall system design, not the existence of the API in general.
That was the question I was asking.
1) is it possible to design a better system with many less considerations.
2) is it a bad overall design?
Again, I have to assume that if we raieded the codebase and rewrote it minus 80% of the legacy shit, we could do a better job, but maybe not.
But I think the more promising use for this could be enabling aesthetically pleasing color palettes that are power consumption optimized. Picture a HN that switches to darker tones of the current colors when you're on a mobile device.
It will ignore site-provided CSS.
Interested?
Honestly, I think Brave is good for everyone - including advertisers. There are interesting new patterns to develop here, I'd bet. With every change in tech comes new possibilities, Brave is opening the door to a lot of potentially new ideas/strategies here IMO.
The big problem is how much of the digital advertising "rent" goes to Google and Facebook alone, for so little. Perhaps 80% of 70B/year in the US alone. This will not continue. What's next? We have an idea.