The browser vendors could start taking the idea of asking for permission seriously.
For WebRTC, browsers could block local addresses. uBlock Origin can do this on Firefox already.
For battery: browsers could treat it like location and ask for permission. Why does the average site need to know my battery status?
For fonts: browsers could standardize a list of system fonts available on each platform. It's 2016 already: web fonts are here, are widely supported, and no legitimate website should be relying on some oddball manually installed font.
This problem is hard to solve, but the Tor browser has it mostly solved. Other browsers could learn from it.
> browsers could standardize a list of system fonts available on each platform.
It would probably make sense to completely disable support for local fonts unless permitted by the user (for legacy websites that depend on it). All modern browsers support @font-face, and without @font-face you can always depend on the special keywords serif, sans-serif, and monospace; these will load the system's default font for that category.
I hope there is another way to solve it, as I have installed web-fonts to my PC to improve page loading speed for some common fonts I keep seeing (the most recent being the Roboto font stack from google).
It would be a shame to have to keep re-downloading that every time.
You don't have to. Fonts should be (and usually are) offered to the web browser with the instruction to cache them indefinitely. You will only have to re-download them when your cache is cleaned up (due to its size, private browsing, or manually cleaning it). Upcoming technology WOFF2 helps further compress them by a significant margin as well (I've seen up to 50% improvement in size over plain WOFF).
The problem is that the behaviour you are describing is also one of the ways a fingerprinter gets its data on your fonts; by specifying an @font-face declaration that first tries for a local font, and only loads a remote font if that is not found. Do this for a short-list of popular but distinct fonts (such as Roboto), and you have a nice amount of bits of identifying data to add to the stack.
Also, tricks like these exist (using rendering metrics to detect fonts):
Browser caches are extremely unreliable and pretty small in the grand scheme of things.
On some mobile platforms the browser cache can be replaced entirely by some heavy pages!
Plus, even if we assumed "cached forever" actually worked for a significant amount of time, it still doesn't solve the problem that I am hoping to solve. I know many websites use the Roboto font. By installing it I no longer need to ever download that font again. It doesn't matter if it's the first time i'm seeing the site, if they use a CDN, if they link to the bold/light/regular version or their own packed font, etc...
I understand that it's a privacy issue, but I'm hoping there is a way to solve that privacy issue without removing that feature.
I would go further and disable remote fonts as well since it's not crucial like images and is an attack vector that should have been avoided. The better solution would have been a shared set of web fonts distributed with browsers, just like certificates.
Fonts are different in that they're not as crucial to the content as images. You cannot replace an image with an alternative text form while retaining the content, but you can display the content completely with WOFF missing.
I think the logical conclusion of that argument is to also disable all CSS. Fonts are styling for text, CSS is styling for markup. I think most the arguments against disabling CSS can be used against disabling fonts (barring that people do crazy shit with CSS most often now, so it complicates the issue).
Really, in the end, all input accepted from the remote side (including text/html) needs to be vetted and processed by security conscious routines. I don't personally have a reason to assume a font library is more likely to be exploitable than an HTML+CSS parser and layout engine. Based on complexity, I would actually assume the opposite, which is probably right, except we've already found and fixed a lot of the exploits for the HTML parser and layout engine.
I've considered what might be necessary to dispose of server-side CSS.
A set of standard page templates could do it. Clients could then choose their preferred client-side CSS to apply. Article, index page, image gallery, catalog entry, search result, etc.
Seems a finite set should cover most needs. Which ought be available from a few fairly standard sources (CMS, blogging engines, frameworks).
As I see it, the web is the most vibrant medium of expression and innovation we have today. While I don't doubt there would be gains in security to limiting it in many aspects, I question whether the specific level of security gain would be worth the loss of innovation and expression. I think there are many areas we could focus on instead that would increase security without the same level of negative consequences, so I espouse doing those first.
Not to mention I don't think it's a solution that's viable given economic principle and how much people value expression. We'd just be back to the equivalent of Flash sites again, with whatever takes over for flash (canvas?).
It's not just security, the other half is usability. The way popular web sites work is that they change stuff around regularly only to make it look different but change the behavior as well. This breaks stuff like existing functionality, key+mouse sequences to get stuff done, places you've learned to look at and navigate to quickly. Computers and modern appliances (including cars) are strangely affected by this constant desire to shift things around unnecessarily because someone told them they could sell it as it looks different now.
GitHub and gmail are prime examples for sites that broke a lot of things in the process.
Maybe what we need instead are real APIs and custom clients.
Consider the implications of what this means though. If sites are not free to innovate, things like Github and Gmail wouldn't exist. They only reason we aren't stuck with a Hotmail interface circa 2002 is because people were able to innovate on the web. To lock down CSS (or Javascript, there's no reason I can think of you would lock CSS and not Javascript) to a specific set of capabilities is both a statement that it is sufficient for all needs, and that we can decide by committee what is a good set of standards to lock into. I think both assertions are laughable false.
If we had locked down CSS five years ago, what CSS would be not be capable of using today? If we lock it down today, what would we be missing out on that would come five years from now?
Design by committee is horribly inefficient, and rarely takes into consideration the full needs of the users. What's more, it can't take into consideration future needs. Design by committee gets us XML. Adoption by iteration and evolution gets us JSON. XML has its place, but JSON is overwhelmingly more popular in certain contexts for a reason, it fits the domain better.
Lastly, iterating on Github and Gmail would not stop even if there was a complete lack of CSS and Javascript, it would just be more tedious as everything was done through a full page serve, just like the old days. That wouldn't prevent site redesigns along with missing or broken features, it would just make everything look shittier, perform slower, and use more server side resources.
That said, a sane standard for embedded interfaces, where choice is restricted, it needs to live a long time, and needs to have sane accessibility features would do well with better standards. I view that as a separate problem.
The fact of standard templates needn't prevent the possibility of novel templates. But it ought make the prospect slightly more user-controllable. Design-by-committee isn't the alternative to design-by-fuckwits, the present mode.
Github and Gmail are both tools which now face the dilemma of gratuitous changes -- many of the recent innovations haven't done much for usability, for numerous reasons (familiarity itself is a key factor, GUI offers limited capacity for improved functionality, jwz has commented on this from his Mozilla experiences).
But most changes to default styles are pants.
Hell, much the problem is that default styles are pants. If browsers had a set of presentation styles that did work well (see the "readability" modes offered by Safari, Firefox, Readability, Pocket, Instapaper, etc.), then we'd have slightly less a problem.
Github, Gmail, Google Maps, etc., are largely the exception to long-form informational content pages. I'm OK with an explicit "app mode" for such sites. But 99.999999% of what I read would do vastly better with uniform presentation.
More attention to content and semantic construction. Less to layout frippery.
> The fact of standard templates needn't prevent the possibility of novel templates.
If your stance is "provide well established default templates, but don't enforce their use", then I have no disagreement. That's not how I interpreted "I've considered what might be necessary to dispose of server-side CSS."
> Github, Gmail, Google Maps, etc., are largely the exception to long-form informational content pages. I'm OK with an explicit "app mode" for such sites. But 99.999999% of what I read would do vastly better with uniform presentation.
I think that depends heavily on what you use the web for. You and I likely read a lot on the web. Some people might stick largely to Facebook and Gmail. There are people that spend a lot of time in Github, and others that spend very little. Some people use a lot of online organizational and collaboration tools, others none.
> More attention to content and semantic construction. Less to layout frippery.
What you call layout frippery, someone else desires. This sounds suspiciously like remaking the web for your use cases, not for general use cases (which are always changing). But I'm not sure there's even a problem to address, you already addressed through referencing "readability modes" as an example of presentation styles that do work well. Why isn't that your solution to this perceived problem?
It feels like you're trying to achieve the equivalent of forcing all the printers to agree to not print magazines that don't conform to someone's opinion of what a good magazine is. I'm just not sure why that's even desirable.
> Something tells me you'll not be convinced.
No, not yet, if I understand your position correctly.
Defaulting to standard formats, and, on the basis of improved semantic parsing and ranking, promoting them through higher Search rankings (ceterus paribus) would be a Good Thing.
Among the problems of present Web design is that the Web is an error condition (there's a wonderful essay exploring this), and browsers default to allowing broken behavior, even adapting themselves to it, explicitly.
The lack of a publishing gateway, even a minimal one which enforces markup correctness to the Web is a problem.
Layout frippery as pertains textual content has a rather well-supported basis. Complexity is the enemy of reliability, and more complex layouts offer far more ways for sites to break. That's a well-established fact that successive generations eventual learn (or fail to learn) at their peril.
(The phrase "Complexity is the enemy" itself dates to the 1950s. I'd have to check the year, but have remarked on it before. Source is The Economist newspaper.)
I've seen what happens when documents and other media are aimed at very specific readers. Eventually, they rot.
Bog-standard HTML (or some alternative markup -- I'm increasingly partial to LaTeX) tends, strongly, to avoid this.
You're also going back to ignoring points raised earlier in this conversation about security, privacy, and usability.
And yes, if there's a call for an app-based runtime environment, which Google seem quite bent on producing, well, that's a thing. But no need to fuck up the game for the rest of us.
And models which prove useful could and should be incorporated.
I'm pretty gobstopped, for example, that 25 years after its introduction there's no affordance in HTML for notes (e.g., footnotes, endnotes, sidenotes, as presentation is a client issue), or for hierarchical presentation, e.g., of comments threads.
On can create nested hierarchies, but one with an integrated expand/collapse/sort/filter functionality doesn't exist. This was extant in Usenet newsreaders and mail clients 20 years ago. Why not the Web?
I don't really have any issue with most of what you are saying, except "The lack of a publishing gateway, even a minimal one which enforces markup correctness to the Web is a problem.", and my issue with that really depends on how what you mean by "problem". Sure, a publishing gateway would enforce some conformity, and some level of conformity is beneficial (I'll even allow that more conformity than we currently have would be beneficial), but too much conformity is not. Too much conformity breeds stagnation. So i'll re-frame my stance: How do you enforce or encourage conformity without going to far? How do you keep the entity or entities you've entrusted this task to from going to far?
> You're also going back to ignoring points raised earlier in this conversation about security, privacy, and usability.
I was just working off your points, which all seemed to be about usability. I've been treating this discussion as somewhat distinct from that one. I can definitely make arguments about conformity having it's own negative aspects with regard to security.
We can begin by actually reviving browser user style sheets and having a well known and respected sets of names will allow for appropriate styling on the client.
I'm all for user style sheets, I see no problem in people overriding site defaults. Re: sites breaking existing functionality while changing, maybe I just don't see big regressions as having happened in Gmail (which I always have open) or Github (which I rarely have open, as my source is in a local repo, but I visit on a regular basis from links here and elsewhere). It is interesting that you mention keyboard mouse combos, when to my knowledge both sites have put specific effort into making keyboard shortcuts that work and allow some level of navigation without any mouse.
I have to use Gmail in static HTML mode so that it doesn't try to reinvent and fail at a text edit control for composing a mail.
GitHub has been, like Twitter, grabbing more key bindings that existed before in a web browser like Ctrl-K and their comment edit box got limited in its resizability, forcing me to edit outside the website and paste into it often enough that it's an annoyance.
> I have to use Gmail in static HTML mode so that it doesn't try to reinvent and fail at a text edit control for composing a mail.
I'm not really sure what you are referring to here. Gmail does attempt to give you an editor for emails, but it's extremely simple in my experience to get it to do what you want most the time. If your complaint is that you want it to just send a text email, and not a multi-part with a plain text version and an HTML version, in which case I have to question why, as all it does it add choice and allow people to view it in the format they prefer, and it should look the same either way.
> grabbing more key bindings that existed before in a web browser like Ctrl-K and their comment edit box got limited in its resizability
Re: key binding, yeah, I can see that as somewhat annoying. I suspect they are trying to match some standard usability map and thinking of their site as an application, but it's annoying that it interferes with the browser (but only when within a text input, from what I can tell).
To some degree, I have to agree with what's probably Github's stance, which is that it's their site, and while it may seem annoying in some respects, they may have specific reasons they do things. They obviously aren't going to be able to make every change something everyone likes, but I don't necessarily think they are making change for change's sake. It's likely in response to pressure from gitlab and competitors. Presumably they are audience testing. The best way you can speak to this is to not use them when possible, or urge others to not use them.
Re Gmail: the bug is that they replaced the browser text box edit control with their homegrown JavaScript solution which does not work at all. Copy/Past, scrolling, and many other features are broken with it. On top of that, you cannot resize it.
Re Github:
The big issue is that they start hijacking keys that were free before. It's hard to impossible to sway developers to use anything but Github. I've tried and been treated as if I'm in the luddite camp.
> homegrown JavaScript solution which does not work at all. Copy/Past, scrolling, and many other features are broken with it.
These all just work for me. I'm not sure what the specific complaints are, maybe it's a Firefox thing, but it's not like there's a lot in chrome that FF doesn't support.
> On top of that, you cannot resize it.
A little convoluted, but there is a way. In the subject of the thread, to the right, along with the collaps all control, there's the option to open the thread in a new window. This window can be resized, and since the input is the size of the window. Although, I suspect Gmail is meant to be viewed as more of an app than a site, so if the window size is not just about composing, but use, it might be worth using it as a freestanding browser window, distinct from and sized differently than other tabs, if you aren't already. I might actually play around with doing that not that I've said it.
> Re Github: The big issue is that they start hijacking keys that were free before. It's hard to impossible to sway developers to use anything but Github. I've tried and been treated as if I'm in the luddite camp.
Yeah, that's unfortunate, and I would have hoped Github would do better. I don't really think it's the norm though.
As cm3 notes, usability is as much if not more a concern than privacy and security. Though I'd not dislodge any of these three from a position of high primacy.
There's a risk / frequency trade off with all of these. Privacy can be quite possibly costly or fatal, though slightly more rare. Not so rare though that 20% of all Web users in a US Department of Commerce survey (see my recent comments history) report known credit card fraud. That's many tens of millions of affected users.
The security risks are similar but also extend to organisations which might stand to lose control over their own (validly) private information, or control over systems (see for example concerns over SCADA infrastructure, or industrial process control).
Usability and adaptability issues pose lower risks, but have a much larger affected field.
It goes well beyond the visually disabled, illiterate, and cognitively challenged. Anyone who's landed on a desktop site that's unusable on mobile has encountered a usability challenge. Google, Apple, Facebook, and Amazon are all rapidly pushing us, some kicking and screaming (I include myself) to an audible Web -- one in which the primary control and response interfaces are spoken.
What landing on a small set of templates does is provide for clearly parseable and understandable content. In a world where the goal isn't to read a full page but to extract and convey a useful item of information from it, wading verbally through megabytes of unparsable and nonexcludable content isn't particularly useful (and yes, figuring out how much a data reference is worth to the data-rerference intermediary is another question worth considering).
More generally, in my case, with only modest perceptual impairments (reading small, low-contrast type is among the earlier signs of your impending death), I've come to conclude for some years now that Web design isn't the solution, Web design is the problem. There are only so many ways you can present content that doesn't fuck with readability. I try, very hard, to ensure I'm not doing this on my own modest designs (look up "Edward Morbius's Motherfucking Web Page", a riff on a popular refrain, for my own principals in action).
My most common response when landing on a website is to sigh, roll my eyes, and dump it to something more readable. Firefox's Reader Mode. Pocket. Straight ASCII text. w3m.
And no, "novel graphic design" isn't conveying vast new amounts of information. I grew tired of hearing that argument 30 years ago, it's not got fresher since. Bloomberg, The New York Times, and the BBD are all experimenting with high-concept article formatting. In my experienct, without exception, it simply Gets In The Fucking Way.
My half-serious response to this is to create a new web browser embodying these and a few other principles. The working title is "the fuck your web design browser". FYWD for short.
Ninnies may opt to call it the Fine Young Western Dinosaurs browser as an alternative.
> My most common response when landing on a website is to sigh, roll my eyes, and dump it to something more readable. Firefox's Reader Mode. Pocket. Straight ASCII text. w3m.
> My half-serious response to this is to create a new web browser embodying these and a few other principles.
In all seriousness, I wonder if spoofing a mobile client (easily done through most browser developer console's or an extension) might immediately result in a more useful experience for you on the majority of sites. Given the viewing constraints of most mobile platforms, and the focus on mobile accessibility (it's supposed to account for over 50% of traffic now), I imagine many sites try to but some minimum level of effort in to at least make it usable.
The majority of my browsing is mobile these days. 10" tablet.
Even sites which are otherwise well-designed (Aeon and Medium come to mind) insist on dark-pattern behavior such as fixed headers/footers. Again: straight to reader-mode for that.
(Screenshots contrasting site and a Reader Mode session included.)
I've written directly with the site designer who seems utterly insensate to why 14pt font isn't in fact a majickal solution to all readability problems.
Really? That seems unlikely. I mostly see people use phones, and small tables, so <= 7".
> Except for the sites which break that. Violet Blue's Peerlyst comes to mind
There will always be someone thwarting best practices, just as there will always be those that skirt or break the rules in systems that are less lenient. There's not a lot of recourse, you want what they've got, so you are at their whim unless you can work around their imposed difficulties or find another source.
> I've written directly with the site designer who seems utterly insensate to why 14pt font isn't in fact a majickal solution to all readability problems.
See above :/
> HN itself is only barely usable.
Yeah, but I think the reasoning behind HN is slightly different. I suspect HN assumes you will takes some appropriate steps to optimize your use of the platform. Instead of "we will tailor the view to our artistic vision and you shall not besmirch it!" it's more of a "we believe in user agency, so get off your ass and make it better for yourself." Depending on your point of view, skill level, and site usage, you might find one more appealing than the other.
Personally, I use one of the browser extensions that allows collapsible comments, inline replying, and user info on hover over username.
> Really? That seems unlikely. I mostly see people use phones, and small tables, so <= 7".
Ignore that, I misread the sentence. I thought you were saying most mobile browsing is with a 10" tablet. I'm not trying to tell you that you're wrong about your own reported habits...
Mozilla's replacement to the Gecko engine that run's Firefox, written in rust. Often covered here[1], the benchmarks look really promising. Small portions of the codebase are already trickling back to FF where applicable.
The complexity and size of a modern web browser and the need to better engineering tools to combat this are often touted as some of the reasoning the Rust project started.
> Why does the average site need to know my battery status?
I would go further and suggest that really no site needs to know it (I am sure there could be a few reasonable uses, but still). Which makes me wonder if we could strike back by abusing the WebRTC spec and fuzzing values like these, instead of simply blocking them.
Exactly - most sites don't need my exact location, or access to WebAudio or whatever. It should be a red flag for most sites, however most users won't know how to react in such a situation.
I'm not familiar with WebRTC. What's the use case there? I can't remember ever wanting to create an in-browser p2p connection on my local network. What would it be used for?
But it still ignores the proxy settings and will use STUN to discover your "external IP". Thus users that think they are using a proxy end up not actually doing so.
in-company hangouts, video conferencing, etc. Without p2p on local network that would have go outside the company and back in.
Others have pointed out this behavior has changed in Chrome 48. You don't get the local IP unless the page asks for access to the mic/camera which the user has to give permission for.
For WebRTC, browsers could block local addresses. uBlock Origin can do this on Firefox already.
For battery: browsers could treat it like location and ask for permission. Why does the average site need to know my battery status?
For fonts: browsers could standardize a list of system fonts available on each platform. It's 2016 already: web fonts are here, are widely supported, and no legitimate website should be relying on some oddball manually installed font.
This problem is hard to solve, but the Tor browser has it mostly solved. Other browsers could learn from it.