Hacker News .hnnew | past | comments | ask | show | jobs | submit | itdaniher's commentslogin

> True diversity means listening to qualified and civil voices...

Referring to the leadership of Heritage as "civil" is a stretch from the point of view of individuals in categories repeatedly demeaned and dehumanized by the members of the organization acting in their official capacities.


All of these are true! Except maybe the first one, which is a gross oversimplification.

"The dose makes the poison" is not something I expect an average Google user to have modeled accurately.

Edit: after reviewing other examples in this thread, my opinion of an average Google user has fallen drastically. Was mostly having a laugh at the fact fluoride salts are generally a thing I avoid, which seems to be the intuition represented by your example.


*ARM processors with speculative / out of order execution are affected.


My understanding is that older A53 implementations of AArch64 / ARM64 are strictly in-order and thus not suceceptible to Spectre etc.


This is great! Thanks for the recommendation.


But don't add all 54 on a magnet/torrent, two should be enough, maybe four at most.


I don't understand why, but I believe I've observed similar. Possible hypotheses include:

DHT Sybil attack? Hash ring bloat? Bad peers distributing exclusively irrelevant content?

Wonder if this is a common observation, and if so, what kind of research might elucidate the underlying change.


It's visible verbatim in an archived version of the page. See:

https://web.archive.org/web/20141226094343/https://developer...


Maybe once upon a time, but with blobless mainline Linux kernel support for almost all features on almost all SOCs[1], including video codecs on many parts[2], anyone claiming Allwinner to be "the devil" or variants on a theme is unambiguously incorrect. Broadcomm and the raspi foundation are evil. [3][4]

[1] https://linux-sunxi.org/Linux_mainlining_effort

[2] https://www.kickstarter.com/projects/bootlin/allwinner-vpu-s...

[3] https://twitter.com/marcan42/status/1088472549715918848

[4] https://github.com/raspberrypi/firmware/blob/master/boot/LIC...


Running a build of Ayufan's 4.19 patches on a rock64 with latest dev device tree from the Armbian project. Eth runs close to theoretical, finally, and I've not observed any issues with USB3 either. Months of uptime, TB of traffic.

Here with the rock64 it was just a matter of time till hardware support settled in mainline, and it seems like we're there!


> your software will automatically update to the full released version at no additional charge.

So, give your proprietary software both network access and access to all my source code?

I have very few complaints about the Jedi autocomplete library, which is neither proprietary nor requires network access.

I welcome innovation in dev tools, but I wish you had found a monetization strategy that didn't require us to trust you so completely.


Your concerns are understandable. It is about as risky as installing an editor plugin which updates automatically.

The private keys used to sign releases are kept offline and would not be available to an attacker even if they compromised my online accounts.

Finally, TabNine will work correctly if you deny it network access (say, by blacklisting update.tabnine.com).


...as risky as installing a proprietary editor plugin which updates automatically, yes.

Also, AFAIK most understandings of MIT, BSD, and Apache 2.0 licenses require you to acknowledge the copyright holders of the source code you compile into your binary, even if the licenses permit binary distribution. I can't find your "Copyright (c) 2018 Tokio Contributors" or "Copyright (c) 2014 The Rust Project Developers" that I'd expect based on `strings TabNine | grep github`. Maybe you've got a lawyer that suggests otherwise? Your plea of "trust me, I have good hygiene" carries less weight when I have to `strings` your stuff to know what shoulders of which giants you're standing on.


> ...as risky as installing a proprietary editor plugin which updates automatically, yes.

Can't you make the same complaint about any auto-update functionality in any software? Even if it's BSD licensed, you're still counting on whomever has authority to push an update to not push malicious code.

This doesn't seem to have anything to do with the fact that his code is proprietary nor his monetisation strategy, so why are you singling him out for those?


Proprietary - Can't patch out the autoupdate, which I might be tempted to do if something else in my toolchain did things at someone else's leisure.

DRM/monetisation - the product as of my comment didn't seem to acknowledge the open source works compiled into the binary, and I didn't think that was a good look for someone with the authority to push out malicious code.


As risky as ones that don't update automatically either. Just because a plugin doesn't update automatically doesn't mean it doesn't still have the capability of doing network access. Unless you're actually sandboxing all your IDE plugins and denying most of them network access (and verifying on every new IDE plugin you install whether it's allowed network access), but I don't believe that's how IDE plugins generally work.


MIT only requires source attribution. It's the BSD licenses that require attribution for binary forms of redistribution. Still, it is good manners and good cover-your-arse practice to attribute whatever free software work they used (Google does this with their giant "open source licenses" page).


MIT has no special language regarding source or binary distribution, it simply states:

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

It's up to a court to decide what "copies or substantial portions of the Software" means.

Personally, I've always very much interpreted that to mean both binary and source.


Well, you could argue that the notice is "present" (in a very esoteric sense) in a binary distribution of the software because it was present in the source code used to build it. You could also argue that a compiled version of a program isn't a "copy or substantial portion" of the Software (compilation is effectively a form of translation, which is a derivative work under the Copyright Act in the US -- and not just a copy).

Personally I would still include it in both, but I always had the impression that MIT was looser than BSD-2-Clause about this. BSD-2-Clause explicitly states that binary distribution needs to include the notice in "the documentation and/or other materials provided with the distribution", and I have a feeling that the license authors might've had a reason to want to be explicit about it.


Does the Vim version autoupdate? I'd rather it wait for me to run my plugin manager- I specifically don't want anything on my machine to update when I'm on-call or traveling.


Wait, is the auto-update all that's needed for network? I assumed it was license validation or something. If it's just updating, couldn't you provide a different method of updating like manual update checking, and then peoples concerns would be solved?


No, it does use the network to validate registration keys. Presumably this means a TLS connection per invocation of the binary.

> TabNine makes web requests only for the purposes of downloading updates and validating registration keys.

from https://tabnine.com/faq


> Finally, TabNine will work correctly if you deny it network access (say, by blacklisting update.tabnine.com).

Just to clarify - would it still work if I deny network acess for the TabNine binary, _after_ validating my license key? Or is the key validation invoked on every launch (hence requiring network access)?


Yes, it will still work.

(License key validation requests go to tabnine.com, so you should blacklist that too if you want to deny all network access.)


Thanks! Purchased a copy :)


I agree with your concerns - I wonder what could be written to alleviate them? This brings up an interesting problem.

Ie, could we write a monitoring proxy where if enabled, all traffic goes through this proxy. This proxy enables the end user to monitor 100% of traffic, all http requests, and could even have a secondary documentation flow that explains the I/O for security minded individuals.

Then you'd shut off remote network access to the binary, monitor all traffic, and feel secure knowing that it's only sending what it says it's sending, and why.

With that said, I imagine you could do the same thing with a sniffer. Perhaps a documentation standard could be built into request/responses, so a monitoring program like Wireshark could snuff the I/O and see what it is.

Do you have any thoughts on how someone could both network-license, and make you feel secure in their I/O? Ie, no trust needed?


I don't think a DRM solution that is both robust against an adversary and inspectable by a stakeholder can be engineered. Software can't look out for both the person running it and the person selling it simultaneously when their needs are mutually exclusive. Cory Doctorow has some eloquent content on the topic, ie at [0].

In this particular case, the use of TLS (good!) makes it relatively challenging to inspect. Assuming the author isn't shipping a cert in his binary (doesn't look like it) - I'd have to spinup a new VM, load a custom root cert, and mess with a TLS terminating proxy / forwarding solution, and hope he's not using a secondary stream cipher on top of TLS. Maybe I get lucky and https://mitmproxy.org/ or something just works out of the box. In any case, lots of effort to know he's not siphoning up all the source code on the local machine and using it to train v2 of his project. And the more robust the DRM solution, the less feasible it is to inspect.

[0] https://github.com/jwise/28c3-doctorow/blob/master/transcrip...


If the amount of traffic is predictably small though, you can be confident that it’s not uploading the entirety of your source code, so perhaps some mechanism to estqblish that would help?


Some code is a lot more valuable than other code. For example, token files for connecting to remote servers.


There is no good reason for authentication secrets to be in your source tree though.

I’m not suggesting this is perfect in any case, but it would at least place an upper bound on whatever amount of IP leakage you think might happen.


But do you ever edit your authentication secrets in your text editor? I edit my .env file in vim all the time.


A combo of two applications: main app and network agent. Main app writes to a file with request, registration check or update, in JSON or other text-format for user inspection. It loads the agent which reads same file, applies operations, sends them to 3rd party, and writes result into another file. Main app reads that the second it appears. To keep it simple and not have to delete, the files might be numbered with old exchanges kept unless admin/owner deletes them.

With such a setup, users can see exactly what data is outgoing, have a reasonable belief they know what's incoming is harmess, main app gets no network access, agent has no access to secrets/system, and agent can be open source (entirely or mostly).

So, there's a quick brainstorm from how I did privilege-minimization for high-assurance security. This is basically a proxy architecture. That's a generic pattern you can always consider since it can help protect lots of risky apps both ways.


Take a look here for some solutions:

https://www.openmined.org


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: