I believe the GUI idea is still alive, but today it can be web-based. See 1010data.com.
1,160 karma · joined May 14, 2016
Whenever I have suggested on HN that there is such a thing as "finished" software that is free of serious bugs, I get some resistance. There is a consistent knee-jerk reaction citing the same tired, old meme, "All software has bugs", and "Software is never finished."
Sustrik's post proves I am not the only one perplexed by this strange belief that no software is ever finished.
IMO, it is not a question of being infallibile or being available to fix bugs. The point is that there are programs that are not continuously growing in size and complexity. They are not "dead". They are "finished".
As for OpenBSD, certainly some programs I would consider "finished" but overall the size of the kernel and base distribution are in fact growing. Not only new drivers, but new programs and new libraries continue to be added. More code means more probability for bugs and vulnerabilties.
Anyway, less code, more terse syntax means it can be easier to find problems. Not everyone will agree with this of course. But I agree with Whitney and others. Less code makes it easier for me.
With earlier versions, e.g. k2.8, there is a `show command to trigger a pop-up window that reminds me of Tcl/Tk, containing the values in editable fields.
The interpreter is terminal friendly and works without the GUI but it has no formatted output of tables in ASCII like in k4. x11 libraries are a dependency.
s/instead of/in addition to/
For example, DNSCurve-enabled nameservers are in the form key.name.tld, cjdns addresses have a key fingerprint embdedded in the users IPv6 address, etc.
Not only that, it is the only software I have ever seen that used a GUI and then ditched it in a subsequent version.
Few programs are so aligned with my own software sensibilities.
Only complaint is that they used to have a FreeBSD port and now only have Linux and macOS but no BSD.
Unfortunately Linux compat in BSD is being perceived by some as a potential security issue these days.
One of the top comments there suggested that the solution lies in relying on DNS which provides "globally unique" names.
But the commercial CA system already relies on domainnames. That is its weakpoint.
The author at ian.sh shows how additional checks by third party CAs, e.g., business registration, do not necessarily solve the problem either.
The best proposals I have seen for solving the problem are ones that have no reliance on third parties, e.g. certificate vendors, domainname vendors, etc. Another way to think of non-reliance on third parties is "middlemen". If they are necessary, then the system is vulnerable.
It is a very old problem that apparently has never been fixed. Today solutions that try to avoid middlemen do exist. But comprehension of why this is necessary is apparently still small-scale because focus remains on the commercial CA business, which seems to be at odds with any system that needs no such middlemen.
This author, who many HN readers know, explains it much better than I can: http://sprunge.us/NHTK
Users or businesses can create and exchange their own public keys directly. (Think of HTTPS like SSH.) They do not have to rely on third parties to assist them.
One does not need a third party CA to perform effective encryption. Have you ever wondered if browser warnings are an insidious way to keep commercial CAs in business?
Public keys are globally unique. Names are not. One could combine them (e.g. key fingerprint plus name) to form an identifier that is better than a name alone.
Recap:
Names alone are not enough to perform effective disambiguation via ICANN DNS or major-browser sponsored CA system. Volunteer-supported Wikipedia actually does a better job of disambiguating names than these commercial services.
Public keys can be generated directly by the named entity they represent instead of by third parties. Middlemen are unnecessary and cause the system to be vulnerable.
The reason I asked is because forums.aws.amazon.com redirects to signin.aws.amazon.com, and generates some faked up OAuth credentials.
root.zone data is reasonably static. Having a local copy of this data, resolution can be done in two queries: 1. tld ns 2. auth ns, which is the case for many, many www domainnames (the majority, perhaps), or even one query (I think some .mil domains used to be a well-known example). As a user, I view every added query as an additional cost.
It is possible to minimize queries via other means that are under user control and do not rely on third parties.
Running a root locally. Custom stub resolvers with tld ns IPs compiled in. Storing RRs for common nameservers in local zone. Storing DNS data in bulk for important sites that will be revisited, copying to HOSTS and updating the data periodically. I have been using techniques like these for many years. And, it is getting easier every year as more bulk DNS data is available, e.g., internet scans of DNS, TCP DNS services that accept pipelined queries, etc. (If I am not mistaken, the author of the "qname minimisation" draft also was the one with the "DNS looking glass" idea.)
https://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisat...
Despite usual mailing list/forum comment/blog memes and mantras, if one surveys all websites (not just popular ones), DNS data is mostly static. That provides great opportunities for speedups by avoiding querying ICANN DNS for the same data 24/7/365. Cue Schopenhauer quote about truth. Someday maybe we will see an internet draft about "DNS minimization" for users.
Did AWS forums start requiring an account for read access?
Here are some other HTTPS-enabled search engines to test. If I am not mistaken all have been mentioned on HN in the past.
https://wiby.me
https://gigablast.com
https://mojeek.com
https://unbubble.eu
https://ecosia.org
https://searx.me
https://symbolhound.com
https://findx.coms/that goes viral before reaching \"proper\" channels//
The fact that the problems existed to begin with is more troubling than whether they became known outside the company or not. IMO.
With an open source UNIX-like OS (like the ones Apple sourced from for parts of macOS), both the developers and the users can watch the commits as they happen. Developers and users anywhere can choose to watch the commits and may be able to detect a series of poor quality ones. At least they can make informed decisions on the relative merits of changes from one version to the next. (Edit: They might choose not to compile or install certain components. I do not use X11. Nor do I use systemd.)
The fact that development of macOS is hidden from those outside Apple and that problems are protected from "going viral" does not make the problems any less of an issue for macOS users.
The issue is not how fast and secretively they fix problems, it is how many problems their developers are introducing into the existing version to begin with.
If there are problems routinely being introduced then no amount of fixing after the fact and behind the scenes is going to make the OS higher quality. Only due care taken before introducing changes will guard against further deterioration of quality level.
(Edit: The mention of open source is not intended to be interpreted as an argument that open source inherently results in better software. Perhaps skill and attention to detail are at cause. This is a debate worth avoiding.
The relevance of the mention of open source is intended to suggest that detecting and avoiding problematic software may be easier for some users, e.g. yours truly, if they can access the source code. As opposed to hoping that Acme Hardware and Software Corporation will quickly and secretly fix all software problems that slipped through their QC procedures. Too late for the user who has already paid for the software and updated to the new version. That argument should not be too controversial.)
Apparently Firefox 57 when it is installed tries to switch the users default search engine to Google.
Whether it asks for user permission to do so, I am not sure.
Do the terms of the deal actually require them to do this?
[ ] True [x] False
First, is it the OS that distrusts certificates, or is it the HTTP client?
Second, CA certificates such as the ones trusted by HTTP clients (contained in "browsers") are self-signed certificates.
Pre-installed CA certificates in corporate HTTP clients (e.g., Chrome, etc.) and CA certificates in downloadbale "bundles" available from corporations (e.g., Mozilla) are self-signed.
When someone buys an iPhone, there is an expectation that an ongoing relationship with the company is created. It is assumed every purchaser wants to use Apple's time servers, Apple's messaging service, Apple's cloud storage, Apple's software review process, etc. and there is no opt-out. Consequently the purchaser is expected to establish a means to identify themselves to the company (AppleID) in the future. Fingerprints may be collected, facial recognition, etc. Apple has the means to know its hardware customers, very well. It does not really feel like we own the hardware. More like a lease or rental. Feels like we are being used as a source of further revenue generation. A massive user base tethered to the company that it can use as a bargaining chip to make deals with other companies.
Here is a different approach. Imagine you have two mobile devices. 1. An iPhone. 2. A portable computer running an open source OS that can act as firewall, authoritative DNS server and/or gateway. Apple has no control over #2. #1 can only access the internet through #2. #2 belongs solely to the user and it is controlled by the user, not any company. Perhaps one day we will see Apple controlling the user's routing table and any network settings entered by the user will be subservient to Apple's.
Written comments require submission of four copies and must include a contact address. All must have original signatures.
Should the FCC give more weight to written submissions than to electronically-submitted comments?
Will the FCC contact the submitters for permission to use their comments in the decision-making process?
I know that e.g. in some smaller democratic governments, legislatures accepting written submissions from the public will contact the submitters to obtain permission to use the comments, regardless of whether the legislative committees use them or not.
This could function to some extent as a verification of identity.
Can we challenge the FCC's electronic comments submission system as fundamentally flawed?
Due to numerous data breaches, there is significant, known availability of personally identifiable information on US citizens available to anyone, anywhere in the world with an internet connection.
Can FCC ignore this and provide a comment submission system that performs no meaningful checks on identity of commenters?
Wish we could modify settings such as "use_backend", "backend" and "server" the same way.
Maybe there is a workaround.
Further, I do not think of browsers in terms of "market share" nor testing for one browser or another. I guess I have done a poor job explaining the point about standards.
Testing input, e.g. a webpage, against a program, e.g. a browser, is backwards, IMO. A program should be tested against input. If the program fails given legal input, then if desired, fix the program.
The web contains plenty of legal input for a wide variety of clients. I am consuming it everyday.
This plain fact appears to be outside of Mozilla's purview. But to me, a user, this is what the "open web" means, much more so than a squabble between Mozilla developers working on Firefox and former Mozilla developers working on Chrome over some exotic feature to entice web developers.
The "open" web to me means I can retrieve information with a simple open source client I can compile, and without an overly complex web browser controlled by a corporation/organization that is by its complex nature unreasonably difficult to compile except for a select few people. That is not "open" within the meaning I subscribe to, which is more along the lines of "accessible".
The more complex the browser becomes and thus the more complex the input that web developers create for it, the less "open" the web becomes, because it becomes less accessible.
I do not expect anyone to agree with me, but I at least hope that these points make some sense.
I believe you. Do they want to take action to address it?
"The problem is that if the open Web platform does not expand to meet the needs of modern applications, then modern applications will simply be restricted to single-vendor platforms like iOS, Android and Windows, and over time the relevance of the open Web will atrophy. That is not an acceptable outcome for Mozilla."
I understand. Why does the "open Web" need to stay relevant? Honest question. The answer to this question is really the core issue, IMO.
"If you can convince Web developers to build sites that work on cut-down browsers, great. I don't see any way to make that happen en masse though."
Not sure where the "en masse" part comes from. That was not in the original comment.
The comment was meant to draw attention to denial of choice in user agents given to users. The illusory scarcity of browsers that will "work". (Thus web developers design for browser implementations instead of according to open web standards, which should be implementation-agnostic. Browser developers are the ones who are seemingly in control of what is and what is not a "standard" in the mind of the web developer. Too often, companies are the ones writing the "open web" standards.)
I believe in the antithesis of the "en masse" notion.
That users do not need to converge en masse around a small selection of known, complex web browsers because most sites, e.g. those that simply present information, already "work" with cut-down browsers.
I use a non-graphical user agent. Most sites work fine for me. I get what I need. And this is without the web developer even contemplating the software I am using. To the extent they are following certain open standards for HTML, it all works anyway.
On the same day as the OP was posted, it shared the HN front page with a re-post of a 2012 ACM submission by PHK.
In this ACM submission, PHK describes building Firefox on FreeBSD.
He cites something like 122 dependencies, and a requirement for some binary to run plugins.
I have build Firefox on BSD myself using pkgsrc. It takes longer than building kernels.
Is there a "Firefox Lite" where a user can opt out of various features at build time?
Why not?
"FWIW Mozilla obtaining a monopoly would be inconsistent with their mission and I don't think actual Mozilla developers are aiming for that. Partly because it's not a realistic outcome!"
Nor am I suggesting that providing options to users should result in any "en masse" behaviour by users or web developers.
It is not a realistic outcome.
The goal of the experiment might be to provide some software to users that the market share leaders will not provide. Is this realistic? Mozilla has taken risks before. Not every project it has sponsored has attracted a mass following of users.
For example, imagine a version of Firefox that optionally has no Javascript engine. This software would be less complex (and intentionally less functional). But believe me, as a text-only browser user, it would still work.
If a user complains about a major browser as "bloated", if she complains about ads and is forced to use NoScript or an ad-blocker, if she is pondering how complexity makes her browser more vulnerable to attacks, then it would be interesting if there was another option she might try, which came from a well-known source such as Mozilla. She might build Firefox without the features that lead to these problems.
What happens after that is anyone's guess. As it is with any experimental Mozilla project.
But at least one can say that an option was presented to move away a state of from increasing complexity in addition to the option of using Mozilla's full-featured Firefox browser competes for market share with the other major browser vendors.
Internet commentators sometimes reference a quote from Steve Jobs something like: users do not know what they want (until Apple gives it to them).
While this may be self-evident to developers, I believe that users do know what they do not want. These are programs features, modifications and behaviours that users are familiar with because they have been using the software for years. Alas, rarely do developers of graphical programs give users the option to remove features. As such, we can only guess what might happen if they had that option.
A large portion of the web does "work" when using user-agents that lack the latest features. It also works with the recommended browsers. The question is whether Mozilla can acknowledge this is true and release software that takes advantage of it. Mozilla can still pursue its mission, including keeping up with the Joneses.
s/open source Linux computer/computer than can run Linux and other open source kernels/
https://mail-index.netbsd.org/port-arm/2017/10/23/msg004423....
Annual salaries from 2015 (reportable compensation from IRS Form 990):
Mitchell Baker, Chair $977,382 + $45,530
Bob Lisborne, Director $92,000
Mark Surman, Exec. Dir./President $170,699 + $40,602
Jim Cook, Treasurer $934,526 + $45,530
Angela Plohman, Secretary/VP Operations $121,322 + $30,342
Christopher Lawrence, VP Learning $153,492 + $62,538
An-Me Chung, Dir. Partnerships 154,946 + $72,672
Daniel Sinker, Dir. Partnerships 123,630 + $64,215
Hiram Paul Johnson, Marketing Lead 126,605 + 54, 903
Andrea Wood, Online Organizing/Fundraising Lead $135,048 + $46,322
Samuel Dyson, Director Hive Chicago $114,860 + $63,549
Perhaps the author is telling the truth. Consider the salary costs of retaining skilled "maintainers" like the above personnel.
Note I am not condemning Mozilla. They do good work.
However I am not quite sold on the idea that their purpose for existence is to "keep the web open" or whatever tagline they are going with.
For example, an "open" web would be one made for all browsers to access, not just a select few who have chosen to try to keep up with an arms race of recently-added, non-optional "features" that carry serious costs to users. The key word I wish to emphasize is "non-optional". Users are not given choice and that is most likely intentional.
Many a web developer presents the user with a small selection of "acceptable browsers", the ones that will run third party code and readily show heavy, third party advertising. Anything else is "prohibited" and must be a "bot". Users are sometimes even shamed for not using the web browser or version that the web developer wants them to use, calling the user's software "outdated" when they have almost no information about the user's software except its behavior and some easily forgeable HTTP headers. In many cases, e.g., where the user is just retrieving some information, that is just silly.
Not every website needs to show advertising. Not all information is commercial. Not all information is graphical. I am not using one of the select few targeted browsers to read HN or post this comment, but I am getting the same information as the readers who are. And for some reason(s), web developers flock to this "outdated" website. Why?
Clearly the web can be both accesible by simpler user agents, and fully-functional for the most bleeding-edge features of corporate-sponsored browsers at the same time. The original web standards, e.g. basic HTML, still work, very effectively. The web as a means to offer basic functionality such as HN can be "backwards compatible" with user agents that are far more simple than Firefox, Chromium, etc.
The select few browsers that many web developers target overwhelmingly controlled by corporations and other advertisers. Netscape and the idea of corporations paying to use a browser may exist only as entries in the historical record, but I do not think we can say that browsers are truly separated from corporate funding (and influence). Browsers are still commercial, in a sense, IMO. While it might be viewed as "free software", the authors of these few browsers are well-paid by their corporate (or "non-profit") employers and the end goal is "market share", ideally a monopoly.
This is fine if the web is 100% commercial. But it did not start that way and it still isn't 100% commercial. Non-commercial uses are still alive and well.
It is not necessarily Mozilla's fault for the direction the web moves in, e.g., making content less accessible by simpler user agents. However, if their purpose is to make the web "open" or some such "non-commercial" aim, then what could they do to enable and promote use of simpler user agents (and thereby promote their acceptability among web developers)? I can think of a few things. I am sure others could as well. There is no shortage of users who are dissatisfied with the (lack of) variety of user agents that are available.
http://bitcheese.net/web_browsers_must_die
The question is whether Mozilla really wants to listen to users who might criticize dismiss their browser as, e.g., too bloated.
I believe users place too much trust in corporations such as Apple, Google or Microsoft to protect them. There is too much debate over which company to choose ("I like ___________'s approach to security") instead of questioning whether delegating security to any of them is truly the wisest course of action.
I hope that this incident causes at least one user to question whether users might benefit from adopting a less trusting and more vigilant approach to protecting their data.
And by "vigilant" I do not mean "choosing the right tech companies to trust", diligently installing updates from these corporations and feeling self-satisfied.
I mean questioning the status quo and thinking seriously about the benefits of free, open source operating systems that are potentially reviewable by millions of developers and users. Systems that can be modified, compiled and installed easily by anyone, not only by small groups of people in corporations with special knowledge. Systems that can, e.g., permit and maybe encourage "safer", more conservative usage patterns.
Under the prevailing laws, I believe this pool of open source developers and users will always contain a larger number of people who care more about protecting user data than any groups within the above companies. It is a matter of self-interest.
Apple is a company with seemingly infinite resources at its disposal. But clearly in this case there were more people seriously interested in fixing this vulnerability outside of the company than within it. And as a dumb, naive user, I question anyone who would suggest that no one except a small group of people at Apple would be competent to do this work.
IMO, this mistake had nothing to do with what makes Apple valuable, namely their hardware. A UNIX-like OS running on Apple hardware does not need to be proprietary and, IMO, users have a compelling interest for software, that can expose their data and pose other security issues, to be open.
So what is the problem here?
How to "hide" private subdomains?
How to "securely" configure S3 buckets?
IMO, the problem is in the use of the CA system, where control over "names" (e.g. subdomains) is shared with third parties (certificate issuers) instead of being solely with the user who wants to reserve names.
It is possible to have a non-CA PKI system where the user controls both the issuance of the public key and the associated name she will use. In such a system, no third party has control over names. People learn the user's name and the user's key from the same source: the user.
Thus there is no issue of trust re: using third parties, and thus no need for monitoring what names the third parties are issuing, e.g. via "certificate transparency" logs. CT logs do not need to exist.
This is not a new idea and it has been proven to work. I can prepare a post with examples if anyone is interested.
And HIBP is an example of this attitude because it collects data dumps and then (at least) collects and retains user-submitted email addresses and a record of presence/absence of such "live" email addresses in the data dumps. This is beyond the scope of what is needed to provide the service, namely, copies of the data dumps available for download. The user need not share their search terms with any third party, such as HIBP. A means to search these dumps locally (offline) without sharing the searches with third parties such as HIBP exists. "Online tools" are vectors for gathering the sort of data that is later the subject of "data breaches". Offline tools do not suffer from this problem.
"6. Data breaches are redistributed extensively. There's an active trading scene exchanging data both for monetary gain and simply as a hobby; people collect (and thus replicate) breaches."
HIBP is collecting and thus replicating data breaches for "monetary gain" or "simply as a hobby"? Or is it something else?
As above, HIBP does not provide users with the data dumps they need to check them locally (offline) without submitting contributing more data to third parties in the process (e.g., working email addresses, associated search terms, associated originating IPs, etc.).
Further, users are not provided with transparency into what HIBP is doing i.e., what it is storing and how and where it is stored. Users cannot evaluate the security practices of HIBP as yet another online repository of sensitive user data that by virtue of its existence could be a target.
In summary, what he is not telling US Congress is that 1. "online services" or so-called "online tools", HIBP being one, are a major part of the problem and 2. there are alternative solutions, i.e., offline service and offline tools, and what HIBP provides is an excellent example of where an online service is unnecessary and is collecting large amounts of user data, unnecessarily.
Addendum: "What I'm telling you" is that I believe the problem is data collection. Any "solution" which collects data, and in this case data it is not supposed to have (e.g., a data breach), then collects more data (e.g., metadata) from users and finally asks users to trust the "new collector" is not a solution, IMO. Especially where the new collector shares no technical details about his operation (e.g. storage of user data). This practice ignores simple, obvious solutions to the problem of data collection, such as performance of tasks offline which if performed online would likely lead to the collection of user data. It reinforces the mindset that perpetuates the problem: that data collection and trusting third parties is always necessary.