Ask HN: How prevalent is non-cookie-based web tracking today? - <AUTHOR> I just started reading about things like Header Enhancement and SuperCookies and find them to be quite egregious. Does anyone know how much of this activity is being used by big known companies?<p>For example, I just found out that my account settings at Verizon Wireless were allowing them to use Header Enhancement (UIDH) adding a unique identifier on every http request I sent. So, if I log in to a site, they can associate the UIDH with my account so next time I'm in browser incognito mode, they already know who I am (or have a good guess). <comment><USER2> Trying to circumvent tracking at the browser level is hopeless.

The only effective approaches that I know of are 1) using Whonix (best in Qubes) to connect via Tor; and 2) using multiple OS-level VMs that connect via different nested VPN chains.

And even then, there are risks from fingerprints that depend on GPU and virtual graphics drivers in VMs.

So when compartmentalization really matters, it's necessary to use different host machines, on different LANs (or at least vLANs).

Using Tor is rather painful, given all the CAPTCHAs. And the learning curve for Qubes is a little steep.

But using multiple VMs with different nested VPN chains is actually quite convenient, once you've set it up. I use a pfSense VM as the gateway router for each VPN service. So creating nested VPN chains is easy: You just create virtual networks of the pfSense VMs, with Linux workspace VMs wherever you like.

With a decent host machine, I can work ~seamlessly as a few low-isolation personas via nested VPN chains, and another few high-isolation personas via nested VPN chains and Whonix instances.

<comment><USER3> Not sure about the priorities here. Fingerprinting should be the main concern, so steps 1,2,3 are obscuring IP address and disabling cookies and JavaScript. Even beyond that, not sure how chaining VMs etc helps much more than a single VPN.

Although an ideal solution would spin up a random VM, browser, screen size, and tor connection for each new web page visited...

<comment><USER2> > an ideal solution would spin up a random VM, browser, screen size, and tor > connection for each new web page visited...

Sure. I wouldn't limit it to Tor, though. Because there are just too many CAPTCHAs. That's much less of an issue using VPNs.

Chaining VPNs is arguably overkill for avoiding fingerprinting. Still, trusting a single VPN service is risky. If they were complicit, you'd still be tracked. But if you at least chain two VPN services, there's less risk. Overall risk is more or less the product of all the individual risks, if they're independent.

Edit: If exploit resistance is less of an issue, it's easy to chain VPNs at the Linux OS level using ip route and iptables. Iptables rules drop everything on enp0s3 except traffic to the first VPN server, and drop everything on tun0 except traffic to the second VPN server.

You set enp0s3 as the route for the first VPN server. After connecting to it, you set tun0 as the route for the second VPN server. After connecting to it, you check for leaks using tcpdump.

<comment><USER4> How do you pay for your VPNs in a non-trackable way?

If you pay via credit card, the VPN account has your name attached to it, no? So what good will chaining VPNs do when all the VPNs have your name attached to them?

Bitcoin is also supposedly not anonymous (or so I've heard.. I really don't know much about bitcoin, so please correct me if I'm wrong here), so paying with it sounds like it won't be any better.

Also, I have to ask: Who are you trying to prevent being tracked by? If it's by advertisers, I don't see how chaning VPNs would be any better than using a single VPN.

<comment><USER5> I have been using Mullvad[1] for a year or so now and am really happy with the extent they go to avoid storing payment information. One of the things that caught my eye about them initially is that you could literally mail them an envelop containing your account number and $5 cash and they will add that time to your account, which seems to solve what it was you were asking about (although I am sure physically mailing something comes with it's own issues of privacy).

[1][https://mullvad.net/en/help/no-logging-data- policy/](https://mullvad.net/en/help/no-logging-data-policy/)

<comment><USER2> Yeah, love Mullvad. They've been around for about a decade. Along with AirVPN, Insorg and IVPN. IVPN may still accept cash as well.

</comment></comment></comment></comment></comment></comment><comment><USER6> I don't want to go into much detail, but I work for a major company in this space and nost companies in the industry can track you with reasonable success even if you are logged out over multiple devices. Your (approximate) location, browsing habits and patterns are good enough data to predict what kind of stuff you buy.

If you want to not be tracked, turn off JavaScript for a start.

<comment><USER7> > _good enough data to predict what kind of stuff you buy._

Then why are the ads that _do_ sneak through my adblockers or onto Instagram, etc., such hot, moist garbage? Is it just a lack of people wanting to advertise at my demographic?

<comment><USER8> I have been suspicious for a while that all of these companies that claim to know everything about us, or people who are afraid that these companies know everything about us, are wrong.

I don't feel like I am unusual in any way, as in I can't see how I have any natural, dumb-luck defense against any of this tracking. If companies like Google, Amazon, FB, etc, are in any way really trying to use what they think they know about me to get me to buy stuff or influence my thoughts or behaviour, then they seem to be doing a really, really bad job of it.

As far as privacy goes, my concern is far more focused on apps/programs stealing my photos of my kids, or tracking me around town, or knowing who I meet and talk to.

As far as predicting my future behaviour, I have not been impressed so far.

<comment><USER9> There was a point a year or two ago where everyone was recounting these stories of how AI targeted advertising was terrifyingly accurate, it could tell you were pregnant before you found out for yourself, etc. At the time I was routinely opening YouTube with cookies disabled and getting suggested YouTube generated categories with a super low hit rate, stuff like "Recipes" that would be filled with nothing but general interest food videos (i.e. "you won't believe what we found at this market", "we made the largest burrito ever", never with any instructions), "Metal Music" containing a single acoustic cover a metal song and half a dozen EDM tracks or "Role Playing Games" stocked to the brim with Fortnite videos.

I just checked now and it's better than it was but there's still a "DIY" category containing one DIY video, a Japanese cooking tutorial and a video of somebody putting iPads in a bucket of slime. I'm not sure I have very much faith in their ability to deeply infer things about me from a limited dataset when they can't identify videos with ingredients in the description or sort music into genres given the set of all music (and millions of comments on it) to work with.

</comment></comment></comment></comment><comment><USER10> By far the biggest tracking offender is Javascript. Enabling it could reveal your operating system, cpu/gpu architecture, screen resolution, draw a precise and unique canvas fingerprint, etc. There are also mutable browser headers like user-agent and of course your IP address. However, the more advanced and insidious tracking is based on your behavior - what time you're active, what wifi networks are in range, who you communicate with, what is your writing style, and so on. Most of that collection happens on mobile phones, so I strongly advise against signing in on Android/iOS devices if you don't want to be tracked across the Web and beyond, or using telemetry-free open source mobile operating systems altogether.

</comment><comment><USER11> You give a USA specific example, so I'll give one from where I live: aside from a few (like Google, Facebook, LinkedIn) that I suspect do things like recommendations or friend suggestions based on our static IP address, in the Netherlands it's virtually nonexistent. And illegal, at least without telling us that they do tracking (no matter if it's through cookies, the law never even mentions cookie). Header injection (MITMing traffic) is something I only hear about from far away and seems very invasive to me.

Same in Germany, but there they have rotating IP addresses (which is both a pain (hosting) and a blessing (privacy)).

Hmm, although, would MAC address tracking count? That happens here and there (by roughly the same amount in any EU country, as far I can tell, which is not very much), mostly with WiFi captive portals where you sign away your soul in the terms of service. I'm not sure about the legality (hiding GDPR consent in the TOS) but it happens. From experience, I can say that if you find out and you send them a letter with a copy of your ID, they'll happily give you all the data they have on any MAC address you claim.

<comment><USER12> I caught Vodafone and Telekom in Germany injecting headers. The former for shady cooperations and tracking, the latter for cache screwery. The latter did dns modification to turn nxdomain into a navigation help, a site that looks like google but everything is ads.

Vodafone CPE equipment saves all mac adresses ever present in the local network and unassociated wifi client macs in the air and sends them back as part of diagnostic data.

Edit: They also DNS Censor popular warez sites and libgen

<comment><USER13> > They also DNS Censor popular warez sites and libgen

This happens in some other European countries, too, like Italy.

</comment></comment></comment><comment><USER14> Use browser plug ins

* ublock origin

* no script

* cookie auto delete plug in, deletes cookies if tab is closed

* (I use also I don't care about cookies for the EU cookies clusterfuck)

* Canvas blocker

* Privacy badger

* Glyph detection blocker

* Decentral eyes

* Privacy settings

* Privacy-Oriented Origin Policy

* WebRTC leak protection

* https everywhere

* I have a browser spoofing plug-in too but don't think it works so well.

Use VPN

use different browsers for different purposes.

use startpage.com instead of google

Here, try your luck:

[https://amiunique.org/](https://amiunique.org/)

[https://panopticlick.eff.org](https://panopticlick.eff.org)

Does not work so well. Instead of preventing canvas, fonts, browser ID etc., the plug-ins should randomize it.

<comment><USER15> Are you aware of any way to bundle setting for Firefox (or whatever) that include these kinds of changes?

I know you can export the about:config and share that, but I have always wanted a kind of ansible for setting up a browser with plugins and other changes for my personal use.

Additionally, If I could tell my friends and family: Hey just use my Firefox Playbook and feel safe on the internet, thereby reducing the cognitive load of figuring out how to do that, I'd probably have a lot more success helping curious but busy people take control of their privacy.

<comment><USER14> You don't want your family to use my setup. I breaks many things.

A person not in IT is probably just fine if you install ublock Origin.

Or you would have to train your family to use different browsers for different things and you want to have at least one "vanilla" browser on your system. Just recently my US CC website stopped working with my browser. For such things you want to have one major browser without any plug ins.

e.g.

1\. Google Chrome (Vanilla, no plug ins). Used when needed (recently to pay my CC). 2\. Chromium: Facebook, Gmail 3\. Firefox: buying tickets etc. 3\. Vivali Browsing the internet

Again my setup does not work so well against fingerprinting. My plug-in combination is so unique that I can be tracked via my plug ins.

</comment></comment></comment><comment><USER16> Apart from the usual canvas / webrtc in-browser shenanigans, the most surprising one that I found was using a _dns cookie_ to track users across browsers and devices discovered/invented/disclosed by u/DanielDent: [https://news.ycombinator.com/item?id=20219878](https://news.ycombinator.com/item?id=20219878)

> _As with traditional HTTP cookies, DNS cookies can be used to track users on > the web. They have no concept of "first party" or "third party" and can be > read across different websites or from a different browser. They can also be > used outside the web environment, for instance to track a web conversion > which occurs after reading an email but not clicking on a link, or to track > a sign-up in a mobile application after viewing a website. They also have > application in DDoS mitigation - especially on IPv6 networks._

I am curious what other techniques are in active use to track a user across devices / software...

<comment><USER17> DNS cookies are nasty. The POC tracks you between normal and private tabs, even with the Tor browser.

</comment></comment><comment><USER18> Excellent reading for anyone interested the subject from a technical and business/enterprise point of view. This gets rid of the FUD 'browser fingerprinting' and uses actual industry terms.

[https://blogs.gartner.com/martin-kihn/how-cross-device- ident...](https://blogs.gartner.com/martin-kihn/how-cross-device-identity- matching-works-part-1/)

[https://blogs.gartner.com/martin-kihn/how-cross-device- ident...](https://blogs.gartner.com/martin-kihn/how-cross-device-identity- matching-works-part-2/)

<comment><USER19> This is mostly talking about creating a probabilistic ID graph - creating a unique ID across devices. This is technically not same as browser- fingerprinting. Latter is much simpler

<comment><USER18> Yeah that is kind of the point I wanted to get across. Fingerprinting isn't some major secret that big tech is using.. its a small tactic used by some companies that gets more attention than it really deserves. There is a section in part 2 specifically about fingerprinting under the subtitle "DENTIFYING A DEVICE WITHOUT AN ID".

Browser fingerprinting is a single piece in creating an id graph. Fingerprinting would be 100% useless without a graph, unless you're doing it to individuals which would be NSA-level acting.

</comment></comment></comment><comment><USER19> I would think Header Enhancement is not widely used (only few ISPs or so use it) but Browser fingerprinting must be quite wide-spread. It is hard to detect from the client-side so hard to say how wide-spread is it

Here is a study of fingerprinting effectiveness. Not what you wanted but a worthwhile read.

[https://medium.com/slido-dev-blog/we- collected-500-000-brows...](https://medium.com/slido-dev-blog/we- collected-500-000-browser-fingerprints-here-is-what-we-found-82c319464dc9)

<comment><AUTHOR> So, how does browser fingerprinting work. Does it basically look at the 1) IP and 2) Browser Agent pair for near uniqueness?

<comment><USER19> Lots of things from browser settings to what plugins you have.

These guys will tell you how unique is your browser fingerprint

[https://amiunique.org/fp](https://amiunique.org/fp)

<comment><USER20> This should be mentioned here, too [https://panopticlick.eff.org/](https://panopticlick.eff.org/)

</comment></comment></comment></comment><comment><USER21> I can't provide stats on your questions, but as per your example, your ISP can only add headers to non SSL traffic. Any website you access with HTTPS is safe from this type of privacy violation.

So as "Encrypted web traffic now exceeds 90%" [0] I'd guess at least this type of tracking is gone.

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

</comment><comment><USER18> The most common non-cookie based tracking are cross-device graphs that are registration based (reg based) and run by facebook/google/linkedin/pinterest/etc. If you've ever logged in to facebook (or haven't logged in) and a site has a fb pixel or share button, its much easier for them to track you.

These all have cookie/nonreg-based components, and there are plenty that don't rely on reg based data at all.

</comment><comment><USER12> Google Captcha only works if webgl canvas is available. If its not available they give me infinite captchas and never let me through.

</comment><comment><USER22> FYI about these two websites that demonstrate the various data your browser shares:

[https://browserleaks.com/](https://browserleaks.com/)

[https://webkay.robinlinus.com/](https://webkay.robinlinus.com/)

</comment><comment><USER23> Here's an option for adblock + vpn. [https://ba.net/adblockvpn](https://ba.net/adblockvpn)</comment>


Most honest cities - <AUTHOR> http://www.rd.com/slideshows/most-honest-cities-lost-wallet-test/ <comment><USER2> Any statisticians want to chime in here? How many wallets should be dropped in each city before you can reasonably rank them? Or, is it statistically significant that Lisbon was 1/12, while Helsinki was 11/12? In other words, even with the small sample sizes, are those two values far enough apart to state the difference with 95% confidence?

On another note, that site sprang 20 separate trackers/beacons/etc. in Ghostery. I know at least one was Disqus, but 7 were different beacons, and the slideshow itself didn't work correctly without disabling it.

<comment><USER3> I guess the rate would also vary widely depending on which part of the city or time of the day you drop the wallet.

<comment><USER4> Also, quite possibly: day of month (contrast a week before payday vs just after), temporary local events and conditions (high unemployment one year vs the previous), and if the wallet contained a tourist's details: the level of 2nd language knowledge predominant in the country (e.g. the old lady in one of the first slides probably didn't speak English, meaning a barrier to contact or an opportunity for a second individual to pocket the wallet).

Overall though, if you randomised the drops nicely, increased sample size and repeated them a few times, it might be an interesting study.

</comment></comment></comment><comment><USER5> Sorry but this is almost a random test.

What neighborhoods? What days? What hours?

All that can make a difference and quite a big one.

</comment><comment><USER6> Wallet is not a good testing device. It's a common sense in a lot of people that if you see a wallet lying around on the ground, you should never pick that up. If you do, there will be a bunch of thugs showing up from nowhere, claiming it's their wallet (it is) and there used to be 1000 dollars in that wallet (there's not). It's one of the oldest tricks.

<comment><USER7> I have never heard of this trick. It must not be popular in Washington, DC.

</comment></comment><comment><USER8> It would be great to see this methodology taken to its logical end. Decent sample sizes and some transparency in how drop sites were chosen, what the wallet contents were, etc.

The measurement of this kind of empathy seems intuitively valuable. I wonder what it would correlate with. Probably a higher average standard of living, but maybe more homogenous societal values? A smaller population?

</comment><comment><USER9> Meh, article created to maximize clicks, not an objective study by any means. When you have to click for the next city, that should've been a giveaway.

<comment><USER10> The site has according to ghostery 66 trackers on it

that's insane

</comment></comment><comment><USER11> Except for London, the honest to dishonest ranking seems to equate to a prosperous to impoverished ranking.

<comment><USER12> I disagree, there doesn't seem to be a clear relationship with affluence. Here's the list along with GDP PPP per capita at a country level [1]:

      Helsinki, Finland   11/12   35771
      Mumbai, India        9/12    3843
      Budapest, Hungary    8/12   19497
      New York, US         8/12   51704
      Moscow, Russia       7/12   17518
      Ambsterdam, NL       7/12   41527
      Berlin, DE           6/12   38666
      Ljubljana, Slovenia  6/12   27837
      London, UK           5/12   36569
      Warsaw, PL           5/12   20562
      Bucharest, Romania   4/12   12722
      Rio, Brazil          4/12   11747
      Zurich, Switzerland  4/12   44864
      Prague, CZ           3/12   27000
      Madrid, Spain        2/12   30058
      Lisbon, Portugal     1/12   23047

n.b. How about 'least honest source of pageviews' for Readers Digest on this article?

1\. International Monetary Fund, 2012 data.

<comment><USER11> I think you need to look at the City level, not country level - I know from experience that one city in that list is a poor dilapidated hell hole in a wealthy country - but you're right, London isn't the only outlier.

</comment></comment></comment><comment><USER13> As an Indian both humbled and surprised to see Mumbai at top of the list.

</comment><comment><USER14> Where's the complete list of cities they tried it in?

... or did they only try the 18 cities included in the slide show, almost all in Europe?

<comment><USER2> Yeah, just those 18 cities, 12 wallets in each, for a total of 192 wallets.

<comment><USER15> 16 cities, 16*12=192. The first, 18th and 19th slides did not refer to any city.

</comment></comment></comment><comment><USER16> I got to the bottom of the list thinking "damn it, rome is the most dishonest?", but it wasn't even in the list :)

</comment><comment><USER15> As anecdotic and not rigorous this is, I fully expected Madrid (or any Spanish city) to be one of the last :(.

<comment><USER17> As someone from Lisbon, _ouch_. But it doesn't surprise me, there have always been plenty of pickpockets in the city, particularly in the more touristy areas. The cops have identified more than a 1000 in the last five years.

That said, as far as I know we fare much better on violent crimes, and in general I've rarely felt unsafe on the city, even walking alone at 3am and later.</comment></comment>


Security vs. Convenience in Anyvite - <AUTHOR>

I just saw this in an Anyvite message:
"Note: Please do not forward this email. Doing so will give other people access to your Anyvite account."
In looking at the URLs embedded in the email, it was clear that they have some hashes glued in there to allow the user to bypass the login.
I'm not trying to bust on Anyvite; I've considered a similar scheme myself.
But I ended up deciding that it was a bad idea.  Other opinions? <comment><USER2> The message is a bit vague, but we chose that wording because it conveys the point more succinctly than a complete explanation.

If someone forwards an email to a friend, that friend will be able to RSVP and comment on behalf of the forwarding user, but they won't be able to create/edit/cancel the event. All of the admin controls still require the admin to login.

We chose this as a matter of convenience since most people will refuse to RSVP anyway and if we required them to fill out a registration form first, we wouldn't be any better than evite. As noodle mentioned, if someone can RSVP on your behalf for a single event, it probably isn't the end of the world. It's completely depending on the security requirements of your app.

</comment><comment><USER3> Evite does the same thing. My friends and I frequently forward our invitations around to each other with the note "If you're interested bump up my RSVP count or add yourself with the 'invite more people' link on the right.

I think it's fine in this case for the added convenience of not having to register/login. It's an invitation system not banking.

</comment><comment><USER4> depends on the nature of the app. while probably a 'bad thing', i don't think that someone maliciously gaining control of your anyvite account will ruin you, so a convenience like this might be acceptable in the eyes of the engineers.</comment>


Show HN: Nodebook – Minimalist Multi-Language REPL with Web UI - <AUTHOR> https://github.com/netgusto/nodebook/tree/master <comment><AUTHOR> Re-submitted because Multi-Language support has been added.

Currently supporting:

        * C11
        * C++14
        * Go
        * Haskell
        * Java
        * NodeJS
        * Lua
        * PHP
        * Python 3
        * R
        * Ruby
        * Rust
        * Swift</comment>


Ask HN: Do you use print() debugging? - <AUTHOR>

Or puts in Ruby, or System.out.println() in Java, or echo in shell scripting and PHP, or printf() in C/C++, or console.log() or worse, alert() in JS, or the equivalent in whatever language and environment you're in?
I'm primarily a JS developer, and the first debugging tool I use is usually alert() or console.log(). I usually just have to locate a single line that is past the point something has gone wrong, and I can usually very quickly binary search between this line and the event handler to find the offending line and fix it. Of course, the binary search is guided by intuition and if I don't find it after a few alerts I will start setting breakpoints in the debugger and/or stepping through instead, but somehow I've always seen the debugger as this big, heavyweight sledgehammer I don't whip out unless I'm actually stuck.
I do the same thing in all of the above mentioned languages, and in fact have never used a debugger at all for Ruby or the Pythons, though I assume they exist (nor for shell scripting or PHP, but do those exist?). I consider myself at least a proficient coder, and in particular have substantially used all the above languages (I've also used Scheme in a class, but nothing substantial). One of the best coders I know, who mainly codes in Ruby, also often first tries puts debugging. Yet I've also been ridiculed (in a nice way) by another friend for even suggesting to someone that they try to debug what seems like a simple mistake with a few quick print statements.
In a way I agree with them--print statements are a crude way to debug. But they're quick and dirty and get the job done and aren't hard at all to clean up. So I wonder: how many others debug with print statements first and a debugger second? <comment><USER3> Yes, I use it all the time.

Using a real debugger is great, and it gives FAR more power. It also allows me to wander around and check the values of various things without having to re- compile, re-deploy, and re-run the application up to the point where the error is occurring.

But getting the debugger to work takes a few hours of setup. If I'm at someone else's desk helping them debug a problem, it will take hours to get the debugger working, and only a few minutes to add the print statement.

If I'm working at my own desk and I briefly need to make a small change to another application that I don't normally work on, it would take me hours to get the debugger set up and only a few minutes to add the print statement.

If I'm fixing a problem that only occurs in QA (or worse yet, in production) then I have to use logging or a print statement because it would take days to get permission to attach my debugger to QA.

If I'm working on my own usual project, then I use the debugger because it is many, many times more powerful. Unless it's Tuesday, or for some other random reason the environment gods hate me and my debugger isn't working today. Then, depending on how much of a rush I'm in, I invest another few hours into fixing it or I just add a print statement and get on with my work and fix the environment later.

PS: I'm writing this while waiting for my IDE to recompile the world in my 4th attempt to get my debugger working again because my environment broke for no known reason.

</comment><comment><USER4> I debug primarily with print statements. There are a few times when a graphical debugger has been/would have been easier.

At a Python conference some 10 years ago I asked the same question. About 1/2 the people in the audience who responded said they were also primarily print- statement debuggers.

</comment><comment><USER5> I debug with printf. I also use nano or pico as an editor and write web application backends in C++. These choices are probably not very common, but who cares?

It's simple enough: they work for me for some reason. If they work for you too, great! If not, keep searching.

I find that debuggers are just another tool, and use them when necessary (not too often). They do not excuse you from really understanding the entire state machine which is your program. Woe to those who try to fix something without first understanding it. It turns out that my well-placed printf/LOG calls tell me what I need to know most of the time.

</comment><comment><USER6> Not if I can help it.

I mostly do medium-scale (5-50 people) C++ development. There are two main mode of debugging that I fall into: 1) I just wrote some code. Does it actually do what I planned? Let's see where it goes in practice. 2) Some code I've never seen before just screwed up. What the hell is just happened? OMG What the hell is all this stuff?

It helps that games are largely "while(1) doMainLoop();" kinds of apps as opposed to event-driven, asynchronous, multi-process, distributed, interpreted, whatever apps. It also helps that, as much as I can, I work in Visual Studio. The debugger works easily, reliably, continuously. It's faster for me to casually browse through deeply nested data structures than it is to type "print foo.x, print foo.x.bar". Data breakpoints are god-sent. "Break, change a variable and continue" is really nice for tweaking and quick-and- dirty testing. "Break and move the instruction pointer" is great for re- running a rare screw-up or skipping over code that would kill the process you are deep in the middle of debugging.

It seems to me that most of the people who rail against debuggers fall into A) working on systems that are not amenable to debuggers, B) stuck with very poor debuggers or none at all, or C) don't need debuggers because they either working alone on very small code bases or have dedicated many years of their life to absolutely understanding a every line of a single, slowly changing code base.

</comment><comment><USER7> Most of the time, by looking at a backtrace (I primarly debug C stuff, by the way), I already have a good idea what the problem might be. Tracking that down in a debugger is horribly inefficient, especially if optimisations are involved (how may times did you try to print a local variable, or a parameter, only to be greeted with <this value has been optimized out>?), so another way to see the program flow is required.

printf() does wonders in this area, if you can put them at the right places. Over the years, I found and fixed far more issues with printf() than with a debugger.

Granted, sometimes a debugger is neccessary, at least until I understand the problem, and become able to reproduce it. Then printfs it is again. If I can't reproduce it, and only have a core file to work with, then, obviously, a debugger is one's only choice. If I need to extract information from a core dump, a debugger is the way to go again.

But when trying to examine running code, printfs are - in my experience - <USER2> straightforward to work with.

</comment><comment><USER8> By way of background, I'm older than a lot of people here (42) and have been programming since the 1980's. Programming is a hobby for me after I got my law degree.

I still use print statements for debugging because they work - by now, I've switched primary languages three times (BASIC -> Turbo Pascal -> C -> Python) and development environments way too many times to count. I remember when IDE's were new.

My point is not that IDE's suck (they're pretty nice, really) but that unless I'm deep in a project, the time it takes to learn the ins & outs of the debugger/IDE environment probably won't lead to a net increase in productivity.

Also, IDE development is more complicated where the code is running on a server somewhere else.

I work interactively in the Python interpreter when testing/experimenting and then use vi to work on the real code.

</comment><comment><USER9> I use some sort of logging a lot. In general it works pretty well, however there are some situations where it can cause problems. Outputting text to the screen, or a file is a relatively expensive operation, so it can screw up timing because it can be slow, or cause context switches. (Which can screw up trying to debug some multi-threaded issues such as deadlock, or resource access.)

Back in m C++ days, I finally created a fast "output queue" which would contain my tracing strings, then a separate thread would read those and output to wherever. That way, the tracing thread would not be _as_ affected by timing issues.

</comment><comment><USER10> Depends on what I'm doing. I tend to think of debugging as roughly split into algorithmic and systemsy debugging: do I think I've messed up an algorithm, or do I have some messed-up software-engineering stuff like component interaction or memory management?

For algorithmic debugging I tend to do mainly printf debugging. In fact usually more like: read and mentally trace the code, and then printf a few things just to make sure they're what I expect them to be.

I use "real" debuggers if it's a more systemsy thing, like a bunch of interacting components, or inexplicable weird crashes.

</comment><comment><USER11> _have never used a debugger at all for Ruby or the Pythons, though I assume they exist (nor for shell scripting or PHP, but do those exist?)_

You can remotely debug PHP using the xdebug extension (<http://xdebug.org/docs/remote>). You'll need a DBGp client too. It's useful for complex logic but I still find myself falling back to var_dump() for quick tests.

</comment><comment><USER12> I code Perl at my day job and I use print statements. I'm in a terminal coding, and I've never really learned how to use the Perl CLI debugger. Normally I suspect what's broken and I just need the print statements to verify.

In Xcode I use the breakpoints because I'm practically already in the debugger, and I did similar when I had to hack on some C# & VB code.

</comment><comment><USER13> I used to do that (in Python) but find it's much more efficient to use the logging module. If you're going to put in print statements, it's likely to be a good spot to put in a debug/error/info/warn log, so when you're application is being used you can turn the logging to whichever level you need and see what's going on.

</comment><comment><USER14> For JavaScript I use console.log and "debugger". If you're unfamiliar, including a "debugger;" expression will pause execution and open a debugger (but only if one is available). Very lightweight and handy. This works on Chrome, Firefox, and likely others. Further, you can conditionalize it with if statements.

</comment><comment><USER15> Depends on the language and what kind of software I'm working on. Building a C# app for WP7? It's trivial to toss in breakpoints and step through the code using Visual Studio.

Doing PHP work for some simple CRUD web app? Echo statements usually do the trick.

</comment><comment><USER16> I used to use a debugger more extensively when I was writing Fortran. More recently, writing Python, S-Plus and VBA I've mostly used print (or MsgBox) - easier to do with interpreted languages, stepping through code is also easier.

</comment><comment><USER17> in general I don't think it makes that much of a difference. find what works for you.

(ruby-debug, for example, doesn't feel like a big, heavyweight sledgehammer, so you might just wanna try it out.)

for me, it depends on the complexity of the problem.

when there's something wrong and I have absolutely no idea where to start (which is a bad sign anyway :) ), using the debugger is easier than scattering print statements all over my code. but when one print() will probably tell me what the problem is, I don't bother using the debugger.

(… and thanks for reminding me to learn how to use ruby-debug.)

</comment><comment><USER18> My code normally has all sorts of: if(DEBUG) { print $foo }; (with a global boolean DEBUG variable) in it.

Ugly? Probably. Useful ass-saver? Definitely.</comment>


Ask HN: Is it viable to use Facebook to verify age/gender? - <AUTHOR> I'm not really sure how hard it is to fake a Facebook profile and whether this can be effectively countered by say, only allow profiles who have existed for longer than a month and have more than 3 friends...etc<p>Or is there maybe a better way that is more user friendly? <comment><USER2> Technically it is viable, but realistically it will result in nobody using your service. If you talk to Facebook users, most are very wary these days about giving third parties access to their Facebook account as third parties have historically abused that access (to post things, spam their friends, etc).

Plus the strength of this approach is directly proportional to the level of reward. Without knowing what a person 'wins' if they successfully bypass your check, it is hard to know if the check itself is strong enough.

It ultimately isn't that hard to make a fake account and add three other random/fake accounts. Takes about ten minutes. Then wait a month. The question is, is the reward worth the hassle?

I don't have a better/alternative way of doing this. Online age verification is an on-going problem, and gender verification is a pandora's box (in particular related to LGBT issues).

</comment><comment><USER3> You mention that you are willing to accept a 5% error rate. 5% is a bit higher than the Error Rate from Trolling of most surveys (see [http://slatestarcodex.com/2013/04/12/noisy-poll-results- and-...](http://slatestarcodex.com/2013/04/12/noisy-poll-results-and- reptilian-muslim-climatologists-from-mars/)). Do your users have an incentive to falsify their gender which would push it higher than that?

Since gender is relevant, I assume you're making either a dating app, or an app that feeds into some sort of beureacracy. If the former, then people have an incentive to enter their real gender if they want to get any use out of the app. Linking to Facebook is a bad idea since people are usually kinda wary of linking their dating profile to other social media. If the latter, then facebook is not going to satisfy your stakeholder. You should consider asking for some form of ID or credit card.

</comment><comment><USER4> No... many people create Facebook profiles before they're 13 with fake ages, and then it is difficult to change it to the correct age.

</comment><comment><USER5> Is there something that you're looking to do?

</comment><comment><USER6> No.

<comment><AUTHOR> Well, can you explain why? Note that the application in question is not very critical. An error rate of ~5% would be acceptable.</comment></comment>


Supreme Court That Misunderstood Texts, Email to Take on Video Game Debate - <AUTHOR> http://www.fastcompany.com/1627938/video-games-supreme-court-censorship-law-esa-esrb <comment><USER2> I find this criticism silly. The judges didn't know about something, so they asked. The issue, surely, is the decision and not the questions that get asked along the way.</comment>


The Myth of Talent - <AUTHOR> https://codewithoutrules.com/softwareclown/the-myth-of-talent-51/ <comment><USER2> "These days, I'm not so sure: I tend to think "natural talent" has much less to do with ability than things like practice and motivation."

Why are people so unrealistic as to pretend that talent is a "myth". I became an International Master in chess because of "practice and motivation", but I was motivated because I was winning most games almost from the beginning. Studying was enjoyable because I remembered what I studied. I show my kids chess openings, and they walk into the same trap the next week. Fine -- their talents are elsewhere. By contrast, I simply did not have the eye-hand coordination ("talent") to be good at baseball, and a lot of practice would only have raised me to mediocrity. Instead of pretending that talent is unimportant, let people, especially children, be exposed to lots of things, so that they can figure out where their talents lie.</comment>


A Rebuttal for Python 3 - <AUTHOR> https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/ <comment><USER2> As this rebuttal points out, the original article basically finds two flaws in Python 3 and then tries to puff them up as much as possible. These two complaints are:

* Python 3 is not backwards-compatible with Python 2.

* Byte strings and character strings are different things so now I have to care about stuff.

Although I say that it's two things, it's really one thing since the main element of incompatibility is the byte string/character string issue, since it's that incompatibility that makes it hard to know what the right thing to do is.

Having had to deal with internationalization before, I can honestly say that there's only one way to handle it: convert all string data to your internal representation (be it UTF-8 (Rust), UTF-16 (Java), or UTF-32 (Python)) at the margin where you read/write it, and keep binary strictly separate from textual in terms of representation. This is what Python 3 does and what Python 2 doesn't do. I have seen some people argue that Python 2's model is better because it means that writing something like cat is harder, but that's optimizing for the wrong thing. I've seen a build system written in Python 2 break for the sole reason that I thought to write 一 in the commit message.

As for the complaint that it's taking 9 years for Python3 to slowly become the default instead of Python2, keep in mind that 15 years after the release of C99, gcc was still using C89 by default (gcc 5 skipped C99 and went straight to C11).

<comment><USER3> > Having had to deal with internationalization before, I can honestly say that > there's only one way to handle it: convert all string data to your internal > representation (be it UTF-8 (Rust), UTF-16 (Java), or UTF-32 (Python)) at > the margin where you read/write it

I'm not going to go into the actual subtleties here but there is a lot more to it than what you suggest here. However the biggest mistake you made here is to equate that any encoding is equivalent here. There is a tremendous difference between using utf-8 as internal encoding or a variable encoding like in Python 3. Rust and Go have free bytes/string conversion wheres Python 3 has none of that.

<comment><USER2> Python 3's string types are internally ASCII (or Latin-1, I'm not sure), UTF-16, or UTF-32 depending on the contents of the string, but the API effectively assumes that the encoding is UTF-32.

The main point is that you don't want to be passing around binary data internally and expecting people to decode charsets as needed--the knowledge of charsets will usually be dropped.

<comment><USER3> > Python 3's string types are internally ASCII (or Latin-1, I'm not sure), > UTF-16, or UTF-32 depending on the contents of the string, but the API > effectively assumes that the encoding is UTF-32.

That is incorrect. The API assumes the string is O(1) indexable. It makes no assumptions or guarantees about the internal encoding.

> The main point is that you don't want to be passing around binary data > internally and expecting people to decode charsets as needed--the knowledge > of charsets will usually be dropped.

This is an incorrect blanket statement and I can give you plenty of examples where this is _exactly_ what you will have to do because the knowledge of the encoding is not available until later. This is in fact a common problem that Python 3 has because it decodes to unicode so early that it had to come up with surrogate-escapes to roundtrip bytes in case the encoding it guessed/inferred was wrong.

<comment><USER4> He's talking about CPython, the default interpreter/compiler for Python in many systems. CPython internally uses 1-byte representation if the maximum Unicode code point of its chars is 127 or less (therefore ASCII), 2-byte representation for values less than 32767 (thus utf-16, but only the first half-page), and for the rest it uses UTF-32, which means all lookups can be done in O(1).

Assuming UTF-8 encoding for source files is not that strange, as it is getting more and more the default or preferred encoding for string-based I/O.

<comment><USER3> I understand how CPython works however the external API makes no guarantees about any internal encoding. The implementation of the storage also changed many times.

</comment></comment></comment></comment></comment></comment><comment><USER5> This is a great rebuttal against such an awful book for teaching.

Last year I recommended this book for a friend that was starting to learn to program. After a few weeks I was talking to him about lists, and he didn't understand what I was saying because it doesn't touch a _basic concept like a list_ until Chapter 32! It takes literally two seconds to explain to a person what lists are, maybe a little longer for syntax. Given that he invites people to read other people's code early on (in one of the single digit lessons IIRC), this is a serious omission.

In addition to this, much of the attitude towards programming in the book isn't so much of "Woah! A new thing! It's so cool let's learn it" (i.e. energetically curious), but tends to rebel against new things in a "Well, I know it'll be hard and difficult..." way, which I honestly believe is damaging to new programmers. Programming is one of those disciplines where if you don't have a positive spirit towards both bugs and learning new things, you will get worn down over time. I think it's best to either already possess such an attitude or to show people documentation, etc. that helps them develop such an attitude when learning.

I ended up prodding my friend to pick up Lua. Partly because he was more interested in games development (and there is a great community for that around the Love2D engine), because it is a small enough language to learn and memorize in a week or two, and because I wanted to undo the damage that reading LPTHW had caused on his attitude towards programming.

</comment><comment><USER6> Mr. Shaw's book used to be a decent starter reference. I liked his step by step short chapters, but there were some red flags. For example, he spent several early chapters on string formatters, which are neither terribly common nor useful for a beginner. Other key concepts like iteration were not adequately explained, or introduced far too late in the progression.

Besides the demagoguery, this new piece displays shocking ignorance of basic CS concepts. I will now actively warn my students against consulting his work.

Thanks to eeveee for a detailed rebuttal, which displays an appropriate amount of reprobation, given the original's caustic tone.

Python is an incredible community effort. It deserves support and constructive participation.

</comment><comment><USER7> I certainly didn't get Zed's article, like maybe I'm not familiar with the superior toolings of other languages, but whenever I've used python2to3 I found it helpful enough to get real work done. For example, two years ago, I fell squarely in beginner segment skill wise, and I filed an issue with a repo owner to request to update to be python 3 compatible (an ORM for RethinkDB - [https://github.com/linkyndy/remodel](https://github.com/linkyndy/remodel)). The obviously talented repo owner initially responded he feared it would be complex and take a long time. I then spent a weekend to learn the library, used 2to3 to get 95% there, fixed the remaining small issues, and updated the repo to be compatible with Python 3, passing all tests. Sometimes these python2 programmers just do not want to change.

</comment><comment><USER8> Great point for point rebuttal. I was annoyed at the original article when it was circulated recently. As eevee points out, most of the original author's points are invalid or unimportant, and to me it seems that he is just mad he has to write another "learn Python" book for Python 3.

I'm a Python beginner and I recently wrote a few small tools in Python 3. They have a few functions, do network I/O, argparsing, connect to PostgreSQL, etc. It took me a few hours and it was fun.

</comment><comment><USER9> It's human nature to resist change. Making a clean break and avoiding backwards compatibility was the smart move, it annoyed many, but I look around and see some languages truly suffering from such things years down the track.

Python3 is superior, its nothing but fandom when people say otherwise. Starting from scratch I'm yet to see any real benefit for 2, yet it still happens routinely due to the mindsets of some.

</comment><comment><USER10> The original article by Zed should stand as an example of logical fallacies.

</comment><comment><USER11> Maybe Curmudgeon Driven Development is a thing. I was totally surprised that by the end he hadn't advocated Perl 6. Like, "This is how it should be done: Parrot in Perl 6".

I was hoping out of this kerfluffle that some one would make Python3's TypeError show which variable was the byte string and the normal string. I haven't seen any people argue for improving the error reporting. It's that kind of thing that helps beginners when they start trying to do things with their current knowledge.

</comment><comment><USER12> I'm amazed how people always list "three ways of formatting strings", when in fact there are four. :)

Admittedly, the fourth is not built-in, but it's part of the standard library: string.Template

</comment><comment><USER13> for all his points about adoption of python 3, i think an interesting data point is that many of the OpenStack projects are actively converting (or already have converted) to python 3. that's no small amount of python.

</comment><comment><USER14> > Zed Shaw, your behavior here is fucking reprehensible.

s/here//

</comment><comment><USER15> Ported all my code base to Lua. Python can die now.

</comment><comment><USER16>
        # -*- coding: utf8 -*-
        print "Hi, my name is Łukasz Langa."
        print "Hi, my name is Łukasz Langa."[::-1]

This is a bad example. Reversing Unicode strings isn't an operation that is often needed in practice, and it shouldn't be done codepoint-wise anyway, because some characters have to be represented with multiple codepoints:

        Python 3.5.2 (default, Nov  7 2016, 11:31:36)
        [GCC 6.2.1 20160830] on linux
        Type "help", "copyright", "credits" or "license" for more information.
        >>> 'x́q'[::-1]
        'q́x'

Doing it properly is bit of a grapheme clusterfuck: <[http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries...](http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries>).

<comment><USER17> See, this _is_ a good example because in Python 2 the string is just bytes. Ł is 0xC5 0x81. Reversing those bytes just corrupts the content. This isn't exclusive to this one operation. Let me give you another example:

      >>> print "Hi, my name is Łukasz Langa.".lower()
      hi, my name is Łukasz langa.

Whereas on Python 3:

      >>> "Hi, my name is Łukasz Langa.".lower()
      'hi, my name is łukasz langa.'

Or even more basically, Python 2:

      >>> len("Hi, my name is Łukasz Langa.")
      29

Python 3:

      >>> len("Hi, my name is Łukasz Langa.")
      28

Sure, there's hard things about code points and graphemes that Python 3 also doesn't touch, like the example you gave (originally: characters outside of the BMP using surrogate pairs, later: using combining characters), or equality (where normalization might be needed to compare two strings that look alike), or sorting (where collation rules mean the same code points might sort differently depending on the language used). But there's tools to deal with those tricky situations and the default is much more robust.

And sure, you can use the `unicode()` type in Python 2 to get the correct results but the problem is that most APIs will work with both types and silently do the wrong thing every now and then. Those include UnicodeDecodeErrors and UnicodeEncodeErrors that you get _sometimes_. In Python 3, without the magic type promotion, you'll get a sane TypeError every time.

Disclaimer: the name used in the example is mine.

<comment><USER16> It's only 'more robust' as long as you don't care about languages in which it isn't.

The example is bad, because reversing code points _also_ corrupts the content, but in a different and a somewhat harder to detect way. A better method of reversing text is to split it by grapheme clusters and reverse that. (It may still fail to work when someone manages to sneak a bidi control character in the string, and I am quite confident there may be other issues here that I cannot anticipate right now.) Python 3 offers no advantage here over Python 2. Reversing code points only appears to work, until you feed it stress-marked Cyrillic or Korean with individually encoded jamo; which is quite similar to the charge levelled against Python 2 strings: 'it appears to work, until you feed it non-ASCII input'. The problem isn't solved; the failures are just swept over to language environments in which Western programmers often don't bother to test their programs.

Expecting len() to count characters in a string, as you seem to be doing, is also wrong.

        >>> len('а́')
        2

The correct way to count characters is, again, to count grapheme clusters. However, counting characters is not an operation that useful in practice either. If you want to check a string against a database limit, those are usually specified in bytes (or sometimes indeed in code points). If you wish to know how much a piece of text takes on screen, you should ask a font- rendering library to compute it for you; unless you're rendering to a tty, in which case fine, count grapheme clusters. Apart from which syntax gets you codepoint versus byte length, there's no difference here between Python 2 and Python 3 here.

Case conversion is also locale-dependent. In Turkish and Azeri, the uppercase form of i is not I, but İ. In Lithuanian, the lowercase form of Ì should be i̇̀, which has both a dot and a grave accent above. str.upper() and str.lower() fail to take that into account, and don't even warn about it in the documentation. Again, it _almost_ works... until you're a Turk and it doesn't. Is it really all that better than Python 2?

Manipulating human-readable strings is _hard_. Operating on code points instead of bytes makes it easier, but doesn't solve it completely. Handwaving about 'tools to deal with those tricky situations' is not an answer; I am quite sure some of those tools exist for Python 2 as well.

</comment></comment></comment><comment><USER18> It's really not surprising to me that the original link to Shaw's article is buried on HN.

This is exactly what he is talking about: it's not about right or wrong anymore, it's all about tribalism. I can remember when RoR was the newest, hip, thing in Silicon Valley. If you even mentioned something wrong with it on HN, you were silenced and downvoted.

There were real issues with RoR that needed to be addressed, but the community developers would rather spend time silencing opposing opinions that actually fixing the flaws in the language.

Where are these developers now? They all moved onto Javascript frameworks and node.js.

There are real issues with Python 3. The Python 3 faction of the community has basically told anyone that asks to fuck off and do things their way.

The responses here on HN and this 'rebuttal' have really just proven his point. I would have rather it proven him wrong.

<comment><USER19> Ah yes. "You wrote an article which was incorrect, here is an explanation of why what you wrote was incorrect, backed up with reasoning and sources" is _exactly identical_ to "fuck off, do things my way".

I am glad to have your wisdom on this issue.</comment></comment>


Ask HN:  Should you be able to change git history - <AUTHOR>

This HN Thread: https://news.ycombinator.com/item?id=7932624 Talks about a tool where you can change your git history to draw in your GitHub profile. Obviously I think its a good idea.  Wanted to get the communities thoughts. <comment><USER2> It's not really changing history, just backdating commits. Can anything be done to stop people adjusting their system clocks, or writing false data into their commit history? There is no way to disprove those commits, especially since commit and push are disparate events in git.</comment>


Hand dryers 'splatter' users with bacteria, scientists warn - <AUTHOR> http://www.telegraph.co.uk/science/science-news/11243110/Hand-dryers-splatter-users-with-bacteria-scientists-warn.html

<comment><USER2> From the end of the article:

 _The research, funded by the European Tissue Symposium, was published in the Journal of Hospital Infection and presented at the Healthcare Infection Society (HIS) International Conference in Lyon, France.

A spokesman for Dyson, which makes jet hand dryers, said: "This research was commissioned by the paper towel industry and its flawed.

"They have tested glove covered hands, which have been contaminated with unrealistically high levels of bacteria, and not washed."_</comment>


What's coming in Meteor 1.2, and beyond - <AUTHOR> http://info.meteor.com/blog/whats-coming-in-meteor-12-and-beyond <comment><USER2> It is highly encouraging to me that Meteor is acknowledging the larger trends in the Javascript ecosystem and promoting React to an officical frontend layer instead of doubling down on their homegrown solution. Likewise for seamless Babel integration and planning the move to official ES6 modules.

Buying into a full-stack solution like Meteor is a scary proposition; you're giving up a large amount of control for a promised big increase in immediate productivity (which I do feel Meteor delivers on). This blog post goes a long way to alleviate my fears and makes it more likely I'll use Meteor for certain future projects.

<comment><USER3> Honestly I'm very likely to stick with Blaze for the time being, as I've found it easier to follow & understand than Angular (haven't tried React yet).

I just like the sticking with general modularity approach (that really reminds me of Ruby).

I don't think the Meteor proposition is any scarier than getting into Rails, Django, or even Laravel. You're basically trusting a growing ecosystem that will prevent you from re-inventing the wheel.

<comment><USER4> Rails, Django, and Laravel are all server-side frameworks. You could replace one with another, without having to rewrite any client code.

Meteor is all-encompassing, covering both the client and server. That means you have much less agility in terms of swapping out components, but of course its convenience is unparalleled.

Actually this has me wondering, is there anything else out there like Meteor that covers both client and server development at the same time? Maybe GWT?

<comment><USER5> > Actually this has me wondering, is there anything else out there like Meteor > that covers both client and server development at the same time?

There's also Derby.js and Socketstream which arose around the same time as Meteor:

[http://derbyjs.com](http://derbyjs.com)

[http://www.socketstream.org](http://www.socketstream.org)

</comment></comment></comment></comment><comment><USER6> Official React support - woohoo! I've been using React and Meteor together to build a desktop web app for quantified self, and I have to say, the combination is magnificent for productivity. The app is 90% JS and a little CSS, and reactively updates with no extra code. MongoDB and server logic is separated from the client-side view rendering, so if I wanted to make it a thin client and remotely host the computations on another server it would be a piece of cake.

An example file of code for the records overview (dashboard was a bit tabby- spacey): [https://github.com/liamzebedee/metric/blob/master/client/fea...](https://github.com/liamzebedee/metric/blob/master/client/features/RecordsOverview.jsx)

<comment><USER7> How is the performance ? For me something like Atom feels very sloppy compared to Textmate / Sublime

<comment><USER8> Have you tried Atom since they shipped version 1.0? It's been sped up a LOT.

However, I don't really think that this topic has much to do with React / Meteor, as Meteor is a full-stack web-solution, Atom is a desktop text-editor built with web technologies (and specifically React)... It's like saying my Ferrari goes faster than your boat, yup, on land.

<comment><USER7> I know but i have commented on a guy's post talking about building desktop web apps.

Also yes i have tried the latest Atom's version. I am not bashing it's just that i feel that the performance is still worse than the native solution (obviously).

</comment></comment></comment></comment><comment><USER9> When ES6 and web components come out, are we even going to need frameworks like Meteor? It seems like all of the advantages of MVC frameworks go away once you can create controllers and models in native Javascript and views in native HTML.

<comment><USER8> It's completely different from ES6, it's a full-stack framework, so it does SO much more than just a front-end framework.

Meteor's main selling point is the reactivity; you can call `Books.insert({ name: "test" });` on the client, in-browser and it then updates the UI optimistically, updates the DB on the server AND propagates the change to all other clients, which in turn updates their UIs. All with one line of code.

Take a look at DDP, one of the core building-blocks of Meteor: [https://www.meteor.com/ddp](https://www.meteor.com/ddp)

<comment><USER10> Is DDP or Meteor really needed though? Couldn't you easily set this up with RethinkDB using its Changefeeds killer feature for real-time + socket.io along with whatever other library/frameworks you want to use without ever touching Meteor?

<comment><USER11> Yes, you totally can, but I found running one command:

curl [https://install.meteor.com/](https://install.meteor.com/) | sh

so much quicker (in the short term and long term) than reading a myriad of tutorials and then bashing my head against this configuration of several products for multiple weeks to get what Meteor provides as part of a single maintained and updated system.

</comment></comment></comment></comment><comment><USER12> tldr: ES6 = standard, SQL support is coming, faster builds and mobile toolchain development a priority. Reactive rendering with Blaze, Angular or React + Meteor is available.

<comment><USER13> SQL support has always been "coming." It's been on their Trello roadmap for more than a year. The specific messaging in this post is that the new version of Meteor is coming late this summer, will not include SQL support, but that SQL support is something on their radar for the future (late in the year? next year?)

That bit is not news or anything new.

<comment><USER14> I think the intention is to signal that SQL is likely to be one of the things we work on immediately after 1.2 is released.

</comment></comment></comment><comment><USER15> Anyone out there using Angular and Firebase? That's been my go-to "stack" for achieving 3-way binding of the UI, javascript model, and remote database. The only downside is that you're locked into using firebase as a service, can't host it locally, and you're limited to what their API supports. It's amazingly fast in terms of ability to churn out features.

Meteor seems to be the only thing that comes close to giving offering the same amount of productivity as I can get using Angularfire.

Has anyone used both, that can comment?

<comment><USER16> I did the design of a project that used Angular inside Ionic with Firebase as backend. They integrated well, no particular problem. Just be careful not to keep websockets open unless those you really need. Close the others. They'll keep the CPU busy and bleed the battery.

The only major problem was with Firebase itself, when we had to start duplicating data because it's a tree and it doesn't have joins. But it would be unfair to complain because it's like that by design and we knew what was expecting us. Is there any service like Firebase but with joins?

<comment><USER17> I haven't used Firebase, but would RethinkDB with its real-time feature be an alternative that has joins? It has the drawback that it'd be self-hosted, but apart from that..?

<comment><USER4> There's also Compose.io for a hosted RethinkDB.

</comment></comment></comment></comment><comment><USER18> So when is Meteor going to start sending actual web pages? I ask here, because seeing a blank page that consists of

        <body>
        </body>

Isn't very useful. ES6 is nice... _when javascript is available_. I know it's current popular to pretend that progressive enhancement is too much work, but that doesn't change the fact that your site doesn't even have an error mesaage when javascript is filtered at the firewall.

<comment><USER19> There is a difference between web pages and web applications, and Meteor is built for the latter. There is no such thing as a progressive enhancement path in many cases. If your firewall (?) strips out JS, then you are on a broken network.

How does it do that anyway? Most sites are HTTPS.

<comment><USER18> Yes, there is a difference between pages and apps. You should still not send only empty body tag. Click link, see blank page - how am I to know what kind of page it is? I'm really only referring to _documents_ (like www.meteor.com, I presume - I can't actually read it from this computer as it's a blank page). Even on "web apps", there should really be at least an error indicating that the app only works with JS, or maybe a link to a fallback/alternative if appropriate.

Note: a search page is not an "app". Progressive enhancement works just fine in almost every case that isn't a purely interactive app (i.e. google maps or a game). It is trivial to render, as needed, the HTML template with the header/footer, or a layout-free snippit, or simplee JSON, or whatever else is needed. This was basically zero extra work in Rails years ago, so I don't see why it can't be done now.

As for stripping JS, that is easy, and done for security reasons. Yes, this requires a custom cert so the firewall can MITM the connection, which most businesses do anyway. No, this does not make it a broken network. Javascript is optional, and always has been. ( [http://www.sitepoint.com/javascript- dependency-backlash-myth...](http://www.sitepoint.com/javascript-dependency- backlash-myth-busting-progressive-enhancement/) )

<comment><USER20> There is actually nothing in meteor which states that you have to have only a body tag in your html. In fact, you can very simply render html headers, footers, and other static html without javascript. You can also handle 404 and send static pages for such appropriately. If someone has misinformed you, do take their opinion as nothing more than nonsense.

Now if you happen to run across a site which does not handle this properly, that is not shocking in any way. I have found that generally speaking those who disable javascript often complain about sites which extensively use javascript. They say things like "you can't assume that everyone has javascript enabled", "javascript is a security hazard and you can't expect me or anyone else to run a site with such a blatant vulnerability", and "how dare sites use such shotty technology to give an experience, they need to realize we need the same experience but without all of the vulnerabilities". The list of complaints go on and on.

The reality of the situation is this: as someone who makes consumer applications for profit, most of us don't care about you. If you are willing to turn off javascript, you are probably not my target user. If you work in an organization which does something so stupid as to break ssl in order to commit mitm attacks on your own employees in the name of security, you are probably not my target user. I do this for profit, not to cover ever last edge case known to man for every "security conscious" consumer of the Web. I worry about the security of my actual users. I worry about giving them the best possible experience. I care that they can use the product and enjoy it and will come back again and again. Javascript is optional for you, but it is not option for my applications. Hundreds of thousands of my users don't seen to mind.

<comment><USER18> > nothing in meteor

That's actually very informative. ?I guess www.meteor.com is one of those sites that doesn't handle it properly? I? have no idea.

> Hundreds of thousands of my users don't seen to mind.

Really? Have you asked them?

Hundred of thousands of your users probably have _no idea whatsoever_ what their browser is doing, and it is disingenuous to say that they "don't mind" \- _especially_ when javascript is used for things like tracking reading times and other things probably call "analytics" and a lot of us call "spying".

> I worry about the security of my actual users.

Apparently not - you just make sure your users can only be people who know nothing about modern network security.

Remember, I'm not saying javascript applications are bad or that you shouldn't write them[1]. I'm saying you shouldn't leave your precious "user experience" _in the case where javascript is not available_ as a totally-useless, non- informative blank page. Which _many_ sites have started to do, www.meteor.com included. Thqt''S IT. All this arguing about javascript is missing the point.

[1] At _most_ , I only suggested that a lot of the time what is being made is _not_ an application", but a fairly simple document. The only reason javascript could be _needed_ (isntead of progressively enhanced) on something like a simple search page is if you are trying to run spyware (such as google- analytics) in the background, behind the user's back.

</comment></comment></comment></comment></comment><comment><USER21> Great news that ES6 support is shipping this summer. You can already use Babel, but having everything set up by default, with examples using ES6 will be great.

BTW, I wish there would also be built in support for Typescript. I have done some simple experiments with Meteor and Typescript but it has a do-it-yourself feel abut it. As much as I like Typescript, I will probably just use ES6.

</comment><comment><USER22> I started to use meteor a month or so ago. For a person like me, from Java Enterprise land, this tool is refreshing. Glad to see new goodness is coming, especially SQL support.

</comment><comment><USER23> Awesome!! never saw this link they've mentioned - [http://react-in- meteor.readthedocs.org/en/latest/](http://react-in- meteor.readthedocs.org/en/latest/)

I've been playing with meteor just recently and am totally loving it. I really like Blaze, but love React's component system, so not really sure which way I want to turn now... I'm almost thinking of just implementing a React-like dictionary in Blaze to keep it more 'component' like , because I really dislike the jsx transpiling.

Anyway these announcements are definitely making me more convinced that I should try Meteor in a production app. I see many good things coming for this project.

</comment><comment><USER24> Really glad to see React Native mentioned here, albeit briefly. Hybrid mobile apps like the ones currently supported by Meteor always feel kind of clunky, and the 3rd party implementations of DDP for iOS/Android feel like a workaround and not the Meteor-way of doing things. Would be interesting to see how React Native is integrated into Meteor. Though what I really want to see is Blaze Native.

</comment><comment><USER25> I never used Meteor but I was impressed by this framework 3-4 years ago. In the last years with the javascript client/side logic growing it looked obsolete in some components. But now with this new support of the two most popular framework js and the support of Sql I think that is could be get more developers and contributors 'than ever' :)

</comment><comment><USER26> Is anyone else unable to log into meteor.com forums? I click log in, the popup tells me I'm already logged in, click "use this account" and it drops me back where I was with a modal(ugh) about making an account.

<comment><USER14> (I work at Meteor)

I'm sorry! I haven't heard any other reports of an issue like this; what browser/system are you on?

<comment><USER26> No worries, really a minor thing but is happening for me on both chrome latest(43.0.2357.130 64bit) and firefox developer 40.0a2 on OS X 10.10.4.

Click log in, pops up a window where I either login or it says "use this account you're logged into?" and then drops me back at the forums with a signup modal(and when I close that, still logged out).

Meteor has been great for me though, you guys are building(have built) a really cool thing.

</comment></comment></comment><comment><USER27> > Meteor goes with Angular/React like peanut butter goes with jelly.

Terribly, then. ;)

</comment><comment><USER28> Wow, when did they add database support? I'm pretty surprised it's been done before this release.

</comment><comment><USER29> Thought for sure this post was going to be all about Galaxy. Oh well, still didn't disappoint :).

<comment><USER14> That wouldn't be about Meteor 1.2 - I don't think Galaxy will ship as part of a Meteor release, but rather as its own product.

</comment></comment><comment><USER10> "We're going to support React and Angular!"

Translation: We're going to support the big JS names the general public is most aware of, because... well... please, use Meteor.

</comment><comment><USER30> And yet they still tell people to install Meteor by piping to their shell. Incredible.

[http://curlpipesh.tumblr.com/](http://curlpipesh.tumblr.com/)

[https://paragonie.com/files/blog/pipeshell.jpg](https://paragonie.com/files/blog/pipeshell.jpg)

<comment><USER31> That's a pretty common thing. I don't see the problem.

<comment><USER32> It being a common thing _is_ the problem. It's teaching insecure habits.

<comment><USER33> What do you think about this solution: introduce a layer on top of SSL that just verifies whether the private key of a certain explicitly stated site has signed a file?

In other words, compromising the server wouldn't be enough, because that doesn't give you the SSL key, so it would still fail "curl|is_signed_by site.com|sh", which they can only pass if they compromise the private key?

Better than the current system?

<comment><USER32> > compromising the server wouldn't be enough, because that doesn't give you > the SSL key

But it does. The server needs to have the SSL key to be able to serve requests over HTTPS.

It may be encrypted with a password, but at that point you're severely degrading your integrity assurances (compared to offline executable/archive signing). Might as well do it right with offline signing, right off the bat.

<comment><USER33> interesting. What if a script just uses the SSL infrastructure to get the private key associated with a domain name, without actually needing anything at that domain name to come over SSL? Then the private key does not have to be live/online at all, but could be used to verify the shell script. This is getting complicated, but if there is infrastructure, it should be possible to use it.

Personally I think curl of an https URL is not the worst thing in the world.

<comment><USER32> I think you need to read up a bit more on how asymmetric key cryptography works :) Verification is done using the public key, the private key is used to _sign_ something. That's why it's so useful. This is a good read if you want to learn more: [https://www.crypto101.io/](https://www.crypto101.io/)

Basically, the separation between 'server serving the downloads' and 'machine signing the release' is _intentional_ , and should be maintained. Consider it an 'airgap' of sorts, although it usually isn't one in the strictest sense of the word.

Making release signing depend on the SSL infrastructure (which is already rather broken in a number of ways) in any way, is a bad idea. Verification is a different story, but secure code delivery is a hard problem anyhow.

<comment><USER33> I understand exactly how it works. How do you get a code-signing paradigm down to something as simple as curl | sh though? (Well not _as_ simple, but still a human-readable one-liner that works on nearly all Linux systems.)

I thought maybe a single-line invocation might piggy-back on SSL as follows:

\- get a server's public key that is not online or able to answer requests (because if it were it couldn't be airgapped)

\- but still use the key to verify the script that's downloaded from the server that _is_ online.

\- only pass the code to sh if it was properly signed by the offline server.

Then the offline server could be "[https://key.meteor.com"](https://key.meteor.com") and the private key wouldn't have to be anywhere but an airgapped machine.

I don't know if there is more of the SSL infrastructure that I'm missing though (I'm not an expert) or if this could practically be reduced down to a tamper-evident one-liner (a la curl [https://install.meteor.com](https://install.meteor.com) | sh). It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!

<comment><USER32> > How do you get a code-signing paradigm down to something as simple as curl | > sh though? (Well not as simple, but still a human-readable one-liner that > works on nearly all Linux systems.)

You don't, really. Not currently anyway. Retrieving a binary/archive and doing out-of-band verification are two logically separate steps.

The problem with your suggestion is that SSL is about _transport_ security. It verifies that you are talking to the right server, but does not provide any guarantees beyond that.

It's not really possible to shoehorn release signing into that, without additional infrastructure.

It doesn't matter how you combine things - the server and the signing system are (and should be!) two separate entities, and you cannot rely on the server to tell you who the signing system is (because that'd give you no better security than not having a signing system at all).

> It would be a marked improvement over just passing anything from a > potentially compromised server straight to bash though!

It wouldn't, because as far as I can tell, you're _still_ relying on the server to tell you what the correct release signing key is. How else would you obtain it?

<comment><USER33> thanks - drop me a line and I'll reply, this thread is getting old and deep. thanks for your thoughts though and hope you do write.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> Yeah! I knew it wasn't just my gut feeling when I went ALL THE WAY with Meteor :)</comment>


Smart gun beaten by dumb magnets - <AUTHOR> http://hackaday.com/2017/07/25/smart-gun-beaten-by-dumb-magnets/ <comment><USER2> There's a very simple technology for this.[1] It's a purely mechanical gun lock operated by a magnetized ring on the user's finger. Some cops use it, in case someone grabs their gun. It's useful to cops who have to work in dense crowds, like transit police. About 10% of cops who are shot are shot with their own gun.

[1] [http://www.smartlock.com/smartgun_detail-r.htm](http://www.smartlock.com/smartgun_detail-r.htm)

<comment><USER3> Sources, please, on the claim that "some cops use it."

I know a lot of cops, and none of them would get close to something like this. Too many ways for it to fail and get them killed.

</comment></comment><comment><USER4> Are there any gun- and tech-literate people who actually think smart guns like this are a good idea? Anytime someone (cop or civilian) pulls a trigger in self defense, they do so as a last resort. Not a time when you want to be worrying about whether you have your smart watch or if you changed the batteries in your firearm.

<comment><USER5> _Are there any gun- and tech-literate people who actually think smart guns like this are a good idea? Anytime someone (cop or civilian) pulls a trigger in self defense, they do so as a last resort._

Have you honestly never heard of an accidental shooting occurring? Heck, it seems like at least once or twice a year we hear about a parent being shot by their own toddler...

Trigger locks and smart guns are specifically intended to prevent these types of accidents.

<comment><USER3> There's no such thing as a "smart gun" that's actually useful in the real world. There are too many failure modes that cannot be tolerated when a gun is needed to save your life.

To your point about toddlers - safe storage and safe methods of carry solves that, and they work with every gun in circulation already.

1) Lock up your gun if it's not directly under your control (i.e., in a holster).

2) Carry your gun in a proper holster, on your person. Not in your purse in the shopping cart, but on your hip.

These two, together, would prevent every case where a toddler shoots somebody.

It's not appreciated outside gun circles, and sadly even in gun circles a lot of people don't get it, but good holsters are the most important investment you can make. A huge fraction of gun accidents trace back to cheap holsters.

<comment><USER5> I'm going to play devil's advocate, here:

 _1) Lock up your gun if it 's not directly under your control (i.e., in a holster)._

"But then it's not available when someone breaks into my home!"

 _2) Carry your gun in a proper holster, on your person. Not in your purse in the shopping cart, but on your hip._

"How does that help me when I'm in bed and someone breaks in in the middle of the night?"

I'm going to be blunt: while I recognize my own reply is somewhat simplistic and idealistic, yours is no better. There is simply no technology, today, that makes gun ownership in the home both safe and is perceived as 100% effective in circumstances where a weapon is needed for self-defense in an emergency situation.

This type of technology is a search for a solution to that problem. Is it _the_ solution? Or a perfect solution? Clearly not.

But to imply there is no solution, or that it's a solution in search of a problem, belies a profound cynicism.

This is Hacker News. Folks, here, believe technology can solve everything, from world hunger to poverty.

But for some reason, apparently it's impossible to improve on the firearm.

it's baffling.

<comment><USER3> It's not impossible to improve firearms - tons of innovation happens in that space. At the same time, anything that decreases reliability is a deadly liability that cannot be tolerated.

To your counter-examples. Carry your gun at home if you're worried about break-ins. Put your gun in a quick-access safe when you sleep. Problems solved

<comment><USER5> So, suppose we live in a fantasy world where a smart gun is developed that has extremely high reliability. Would you agree that would represent an overall improvement in firearm technology?

I'm trying to understand if the objections are rational, or religious.

I honestly can't tell.

<comment><USER3> If you can make a smart gun that is as reliable and foolproof as a Glock, without destroying the ergonomics, you'd have something.

Failure is not an option. 5 9's isn't good enough, and we can't manage that in software with redundant systems. Beating that, in the meager amount of free space a gun offers, is a pretty tall order.

I'm not being religious, I'm being realistic about just far away "good enough" is for a smart gun.

<comment><USER5> Thank you! I appreciate that you took my comment seriously and decided to respond in kind.

I totally agree with you. It's an extremely difficult ask, and I'd never claim that the current iteration of this technology is anywhere near workable.

Another commenter, here, used the analogy of self-driving cars, and I think it's an apt (if imperfect... the problem spaces are profoundly different) one, though perhaps not the way they were intending.

In both cases, the technology problems are enormous, and the failure modes could result in the loss of human life. So it better be pretty damn foolproof if it's to gain any kind of widespread adoption. Yet, you don't get the same level of negativity levelled at efforts to build self-driving cars... that it's impossible and car companies should have never tried.

The original question was: "Are there any gun- and tech-literate people who actually think smart guns like this are a good idea?"

I think the nuanced answer, here, is: Not yet. But perhaps some day.

It seems we might agree on at that!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> This could have been prevented if they had hired someone to test designs against potential hacking during prototyping but I don't believe that it would have been worth the money. Unless someone knows exactly how to put the magnet against the gun, they can't beat it. Everything is vulnerable to some risk and I believe that this gun is sufficiently well designed to prevent most if not all would be threats.

<comment><USER7> Considering the largely accepted belief that a knife wielding attacker can cover 20 feet more quickly than an average trained individual can draw and fire a pistol (it is - at best - very close), it would seem to me that the jammer is the mostly problematic exploit. It firmly tips the engagement in favor of the knife wielding attacker without the pistol wielding defender understanding their weapon had been disabled until it is far too late to change tactics.

I don't see law enforcement ever adopting smart weapons.

<comment><USER8> The military has plenty of anti-jamming technology don't they? I'm guessing if they wanted to do this right there would be ways that are a lot more sturdy than something a simple RF jammer can stop.

<comment><USER9> > anti-jamming technology

Like what? SNR-boosting encoding tricks to get around high-power noise are not going to be fast like you want with a gun. The form factor needs to be omnidirectional. You don't have high power available in a portable device. You can't just change frequencies, because an attacker is likely broadcasting high-bandwidth noise. And you don't know whether the user needs it to fail safe (the bad guys got the gun) or fail hot (the good guys need to use the gun). After that, physics doesn't leave a lot of other options for technology to fix anything!

</comment></comment></comment></comment><comment><USER10> That was a really interesting read and watch, both high tech and low tech hacks.

Given that these guns mean life/death for people I hope this find is enough to take them off the market. So many chances for failure given all these holes.

</comment><comment><USER11> Why does anyone think the magnet attack matters? The wireless safety is designed to defeat a child, or an assailant who manages to wrestle the gun away from you. The idea that they're going to pull out a big-ass rare earth magnet and fire it that way just doesn't make any sense in real-world scenarios.

The problem with the iP1 is that it can be jammed, and this should be a surprise to absolutely nobody.

</comment><comment><USER12> So he hacked a smart gun and the result was.... a regular gun. How is this supposed to be dangerous? He can't fire it over the internet or anything, just disable it's lock. It's like "hacking" an elevator by stopping it: it just becomes stairs!

<comment><USER13> > How is this supposed to be dangerous?

He was also able to disable the weapon from a distance.

</comment></comment><comment><USER14> In weighing whether we should _legislate_ whether the technology must be used and whether we fine or imprison people who refuse to use the technology, even forgetting for a moment about the ~300 million guns already in the US, it's a prudent question to ask... will this technology potentially cost me my life? Clearly the answer for the current state-of-the-art in "smart" guns is YES, this is currently dangerous and error prone technology which IMO should not be legal to sell in a gun because it makes it overall _more_ dangerous not less.

But assuming we want to let companies sell these prototypes and let people buy them assuming they do so fully informed of the risk, and let the courts decide in the end if companies are liable when the "smarts" malfunction...

To the point about legislating whether guns _must_ implement this technology, I think this is a constitutional question, and so I think the bar is much higher than questions like seat belts, airbags, speed limits, etc.

We have the right to life, liberty, and the pursuit of happiness. We have the right to bear arms. And I think that means we have the right to own firearms which are free from DRM, if we so personally choose.

Your laptop can be infected with malware and potentially further spread malware or participate in DDoS attacks. Malware and DDoS as a whole cause great economic damage and potentially loss of life. However, if we let government whitelist all apps and require all computing devices to implement hardware trust zones to verify apps are signed and trusted by the government, this technology could prevent certain malware attacks. Is it Ok for government to pass legislation requiring this? We have the right to free speech and so I think it's a similar constitutional issue and I think the answer must be consistent with the firearm question, and the answer must be NO.

Just because a technology will absolutely save money and save lives, does not mean that technology can be mandated when it would impinge on constitutionally guaranteed rights. Under strict scrutiny a legislative remedy must be compelling, narrowly tailored to its purpose, and the least restrictive means possible to achieve the desired policy outcome.

DRMing all guns, like DRMing all computing devices, doesn't pass the test in my opionion.</comment>


Google employees 'refuse to be complicit' in border agency cloud contract - <AUTHOR> https://www.theverge.com/2019/8/14/20805432/google-employees-petition-protest-customs-border-cloud-computing-contract <comment><USER2> Maybe there's some "don't be evil" left at google after all. Good to see.

<comment><AUTHOR> I think management has gone full-soulless-corporation, but individual engineers still carry ideals and in today's job market they carry enough bargaining power to affect actual change. We should all take note.

</comment></comment><comment><USER3> Great opportunity for Google to let go of these types of people. They made their signatures public which was not very smart in the first place. You dont like what the company does, find a new job.

> We refuse to be complicit. It is unconscionable that Google, or any other > tech company, would support agencies engaged in caging and torturing > vulnerable people.

Are these people really that ignorant and clueless? This is not what is happening. Just because AOC or MSM says something does not mean it is fact. Obama had far worse conditions that Trump does today. Where were these hypocrites?

How many of those that signed are American's?</comment>


"I am the Orson Welles of PowerPoint" - <AUTHOR> http://www.mcsweeneys.net/articles/i-am-the-orson-welles-of-powerpoint

<comment><USER2> I liked the way the author describe a Powerpoint. Excellent!</comment>