File systems unfit as distributed storage back ends: lessons from Ceph evolution - <AUTHOR> https://blog.acolyer.org/2019/11/06/ceph-evolution/ <comment> j-pb From the Blog post:

> We looked at this issue earlier. Fundamentally the tension here is that > copy-on-write semantics don't fit with the emerging zone interface > semantics.

While the paper writes:

> It is not surprising that attempts to modify production file systems, such > as XFS and ext4, to work with the zone interface have so far been > unsuccessful [19, 68], primarily because these are overwrite file systems, > whereas the zone interface requires a copy-on-write approach to data > management

This seems to be a contradiction, and I'd side with the original paper.

<comment><USER2> Yes, found it strange too. The third quote block directly states that copy-on- write design is encouraged by the current hardware.

<comment><USER3> Zone interface is specifically good at log structured CoW is what it says. Later they talk about how they tried using a write ahead log but that it does not work well for managing metadata in a distributed filesystem.

</comment></comment></comment><comment><USER4> I ran a ~ 0.5 PB Ceph cluster for a few years, on quite old spinning disk hardware (bought second-hand.) It was great: it just worked, coped very well with hardware failures, told the operator what was happening. An extremely solid, well-engineered system. My thanks to the Ceph team :)

<comment><USER5> Yup, adding to this: For about four years we ran a similar size Ceph cluster that supported a burgeoning public cloud platform with users making extensive use of block and object. We did this on a range of hardware from creaky second-hand SuperMicro boxes to newer all-flash Quanta-based hardware.

Through questionable hardware selection as well as standard operational challenges such as upgrades and scaling, Ceph never let us down.

The only time we had a major problem turned out to be our fault. The creaky machines we were using at the start 'lost' half of their memory during a round of power failure testing. We didn't have monitoring in place to spot this, and unfortunately it manifest after we lost a node which triggered a significant rebalancing operation across the cluster. With several machines missing 50% of their RAM, this quickly descended into a horrendous disk thrashing exercise. Again, all credit due to Ceph - we were able to coax the cluster back into life with no data loss.

</comment></comment><comment><USER6> I was just discussing with a colleague how technology accretes and how no one reevaluates high-level design decisions even after every single factor leading to those decisions has changed.

It's weird that basic filesystems today are so out of touch with modern realities that we are _universally_ forced to resort to using complex databases even in cases when the logical model of files and directories fits the storage needs really well.

It's weird that hierarchical storage is the only universal model available on all OSes and in all languages.

The more I think about it, the more I realize that we live in a bizarro world where software runs everything, yet makes little to no sense from either human, or modern hardware or system design perspectives.

<comment><USER7> Programming languages are in the same boat - the modern CPU works dramatically different from a PDP-11, but most programming models still assume an accumulator machine; flat memory hierarchy; effectively unbounded LIFO program-control stacks; uniform machine word sizes; sequential in-order execution; and byte streams for I/O. This is despite large register files, multiple levels of caching, coroutines/promises, SIMD, multicore/GPU, and page-level I/O being things. In many cases even assembly language encodes assumptions from the 1970s, and then is internally translated by the processor into how the hardware actually works.

<comment><USER8> I wonder what your thoughts are on the Mill Architecture? It's throwing out every assumption on how to build a CPU, which mandates that the compiler needs to be rewritten to generate code for it.

<comment><USER7> I hadn't heard of it before. I just looked it up and it looks interesting, but I don't have enough hardware engineering experience to judge its feasibility.

I think a larger problem with new architectures is that consumer adoption follows price/performance/power, not any inherent architectural quality. The architecture we're stuck with is the one that most hardware devices get sold with (x86/ARM right now). That gets determined by hardware OEMs, which in turn make their decisions based on what'll help them sell the fastest devices with the lowest power consumption for the least money. So something like RISC V is fascinating and quite elegant, but until there are RISC V chips that are cheaper and faster than Intel ones, it remains an academic curiosity. Then if you're a compiler writer, you gotta work with what you've got for an installed base, and you can't really get adoption for a new language unless it lets startup founders unlock new markets because your combination of development velocity + execution speed lets them do things they wouldn't otherwise be able to.

<comment><USER8> Ah yeah, I'm just as cynical in all the ways you are about the prospects of a 'new architecture' becoming relevant. Just thought you might have known Mills + had some personal insights on the project.

</comment></comment></comment></comment></comment><comment><USER9> The link to the paper in the article requires an ACM subscription. Here is a link to the version hosted by the authors:

[https://www.pdl.cmu.edu/PDL-FTP/Storage/ceph-exp- sosp19.pdf](https://www.pdl.cmu.edu/PDL-FTP/Storage/ceph-exp-sosp19.pdf)

<comment><USER10> I loaded it just fine from the link

</comment></comment><comment><USER5> For anyone looking for more information and benchmarks on the performance improvements in recent versions of Ceph (and with Bluestore in particular), here's a write-up that was done as part of testing for infrastructure to support the Human Brain Project: [https://www.stackhpc.com/ceph-on-the-brain- a-year-with-the-h...](https://www.stackhpc.com/ceph-on-the-brain-a-year-with- the-human-brain-project.html)

<comment><USER11> Unfortunately Julia was just a prototype system that they are going to turn off. KNL made it into one of their main production systems (Jureca) as a "booster" module, but they use GPFS on the main storage system (IIRC).

</comment></comment><comment><USER12> The end-to-end principle strikes again: lowest common denominator abstractions like filesystems are often incorrect, inefficient, or both for complex applications and ultimately must be bypassed by custom abstractions tailored for the application.

<comment><USER13> It's kinda why I think something like an exokernel would make more sense than way OSes trying to abstract things to a certain level. We should be trying to build abstractions that can be peeled layer by layer like an onion, not a potato.

<comment><USER14> Unix files aren't quite an exokernel-style "just securely multiplex the disk" but in some ways they come closer than some other alternatives. No file types, just randomly accessible bytes (well, and an execute bit); no multiple streams; no ISAM, just bytes (except that you do have directories); no insertion (but you do have append and truncate).

You could make them _more_ disk-like by making them fixed-size, with the size specified at creation time, and accessing them in blocks rather than in bytes. Would those be an improvement? I tend to think not. Certainly if those were the semantics provided by the kernel you would want userland filesystem processes to provide appendable files.

Copy-on-write file versioning and cross-file, cross-process transactions, on the other hand, could be real pluses. I'd be okay with those being provided by userland processes rather than the kernel, but I'd sure like to have them.

</comment></comment></comment><comment><USER15> We're actually facing an issue with our Ceph infrastructure in the 'upgrade' from FileStore to BlueStore: the loss of use of our SSDs.

We created our infrastructure with a bunch of hardware that had HDDs for bulk storage and an SSD for async I/O and intent log stuff.

The problem is that BlueStore does not seem to have any use for off-to-the- side SSDs AFA(we)CT. So we're left with a bunch hardware that may not be as performant under the new BlueStore world order.

The Ceph mailing list consensus seems to be "don't buy SSDs, but rather buy more spindles for more independent OSDs". That's fine for future purchases, but we have a whole bunch of gear designed for the Old Way of doing things. We could leave things be and continue using FileStore, but it seems the Path Forward is BlueStore.

Some of us do not need the speed of an all-SSD setup, but perhaps want something a little faster than only-HDDs. We're playing with benchmarks now to see how much worse the latency is with BlueStore+no-SSD, and whether the latency is good enough for us as-is.

Any new storage design that cannot handle an "hybrid" configuration of combining HDDs and SSDs is silly IMHO.

I joked that we could tie the HDDs together using ZFS zvol, with the SSD as the ZIL, and point the OSD(s) there.

<comment><USER16> From what I can tell, BlueStore still supports using separate disks for the WAL/RocksDB[0]?

[0]: [https://docs.ceph.com/docs/master/rados/configuration/bluest...](https://docs.ceph.com/docs/master/rados/configuration/bluestore- config-ref/#devices)

<comment><USER15> Yes, the confounding factor was/is we are using ceph-ansible with ceph-disk. If we want to upgrade we have to make a whole bunch of inter-related changes.

(I'm not the lead on the project, so no doubt have forgotten some of the exact complications involved. Though it does seem slight strange (IMHO) that you're getting rid of the file system, but still keep the LVM layer.)

</comment></comment></comment><comment><USER17> I have sympathy with, and am open-minded to, the conclusions of this article - even as a die-hard, true believer in the filesystem (esp. ZFS) as a useful foundational building block.

However, I hope that these conclusions do not lead to the intentional deprecation of support for filesystems in projects like Ceph. If a non- filesystem backing store is superior, then by all means do it, but I hope the ability to deploy a filesystem-backed endpoint will be retained.

In a pinch, it's very flexible and there are a lot of them lying around ...

<comment><USER18> If nothing else, most filesystems can expose a big file that can be used, with decent efficiency, as though it was a disk. For COW filesystems, turning off COW on the file may improve performance, and, if the FS is on RAID, the resulting performance and correctness properties will be odd.

<comment><USER19> But if services will need to use one big file, we won't have possibility to overcommit disk space (unless they implement something like TRIM).

</comment></comment></comment><comment><USER20> > "For its next-generation backend, the Ceph community is exploring techniques > that reduce the CPU consumption, such as minimizing data serialization- > deserialization, and using the SeaStar framework with a shared-nothing > model…"

Seastart HTTPD throughput as mentioned on their site Between 5 to 10 CPU, it can achieve 2,000,000 HTTP request/sec. Just Vow. But If you look at Http Performance data on below URL, running similar configuration on clouds (AWS etc.) looks costly though.

[http://seastar.io/http-performance/](http://seastar.io/http-performance/)

I wonder what would be cost of achieving similar performance on Hadoop stack.

<comment><USER21> > _it can achieve 2,000,000 HTTP request /sec_

Is that including some db operations? Because otherwise eeeeh: [https://www.techempower.com/benchmarks/#section=data-r18&hw=...](https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext)

<comment><USER22> Ceph has a lot of small ops, where lock and cache contention becomes very significant. (Basically a small piece of data/request comes in from the network and the OSD [object storage daemon] network thread has to pass it to the I/O worker thread and then forget it. The I/O thread similarly just needs to get the request issue a read/write, and let the kernel work.)

Since the whole Ceph I/O model is async the less waiting, scheduling, contention, etc. happens the better.

Currently Ceph is CPU bound, that's why they are trying to improve CPU perf.

</comment></comment></comment><comment><USER23> This isn't surprising, but I guess the results need to be put into perspective with the use case for distributed file systems and NFS eg. reasonable scaling for static asset serving with excellent modularity, in particular when paired with node-local caches. Of course Ceph etc. won't scale to Google Search and Facebook levels, but it's still damn practical if you're scaling out from a single HTTP server to a load-balanced cluster of those without having to bring in whole new I/O infrastructures. And they help with cloud vendor lock-in as well; for example you can use CephFS on DO, OVH, and other providers.

</comment><comment><USER24> I read DigitalOcean is using Ceph for its object and block storage. Do they use BlueStore in production too?

<comment><USER25> Fairly sure at a Ceph Days recently they did a talk mentioning they're on Jewel which would still be FileStore.

BlueStore is really only reaching production deployments and maturity quite recently last year or so.

<comment><USER24> Thanks! This probably means we can expect some IOPS and latency improvements when they'll upgrade :)

<comment><USER26> DO has upgraded their Ceph cluster to luminous back in 2018 according to this blog post: [https://blog.digitalocean.com/block-storage-volume- performan...](https://blog.digitalocean.com/block-storage-volume-performance- burst/)

<comment><USER24> Thanks for the link. I missed that. It looks like they use BlueStore :)

<comment><USER25> My mistake I think I'm confusing them with another provider. Maybe OVH?

</comment></comment></comment></comment></comment></comment><comment><USER27> Slightly off topic but I love Adrian Coyler's blog. Since I never pursued graduate studies in CS I never really got into reading research papers but would love to start reading some on my commute to work.

Does anyone have any recommendations for finding interesting papers? Do I need to buy subscriptions? Is there a list of "recommended" papers to read like we have with programming literature e.g. _The Pragmatic Programmer_?

<comment><USER28> ACM subscription helps, since their "Digital Library" has pretty good coverage of the CS literature. This is something that your employer might want to sponsor.

A strategy to find interesting papers that are worth reading as a novice in the field, is to pick any current paper that is interesting to you and look for heavily cited references. The following websites have citation data for papers:

[1] SemanticScholar.com

[2] GoogleScholar.com

[3] citeseerx.ist.psu.edu

</comment></comment><comment><USER29> Don't most of their problems go away when you fallocate a pile of space and use AIO+O_DIRECT like a database to get the buffer cache and most of the filesystem out of the way?

CoW filesystems like BTRFS proviode ioctls to disable CoW as well, which would be useful here when you've grown your own.

XFS has supported shutting off metadata like ctime/mtime updates for ages.

If you jump through some hoops, with a fully allocated file, you can get a file on a filesystem to behave very closely to a bare block store.

<comment><USER30> > Don't most of their problems go away

No. Yes, you can fallocate. Yes, you can use AIO, or even better io_uring. Yes, you can use O_DIRECT ... if you want to give up caching and have to deal with alignment restrictions, and it turns out that O_DIRECT turns into O_SYNC in some unexpected edge cases. That gets you something that kind of sort of behaves like a block device, but that doesn't solve any of the problems the authors identify.

* No transactional semantics. Roll your own. (I'm actually OK with this one BTW, but others feel differently.)

* No help with slow metadata operations. Still slow if you're still using multiple files, or roll your own within a single file.

* No improvement in support for new media types (e.g. shingled/zoned).

In an ideal world, local filesystems would do a decent job supporting distributed filesystems (and other data stores). Instead, we're in a world where local filesystems fall short in many ways, and the solution to every deficiency is to avoid the local filesystem as much as possible. That way leads to silos and lock-in, so I don't think it's a good answer. Local filesystems need to be better, or someone needs to create an equally standard abstraction and set of tools to do what local filesytems can't.

</comment></comment><comment><USER31> I use ext4 with my distributed async-to-async JSON database: [https://github.com/tinspin/rupy/wiki/Storage](https://github.com/tinspin/rupy/wiki/Storage)

You can try it here: [http://root.rupy.se](http://root.rupy.se)

The actual syncing is done over HTTP with Java though so maybe that's why it works well for me.

</comment><comment><USER32> I guess a minimal install of Ceph is a client and a node with 2-3 hard disks / SSDs.

</comment><comment><USER33> Unfit? That's why I'm using KirbyCMS atop NTFS with zero issues, right?

<comment><USER33> [https://news.ycombinator.com/item?id=13679424](https://news.ycombinator.com/item?id=13679424)

Older thread with people having discussed this that back up my words right up top. I don't have a single issue with KirbyCMS + NTFS, I have distributed back end stuff as I desire, and it just works and has mature documentation.

</comment></comment><comment><USER34> I don't think the conventional wisdom of building on top of filesystems exists. In distributed systems you always naturally gravitate towards using raw storage devices instead of filesystems, it becomes obvious very early on that filesystems suck too much and only create problems. And it's the same with all the embedded database libraries, you really want to write your own, because none of the existing ones were made to address performance and operational problems that arise even in small distributed systems. But at the same time early on you don't yet know most of the problems and don't want to invest time implementing something you don't yet understand well enough, so you end up building on top of filesystems and embedded databases and making plenty of poor choices and learning on your mistakes.

<comment><USER30> As I pointed out to the authors, this wheel has turned a couple of times. In the late 90s, many distributed filesystems (and most cluster filesystems) used raw disks and their own format. This was a burden, both for the developers who had to maintain an entire low-level I/O stack in addition to the distributed parts and to the users who had to learn new tools to deal with these "alien" disks in their system (which also limited deployment flexibility). Thus, when the current crop - e.g. Ceph, Gluster, PVFS2 - came around, they went toward a more local-FS-based approach. All of the issues mentioned in the paper were still real, but on the hardware of the time (both disks and networks) those weren't the bottlenecks anyway so the convenience was worth it. Now the tradeoffs have shifted again, and so have the solutions.

Context: I've been an originator/maintainer for multiple projects in this space, and currently work on a storage system where we add space in bigger increments than Ceph's entire worldwide installed base (according to numbers in the paper).

<comment><USER35> The filesystem as an abstraction has been getting long in the tooth for a long time -- it's taken a long time for the industry to recognize this, but that's the way it is with filesystems because a boring filesystem that never munches your data is preferable to most people to an interesting filesystem.

Some evidence:

* The proliferation of Linux filesystems such as ext4, XFS, ZFS, btrfs, reiserfs, JFS, JFFS, bcachefs, etc. If any of those filesystems were truly adequate there wouldn't have to be so many.

* Microsoft's failure to replace NTFS with ReFS. (Interacts with storage spaces in such a way that it will never be reliable)

* Microsoft's giving up on the old WSL and replacing it with a virtualized linux kernel because metadata operations on NTFS are terribly slow compared to Linux but people don't usually notice until they try to use an NTFS volume as if it was an ext4 volume.

* The popularity of object stores, systems like Ceph, S3, etc.

* Numerous filesystems promising transaction support and then backing away from it (btrfs as mentioned in the article, NTFS, exFAT, etc.)

* Proliferation of APIs to access filesystems more efficiently. On one hand there are asyncio access methods for filesystems which aren't quite as solid as asyncio for networks, on the other hand there is mmap which can cause your thread to block not only when you make an I/O call but later when you access memory.

* Recently some filesystem based APIs that address the real issues (e.g. pwrite, pread) but astonishingly late in the game.

<comment><USER36> _The proliferation of Linux filesystems such as ext4, XFS, ZFS, btrfs, reiserfs, JFS, JFFS, bcachefs, etc. If any of those filesystems were truly adequate there wouldn 't have to be so many._

First of all ZFS is not a "linux" filesystem. Second, available choice of filesystem is a strange thing to use as justification that previously existing filesystems are "inadequate". By what criteria are you establishing adequacy? Success of technologies is often not dependent solely upon their technical excellence but on a variety of factors that may have nothing to do with the technology itself. (Betamax vs VHS, etc.)

<comment><USER35> In theory people would pick the filesystem which is ideal for their application.

In practice it is a lot of work to research the choices, and there's a high risk that you'll discover something wrong with your filesystem only when it is too late.

It's one thing to pontificate for and against particular file systems, it's another to use one for years, terabytes, etc. ZFS might scrub your data to protect against bitrot, but I remember reading harrowing tales from ZFS enthusiasts who were recovering (or not recovering) from wrecks every week but seemed to think it was a lot of fun, or conferred them status, or was otherwise a good thing.

I stuck with ext4 for a long time before finally building a server that uses ZFS/HDD for media storage (e.g. not a lot of random access)

I remember the time when a project I was involved with chose reiserfs because they thought it was "better" and then they were shocked when once in a while the system crash and we found that a file that had just been created was full of junk.

That's a trade-off they made, they decided it was important to journal filesystem metadata (the length of the file is right) but not to protect the content. If they read the docs, really thought about it, then understood it, they would have known, but they didn't.

This book points out that in cases where there is too much competition, you can switch all you like between flawed alternatives, but have no way to communicate what you really want:

[https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty](https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty)

And when it comes to the "Filesystem API" probably anybody who has special needs for filesystem performance would find that a different API than the standard filesystem API would be a boon.

<comment><USER36> I don't disagree with the general premise that a single filesystem might not be applicable or appropriate to all cases or that existing filesystems apis are generally deficient.

My primary issue was with the two specific assertions I addressed, one of a given filesystem's origins and that of choice should being used as a proxy for evaluation of adequacy.

As for ZFS enthusiasts "recovering from wrecks every week", I suspect you're specifically referring to ZFS on Linux or one of the BSDs -- which is not the same as ZFS when used in its original environment -- Solaris.

<comment><USER35> No, it was on Solaris back when ZFS was new.

It seemed like these people enjoyed having wrecks, like the Plebe who enjoyed getting hazed in

[https://www.amazon.com/Sense-Honor-Bluejacket- Books/dp/15575...](https://www.amazon.com/Sense-Honor-Bluejacket- Books/dp/1557509174)

<comment><USER37> So because a file system had issues 20 years ago when it was new.... Do you still drive a car with a carburetor and drum brakes?

ZFS is now incredibly stable and durable, with the exception of some of the early non production ZFS on Linux work that is now fixed (and was specifically billed as non prod use). It has seen me through issues that other file systems would have failed on, including drive failures, hard shutdowns, a bad RAM module, SAS card being fried by a CPU water cooler, etc. Years and terabytes just on my systems, zero issues.

In fact one of the tests that Sun did back in the day was to write huge amounts of data to a NAS and pull the power cord mid writing. Then repeated that a few thousand times. It never corrupted the file system.</comment></comment></comment></comment></comment></comment></comment></comment>


Goldman Sachs limits interns to 17 hour workdays - <AUTHOR> http://mashable.com/2015/06/18/goldman-sachs-interns/ <comment><USER2> [https://news.ycombinator.com/item?id=9739254](https://news.ycombinator.com/item?id=9739254)

</comment><comment><USER3> I'm a summer intern at Goldman in S&T. Days for interns are the same as for the MD (managing director) you're under. You try to get in just before they do and leave when they do. Generally this is 6AM-7PM for me. I don't step foot in the office after 7PM Friday and have zero reason to do so until Monday.

On the IB side working 9AM-11PM, with many days working to 2-3AM, is absolutely the normal. As is working on each day of the weekend. However, these new hours are being enforced by HR heavily - to my understanding, there's no reason for them to apply to S&T - although I'm not sure it'll mitigate any stress.

The issue with IB internships, like any internship, is that you have huge gaps of lull time between projects. However, when you do get projects they're generally time sensitive and need to be done regardless of how long it takes you. This is the life of IB analysts, that those doing the IB internship are lining up to try to get, because it all comes down to doing your two years and going to somewhere (supposedly) bigger and better.

<comment><USER4> 6am-7pm -- how many of those hours are productive? My own brain tends to melt and needs a break after a couple hours of solid work.

I always assume when people (not you) brag about their 100-hour workweeks, that in fact a huge chunk of that includes hanging out with co-workers, lunch, some down time throughout the day, so on.

So, what's your own day like? What's a GS intern do, anyway?

<comment><USER3> Well, for IB I can't comment much. I'd say there's a lot of downtime, playing with basic models, etc.

In S&T it's quite different and depends if you're on a quant desk; relatively illiquid trading desk, like some kind of structured product where you'll get a few trades a day; or a more normal fixed income or commodities desk where you'll be making markets throughout the day constantly trading, analyzing, and monitoring the markets.

On my desk - which falls under FI, although I won't say which area - it's quite liquid, client-focused, and fast-paced.

6am-7am - Making sure all your systems are launched, working, and then analyzing what your colleagues in London, Hong Kong, and Tokyo were up to while you were asleep. Often your book will be managed by those folks and so you'll want to know what/how they executed (assuming they didn't call you through the night to get your opinion, which does happen depending on the product you trade).

7am-5pm - You're constantly trading; analyzing your positions; looking at your risk; calling middle/back office to get things analyzed; on the phone with colleagues in London, Tokyo, etc.; perhaps stepping into the odd meeting, getting someone to watch your monitors; talking to your sales people, giving them ideas, feedback, what clients should like a certain thing at a certain level, etc.

5pm-7pm - Making sure back office completes your risk, analyzing and amalgamating your PnL for the day, chatting with other offices just as you did at the start of the day.

7pm-11pm - Perhaps you'll go home and go to bed early (9pm or so), or, depending on your area, you may go to dinner with clients or have some other social engagement until 10-11pm.

\---

Trading is incredibly diverse, but I think this largely captures the roll of a sell-side (Goldman) trader in most front-office trading rolls. Quant-traders, like you'd find at certain quant hedge funds, tend to be less common at sell- side shops. You'll usually have traders, who just trade, with maths, comp sci, etc. undergrads who work with the quants (who have PhDs in those fields and don't trade at all) to get the data, systems, etc. they want. As a result traders generally, well, spend their entire day trading. Even on quiet days you'll be glued to your screen waiting, reviewing, thinking about what to do next. Market making doesn't involve letting clients dictate where the market moves necessarily, it involves being a liquidity provider and risk mitigator, which is what I'd say traders on the sell-side largely are.

<comment><USER4> Wow, thanks for the reply! Sounds quite stressful.

Go get some sleep!

</comment></comment></comment></comment><comment><USER5> Complete click bait.

GS is telling interns "you can't be in the office between midnight and 7am". I assume they didn't previously have a policy. So what anyone would consider a strict improvement over the previous situation is criticized because it isn't enough of an improvement.

<comment><USER6> The criticism is entirely valid.

This is just a policy, so for now all they've done is announce it and write it down. They could have just as easily made up something more reasonable, like interns can't work more than 60 hours a week.

17 hours a day is up to 119 hours a week, which is clearly exploiting them. The fact that it's (apparently) an improvement is a little scary, and the banks should be embarrassed and called out on it.

<comment><USER5> Interns working only 60 hours a week is much harder to monitor. A policy that says they can't be in the office between midnight and 7am is simple to monitor.

The press has implied or allowed readers to conclude that interns were previous working more than 17 hours a day, which is nice for the author because you don't need to support an implication and you can't be called out for being incorrect in something you never say.

</comment></comment></comment><comment><USER7> Is it not intellectual work? Sleep deprivation really wrecks my ability to think clearly.</comment>


The story of a geek turned customer support representative and salesman - <AUTHOR> http://avlesh.wordpress.com/2012/02/09/the-story-of-a-geek-turned-customer-support-representative-and-salesman/

<comment><USER2> Do you/they plan to have a sales team ?

<comment> avlesh-singh Yes, but somewhere down the line. We are of the opinion that being creators of the tool, we are the most qualified and equipped to sell/market it. However, scaling that up will definitely be a problem. That said, whenever we hire sales people, we'll make sure we hire the ones fit to do "technical sales".</comment></comment>


Ask HN: Should interviews be a two street? - <AUTHOR> I was invited to interview with a company that posted on "Who is hiring" thread. The interview was nine rounds, two phone interviews (one was an online coding) and seven onsite interviews on the same day.
In one of the technical interviews the developer asked me to write a program to find Big O complexity of a given program. I asked about the input constraints to check if this was for recursive functions only and got a reply "all code in the universe, including the code for the program itself".
I explained to him about Halting problem and why  a solution was not possible and also explained I could write a program that uses master theorem to solve a recurrence relation for those that fit the theorem.
He farted and said that's how much my answer stinks. It was pretty rank, enough to peel the wallpapers in the room. I said thanks for the feedback, got up and left the building. On my way out, I emailed the recruiter and politely stated that I do not wish to interview with them any longer.
Two days later I got an email from them stating they're not going to proceed with my application as the developers expected me to be more knowledgable about complexity analysis and data structures.
This got me thinking, why are technical interviews one-way? For a nine round interview process, why don't we kick it off by having their best engineer fight me in a 1 v 1 code battle? <comment><USER2> "why are technical interviews one-way" Because you should sell yourself. Sometimes people at company's side are polite, sometimes they are full of crap. If you don't like an interview that company is not for you, basically. Just continue to search or set up your own company :)</comment>


Faster Recovery for PostgreSQL with Delayed Standby - <AUTHOR> https://www.percona.com/blog/2018/06/28/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/ <comment><USER2> Hi Avinash,

It is very useful and easy to understand since it is given with detail steps. Much appreciated and thanks for your efforts. Hope to get some more blogs with different scenarios.

Regards, Abdul Sayeed

</comment><comment><USER3> Great! Easy to understand. Much appreciate your efforts.

</comment><comment><USER4> Thank You so much for sharing my Article :)</comment>


Malware Found in the Ubuntu Snap Store - <AUTHOR> https://www.linuxuprising.com/2018/05/malware-found-in-ubuntu-snap-store.html <comment><USER2> There is no review process or central restrictions on who can upload to the Ubuntu Snap Store, so in a sense, this isn't surprising. [https://docs.snapcraft.io/build- snaps/publish](https://docs.snapcraft.io/build-snaps/publish)

Does the name "Ubuntu Snap Store" carry a connotation that code is reviewed for malware by Ubuntu, the way that the Apple, Google, Amazon, etc. mobile app stores are? Or does its presence in the software center app imply a connotation that it's endorsed by the OS vendor?

I was at a PyCon BoF earlier today about security where I learned that many developers - including experienced developers - believe that the presence of a package on the PyPI or npm package registries is some sort of indicator of quality/review, and they're surprised to learn that anyone can upload code to PyPI/npm. One reason they believe this is that they're hosted by the same organizations that provide the installer tools, so it feels like it's from an official source. (And on the flip side, I was surprised to learn that Conda _does_ do security review of things they include in their official repositories; I assumed Conda would work like pip in this regard.)

Whether or not people _should_ believe this, it's clear that they _do_. Is there something that the development communities can do to make it clearer that software in a certain repository is untrusted and unreviewed and we regard this as a feature? The developers above generally don't believe that the presence of a package on GitHub, for instance, is an indicator of anything, largely because they know that they themselves can get code on GitHub. But we don't really want people publishing hello-worlds to PyPI, npm, and so forth the way they would to GitHub as part of a tutorial, and the Ubuntu Snap Store is targeted at people who aren't app developers at all.

<comment><USER3> I like Arch's package management model, where sources are split into the official repositories, which are manually approved, and the AUR, which everyone knows are not officially endorsed or reviewed, and to check the sources and PKGBUILDS for anything sketchy before installing.

The processes for installing from the two are also different enough that the user can't mistake one for the other: official packages are a pacman -S away, but installing from the AUR either requires a git clone and a makepkg -sri, or an AUR helper that bugs you to review the PKGBUILD.

<comment><USER4> Well as a lazy arch user i installed pacaur and just use official and AUR sources without much checking. It's just convenient that there's an AUR for everything

<comment><USER5> Be warned that malware like this is in the AUR all the time. It's so common it's not even newsworthy. They are usually pretty good at handling it though.

<comment><USER6> I've never heard of this happening and I can't find a single occurrence of it. I mean, I agree with "don't blindly trust everything in the AUR", but this seems wrong.

<comment><USER7> I maintain 14 AUR packages and have also never heard of this happening.

</comment></comment></comment></comment></comment></comment><comment><USER8> The problem with snaps is that they didn't take security really seriously on desktop: [https://www.zdnet.com/article/linux-expert-matthew- garrett-u...](https://www.zdnet.com/article/linux-expert-matthew-garrett- ubuntu-16-04s-new-snap-format-is-a-security-risk/)

>"X has no real concept of different levels of application trust. Any application can register to receive keystrokes from any other application. Any application can inject fake key events into the input stream. An application that is otherwise confined by strong security policies can simply type into another window," he wrote.

They might have wrapped X protocol to provide more security and control. Instead they decided not to.

They might have created a system which is as bulletproof as on iOS where you can install any apps and be 99.9999% sure that they won't steal your data unless you allow them to. But they created this instead.

<comment><USER9> The issues with X11 you mention is part of what Wayland tries to fix. And why early on seemingly benign things like screenshot tools broke.

<comment><USER8> Yes, I understand that there're people in the community who try to fix the problems. But it's really unfortunate, that Canonical tells us that it's secure whereas it's not: [https://snapcraft.io/](https://snapcraft.io/)

>Snaps are containerised software packages that are simple to create and install. They auto-update and are safe to run. And because they bundle their dependencies, they work on all major Linux systems without modification.

<comment><USER5> From what I gather, Snappy is mostly a marketing gimmick by Canonical. If you want to packages apps, you should use something like FlatPak or AppImage.

<comment><USER8> Do you know whether they more secure than snaps? I like the idea of running whatever I want on my hardware without compromising security very much.

</comment></comment></comment></comment></comment><comment><USER10> _used a proprietary license_

Does the license actually mention it mines? I am reminded of a lot of "freemium"/"ad-supported"/etc. software that makes its author money via ads or whatever else --- and you agree to that if you read the license --- and it is a bit shady to name the miner 'systemd', but it seems rather overboard to call this "malware"... when I see that term I think of software that self- propagates and exfiltrates personal data, delete/encrypts files for ransom, etc.

Also from the page:

 _Size 138.8 MB_

I'm not really familiar with the latest trends in (bloatware?) development, but a simple game like that taking >100MB would make me suspicious --- even 10MB is in the "questionable" range, and ~1MB would be closer to what I consider "typical". 138MB is bigger than the installed size of Firefox, and that's a far more complex application...

<comment><USER11> >a simple game like that taking >100MB would make me suspicious

Nah. Games often feature a bunch of textures and video and sound files. Bad compression or too high resolution on those is quite common, which is why games _are_ often that large.

Also proprietary software usually ships a bunch of libraries - games often ship with a premade engine, which are also often quite large.

As a datapoint, I have a copy of "Strata", which is a simple /minimalistic puzzle game, and it _is_ 78MB.

<comment><USER12> I remember the Facebook app being less than 20 megabytes in size half a decade ago. Now it's almost half a _gigabyte_

<comment><USER13> And for the life of me I can't understand why people use the Facebook app. The mobile web page loads faster, it's automatically sandboxed by being just a browser page and it can do almost anything that the app can do.

Besides on iOS at least, if you click on a link from the Facebook web page, you can take advantage of whatever content blocker you have installed.

<comment><USER14> If you log into Facebook on web, then visit any other site, they send your browsing info to Facebook via Like button.

The Facebook app is _more_ sandboxed, since it can't snoop on your web browsing.

<comment><USER15> The facebook app for quite a while was actually sending facebook data about your phone calls and sms so guess again.

<comment><USER13> Only on Android....they couldn't do that on iOS.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> A Monero miner is one of the more innocuous forms of malware ,compared to a C&C trojan or a keylogger. Some websites will mine monero in the background. Because it's just a js script, it's not much different than a banner ad except it's less intrusive, yet somehow 'currency miner' has more negative connotations than 'ad server'. That is the downside of decentralized mining and asic resistance is you end up with a lot of zombie miners.

<comment><USER17> > Because it's just a js script, it's not much different than a banner ad > except it's less intrusive

Tell that to your electricity provider

<comment><USER18> The same thing can be said about JS ad analytics scripts and ads. Or sites that turn the entire webpage into a JS 'web app' when it'd work fine as HTML with static images and text.

<comment><USER19> Not the same thing. JS increases the usage a bit. Badly broken JS may use a lot of CPU - but the author still has the incentive to fix it. But mining is a completely different category - it's designed to peg your CPU at 100%, because that's what's profitable.

<comment><USER20> And what's worse, for every dollar you spend on electricity for CPU-mining, you (or, in this case, someone else) receive 5 cents worth of cryptocurrency.

</comment></comment></comment></comment></comment><comment><USER21> Unlike flahub where either original develop or flathub admins take control

Canonical's Snapcraft literally says "Get published in minutes"

Any random guy would publish his malware with near no review

[https://dashboard.snapcraft.io/snaps/](https://dashboard.snapcraft.io/snaps/)

Yes, they maybe win the counter for published apps compared to flathub. Congratulations!

<comment><USER5> I really don't see the use case at all for Snappy. I mean FlatPak makes sense for devs who want to "package- once, run everywhere", but Snappy is Ubuntu- only. The thing is Ubuntu through Debian is really good at having lots of up- to-date packages. Why abandon that for some crummy app store?

<comment><USER22> The "Users by distribution" table at the bottom of the Spotify page is worth a look: [https://snapcraft.io/spotify](https://snapcraft.io/spotify)

Snaps are not Ubuntu-only. You can find install instructions for many distros here: [https://docs.snapcraft.io/core/install](https://docs.snapcraft.io/core/install)

<comment><USER21> Snap is a proprietary format that is canonical-centric, don't tell me that the community make choice to make client opensource but official store both hardcoded (initially) and closed source.

On the other hand,flatpak is a freedesktop project, done using open standards like OCI and ostree.

<comment><USER23> No. Snap is not a proprietary format at all. It's a squashfs file with a small amount of metadata. You can make a snap by plopping a file in a folder, add a simple snap.yaml which describes the application and then "make" a snap with the common mksquashfs tool.

There is room in the world for flatpak and snap to co-exist. We created snaps as an evolution on from clicks on the Ubuntu phone, and it covers use cases that flatpak wasn't designed for.

<comment><USER21> Remember ubuntu one storage solution? An opensource client does not make the whole thing free software and open standard.

</comment></comment></comment></comment></comment></comment><comment><USER24> Whoa, I made Hextris ([https://github.com/hextris/hextris](https://github.com/hextris/hextris), one of the games removed from the store) a few years ago! Is there any precedent in OSS developers being held responsible for misuse of their code?

<comment><USER25> From the license you chose:

 _The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things._

Part of the problem with letting people have freedom is that they have the freedom to make decisions that impact communities in a negative way. But it's usually worth the tradeoff.

This is probably the most relevant line though:

 _For the developers ' and authors' protection, the GPL clearly explains that there is no warranty for this free software._

i.e. you have nothing to worry about, but you also probably can't do anything to punish the misuse. After all, misuse is subjective.

</comment></comment><comment><USER26> This is exactly why you should not run random docker images and snaps. Docker images are also run as root in many cases. It is better to build app images from scratch and understand what exactly goes into the image.

<comment><USER8> Why not run random docker images? As far as I understand, docker container are pretty solid. Not super solid but solid enough.

<comment><USER27> Those random docker images are rarely used in isolation. They typically handle your data and often your customers data.

Beyond that, numerous escape exploits in linux containerization (and docker specifically) have popped up over the years, and many more are going to pop up over the coming years. This is not a mature space.

Running random binary code distributed from an non-curated source, even in a "container" is going to end in heartache.

<comment><USER28> And that's why you should usually build your own images, and only trust docker images from the same people whose binaries you'd also trust with all your data.

(e.g. a docker image from RedHat may be okay, one from zhenghe8 likely not)

</comment></comment></comment></comment><comment><USER29> It's only a matter of time before some major successful linux system attack is delivered via snap/flathub.

Distributions and their package maintainers serve an important role. In the interests of consuming more & faster people seem to be ignoring that.

I wish we had enough resources in the free softare community for all software to be packaged and maintained in the distributions by independent parties unaffiliated with the creators as a rule.

<comment><USER30> In theory you can have the last bit with flatpack (and perhaps snap), the issue here is auditing what goes in the repositories, not the package format.

<comment><USER29> Have you ever gone through the rigamarole of getting a project into a major distro like debian?

A bunch of the guidelines governing that process are simply unenforcable in a model where the developer builds and publishes the release.

I am not of the opinion that those rules are irrelevant to the stability and security of our systems.

There's a significant push to establish a more app-store model for linux distributions, taking the distributor largely out of the loop for software that isn't part of the base system.

This has both positive and negative consequences.

Today the negative consequences are largely hand-waved away with something along the lines of "containers will protect you".

<comment><USER30> I do not really see the difference between the app-store model and the distribution repository model, at the end of the day both are models that teach the users to only download stuff from a specific place. This introduces gatekeeping middlemen that personally i'd rather do without. But if there is going to be a central """trusted""" place, i'd prefer it to be distribution agnostic.

(although even that isn't ideal since in practice it ends up with the major popular distributions pushing agendas to the smaller distributions through whatever requirements are there for "compatibility")

<comment><USER29> It makes a substantial difference when we're talking about open software the distributor builds from source. The major distributors set a relatively high standard for the build process.

The same cannot be said for developers in my experience, who often don't even see a problem with the build process accessing the network - and frequently will publish releases built from the same host environment they use for their general daily computing.

From the perspective of a distributor, the packages should be perfectly buildable (and for official releases, preferably so) with a toolchain of known provenance in a clean environment without network connectivity.

The priorities are quite different for the developer of software and the distributor of systems incorporating that software. It's similar to the tension between system administrators and developers.

</comment></comment></comment></comment></comment><comment><USER31> This is the Snap distribution system working as intended with unfortunate consequences.

</comment><comment><USER32> There is no review process for sandbox apps, the manual review is for apps with access system wide.

</comment><comment><USER33> Can anyone clarify if this is a possibility for apt packages as well? As far as I understand, there are 4 types of apt repositories (for Ubuntu): Main, Universe, Restricted, Multiverse.

I guess Main is safe since it's handled by Canonical, but the rest?

Moreover, a lot of installers simply add a custom repository to sources.list.

What are some good practices for a novice user, regarding apt?

<comment><USER5> So, most source-based package managers are going to have higher standards & catch something like this. Not every line is going to be audited, but demanding free licenses, active git repos, and wide userbase goes a long way to keep stuff clean. Obviously many valuable packages are left out & you will be tempted to install the .deb files.

I would say if you are at all concerned about safety: don't install apps through .deb file that developers sometimes push. They are generally safe, but there is always a potential that these files are malware.

For instance, lots of people use Atom as their text editor, but Atom does not make it possible/easy for packagers to build Atom from source[1]! Everything used to come with a configure, build, & install script, but I guess it's not hip enough anymore.

[1]: [https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=747824](https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=747824)

<comment><USER33> Indeed, building from source is falling out of fashion, with everyone creating a package manager these days. I find some of these very opaque, for example Rust has it's own package manager which downloads and runs binaries at its own discretion.

[https://github.com/rust-lang-nursery/rustup.rs](https://github.com/rust-lang- nursery/rustup.rs)

</comment></comment></comment><comment><USER34> I only get my packages from the central repos. I would be very wary of downloading snaps unless I knew exactly who was distributing them.

Repositories are why Linux repos are free of malware. With more snap-based packages being made available then we are going to see a lot more of this sort of thing.

</comment><comment><USER35> Apple's strategy for their store looks better and better every day.

<comment><USER36> [https://www.bankinfosecurity.com/apple-battles-app-store- mal...](https://www.bankinfosecurity.com/apple-battles-app-store-malware- outbreak-a-8538)

<comment><USER13> From looking at the link, it looks like it just sends information from the device to a web server. It doesn't look like it would have access to anything that any other app wouldn't have access to without explicitly asking for the users permission.

</comment></comment></comment><comment> DC-3 Nice case study in why Arch types are adament that you should properly take the time to read your PKGBUILDs.

<comment><USER37> Arch makes it clear for users that AUR packages are not official.

Ubuntu snaps very easily installable, just a quick command away, which can give users a false sense of security.

</comment></comment><comment><USER38> If you use snaps, be aware that they update automatically on their own. You have the option to set upgrade time windows but you cannot completely disable automatic updates and use your own custom solution to update and administer your system.

Discussion of this issue with snap developers here: [https://forum.snapcraft.io/t/disabling-automatic-refresh- for...](https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap- from-store/707)

<comment><USER39> This is very unfortunate. Despite the negative press snaps is getting, I was planning on releasing a commercial product as a snap. One of the key reasons for doing so was that users had control over what the app is allowed do (via plugging/unplugging slots), a feature flatpack lacks as far as I can tell.

However this changes everything. Disallowing owners from controlling their software and hardware is not something I want to encourage. We have enough of that from Microsoft (and to some extent GNOME Shell developers).

Does Flatpack also force developers' intentions upon their users? Or is AppImage my only recourse?

I want a solution that doesn't mistreat customers.

</comment></comment><comment><USER40> It great to see that the community acts fast and educates others.

</comment><comment><USER41> While this is obviously malicious, I think I would favour paying for things with a few CPU cycles, as long as it was voluntary and overt.

Want to read this article? Please click here to mine a cryptocoin for 30 seconds. Great, thanks! Here's a cookie so we won't ask you again to mine for a whole month.

I would much rather have this than being shamed into looking at ads. It always struck me as utterly bizarre to be told that not wanting to see ads is somehow immoral.

<comment><USER42> That may be fine on desktops but absolutely unacceptable on mobile and laptops, due to battery usage.

<comment><USER41> Wouldn't be a payment if CPU cycles didn't have some scarcity.

My laptop would be fine with 30 seconds of a CPU spike, though. Most phones could probably also tolerate it.

</comment></comment></comment><comment><USER43> As someone who hasn't yet used Ubuntu 18.04, is the snap store something I'll be using in 5 years time instead of APT, is it just another attempt by Canonical to jump on the app store bandwagon, or is it something completely different?

Excuse my ignorance but I'm intensely suspicious of "stores" on open source operating systems.

<comment><USER44> You might be using it instead of APT for some things, but it won't replace APT.

Say you want the newest version of LibreOffice for whatever reason. This is a typical use-case where Snaps will come in handy. They have most dependencies bundled into the application, so you don't have to worry about your whole system getting wonky by installing newer versions of those dependencies to go with the newer version of the application.

This is also meant to serve as a way for devs to release software without much hassle. So, they don't have to open-source their code, hope that someone finds it, packages it for Ubuntu and in like five years time is available to end- users through the repositories.

They also don't have to worry about building a .deb, .rpm, Arch's format and whatever else there is, including accounting for the differences between distros. So, Snaps are supposed to work on all distros the same.

Ultimately, this will bring in more proprietary applications.

Well, and Snaps are sandboxed, so there's some protection, which makes those proprietary applications somewhat more acceptable, but as this piece of news shows, it's not complete protection.

Is it another attempt of Canonical to jump on the app store bandwagon? Most definitely yes. There's a competing format, Flatpak, which does pretty much the same, also AppImage which is somewhat older and without sandboxing, and Canonical is mainly just pushing their own format, because they'll have control of the store behind it.

Like, it's not impossible to hook up other Snap stores, but Canonical has established their infrastructure as the primary source and then how many users are going to look elsewhere?

<comment><USER43> Thanks for the info. I like that Canonical are trying to solve the problems with package managers, but it's a shame we can't focus on making APT and friends more capable of the positive parts of app stores without bundling things into binaries akin to Windows executables. Allow multiple versions of libraries able to be installed, provide path translation (so systems that store binaries in /opt and others in /usr can still work from the same .deb file) and make sure repositories are more frequently updated. This might require Ubuntu to move to a rolling release, at least for some of their products (maybe they could keep releasing LTS versions every two years but have a rolling release for everything else). Sandboxing is arguably nothing to do with the package manager or app store - it's the kernel's problem. And bundling dependencies together is bad for security - critical vulnerabilities (recent example being in SSH) would not be able to be patched with one update, leaving unmaintained code that bundled a vulnerable dependency permanently flawed.

I think I'll wait for this most recent example of the trend to make everything into an app to blow over...

</comment></comment></comment><comment><USER45> Is there some workable way to just add rando user-requested distros (or, more importantly, Debian) to a PPA? Is there some alternate/sane way to distribute packages for Gnu/Linux without smothering my development process in molasses?

I don't even mind creating a VM for _every single distro_ a user requests, and doing a huge automated binary compilation fest for every release. The only thing I care about is that the software is distributed through channels which make it explicit that the current stable version is the _only_ version I support.

<comment><USER46> It is not the job of the developer to package software, that is for maintainers. The best you could do is specify dependencies and tell them how to compile. If it is proprietary, then you might have to support a few popular formats(debs and rpms) and make sure they also work on other distributions without much effort. For example Arch User Repository has google-chrome that repackages it into the native package format but since all dependencies are known, the binary packaged for Debian also works in Arch Linux.

</comment></comment><comment><USER47> It's too bad there isn't some sinister cabal of trusted individuals within the Ubuntu project that can review packages for quality and package them securely and in an auditable fashion.

<comment><USER48> A snap package may ask for elevated permissions. In that case, it goes for manual review.

But if it does not ask for special permissions, then it goes in automatically. Because the app is quite confined.

Compared to other package repos, here it's somewhat better.

</comment></comment><comment><USER49> I've had bad experiences with Snap.

I understand that with Snap devs have to bundle their own dependencies and take care of upgrading, which is bad if I understood correctly.

In my case, a few programs I had installed needed to be connected to other snaps, and they would suddenly stop working for no apparent reason. Only by trying to launch the misbehaving program from the command line I'd find out I had to update the connected program(s).

Has never happened to me with Apt, so my opinion so far is that installing .deb files is vastly superior, at the moment.

</comment><comment><USER50> How does one figure out who a given snapcraft packager is? E.g. Sublime Text says it's packaged by Snapcrafters. Who is that?

<comment><USER50> Presumably it's [https://github.com/snapcrafters](https://github.com/snapcrafters) , but what links the Snap Store identity to that GitHub org?

Where does snapcraft.yaml get executed? On my computer? On Canonical's infra? On the packager's computer?

<comment><USER23> The build service at build.snapcraft.io is what builds it. Anyone can hook up their github repo (containing a snapcraft.yaml) to build and have to automatically rebuild the snap when changes in the git repo occur. It then pushes the snap to the 'edge' channel in the store. Developer validates that build and then pushes to stable for all users.

<comment><USER50> Thank you.

As a user, how (other than asking here) was I supposed to convince myself of the identity binding between "snapcrafters" and the GitHub org and to convince myself that trust in the correspondence between snapcraft.yaml and what I get when I install a snap is rooted in Canonical's build service and not in trusting an individual uploader not injecting different binaries?

</comment></comment></comment></comment><comment><USER50> The risk here is not just going to the Snap Store. At least right now on Ubuntu 18.04 if you type a command that's not installed but is provided by a Snap app, the shell suggests that you install the snap the way it suggested an apt command previously.

</comment><comment><USER37> I'm not familiar with Ubuntu snap store, but how does it compare with Google play store in terms of security?

For example, do apps need to request permissions for accomplishing specific tasks, or is there any kind of sandboxing involved?

<comment><USER48> The snap packages can either ask for elevated privileges or ask for standard access. In the former, they go through some manual review.

I do not know if there are any auto checks when the package is added automatically.

</comment></comment><comment><USER21> One need to take special care about snaps as they need to be a sandboxed gui apps. According to OMG ubuntu report this incident installed system services. And we know that snaps can ship even kernel modules.

</comment><comment><USER51> Snaps was initially tooted as _the_ bestest securest container based application solution by Canonical back then. It is impossible for the app the steal your data, they said. Because of "secure encapsulation" and such. So, that means that there is no need for a review process for uploads, just to make installing packages even _more_ easier than it already is?

I'm sorry, Canonical and Ubuntu are the point were Open Source Software apparently breaks with its traditions. No review on binary blobs uploads most certainly made with OSS when marked "proprietary"? They are kidding, right?

</comment><comment><USER52> Ubuntu 18.04 is horrible on this.

The default GUI package manager, "Ubuntu Software" shows up snap packages just like ordinary packages. It was uploaded by somebody who is not bright at the domain and badly configured for locale. It can only handle ASCII characters. Probably reviewed by nobody.

</comment><comment><USER42> Can somebody explain the need for this new package management thingy when apt exists and works nicely? Why have 2 softwares to do the same thing.

<comment><USER7> I agree; I have zero interest in installing software using anything other than my system's default package manager. The whole point of package management is centralization, keeping track of chaotic dependencies and install states. Having multiple package managers, that don't know about each other's state, on the system defeats the purpose entirely.

</comment></comment><comment><USER53> >For example, the 2048buntu snap was submitted as proprietary, so we can't actually see the package contents, except for the init script which you can see above.

Unless the Snap Store uses some kind of DRM, I don't see how that can be the case. Just install it and see the contents in your filesystem?

<comment><USER54> It probably refers to distribution of binaries without source code, which MIT license allows. Wording could be better

</comment></comment><comment><USER55> One more confirmation that Ubuntu cannot be recommended anymore.

<comment><USER56> I think it would be useful if such declarations followed up with an alternative suggestion.

I have no alternative suggestion, because Ubuntu is still what I would recommend to new users even if it's not what I personally use anymore, because they have the track record for getting new Linux users on board and helping them out (via the prominent search results for common problems people come across, etc). On the whole, I also think their design has been consistently decent (including Unity).

</comment></comment><comment><USER57> > Nicolas Tomb used a proprietary license for at least some of his snaps. For > example, the 2048buntu snap was submitted as proprietary. The game in > question, 2048, uses a MIT license

No! MIT is not a proprietary license!

<comment><USER58> The article doesn't say it is. The snap uses a proprietary license which is possible since the game on which the snap is based uses MIT - which allows redistribution under a proprietary license.</comment></comment>


Show HN: Learn blockchain with a handbook full of interactive examples - <AUTHOR> https://blockchainhandbook.io <comment><AUTHOR> Hey everyone,

I'm sure some of you have been down the Bitcoin or blockchain internet rabbit hole once or twice. I normally come out with questions or confusions.

I wrote, proofread, and coded the interactive examples for this short book in 7 days. This handbook is meant for anyone, and I hope helps some of you wrap your head around some of the things I struggled to understand.

Just looking for some feedback :-)

</comment><comment><USER2> Definitely sharing. Thanks!

</comment><comment><USER3> Great!</comment>


Fantastic to fugly: All the new app icons in macOS Big Sur - <AUTHOR> https://www.cultofmac.com/715717/fantastic-fugly-all-new-app-icons-macos-big-sur/ <comment><USER2> It's comparable to GNOME's calling Nautilus file manager 'GNOME Files' which is, in my view, disrespectful and takes away its 'personality' by making it sound like a generic file manager (which it sort of is, but that's beside the point). Imagine how people (who know the actual name of the software) would feel if Adobe 'Acrobat' Reader was renamed to 'Adobe PDF reader'

Ultimately, most of the new icons lack the level of detail the current ones have and will lose that in an attempt to achieve a 'coherent' icon shape.

</comment><comment><USER3> I've always wanted these icon changes, for like 10 years!

There's a thing called symmetry you know...</comment>


Next Generation MITnet - <AUTHOR> https://gist.github.com/simonster/e22e50cd52b7dffcf5a4db2b8ea4cce0 <comment><USER2> So they knew that IPv4 address space is nearing exhaustion, and they that they are using only 2 mln out of 16 mln addresses yet they decided to wait until now? And instead of returning the addresses (like Stanford did) they want to sell them?

<comment><USER3> Sort of reflects on MIT's business school (Sloan) vs. Stanford's, I'd say.

<comment><USER4> Why business schools rather than institutes as a whole, bureaucratic structure, beliefs of particular powerful people on campus, etc.? I'm not sure what this comparison has to do with Sloan and GSB.

<comment><USER3> MIT found a way to monetize something that Stanford had given away for free. Not saying it's right, but it's a business decision. Also, it's a joke. People seem to be taking it rather seriously, which says more about their levels of (in)security than anything.

</comment></comment></comment></comment><comment><USER5> This has been said many times in many places before, but the decision _not to_ design IPv6 such that it is backwards-compatible with IPv4 is one of the worst technical decisions ever made, at least when it comes to organically adopting a new standard.

The second worst decision would be not auctioning off their 16 million IPv4 addresses, right now, probably at peak value of around $250 million.

<comment><USER6> There are a whole host of standards to support interoperability between v4-only->v6, v4/v6->v4, v6-only->v4 addressing. I know it doesn't answer your complaint, but really there is little "backwards compatible" to be done with 32 bits of address + 16 bits of port that doesn't look like another version of NAT, and we all know how much the tech community loves to hate on NAT.

The transition hasn't really been that bad, it's picking up pace precisely because there is increasingly valuable commercial logic in doing so (v4 addresses cost a fortune, as you noted!)

I've been surprised on a number of occasions recently to notice I've been communicating by v6 from public wifi, other peoples' homes, etc. Progress is slow but it is also sure.

In the UK, once BT flick the switch on their home offerings, there will be very few significant sources of v4 traffic left in the UK still awaiting transition

<comment><USER7> > _we all know how much the tech community loves to hate on NAT_

This, I think, is the unpopular but true reason the IPv6 transition has been slow. It ties together two changes, "get rid of IPv4" and "get rid of NAT", and making a business case for doing both of those simultaneously is very hard. Lots of people understand NAT. Lots of vendors understand NAT. Lots of managers understand NAT. ("NAT", of course, means "PAT with implicit firewall," but "NAT" is the term people use.) You _can_ get the same security and privacy benefits and an equally good or even better design without NAT, but that's not what people are used to.

If IPv6 had been a straightforward extension of IPv4 to 128 bits instead of a bunch of cool and reasonable and backwards-incompatible ideas, the transition would probably be done already. The tradeoff, of course, is we'd still be on the same quality of architecture we have on IPv4.

<comment><USER8> How exactly would this straightforward extension of IPv4 to 128 bits look like? How would it differ from how IPv6 today looks like?

Frankly I can't see any way (that has at least some degree of sanity), to make a backwards-compatible replacement for IPv4 with significantly more address space than IPv4.

<comment><USER7> No implication that NAT is bad. 6to4 space (and RFC 4193 space, if needed) would be explicitly okay for use with NAT, like RFC 1918 space. Allow NAT from IPv6 on the inside to IPv4 on the outside, as well as IPv6-to-IPv6 NAT.

Extend ARP to support IPv6 addresses instead of designing NDP. Use DHCPv6 like DHCPv4. Don't have SLAAC; encourage the use of existing techniques (static addressing or DHCP). Don't have RAs.

Don't have privacy addresses, because they're not needed, because NAT is expected. Don't have Teredo, because again, you're expected to get IPv6 addressing from some NAT technology.

Note that I'm not super advocating for extending the IPv4 _space_ to IPv6, except via 6to4 if you want to. IPv6 continues to be its own space. But the advantage here is that you don't have compatibility problems from clients that support RDNSS and not DHCPv6 (looking at you, Android) or vice versa, because the way you do things in IPv6 is just like the way you do them in IPv4 and you can use the existing software stack with just a different typedef. You don't have problems with IPv6's infatuation with multicast and aging network architectures that only begrudgingly support it and fall back to broadcast quickly (cf. [https://blog.bimajority.org/2014/09/05/the-network- nightmare...](https://blog.bimajority.org/2014/09/05/the-network-nightmare- that-ate-my-week/) ); you're only using network features that IPv4 already requires your hardware to support. And so forth.

No implicit 64/64-bit split in addresses, where if you want to build an equivalent architecture to IPv4 NAT, you must have at least a /64 (there are plenty of service providers that give you a /128, and your only option becomes NAT66). With IPv4, if you get so much as a /31, you can usefully put two computers behind it. With IPv6, there's no way to implement, say, SLAAC with a /127; you have to use static addressing or DHCPv6. And you lose privacy addresses, which means you have less effective privacy than IPv4 NAT.

That's the sort of thing I mean by "backwards compatible."

Once we're on IPv6, by all means, convince everyone that you have better ways of doing everything. But if you tie the IPv6 transition to "NAT is bad and if you need it you suck", "multicast is great and if you don't support it you suck", etc., the only thing you'll succeed in doing is delaying the IPv6 transition.

</comment></comment></comment></comment></comment><comment><USER9> Assuming Amazon paid them money for the IP addresses (which are now allocated for EC2 use) it's kind of a shame.

A more forward-thinking deal would have bartered for, say, a lifetime allocation of Amazon Web Services credit.

For the past 5-10 years timeshare computing has grown in popularity again, this time on third-parties' computers. Given this reality and the changes it implies for MITnet -- lots of students and staff spin up "a server" to do experiments that they don't want to host on local physical machines -- it would have been smart for MIT to negotiate some perpetual timeshare credit with Amazon rather than just straight-up cash.

Then (my theory continues) MIT could have allotted some of its information- processing credit for research use and some for student use. They could have given each student a basic quota with the vendor, and reserved some additional information-processing for student projects.

And instead of hiring some full-time staffer to coordinate the distribution of timeshare credit to worthy projects ("I need 100 hours of EC2 c4.large for my thesis") they could have done something really clever and asked students themselves to divvy up the credit via an advisory organization of technically minded folks.

Imagine that -- MIT could have helped support some kind of student information processing board …

<comment><USER10> > A more forward-thinking deal would have bartered for, say, a lifetime > allocation of Amazon Web Services credit.

You'd prefer an unlimited gift card over cash? Amazon is a top provider in cloud services now, but you'd be betting a lot on them in the future and essentially locked into their platform (if you wanted to get fair value for the IP addresses). Cash is a much safer deal, and as noted they will invest it anyway.

</comment></comment><comment><USER11> Previous discussion (where I originally posted this gist): [https://news.ycombinator.com/item?id=14150854](https://news.ycombinator.com/item?id=14150854)

</comment><comment><USER12> > David Clark, a Senior Research Scientist at our Computer Science and > Artificial Intelligence Lab (CSAIL) quickly saw the importance of these > addresses and requested an early allocation of them, both to support > research and eventually to support all of computing at MIT. We hold a block > of 16 million IPv4 addresses.

Smart man.

Anyone got a guess as to how much money this sale might raise?

<comment><USER13> This was (indirectly) on HN yesterday... [https://news.ycombinator.com/item?id=14150854](https://news.ycombinator.com/item?id=14150854)

I'm seeing numbers between $10-$20 per IP, but this is also probably a bulk sale so there might be a discount... Say +/\- $250 million?

Perfect time to sell them off as the IPv4 shortage tightens and IPv6 hasn't reached critical mass yet.

<comment><USER14> > _but this is also probably a bulk sale so there might be a discount_

I was thinking the opposite - isn't the block (or a sub-block) worth more in bulk than its constituent addresses?

In the same way that a complete collection of N Foobars has more value to a Foobar collector than N times the average value of a collectable Foobar.

</comment></comment></comment><comment><USER15> They should do the responsible thing and give it to ARIN. They don't 'own' the IPs and really have no right to sell them.

With that said, they basically built the Internet so I won't hold it against them.

<comment><USER7> ARIN doesn't 'own' the IPs either.

(The fact that MIT refused to recognize ARIN's rights over the IP space was historically why ARIN never gave MIT an IPv6 prefix, or so I hear....)

<comment><USER16> I've never signed the legacy registration agreement for my IP space, either. I've had it since 1993, before ARIN existed.

<comment><USER17> What did you do with it ?

<comment><USER16> I have it routed to a rack at a local datacenter. I use it for hosting personal projects, etc.

</comment></comment></comment></comment></comment><comment><USER18> Wow, they only use 2 million out of the 16 million addresses in their stockpile? It would be interesting to be able to trade IPv4 addresses on an exchange.

<comment><USER19> There's stuff like [http://www.ipv4auctions.com/](http://www.ipv4auctions.com/)

We recently bought a /24 for ~$4k and now use it with Vultr's BGP support.

</comment></comment><comment><USER20> Won't this just delay the adoption of IPv6?

<comment><USER21> Depends, some who cant migrate will keep living on these, and maybe later switch. Maybe even helping those migrating to do so by ensuring future customers in a while.

</comment></comment><comment><USER22> " Our intention is not only to advance our own agenda, but to help shape the future of the on-line world. For instance, non-technical issues are now shaping the future of the Internet as much as, if not more than, technical innovation."

Did they just say they were going to be funding politics and activism with most of the money?

<comment><USER3> No. They're more likely to be talking about social-science research, and tools to apply that research. How about better tools to understand public sentiment, to analyze or sort content, to facilitate positive online interaction? How those tools are used might be political, but the science and technology behind them are not.

</comment></comment><comment><USER23> It was only a matter of time before this happened, I've been trying to come up with ballpark estimates as to how much they could have sold the /9 for but I can't seem to find too many numbers on how much a block of ip address actually costs.

<comment><USER24> $11-15 per IP and that was what I was seeing three years ago. So if that lower end is still valid (would seem unlikely) then something over $90 million.</comment></comment>


"We are considering adding an extension to restrict the use of WebRTC" - <AUTHOR> https://bugzilla.mozilla.org/show_bug.cgi?id=959893#c116 <comment><USER2> I don't understand why a peer-to-peer network connection is different from Ajax. Browsers don't require user approval for 3rd-party XMLHttpRequest connections. WebSockets are even more permissive. Why is WebRTC being singled out here?

If I were a conspiracy-minded person (I'm not), I'd have to wonder if this was some kind of corporate-driven attempt to suppress peer-to-peer networks. In fact, I do think this is being done in good faith (even though I strongly disagree), but other users will not be so understanding.

Edit: s/advertiser-driven/corporate-driven I think there are a _lot_ of big companies, particularly social media, that have a huge vested interest in suppressing web-based peer-to-peer networks. Not claiming that's what's happening here, but the threat posed by WebRTC to those companies is very real. At present, a peer-to-peer Twitter would not be impossible to pull off technically with WebRTC, a DHT, and a modest number of STUN servers. The hard part is convincing users it's in their best interest to switch, but if that could be accomplished...

<comment><USER3> For one, the way it's implemented now, it's only a matter of time until we see WebRTC torrent malware downloading copyrighted files to give copyright holders a reason to sue / C&D users.

In a time where sharing an MP3 can cost thousands of dollars, having a protocol that can share data like that without the users' consent is crazy.

<comment><USER4> What is crazy is that "sharing an MP3 can cost thousands of dollars", not any protocol.

<comment><USER3> Agreed, but it's not something that we can easily change.

Cases like the one I described could actually help by giving users plausible deniability, but that would just end with browser developers being pressured into disabling the feature.

</comment></comment></comment></comment><comment> SG- I think the sensible solution (and this goes for anything where there's security or privacy concern like WebGL) is to block it by default however to prompt the user that the website wants to use WebRTC.

The user can then choose to allow it for one time or to whitelist or blacklist the site.

<comment><USER5> > and this goes for anything where there's security or privacy concern

It would force web developers to think much harder about feature detection and being non-intrusive about their usage. If someone gets nagged to enable webrtc just to read some news article it might actually cause some head scratching.

cross domain cookies, local storage, video/audio playback (at least in background tabs), ...

You could even make an argument for cross-domain javascript.

Sometimes it's insane what crap shows up in µMatrix. More requests going to 3rd party sites than the actual content that I want to look at.

</comment></comment><comment><USER6> Could somebody please explain whether it is a technical requirement to leak the internal IP address for this technology to succeed or, if not, what possible reasons could exist for this design decision?

<comment><USER7> It is a technical requirement, because the protocol attempts to connect over the local network if both peers are under the same NAT. The local IP is shared so that the peers can attempt to make a local connection.

<comment><USER6> I'd assume that this is a rather rare usecase in the world wide web, so why is it not disabled by default?

<comment><USER2> No, it's not rare. This is something _all_ peer-to-peer networks running over IPv4 must do. WebRTC video, audio, or data wouldn't work without this.

<comment><USER8> Things worked fine before ICE. In fact, stuff like Bittorrent still works fine. If they were truly concerned with connectivity, they'd use upnp. But since that wasn't a standard from a friendly body, they added this ICE hack to try to make things work.

<comment><USER9> As someone who's implemented a P2P feature for an application: UPnP works great... if you have a router that supports it. Many in the wild do not. If yours doesn't, you have to manually port forward, which, even disregarding the newbie user issue, isn't possible if you're connected to someone else's network. Otherwise, as I assume you know, you can only initiate connections, not receive them, which means you can't talk to anyone with the same limitation - which might not be fatal to your BitTorrent download, albeit limiting your speed, but kinda sucks in something like a one-on-one video chat or game session.

AFAIK, all major video chat applications use some variant of STUN, on which ICE is based, along with some proxying mechanism for users who truly can't connect directly to each other, which corresponds to the rest of ICE.

</comment></comment></comment></comment></comment></comment><comment><USER10> Does anyone else feel that there's something terribly odd going on when _restricting_ something needs to be an _extension_?

IMHO it should be a configuration option, per-site, and off by default. WebRTC also isn't the only thing that applies to.

<comment><USER11> The recent moves to turn the browser into its own OS are worrying. The problem I see is that no one seems to care. Its full steam ahead and its only later do we realize that these new feature and standards are trivial to abuse. I really wish there was some kind of web mission statement on where browsers are going instead of this kitchen sink approach.

I have no idea what the W3C is thinking. I don't think even the W3C knows what its thinking. Its just being reactionary; trying to turn HTML5 into a "flash killer" and shoving feature after feature into the spec. I don't want to piss on progress, but I think privacy and security concerns get a backseat with W3C members, especially Google, whose very existence is dependent on finding information about users to sell to advertisers. Soon we'll need sandboxing and privacy apps to wrap our browsers in. I really hope Mozilla leads the way to pushing back on this recent mad push of thoughtless progress. A more moderate approach would be very much welcome and having more "off by default" options for easily abused features like P2P in the browser, which is what webrtc really is, makes sense.

Right now I had no idea what my browser is capable of. Can it silently turn on my camera and microphone? Probably. Can it make all sorts of crazy p2p connections to various servers/clients silently? Probably. Its all a little scary.

<comment><USER12> > no one seems to care

Article about browser feature creep, currently on frontpage: [https://news.ycombinator.com/item?id=9961613](https://news.ycombinator.com/item?id=9961613)

People do care about this stuff. Maybe not enough people, and maybe not the right people to do anything about it. But there are people right here on HN who do care about this stuff.

<comment><USER11> I was pleasantly surprised to see that article on the front page. It wasn't up when I posted my comment. I do hope this becomes a major issue.

</comment></comment></comment></comment><comment><USER13> Chrome users, look here: [https://chrome.google.com/webstore/detail/webrtc- block/nphkk...](https://chrome.google.com/webstore/detail/webrtc- block/nphkkbaidamjmhfanlpblblcadhfbkdm) or [https://chrome.google.com/webstore/detail/webrtc-leak- preven...](https://chrome.google.com/webstore/detail/webrtc-leak- prevent/eiadekoaikejlgdbkbdfeijglgfdalml)

<comment><USER14> For Chrome, UBlock Origin also has the option to prevent WebRTC IP Leaks: [https://chrome.google.com/webstore/detail/ublock- origin/cjpa...](https://chrome.google.com/webstore/detail/ublock- origin/cjpalhdlnbpafiamejdnhcphjbkeiagm)

<comment><USER13> How cool, thanks. Have not seen that before!

<comment><USER14> This and uMatrix ([https://github.com/gorhill/uMatrix/wiki](https://github.com/gorhill/uMatrix/wiki)) both forked from HTTP Switchboard.

uBlock is an adblocker, uMatrix has finely grained matrix controls for which http requests are even allowed to go through and requires tuning for most sites. I like having both :)

</comment></comment></comment></comment><comment><USER15> What the fuck, this leaked your real IP behind VPN since January 2014 and this isn't fixed yet? This sure looks like a Heartbleed-tier high-priority security hole to me. How is this not bigger news?

<comment><USER16> Leaking a client IP address is not even near the same universe of severity as remotely obtaining a web servers private TLS key. Given the lack of perfect forward secrecy used by web servers at the time, Heartbleed was a "read any encrypted traffic sent by the server, ever" issue.

<comment><USER17> WebRTC doesn't just leak the client IP address, it also leaks the public IP address of all network interfaces on the machine. If you're on a VPN, it can mean you leak your real IP address, too. Many Chinese use VPNs to circumvent censorship or participate in speech, so leaking your real IP address is potentially life threatening.

<comment><USER16> Yes, and Java can leak your real IP address and Flash can leak your real IP address.

If you attack scenario is trying to circumvent authoritative governments, don't use a web browser with extra features or plugins like WebRTC turned on.

"Hiding a users 's true IP at all costs who are using a VPN" is not a reasonable design expectation for mainstream browsers. They are fixing bugs and adding features. This is an extreme edge case at best for them.

<comment><USER17> You listed two things that are optional plugins and are being aggressively deprecated.

The vast majority of Chinese users who use VPNs aren't technologically savvy and just want to read the NYTimes or watch Netflix. Now any embedded ad or tracker can rat them out[1]. We shouldn't ask them to jump through 15 hoops or deal with the the slowness of Tor. A VPN offers a very good compromise of ease vs. security for casual users.

[1]: [https://webrtchacks.com/dear-ny-times/](https://webrtchacks.com/dear-ny- times/)

</comment></comment></comment></comment></comment><comment> j-pb In other news, Mozilla is considering the restriction of IPv6, because it leaks the internal IP.

(VPN leakage is a valid concern though)

<comment><USER18> VPN leakage, like the NYT did, is definitely a concern that can't be dismissed.

</comment></comment><comment><USER19> I hope Mozilla takes a quick decision on this based on its own principles. This sentence saying "we are considering adding an extension" seems to be in stark contrast with the way Pocket was added into the main browser instead of being an ad or recommendation on the new tab page.

</comment><comment><USER20> Why can't they just disable WebRTC by default and ask the user for permission like they do with location and so on, without revealing the IP _before_ the user accepts the connection? Also, maybe the user could easily whitelist some connections/WebRTC IDs?

<comment> jon-wood I'm not sure asking permission really helps. With things like location and video end users at least know what it means, and can make a somewhat educated choice. How do you properly ask an uneducated user the question "Should this site be allowed to open an arbitrary data connection?" \- sites that want to will think of some vaguely plausible reason and users will click away.

</comment></comment><comment><USER21> I submitted this a few weeks ago and it got removed from the front page, but I think it's relevant for anyone interested.

[https://news.ycombinator.com/item?id=9900168](https://news.ycombinator.com/item?id=9900168)

</comment><comment><USER22> How about not disabling it, but merely making use of it visible? (e.g. an icon or a notice in the addressbar)

It would discourage reputable sites from abusing it, because users would start asking questions why a news site wants a p2p/videoconference connection.

<comment><USER23> Because if you really need to be anonymous, it's not good enough to catch it being used after the fact.

Notifying the user after the fact sometimes works for things that are nuisances, but isn't good for privacy/security (imagine if your browser would execute unsandboxed JS and show you an icon each time it did it).

<comment><USER24> It wouldn't have to be after the fact. Firefox already has a little pop-up when sites want to get your location. The options are yes/no/never for this site.

<comment><USER23> Definitely, though that's not the suggestion I was responding to.

</comment></comment></comment></comment><comment><USER25> Is there another problem besides leaking your IP address(es)? It sure sounds like that could pretty easily be solved by just sending hashes of the IP addresses along with the salt used to make the hashes. Then the receiver could compare it's own hash and know if it's on the same network.

I suppose there might be a problem with IPv4 since there are so few IP addresses, so you'd still be vulnerable to targeted attacks, but it would solve the ad network problem.

Am I missing something or just underestimating the usefulness of hashing?

</comment><comment><USER26> I don't really understand how it can leak the real IP address when using VPN. Since everything is going to the VPN anyway, how this would work ?

<comment><USER27> Your network interface still has information about your regular internet connection, even when connected through a VPN. Local apps can query this information. Webrtc clients do this in order to assist setting up direct connections -- it doesn't know you're using a VPN, and will happily hand over info about your network interface to any site.

</comment></comment><comment><USER28> If Mozilla is really concerned with leaking user information, then the extension should extend the use of WebRTC with a default to restrict the use of WebRTC

</comment><comment><USER29> Wow, big deal. An _extension_. Oh noes.

Plug-ins and extensions are, like, mostly non-existent entities, when released under circumstances without any actual demand for them. (compare/contrast: Java to AdBlock)

      > But-but-but evil corporate overlords!

So what? They can do whatever they want on their core networks, so long as it doesn't bleed outside their edge.

</comment><comment><USER30> If they restrict WebRTC then they restrict decentralization and that would move Mozilla out of the Freedom column and into the Fascism column with Microsoft.

<comment><USER31> Do you know what "Fascism" means?

</comment></comment><comment><USER32> The external IP is leaked, too! Clearly this peer to peer encrypted video protocol needs to be restricted, for the good of privacy and security, of course.

Sarcasm aside, what good can 192.168.1.4 possibly be to anyone?

<comment><USER33> It makes it somewhat easier to XSS into your router.

(P2P encrypted video? Great. P2P systems in the browser driven by Javascript from any web page or ad network? Less great idea there.)

<comment><USER2> Can you expand on this, please? How does it make it easier to XSS?

<comment><USER34> Well, I'm not sure about XSS, but imagine you know someone's home IP is:

192.168.1.10

Based on this, you can probably guess the router is 192.168.1.1 and maybe even have a clue about the vendor based on the IP assigning patterns.

Then you can direct them to a page with an submitting POST <form> that makes modifications to their router settings. This is more like CSRF than XSS though.

<comment><USER35> funny, of all the routers I used (all were provided by my ISP), their IP were 192.168.1.254</comment></comment></comment></comment></comment>


You sure you've got a floppy disk in the drive? Or is it 100 in the chassis? - <AUTHOR> https://www.theregister.co.uk/2019/03/29/on-call/ <comment><USER2> Pretty sure this one is an Urban Legend, and not actually true. It was doing the rounds back when 5 1/4" HDDs and 5 1/4" Floppy Drives were current equipment.

<comment><USER3> I'd not be that sure. My son (then 5 or 6 years old) managed to insert a CD exactly into the gap between two devices on a tower. He insisted on having the CD inserted although the CD player apparently was empty. It took me a while to figure this one out.</comment></comment>