They're doing dual stack, not ipv6-only with nat64/dns64.
267 karma · joined January 30, 2013
Not entirely true, publishing the code isn't the same as allowing its modification. Code signing can be used to limit which versions are allowed to run.
Reproducible builds of the source would allow one to ensure that the binary, certified version of the code their baseband processor is running is legit (i.e. not backdoored). It would also help audit the code and spot security holes.
ufw comes pre-installed on ubuntu and is dead simple to use, there's really no reason not to use it.
# ufw allow 22/tcp
# ufw enable
To answer your question, lftp [2] on the command line, cyberduck [3] on osx. Both of these tools are capable of connecting to sftp servers, too.
Also, sshfs (+ osxfuse for osx) [4] is definitely worth a try.
[1] https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13
Try OSMC [1], it's a massive improvement over Raspbmc and is being developed actively. Works like a charm. If I'm correct, the main Raspbmc dev went over to OSMC a while back.
[1] https://osmc.tv
Use key-based authentication, disable password auth in sshd_config and install sshguard.
If you're an ISP, you could probably put multiple nat64 boxes in the core so that all your customers benefit from it and can gradually switch ipv4 off (since they can transparently reach ipv4 endpoints through the nat64 gateway).
Then there are a few applications that don't handle ipv6 properly (i.e. skype), and Apple's decision of mandating ipv6 support is meant to fix just that.
Then there is 4XLAT, ds-lite and others which allow for a single stack ipv6 network and carry ipv4 on top of it to the endpoints which need it.
The faster we get to single stack ipv6 only, the better.
What Apple did with iOS9 is improve its address selection algorithm to prefer ipv6 in a majority of cases (if both the device and the server are dual stacked and unless v6 path latency is much greater than its v4 counterpart, v6 will be used).
In contrast, ios8 would prefer v4 over v6 when both endpoints were dual stacked.
Also, from what I've seen, iOS devices won't provision ipv6 addresses on their cellular interface unless their Carrier Profile says they should, so you might have encountered devices not getting ipv6 addresses even though they were connected to a dual stack network. Wifi always uses v6 if the network supports it.
Taking ipfs/ipns [1] as an example, having handlers inside web browsers would allow people to link from http[s]:// to ipfs:// and vice versa in a seamless way, lowering the barrier to migrate.
From there on, there's nothing preventing you from distributing your application code (html/css/javascript/whathaveyou) over ipfs, and make use of WebRTC for user-to-user interactions.
Obviously http[s] is going to stick around for a while as it has its use cases (basically anything that deals with a centralized service, from online banking to search engines to apis), but having a secondary, peer to peer means of distributing content and applications would be a major plus.
[1] http://ipfs.io (they have a working implementation in Go with an HTTP gateway as well as a FUSE filesystem)
hulbee.ch uses an invalid security certificate. The
certificate is only valid for the following names:
*.hulbee.com, hulbee.comIt is packaged in debian, ubuntu and probably other major distros these days.
Coming off that board, I see two large wires (red and black) running to a battery connector and two smaller, black wires running to what looks like a temperature sensor.
Your hand is holding a heatsink for the board's power electronics. The smaller protruding black knobs aligned with the LEDs are most likely push buttons, according to the layout of the device [1].
A temperature sensor in an UPS (what I believe the box is) is very common, as it would require ambient temperature readings for optimal charge and safety concerns. You will also find them in hard drives, TV sets, switching power supplies, etc. You can buy them in bulk on ebay [2], for cheap.
Is that sensor what you believed to be a microphone? Or did I miss something else?
[1] https://instagram.com/p/32-Yn5q3ab/?taken-by=navrajchohan [2] http://www.ebay.com/itm/10-pcs-Thermistor-Temperature-Sensor...
EDIT: added ebay link.
This. It's really hard to stay focused on an article or piece of text longer than a few sentences with flickering images, autoplaying videos (with sound), and recently those pesky javascript overlay popups.
Blocking ads doesn't just make for a faster web experience, it also allows you to have proper attention spans necessary to read and digest two pages of text, and that's true for any kind of audience, tech-savvy or not.
Obviously, privacy invasion, constant and pervasive tracking, malware distribution, profiling and exploitation of personal data in jurisdictions with poor consumer protection laws and over which you have no control or say are all alarming and dangerous.
When people started raising concerns and calling this out a few years back, ad networks (and the tech industry they are living on) came forward with DNT, "voluntary opt outs", privacy policies and "personalized contents and ads".
Most people would probably agree that all these options are equally laughable as they merely try to appease concerns rather than addressing them.
Regardless of my personal opinion, is it really surprising to see people of all kinds start using tools making their experience better? For most people, the web is merely a medium, just like paper books.
1) your app/client will work just fine on ipv6-only networks with NAT64 gateways, making for a better experience for your customers (less breakage on such networks) and will help network operators transitioning to v6,
2) if it does any kind of p2p (think rtp, webrtc, bittorrent, sip, etc.), it will take advantage of nat-free v6 paths for client to client communications, regardless of which address family it uses to talk to the backend.
They sit there idling and unattended, burning power and disks, until some script kiddie finds whatever default root password was used or how to exploit some random apache/ssh flaw.
At that point the possibilities are endless: bitcoin miners are quite unnoticeable in most environments, but DDOS/spam zombies, proxies, bittorrent seedboxes, botnet C&C, "warez" and http servers serving drive by exploits are fairly common.
Protip: ask your datacenter provider to power your servers down (be it VMs or dedicated gear) after racking them up. Powering them back up when you really need them will only take you a minute and you'll save big on power, bandwith, security and peace of mind.
1) L2 address resolution (neighbor discovery), which ARP used to do in ipv4,
2) full network autoconfiguration (global scope addresses, default route(s), DNS resolver), which DHCP used to do in ipv4 (although DHCPv6 is still an option),
3) multicast group management (MLD), which igmp used to do in ipv4,
4) path mtu discovery (through 'packet too big' messages this article references). Routers fragment packets exceeding the link MTU in ipv4, they notify the source of the lower mtu in ipv6.
ping, TTL exceeded, destination (host, route or port) unreachable and parameter problem were mostly carried over from ipv4.
Blocking 1, 2 (and to some extent 3) on a local network will most likely break ipv6 connectivity entirely while blocking the others will only break it in subtle, hard to debug ways (especially with ECMP and traffic engineering where multiple routes for a given destination can be used).
I've found that explaining this before asking network admins to unblock icmpv6 filters is a good way to succeed (although it can be hard, i'll give you that).
People aren't used to filter ARP or link local broadcast in ipv4 (which DHCP uses), so telling them that they need to allow icmpv6 to let stations merely configure themselves is a bit of a mentality change.
At the same time, developers of firewall management tools like ufw understood this problem a while ago and insert a working, good, tried and tested icmpv6 accept list as first rule which you can't mess with.
Telling people to use ufw is usually much better than teaching them ip[6]tables.
Also, they come with upnp and other unnecessary daemons disabled which greatly reduces their attack surface.
"We do not use an SSL certificate because we only provide articles and information" [1]
Also, no mention of the likelihood of law enforcement coming to your door and serving you warrants/NSLs to get customer information.
Marketing your product as anonymous seems really misleading to me. Also please at the very least enable SSL.
You can't trust users to make sane choices when it comes to privacy in the exact same way that you can't expect drivers to decide if a car is safe to drive or not. Joe Sixpack isn't going to use browser privacy extensions, clear their cookies, use tor, etc.
Some entity (probably a government/administration of some kind, but I can see NGOs doing that too) needs to be tasked with enforcing privacy laws in the same way that (at least in most of Europe) you are required to have your car inspected for safety and maintenance every few years.
EDIT: Across the EU, the Commission for the Protection of Privacy [1] would be that entity. There are additional government instances in various member states, like CNIL [2] in France.
[1] http://www.privacycommission.be/en/european-union [2] http://www.cnil.fr/ - http://www.cnil.fr/english/
Using a LB to offload SSL termination might seem like a good idea (you save a bit of CPU, really not more than a few percent in practice), but you expose your customer traffic to capture/inspection between the LB and your backends. This network can span multiple hops or even datacenters.
Also, when the next openssl vuln hits, you can patch your setup in no time and do not need to wait for the LBs to be patched at your vendor's will.
I would still run my editor locally (your pick. I use vim almost exclusively).