Europe drafts law to ban mobile roaming charges - <AUTHOR> http://www.theguardian.com/business/2013/sep/05/europe-law-ban-mobile-roaming-charges <comment><USER2> > Her proposals have faced fierce opposition from the largest networks, > including Vodafone, Orange and Telefónica, which say the end of roaming > within Europe could cost them €7bn (£5.9bn).

Delicious tears.

Though I object to the use of the word "cost", it will remove unmerited earnings but will not add costs to their balance sheet: notice how the operators whining the most are the pan-european ones? That's because they can currently charge roaming fees for operations within their network, fleecing their own users.

<comment><USER3> > it will remove unmerited earnings

If people are currently paying roaming costs, then the earnings are clearly merited. You might find the practice distasteful, and wish it did not exist, but that does not make it illegitimate; they found something the market would pay for, and successfully got the market to pay for it.

There's no monopoly on cell carriers, as evidenced by the three separate carriers mentioned just in the sentence you quoted.

<comment><USER4> The fact that this was downvoted shows people on HN don't understand how the free market works. Adding more and more regulation only makes things worse for the end paying customer. Good luck.

<comment><USER5> _Adding more and more regulation only makes things worse for the end paying customer._

This is simply not universally true. The cell market doesn't exist without regulation. If any company can throw up a tower on any frequency and start a cell company the end paying customer is going to have a horrible experience.

<comment><USER6> like the wifi market? Oh right, open spectrum laws actually create useful services for consumers.

It is a fallacy to believe that frequency regulation is needed for services to come to market. Coopetition does happen in the real world (see all the devices made for open spectrum like 2.4ghz)

<comment><USER7> _like the wifi market?_

47 CFR 15 (and other countries' equivalents) probably counts as regulations.

</comment></comment></comment></comment></comment></comment><comment><USER8> This is one of the things the EU is really good at: making people-centric decisions, instead of corporation-helping choices. This roaming-charges change has actually been a long time coming, with forced decreases in tariffs for a while now, so it shouldn't surprise anyone. I just wish some similar agreement can be reached (in time) with countries outside the EU.

<comment><USER9> > I just wish some similar agreement can be reached (in time) with countries > outside the EU.

Intercontinental roaming charges are a bad joke (3$ incoming, 5$ out and yes, that's per minute) . What I do is to get a local SIM and communicate the number to those contacts that need it.

Internet (sometimes 20$ per MB and yes, you read that right) is less of a problem due the ubiquity of free WLANs.

Another really excellent thing the EU did is to mandate mini USB as phone chargers. With the noticeable exception of Apple every newer phone can be charged with any newer charger. This used to be a major pet peevee of mine.

<comment><USER8> I don't know if this still the case, but a while ago i bought an iPhone from UK (after the mini USB mandate), and it came with an adapter to miniUSB in the box. Even Apple had to abide to the new regulation.

As for the roaming charges, I completely agree. Even now, within Europe, it's really bad for data. I've traveled through 10 EU countries in the last 3 months, and had to buy 7 SIM cards, as my home carrier charges 2EUR for 5MB. I was lucky with my 3LikeHome sim card from Austria, which you can use with your home rates in a few other countries.

<comment><USER2> > it came with an adapter to miniUSB in the box

Yeah but that's an adapter, even though it does abide by the rules you still have to carry the adapter around. Most manufacturers just switched to miniUSB entirely, so you don't need an adapter, any combination of charger and phone should work (in practice there may be issues with undervoltage, I've seen combinations of phones and chargers not work)

<comment><USER10> There's not even rules, the EU just asked them to sort it out, otherwise it would legislate so they had have a common standard.

<comment><USER11> even better

</comment></comment></comment></comment></comment></comment><comment><USER12> I hope this is the tip of the iceberg of better things to come.

One of the most disruptive ideas the EU is working on (among alternatives) is detaching the network from the operators. This can considerably reduce network capex, homogenise network technology and allow for a real single EU telecom space.

By having operators become clients of a single network users will benefit from increase pan-EU competition, with more competitive and transparent rates.

This has been partly done at national levels in similar sectors, specially in the gas and electricity sectors (see National Grid in the UK, Snam Rete Gas & Terna in Italy, etc.). Gas and electricity networks are private but regulated, and third parties have access rights to the network to retail gas & electricity. In this telecom case, operators don't have commodity risk, which makes third-party access to the network infinitely easier.

Fingers crossed.

<comment><USER13> > One of the most disruptive ideas the EU is working on (among alternatives) > is detaching the network utilizes operators.

Since i was quite young it blew my mind that we didn't have one universal network which every network utilises. It is clearly more efficient, removes redundancy, spreads costs.

<comment><USER14> Networks can never work with capitalism, as there's more benefit to extending an existing network than creating multiple competing networks. Roads, Internet, wired phones. Thus the network might as well be owned and run by the government, and access to it sold to the public/companies.

<comment><USER15> I'm quite ignorant of the specifics of European and American telecom ecosystems. But I clearly remember the time when the network was owned and run solely by the Indian government. It was horrible. In the 80s, when we applied for a telephone line, we typically had to wait for about three years for it to be installed. To call someone in a different city, we'd have to place a "trunk call": call an operator, and request a line. The operator would call back when the line became available, typically an hour later. With private industry, even those who live each week hand-to-mouth can afford to carry around cell phones.

> Thus the network might as well be owned and run by the government...

Given a choice, I'd rather not live in such an ecosystem. Again.

</comment></comment></comment></comment><comment><USER16> This is a "bad thing." And here is why:

I hate roaming charges as much as anyone, nobody wants to pay 200%+ when they go to France or anywhere else within the EU. That being said, competition at least around here for mobile/3G is extremely healthy, prices have come down year on year and the choice/availability has gone up.

What I fear would happen if this went into force is that many (all?) of the smaller operators would go out of business overnight as they couldn't find a network within all continental european countries who will roam for them at a reasonable price.

Then you'll have Orange/Vodafone/etc who own a lot of the infrastructure across europe leverage that so essentially they're the only competitive player and get to set the prices however they want. They'll sell their subsidiaries roaming at X and their competition roaming at X*1,000.

Just look at the US: Their networks are inter-state, and as a result of having to cover such a large landmass it is almost non competitive. You have three companies controlling the whole country. Prices are extremely high and services/choice is poor.

I'd take what we have now, roaming charges and all, over a three network oligopoly.

<comment><USER17> >They'll sell their subsidiaries roaming at X and their competition roaming at X*1,000.

I doubt that would be legal. Anyone knows for sure?

<comment><USER16> As far as I know the EU does cap roaming charges already, and they could continue to do so in the future. But as far as I know there is no rule which forces companies to charge equal prices for their competition and their subsidiaries across borders.

For one example, Vodafone UK for £3 will let you use your "UK minutes, texts, and data" in any european country. The reason they're able to offer that is because Vodafone runs networks in most european countries.

<comment><USER18> Maintaining infrastructure doesn't become more expensive just because the competition is using it when roaming. What they're doing is basically double dipping charging customers for service and competitors for roaming which the network are passing along to the customers.

However you look at it the customer is the one getting screwed here. They are only bitching because they're being forced to re think their business model and make it more fair.

When you think that Vodaphone is doing it even if you're still using their network just in another country it makes you think what's the difference between this and stealing? They're not competing with themselves so it's basically a scheme to make more money.

<comment><USER19> I'm not sure that's true. If Company A builds out a bunch of infrastructure but it's mostly used by Company B's customers, then Company A isn't getting the earnings it needs to pay back the infrastructure investment. Either Company B's customers need to send some revenue to Company A, or Company A is going to go out of business, possibly taking the infrastructure with it. Roaming fees, whether paid by the customers, the companies, or both, are necessary to support building and maintaining the infrastructure.

Now, when Company A and Company B are actually two divisions of the same parent company (which is apparently often the case for Vodaphone) then you're right; the roaming fees are double-dipping.

<comment><USER18> Company A is still able to adjust pricing on a global level (all customers) to compensate. If too many of Company B's customers go on Company A's network pricing will increase until they start choosing cheaper networks automatically balancing load and keeping prices at a similar point.

Plus we're talking about roaming here it's not like a lot of people decide to go on vacation at the same time and stay there for years until the company collapses.

</comment></comment></comment></comment></comment></comment><comment><USER20> Am I the only on that thinks this is a bit of an overreach? Seems to me, good justifications for legislating would be

-If customers were being tricked into paying roaming charges in nefarious ways;

-If there were serious externalities somehow not being included in the roaming charge transaction

-If there were monopolistic / market manipulating behaviour going on.

-If the companies were subject to a tragedy-of-the-commons situation where private resolution was not feasible (they're not- the public broadcast spectrum is both rival and excludable in practice).

Instead, the state interest according to Kroes is that it's an "irritant." This kind of top-down control seems a bit counter to the hacker/startup ethos.

Edit: if you're going to down vote, please can you comment and have a dialogue?

<comment><USER21> > If customers were being tricked into paying roaming charges in nefarious > ways

If your phone rings abroad, and you don't pick it up, and the call goes to voicemail, they charge you for an incoming call and for an outgoing call. Even if the caller doesn't speak on your voicemail, you are billed at least 1 minute active + 1 minute passive.

Assume you're an Austrian, and you miss 3 calls while in Montenegro, that's 20€ in unexpected charges.

<comment><USER22> Huh?

Then there's something wrong with your operator. Roaming charges are for the "international" segment: from home, to the country you are, and from the country you are to home. That's why you pay extra to make calls, and that's why you get to pay when you receive calls.

But it's also "opt-in": you only pay for what you accept. You won't pay for SMS because you can't elect to receive them or not. And, if you miss, or reject a call, it goes to your voicemail. And the voicemail is in your country operator's. So, of course, you won't pay. Unless you have a weird phone and the voicemail is in your phone. Then turn off your weird mobile phone.

<comment><USER23> That voicemails are not subject to roaming charges within the EU is a quite recent thing, and I'm not sure if it's a result of regulation or if the operators have just pre-empted being forced to do it. When roaming outside of the EU, you can still expect to get hit with massive charges for receiving voicemail.

It's result of a quirk of how voicemail calls get routed: If you set up call diversion to your voicemail with your network, you'd not pay anything.

But if you fail to answer, or divert calls to voicemail with your phone, the calls would get routed to the network your phone is active in, you'd fail to answer, and the call would get routed back by the operator you're roaming with, rather than having that operator somehow just signal that the calls should be diverted at source, and you'd get to pay for the pleasure.

At least that's the excuse the operators used. Of course it was particularly shitty that they'd charge people extortionate rates due to shortcomings of the way they do call routing.

<comment><USER22> I've been travelling for a number of years (when a MB in Europe was around 10€), inside and outside Europe, and never ever had this happen, or heard about this happening.

Probably something intentionally made by your operator — but in Spain, I don't know of a single mobile operator who does not route voicemail at their own network level.

</comment></comment></comment></comment></comment><comment><USER24> As a resident in Denmark, this is awesome news. It really sucks that you've got so many internet connected things, but after 300km MAX, you are on the other side of the border, and you are reduced to feature phone-like capabilities (Thanks Nokia/HERE for offline maps).

To people from US; Imagine living on the east coast (with the smaller states) and every time you move outside of your state, you had to use a feature phone.

<comment><USER25> We don't have to imagine it -- that _is_ how it is in the US.

For example, if you are on T-Mobile USA, living on the east coast, anytime you drive west, after about 100km your "4G" smartphone is reduced to a feature phone (either on T-Mobile's own GRPS/EDGE-only network, or hyper-restricted voice/sms-only roaming on AT&T).

This happens even if the other operators have extensive 3G/4G/LTE networks available in those cities.

<comment><USER24> Aren't AT&T, Verizon, etc, nation-wide operators?

<comment><USER26> Yes, they are. HOWEVER:

The USA is __HUGE __. It 's not cost effective to put data where every inch of land is covered, ever slow data (EDGE). There's a ton of sparsely populated land, and rural areas. T-Mobile is a small operator and has the crappiest network coverage. It is 1000x better than it was 4 years ago, as they are adding more coverage, but it is expensive and slow. T-mobile is the worst for data coverage, and voice coverage. I had them for years, and I eventually dropped them for Verizon because I was finding myself without any cellphone service so often, because I travel often, and I find myself in rural areas. If I stayed in the city all the time it would work for me. That means no voice, no SMS, no data.

Take a look at T-Mobile's 3G and 4G coverage map (and voice):

[http://www.t-mobile.com/coverage/pcc.aspx/](http://www.t-mobile.com/coverage/pcc.aspx/)

Verizon:

[http://www.verizonwireless.com/b2c/support/coverage- locator](http://www.verizonwireless.com/b2c/support/coverage-locator)

Sprint:

[http://coverage.sprint.com/IMPACT.jsp](http://coverage.sprint.com/IMPACT.jsp)

AT&T:

[http://www.att.com/maps/wireless- coverage.html](http://www.att.com/maps/wireless-coverage.html)

The other big issue is we have two standards here. GSM and CDMA. GSM is what T-Mobile and AT&T use, and CDMA is what Verizon and Sprint use. These can't play nice-nice with each other. Plus AT&T's 3G was different from T-Mobile's 3G so a AT&T 3G phone couldn't work with T-Moble's 3G signal and vice-visa.

With 4G LTE, I _believe_ this is a standard that both GSM and CDMA are "upgrading" to. I know that my CDMA phone needed a SIM card to work with the 4G LTE network (CDMA cards previously didn't require SIM cards).

</comment></comment></comment></comment><comment><USER27> Long overdue, especially for people living in the smaller EU countries, where driving ~3 hours in any direction will render your smartphone useless (or very expensive). Large carriers, which are complaining the loudest, shouldn't have an issue with this, since they are present in virtually all EU member states.

<comment><USER2> Of course they have an issue, _because_ they're present in virtually all of the EU it's completely free money for them right now.

<comment><USER13> Three in the UK clearly saw this coming and recently made roaming in several countries completely part of your monthly package

<comment><USER28> The countries are: Ireland, Australia, Italy, Austria, Hong Kong, Sweden and Denmark.

[http://www.bbc.co.uk/news/business-23896896](http://www.bbc.co.uk/news/business-23896896)

(This doesn't look to be symmetric, for some reason--if you're a Three customer in one of those countries I don't think you avoid roaming charges in the UK.)

<comment><USER29> Three customers in Italy had the no-extra-charge-when-roaming feature already 4-5 years ago actually. That was both for data and voice. [http://www.tre.it/opzioni/estero/all-estero-come-a- casa](http://www.tre.it/opzioni/estero/all-estero-come-a-casa) EDIT: I see there was a bit of overhead actually. not quite the same tariff.

</comment></comment></comment></comment></comment><comment><USER30> > Other new measures include open internet safeguards to stop broadband > companies blocking legal but competing websites and services such as Skype

I also like the look of this. Not quite full network neutrality but in the same spirit.

</comment><comment><USER31> About time. I'm waiting for this for a while. I travel a lot in EU and it's very annoying going around with a bag of sims in my pocket. Kroes does some nice things; hopefully it'll go through.

</comment><comment><USER32> This could have the potential to become quite disruptive. If there are no roaming charges, I will be free to select any operator from any EU country and am not stuck with the ones where I reside. This will increase competition, and lower prices (or service levels will increase).

<comment><USER33> I don't know about the situation in most of Europe, but I think at least some countries could be severely disrupted by French operators, which seen some very low cost alternatives emerge since the irruption of a 4th operator in early 2012.

2h + SMS only costs 2€/mo, where it used to be 16-25€ only two years ago ; and the full package (unlimited everything, with data bandwith capped after 3GB) 20€

Now if there's a country with even cheaper mobile plans... I'd like to see that

<comment><USER34> Latvia - Tele2, 9eur for unlinited domestic calls/sms+2GB of full speed, after that capped to 64kbps but still unlimited.

</comment></comment></comment><comment><USER35> This will eventually lead to mobile phone charges balancing all over the European continent. Otherwise people in Denmark will be using Bulgarian or Romanian pre-paid SIM cards buying credit online assuming that mobile providers can't charge the same for the services in richer and poorer countries.

<comment><USER36> This could be the case for the internet, but AFAIU not (so far) for the calls or SMS. No roaming fees means that if you have a Bulgarian SIM and live in Denmark and you call a Bulgarian number, you will pay as if you were in Bulgaria. But they can still tax you more when you're calling to the Danish or any non-Bulgarian number.

Anyway, for people who rather use internet than make phone calls, this can be a good deal indeed.

<comment><USER26> When we are all using VoIP rather than traditional voice, this is relevant.

</comment></comment></comment><comment><USER37> About time... companies like 3 and vodafone are basically the same network all over Europe, there is no justification for any roaming charges

</comment><comment><USER38> This is definitely not a good thing. It is a step in the wrong direction that the European Union gains more power to regulate the market in this fashion.

The reason operators are able to charge for roaming as they do, has a lot to do with the fact that the telecommunication business isn't a free business. Currently only a select few in each country who are paying a large licensing fee are allowed to set up the different types of networks (GSM, UMTS etc). What is happening is you grant special benefits to the operators, so they are working in a protected environment. Of course they are going to charge extra if no-one is there to bid lower.

What the EU is doing right now is trying to fix a symptom created by an already wacky system that their member states have created themselves.

<comment><USER23> > Currently only a select few in each country who are paying a large licensing > fee are allowed to set up the different types of networks

Just like in pretty much every country in the world. Spectrum is a public resource, and not an infinite one. Every allocation given to a private company deprives society of other potential uses of that spectrum.

The EU communications market is already vastly more competitive than e.g. the US market in many areas, _thanks_ to extensive regulation to force unbundling of a lot of network and consumer services. This is about fixing some of the remaining problems, yes.

If anything, the regulation of the communications market in the EU is both one of the biggest successes in recent years, and one of the areas where EU decisions are most popular with EU citizens.

<comment><USER38> That is exactly the Point. Spectrum is scarce, and just like land areas are treated(mostly) with property rights, so should radio waves. That it historically has been mistreated doesn't make the solution in the subject any better.

</comment></comment></comment><comment><USER39> Long time coming. India (which is a pretty huge country) did away with roaming (incoming call) charges back in 2003. What followed, was a telecom revolution; albeit with the evil of corruption along the way but good did come out of sensible and foresight.

</comment><comment><USER40> Interestingly enough (Telia)Sonera has already removed (some) of it's roaming charges when roaming on their own network. I think that's quite nice of them, even though it probably was mostly a marketing move preempting this EU decision.

<comment><USER41> Yeah I just recently found out about it. Awesome news as I just moved from Finland to Estonia (but will spend a lot of time in Finland too) a week ago. It would be a hassle with two SIM-cards. It has always sucked to go on trips through many countries where you really could use affordable data, to book hotels/hostels, view Google Maps, Translate among a million small things that make mobile internet useful in the first place. I really love this about the EU; making decisions for the people instead of corporations.

</comment></comment><comment><USER42> Explain to me, why wouldn't this merely result in the phone companies charging higher monthly fees?

<comment><USER43> Most of the phone market is very transparent. It's just the roaming charges that make them feel like a bait and switch. Higher monthly fees are better than roaming charges, because there's clear and transparent competition there.

</comment></comment><comment><USER44> Hear hear, its costs them 7bn ? How about 7bn less revenue from something that is so overpriced its not even funny. Im glad WhatsApp already killed SMS in many countries, the money made on overpriced SMS/MMS must have been ridiculous..

I hope IP will replace all the other stuff eventually. If your abroad its relatively easy to find a Wifi and use Skype/Viber/WhatsApp, so we just need to get even more Wifi!

</comment><comment><USER45> Good or bad this _is_ central planning, or something very close to it. Price controls. Mandated alliances. Minimum coverage requirements.

<comment><USER46> > " _From 2014, customers would be able to keep costs down by selecting > another provider for calls, texts and internet data services while > travelling, if their own network charges extra for service abroad. They > could do this without having to change their phone number or buy a new sim > card._ "

Seems to me like one of the goals of the new regime is to move at least a bit _away_ from the (somewhat clumsy) regulatory approach of setting price controls, in favour of an approach of reducing transactional costs in order to enable free-market competition between providers in different countries.

</comment></comment><comment><USER47> As much as I hate the outrageous high roaming charges, I'm not sure regulating them completely away is the best idea. Dictating companies how much and for what they can charge is one of the strongest possible market intervention, and may very well lead to less competition and therefore, higher prices and (eventually) less innovation.

Personally I think the same effect could be achieved by a much smaller intervention, namely decoupling billing from physical SIM cards. If it was possible to get the local (prepaid) rate without having to get a local SIM card (which, even in 2013, is often a somewhat difficult procedure, especially if you don't speak the local language), there would not only be no reason for roaming charges any more (just get a cheap prepaid rate and you are set), but there would also be more (not less) competition, because one could switch providers any time, even in his own country. The phone number, of course, should remain bound to the SIM card, just the billing should be "virtualized".

</comment><comment><USER48> While it is nice the EU is regulating the mobile phone market like this, it sometimes creates funny situations. In many countries it's cheaper to send an SMS _being abroad_. Right now the regulated cap for an SMS sent in roaming is at €0.09 and will be €0.06 in 2014, but sending texts from your country often costs €0.15 :)

<comment><USER49> It's not unusual to find while roaming that MMS is cheaper than SMS. As in it would be cheaper for me to write out my message by hand, take a photo of it and sent that, than just to send a text message.

</comment></comment><comment><USER50> About four years ago I lived in Tanzania. I had a sim card from Zain(* ). As standard, it had no roaming charges in East Africa and parts of the middle east. In foreign countries, you could even make calls at the local rate. It's great to see Europe catching up.

* Now (I think) part of Airtel.

</comment><comment><USER51> I think this is great, and I cannot wait for this to happen, but we also should credit some operators for their current efforts.

O2 launched in UK Tu Go app which I find really great. It basically allows you to make and receive calls (and text messages) over wifi . Not only it is great if you have spotty reception at home, but you can use your phone whenever you find public wifi abroad.

</comment><comment><USER52> Interestingly, Hutchinson/Three has started to remove global roaming fees from their own network.

[http://www.three.co.uk/Discover/Phones/Feel_At_Home?id=1229](http://www.three.co.uk/Discover/Phones/Feel_At_Home?id=1229)

</comment><comment><USER53> Roaming charge made more sense when you were actually roaming to another carrier when you went to another country. But now that carriers in the EU are almost all trans-national roaming charges make less sense. They're just a relic of the past.

</comment><comment><USER54> I thought it was already passed law, to come into effect July 2014. Guess I was wrong. In any case, it'd be nice not to have roaming data charges.

</comment><comment><USER55> I applaud this - but it feels a bit like treating the symptom, a cause being regulation that helped create an oligopoly.

</comment><comment><USER56> I'm appalled by all the anti free market comments here. Governments have no business dictating simple contractual agreements such as this. So long as governments allow adequate competition the markets will meet customer demands.

<comment><USER57> > So long as governments allow adequate competition the markets will meet > customer demands.

This is demonstrably not the case with cell phone service providers.

Mobile telephony providers use deliberately confusing pricing to prevent price comparison. They use contract lock in to prevent customers switching contracts. They exploit the apathy and inertia of customers.

What would work in an ideal situation is not what would work with the situation we have. Tightly regulated, often government owned, communication networks are being deregulated, split off from those government owned companies, while expanding into new markets.

We need regulation to prevent incumbents from exploiting their government- subsidized position, and to protect naive users from themselves.

<comment><USER56> > Mobile telephony providers use deliberately confusing pricing to prevent > price comparison. They use contract lock in to prevent customers switching > contracts. They exploit the apathy and inertia of customers.

There are many providers now who don't require contracts. Every provider in the US has some sort of prepaid / no contract plan. The prices are much better than contract plans too, at least in the US.

> We need regulation to prevent incumbents from exploiting their government- > subsidized position, and to protect naive users from themselves.

No, you highlighted one of the problems. The government needs to stop backing monopolies / oligopolies and allow competition to flourish. Government involvement always compounds itself. Subsidization and promotion requires regulation later to compensate for the lack of a free market.</comment></comment></comment>


A Back Door to Encryption Won't Stop Terrorists - <AUTHOR> http://www.bloombergview.com/articles/2015-11-18/a-back-door-to-encryption-won-t-stop-terrorists <comment><USER2> So, here's my take on all this 'surveillance is good for you'.

It more or less proves (to me at least) that the government(s) and the various secret services have absolutely no idea who to monitor specifically. So instead of targeting their operations they want to monitor all of us, just in case something of interest pops out that then allows them to focus their attention.

It's a pretty scary thought: just imagine, all that money, all those resources and _still_ they can't do anything other than to put their ear to the ground and _hope_ that someone messes up in plaintext so they can then try to backtrack and see what they might have missed.

In all these attacks it never happened that everybody was under the radar. Always one or more of the attackers that were technically known or even already under surveillance. And yet the attacks happened anyway. Too many targets make for a very thinly deployed service, which then has to be automated to make it work at all.

It's a pretty sobering thought, it also suggests via yet another route that mass surveillance is indeed meant to attempt to 'keep us safe', and that it fails miserably. The road to hell is paved with the best of intentions.

Terrorists have it so easy, all they need to do is to be just a little bit unpredictable or simply old-fashioned (in person) and there won't be anything whatsoever that we can concretely do to stop them. The only thing that actually gives a bunch of actionable data is when an attack is executed or when an attack goes sour (or rather: sweet as in, it does not work) from which direct evidence of contacts or plans is gained. This will then lead to a relatively short lived number of arrests clustered around the people caught or implicated and then it burns out again where the data ends.

And so then we get to wait for the next attack...

<comment><USER3> You nailed it, I think. If surveillance works, then Paris, Beirut, Bagdad et al wouldn't have happed. Realizing it's a pipe dream, I'd love to see a world accept that we the west have done so much damage that nothing will stop terrorism.

Accepting that means we can throw those wasted resources at things that have a better chance of working - throw the tech that detects copyright infringements at detecting pro-ISIL sites, and use DCMA-style tactics to take them down. Fund new research to put effective bomb and weapon detectors into every doorway. Because protecting borders doesn't work either (crunchy on the outside, soft on the inside). Build schools, instead of bombing them. Stop selling weapons to the very people that shouldn't have them. Teach politicians to value non-American lives as much as American ones. Stop honouring violent death, and honour the deaths of people who move humanity forward instead.

There's an endless stream of ideas of what we _could_ do, if only we actually _wanted_ it.

<comment><USER4> > If surveillance works, then Paris, Beirut, Bagdad et al wouldn't have > happed.

I don't think surveillance is very good at preventing terrorism, but I think it could be useful to law enforcement after the fact to round up co- conspirators. I bet that once the identity of the Paris attackers was learned, the NSA pulled up a graph several levels deep of everybody they communicated it or associated with. It could very well help them figure out who else is involved and should be watched.

For the record, I'm opposed to surveillance and would be even if it were shown to be very effective. Privacy is important and is worth more than the lives that have been or will be lost to terrorists and other criminals.

<comment><USER5> They found one of the terrorists phones dumped in a garbage can outside the theatre they attacked, and got the address of their hideout from the messages, so used just regular police work.

All these guys were already on watch lists for fighting in Syria and returning just nobody seems to ever watch the watch list.

<comment><USER6> If that phone was properly secured then those messages wouldn't have been accessible.

<comment><USER7> You'd still have a telephone number. From that telephone number you could go to a judge and request a warrant for the telephone records. From there you could look at all the numbers dialed and received. Now you get a warrant for the addresses of the subscribers.

No bulk surveillance required, just honest police work within the confines of a valid and acceptable legal framework.

</comment></comment></comment></comment></comment></comment><comment><USER8> Encryption backdoors are a lightning-rod topic on HN, but instead of repeating all the common-talking points, I'd suggest the following:

Think through something like this, outside of your expertise, that you think the powers-that-be should just do. Maybe it's something with your local municipality's approach to road resurfacing, maybe it's the quarterback on your favorite football team, maybe it's your local zoning board.

Chances are better than even that there is a decent technical reason why they don't do what they do. Looking at things that way will save you a lot of headache in your life, and set you on the path to getting on someone's side to affect change, rather than just being another shrill voice yelling against them.

So politicians and intelligence services calling for encryption want, institutionally, to keep people safe. How can tech companies do that without breaking or backdooring encryption? That's the real problem to solve, and the first person to figure out how to do that will be way ahead.

<comment><USER9> The best backdoor to encryption has always been social. Talk the right way to the right people... and it doesn't matter what type of security you have.

Isn't that the entire purpose of agencies like the CIA?

It just bothers me when privacy is treated as a negative thing, for the greater good or not. Encryption is a tool to create privacy. The ability to create privacy should be a point of pride as not everyone has that luxury. It should be a human right.

This is the primary reason why I feel things like CISA/CISPA/etc take society in the wrong direction. It doesn't matter if the intentions are good or bad when everyone loses.

<comment><USER10> Except encryption provides a level of privacy that has never before been possible. Could you imagine a physical padlock that was unable to be cracked, cut, or circumvented in any way? It is easy to see how that would scare law enforcement. Imagine your job is to keep people safe. Now envision a kid strapped to a bomb inside a shack and the only thing preventing you from breaking in and saving that kid's life is that magical and unbreakable padlock. That is how many laypeople view encryption. It is hard to tell that person that you won't consider introducing any weakness into that lock.

<comment><USER11> That's a good analogy, but the padlock has already bolted!

Information about the uncrackable padlock is widely available. Bad guys will always be able to get these padlocks from the black market. The question is whether we want the good guys (i.e. us) to have the padlocks too.

<comment><USER10> This is a fair counter, but I feel like we already have examples of how the government would respond there. We might have to switch analogies, but wouldn't encryption then be like a weapon. The goal would then shift to being about deproliferation. The fact that nuclear weapons or AK47s already exist doesn't prevent the government from preventing regular people from acquiring or using them. Maybe preventing new products from entering the market and flooding the market with faulty products (encryption with backdoors) is a good way of combating what is already out there.

<comment><USER12> The terrorists will use encrypted, unbreakable methods no matter that Google or Apple use is their OS. That's really the only point that matters.

<comment><USER10> And I might be able to get my hands on an AK47 if I really wanted and had enough money to dedicate to it. That is the truth of the world. But do you believe that making it harder to acquire a weapon like that doesn't have some benefit?

Back to HN's world, one of the basic principles of human factors is "make the right thing easy and the wrong thing hard." You might not be able to prevent people from doing the wrong thing, but there is still value in making it harder to do.

<comment><USER12> It's not hard to download some software while sitting in your house. Much easier than buying an illegal gun.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> How about this: we assume terrorists can fucking talk covertly whenever they like (since there are myriads of channels and codes that they can use) and that mass surveillance is not the way to catch them plotting their next act.

And from then on, ONLY use surveillance on specific targets under investigation.

And while at it, maybe even have a limit on the number of targets each agency can investigate, so they chose them wisely.

<comment><USER14> >And while at it, maybe even have a limit on the number of targets each agency can investigate, so they chose them wisely.

This is an insanely bad idea. I understand where you're coming from, but think about how that would play out in real life. I was going to write it out, but I really think that you can probably figure it out if you do think it through. From the perspective of the intel/policing agency, and from a political side, there are too many good reasons why we should not limit the number of targets an agency can investigate.

<comment><USER15> How about actively at one time if not in general? I think if you think through it you can figure it out. Just start with all the terrorists and crooks they already had red flags on but did nothing. Then, look at what excuse they make about connecting the dots in so much data. Then look at the two obvious solutions:

(a) Magic, AI, pixie dust tech that spots the evil, relationships, and all key information in nearly unlimited, streaming data.

(b) Eliminating bulk collection (except maybe metadata) while forcing them to focus on the results of targeted investigations on accounts or individuals. Also, forcing them to follow-up on solid, red flags rather than BS around trying to find reasons everyone else might be guilty.

I think pushing for option B is a rational choice. Also, ensuring the greatest accountability possible given all the main players have a history of using their police and intelligence for matters that have nothing to do with protecting citizens.

<comment><USER14> When does an investigation start and end? What about when you're close to filling your limit but a few new great leads come in. Now the agents have to go close a ongoing investigation to follow up on a new one. Sounds like a lot of overhead. Not only that, but the fact of modern intel work is that investigations don't operate in a clear, linear progression.

I think that anyone that's had to deal with arbitrary limits imposed from above understands the perverse incentives that they create. This would be another example of administrators trying to fix something that they don't understand.

<comment><USER13> > _When does an investigation start and end? What about when you 're close to > filling your limit but a few new great leads come in._

What about that? They could have a limit in the tens of thousands or so. As long as they don't waste it on BS, they could follow all the promising cases they want.

The idea is not to let them follow everybody, just for the fun of it.

<comment><USER15> Exactly. You got the message easy enough. Makes me lean more toward sophistry for the other person.

</comment></comment></comment></comment></comment></comment><comment><USER16> Apparently, the terrorists that attacked the concert hall in Paris last week were using... unencrypted text messages to communicate between themselves and/or their "boss".

According to the newspaper Liberation [1], they sent a text message at 9:42pm telling: "we're out we begin".

[1] [http://www.liberation.fr/france/2015/11/18/la-piste-du- sms-e...](http://www.liberation.fr/france/2015/11/18/la-piste-du-sms-envoye- par-un-des-terroristes-du-bataclan_1414317)

</comment><comment><USER17> > but debates about whether the technology should have a "back door" for > intelligence services are heating up again

What "debates"? there is absolutely nothing they can do to enforce terrorists to use backdoored encryption, any debate is just a waste of time, money, and maybe even lives. What are they thinking??

<comment><USER18> Exactly. This is the same as gun control. If a technology exists, you cannot tell people to not use it; otherwise, all you've done is put law-abiding citizens at a competitive disadvantage while arming the bad guys. To argue otherwise is absolute ignorance.

<comment><USER19> > _If a technology exists, you cannot tell people to not use it; otherwise, > all you 've done is put law-abiding citizens at a competitive disadvantage > while arming the bad guys._

This comment is amazing self parody.

So what, we should we let people cook up nerve gas and anthrax and build surface-to-air missile launchers in their garages, to make sure they have competitive parity with the bad guys?

<comment><USER20> Most individuals who would even begin to consider trying to "cook up" substances like nerve gas or anthrax "in a garage" would undoubtedly die in the process, in which case problem solved.

And yes, people should be able to build "surface to air missile launchers" in their garages. It's called amateur rocketry, and last I checked it was quite a popular (and legal) hobby.

The vast majority of encryption is used in a lawful way to protect important things (information). The vast majority of firearms (in the USA at least) are used in a lawful way to protect, deter, as a hobby/for fun, and for sport/hunting.

They are very similar arguments, for a number of reasons, including the utter stupidity of attempting to make law-abiding citizens jump through even MORE hoops whilst accomplishing absolutely nothing in "preventing the bad guys from making use of" said technologies.

</comment></comment></comment></comment><comment><USER21> Oh and by the way - the Paris terrorists didn't even use encryption:

[https://theintercept.com/2015/11/18/signs-point-to- unencrypt...](https://theintercept.com/2015/11/18/signs-point-to-unencrypted- communications-between-terror-suspects/)

How about that? Hopefully now the blame will be put where it should be: the wastefulness of mass surveillance, which dramatically increases the "noise" compared to the signals, since the agencies have to "look" at many more innocent people and waste time and resources doing so.

</comment><comment><USER22> The line at the end that really hit me was this:

> _Almost all the attackers were known to the authorities, and if they had > been watched, their use of encryption programs would have itself invited > closer scrutiny._

This is precisely the scenario that Phil Zimmermann (creator of PGP) and others have been warning about (and working against) for decades. As Zimmermann said in a 1999 essay linked here not long ago, "What if everyone believed that law-abiding citizens should use postcards for their mail?" ([https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html](https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html)) The scary part to me is not just that it's our present reality, but that it's so readily accepted. Crypto advocates need better PR. (And to be fair, better UI.)

<comment><USER23> Better UX as well, but I guess you implied it. The only apps I can convince friends to use that support encryption are the seamless ones.

</comment></comment><comment><USER24> The IRA were known to recruit top stem students from universities in Ireland during their campaign to make bombs. Surely an entity as large and as well financed and ISIS would have little trouble finding bright young engineers & technologists sympathetic to their cause to simply build their own encrypted services? And then so much for the spooks 'backdoors'

<comment><USER25> > Surely an entity as large and as well financed and ISIS would have little > trouble finding bright young engineers & technologists sympathetic to their > cause to simply build their own encrypted services?

You wouldn't even need the brightest engineers. In fact so many encryption algorithms have been opened sourced and / or in library form for so long that it's easy for practically any developer to do.

<comment><USER26> Just having a library that does something doesn't magically bring security. The issue is, engineer still needs to know a lot of stuff (or strictly conform to the instructions) to use the thing correctly. There are too many ways to screw the thing up without even knowing it.

So, if the thing's to slap some nice GUI upon an existing library that implements the security bits, then almost no knowledge's required. But if one has a library full of primitives but still has to combine them in a meaningful way - it's a damned minefield.

</comment></comment></comment><comment><USER27> I think this article misses the most obvious point. Encryption is widely available for free and in the open. It's not about listing the devices or code they might not trust, if there's even one that they do trust, then you can backdoor everything else and it won't matter.

Why do they think they can put the Genie back in the bottle? The answer is they know that they can't, the backdoor only effects the people who don't care they are being tracked. It's not for terrorists, it's for people who carry smartphones. Which is almost everyone, so good enough for them. But the argument is absolutely nothing to do with "preventing terrorism".

</comment><comment><USER28> This is like in WWII, when Churchill and Turing gave so many newspaper interviews re: how awful it was they couldn't crack Hitler's encryption anymore that he finally gave in, went back to the 3-rotor Enigma machines and we won the war.

</comment><comment><USER29> When X is illegal, only the criminals will have X.

Replace X with basically anything.

<comment><USER30> "When nuclear bombs are illegal, only the criminals will have nuclear bombs."

I think your grand unifying theory needs more nuance.

<comment><USER13> I hope we don't depend on the unavailability of nuclear bombs to the bad guys on them being "illegal".

<comment><USER31> No, we depend on the enforcement of that illegality, which is usually assumed when people discuss banning something.

(EDIT: Previously said "making something illegal", which I realised was ambiguous.)

<comment><USER32> What, do you plan to make talking about crypto illegal too?

<comment><USER31> I was replying to the general sentiment, not the specific.

Obviously banning encryption is ridiculous, but the "Only criminals will have X" argument is just silly rhetoric.

EDIT: I just noticed the ambiguity you're more likely responding to in my original post. I'll reword it.

</comment></comment></comment></comment></comment></comment><comment><USER33> I think the entire discussion misses the even more important point - terrorists won't care whether encryption is backdoored or not. It's a good OPSEC to assume all communication is being listened to anyway, and to rely on steganography and disappearing in the noise. Bad guys will simply use the same backdoored crypto everyone else will be using, communicating in the same way they do today, because using the unbroken crypto will be easily detected as suspicious action.

<comment><USER34> _" rely on steganography and disappearing in the noise."_

They already do that[0].

0\. [http://arstechnica.com/business/2012/05/steganography-how- al...](http://arstechnica.com/business/2012/05/steganography-how-al-qaeda-hid- secret-documents-in-a-porn-video/)

<comment><USER33> Yes. My point is, they'll keep doing that, so backdooring encryption doesn't really help in any way.

</comment></comment></comment><comment><USER35> As with most things, I think that it is a trade off. There is a very delicate balance between security and privacy.

Too much surveillance

\- General public feels incredibly uncomfortable due to lack of privacy

\- An incredibly scary amount of power in the hands of whoever has access to that information ( and who knows what they will do with it )

\- Reduced risk of terrorism and security concerns

Too little

\- Increased risk of terrorism + massive security concerns due to lack of intelligence ( it's like trying to find a needle in a huge haystack )

\- Public feels safe due to perceived increased privacy and yet feels unsafe due to ( potentially ) increased number of terrorist incidents.

It's a rather difficult problem to solve. How can we extract critical security information without invading people's privacy?

</comment><comment><USER36> _" I was able to leave and come to Shām (Syria) despite being chased after by so many intelligence agencies. My name and picture were all over the news yet I was able to stay in their homeland, plan operations against them, and leave safely when doing so became necessary," Abaaoud claimed in the interview, according to ISIS."_

[http://www.cnn.com/2015/11/16/europe/paris-terror-attack- mas...](http://www.cnn.com/2015/11/16/europe/paris-terror-attack-mastermind- abdelhamid-abaaoud/index.html)

</comment><comment><USER37> A back door to encryption would be a great tool for terrorists if it were leaked.

<comment><USER38> When not if.

</comment></comment><comment><USER39> I've gotta believe these organizations can find one or two developers among the billions of muslims on this planet. Why wouldn't they just write their own apps for android and call it a day?

<comment><USER40> The Mexican cartels captured and paid engineers to build them there own private cell network[0], so it isn't out of the realm of possibility that ISIS is doing something similar.

I am sure they have at least a few engineers kicking around what amounts to be an entire country. I haven't heard many people harping on about encryption, TBH, except people defending it here and that idotic NYT article.

However, if you had 10 amazing engineers you would likely have strike capabilities orders of magnitude higher than a few suicide bombers. So sure, gather surveillance, but let's play some defense. Shore up our infrastructure much better than we do now, because after they make their own apps and networks, they are going to come for ours potentially.

[0][http://www.wired.com/2012/11/zeta- radio/](http://www.wired.com/2012/11/zeta-radio/)

</comment></comment><comment><USER41> This is to control the population, and it will get asked for every time there is a nice excuse.

</comment><comment><USER42> I always assume these types of stories are red herrings and intelligence agencies already have back doors or decryption methods that they want to keep hush. Make a big song and dance about how encryption is secure and push criminals towards it, meanwhile its a trap. Look at all the Tor takedowns as evidence. It's all fine by me really.

<comment><USER15> Like they did with iPhone, etc before Snowden showed they had compromised it all? ;)

</comment></comment><comment><USER43> If they know there's a backdoor to one type of encryption wont they just use a different form of encryption?

</comment><comment><USER44> This isn't about terrorists using encryption. It's about a culture of control, violence, and domination trying to extend its power to encrypted communiction.

</comment><comment><USER45> _There 's no evidence the plotters of the Paris terrorist attacks used encrypted communications_

First sentence is already wrong.

They recovered smartphones that had encrypted messaging apps.

Still no excuse for government backdoors which will be stolen by all kinds of entities within months of their creation and allow the wrong people to spy on law enforcement itself.

Government had a 10 year headstart before all this, where are all the terrorists they stopped before this?

<comment><USER46> My phone has at least two encrypted messaging apps on it that I've been meaning to learn how to use. Everyone I know uses Kik though and has 0 desire to switch. So we really don't know that they where actually using them if that's all they really found.

<comment><USER45> Well unless they factory reset the phones, which they obviously did not, android keeps usage stats on app so it would be obvious if the apps were used or not.

But you are right, it could just be someone overstating something where apps have the ability to be encrypted, not that they were used that way.

Still all these people were already known to their secret services. Some even had phone taps already. It was yet another intelligence failure like we saw on 9/11

</comment></comment></comment><comment><USER47> I think one thing we as a tech community overlook is the expectations on the intelligence community. The broader community expects the intelligence agencies to stop ALL terrorists attacks, and thats just not feasible. This drives the intelligence agencies to do more, which is why I think there is a big push for broad dragnet activity.

</comment><comment><USER48> Terrorism, anarchy, and general mischief all existed long before the Internet and will undoubtably outlive it.

</comment><comment><USER49> Back doors are very useful to tracking down tax evaders, political opponents or dissenters, or any other number of things which increase government revenue or power. Terrorism is just one excuse used to justify the rest of it. Crypto backdoors will be mandatory one day, it's inevitable.

<comment><USER50> It's inevitable only with an attitude of "it's inevitable".

<comment><USER51> If you believe it, it will come true!

</comment></comment></comment><comment><USER52> Governments regularly intercept plain old SMS messages. If the government can demonstrate cases where this has prevented a terrorist incident in the past, wouldn't that suggest that similar snooping on iMessages would prevent terrorism in future?

</comment><comment><USER52> "Almost all the attackers were known to the authorities, and if they had been watched, their use of encryption programs would have itself invited closer scrutiny."

Well, unless they were using WhatsApp or iMessage, which almost everyone uses.

</comment><comment><USER53> > A Back Door to Encryption Won't Stop Terrorists

It' not like terrorists use Twitter</comment>


Real time form analytics - <AUTHOR> http://www.formisimo.com/

<comment><AUTHOR> "67% of your potential customers who start an online form or checkout don't complete it.

Find out why."

This sounds pretty useful, yet very simple. I wish I'd thought of it!</comment>


Let's Write Some x86-64 - <AUTHOR> http://nickdesaulniers.github.io/blog/2014/04/18/lets-write-some-x86-64/ <comment><USER2> I think it's important to state that ABIs are just conventions, standards that have been decided upon by mostly _high-level-language_ designers, and may not reflect any inherent limitations of the machine itself. In other words, you'll need to know them if you interface with other code written in a HLL, but if you're using Asm, there's no need to stick to this rigidity _within_ the code you write.

For example, the stack alignment restriction only came about because _some_ SSE instructions initially required that their operands be aligned in memory. This is a rather odd restriction considering that x86 was always intelligent about unaligned accesses (they used to be slower, but the penalty has almost disappeared with the latest models), and later revisions of SSE added instructions for unaligned access. But this doesn't affect any other instructions - in particular, call/return don't care, so in your own code you don't need to align the stack every time - it's only when you call into some other code that requires/expects such a condition.

Ditto for calling conventions; they are defined just so you can interface with other code, and not due to any inherent aspect of the instruction set. In fact although there are explicit call/return instructions, nothing requires that you use them, nor does the concept of a "function" even exist at this level. This means you can write horribly convoluted "sphagetti code", but also do what can't be done easily in a higher-level language with "unconventional" control flow, like coroutines ([https://news.ycombinator.com/item?id=7676691](https://news.ycombinator.com/item?id=7676691) ).

Also, I believe that you should learn Asm not just so you can write the same code a compiler could generate, but so you can see and exploit the full potential of the machine. I feel this point is lost in a lot of material on this subject, maybe because their authors also never realised this, and so contribute to the belief that using Asm is extremely difficult and tedious with very little gain. IMHO it's only when you "break out" of the restricted way of thinking that HLLs impose, and see the machine for what it really is, that you can truly see the cost-benefit tradeoff and what it means for code to be efficient. Look at the demoscene 4k/64k productions for some inspiration. :-)

<comment><USER3> An opportunity to mention that Go uses the Plan9 ABI which is different to GCC C style ABI. Plan9 did away with previous ABI conventions to make it easier to port code. Portability was built into Plan9 from the outset, rather than "ok, it works for x86, how shall we #ifdef other CPUs into our code"

A simple overview is given in this recent article

[http://nelhagedebugsshit.tumblr.com/post/84342207533/things-...](http://nelhagedebugsshit.tumblr.com/post/84342207533/things- i-learned-writing-a-jit-in-go)

<comment><USER4> Go doesn't use the Plan 9 calling convention, and there's not a single Plan 9 calling convention anyway. Go arguments are passed on the stack, and results are on the stack too. The Plan 9 C compiler used by the Go toolchain passes arguments on the stack, but the return value is in a register. On Plan 9, the first argument is usually (but not always) in a register. All these are different.

Go inherited and extended the Plan 9 toolchain, but the calling convention was changed. The main reason Go returns on the stack is to support multiple return values.

</comment></comment></comment><comment><USER5> Great article, and nice to have clear examples of calling printf() from x64!

 _x86-64 ABI point 3: Variadic functions need to have the number of vector arguments specified in %al._

Did you find any articles that explain the rational behind the way "varargs" argument passing is done? Or better specifications for it? It feels like a total mishmash.

For example, _why_ is the number of vector arguments specified explicitly, but the number of total arguments is not? It seems so obviously useful to pass that total that you'd hope there would be a good reason not to do so.

And since printf() is using the format string to determine the number of variables anyway, why can't it just count the number of vector arguments itself? What does it do differently when the wrong number is given?

<comment><USER6> See: [https://blog.nelhage.com/2010/10/amd64-and- va_arg](https://blog.nelhage.com/2010/10/amd64-and-va_arg) ("To start, any function that is known to use va_start is required to, at the start of the function, save all registers that may have been used to pass arguments onto the stack, into the 'register save area', for future access by va_start and va_arg. This is an obvious step, and I believe pretty standard on any platform with a register calling convention. The registers are saved as integer registers followed by floating point registers. As an optimization, during a function call, %rax is required to hold the number of SSE registers used to hold arguments, to allow a varargs caller to avoid touching the FPU at all if there are no floating point arguments.")

When va_start is used, it needs to save argument registers to the stack in the prologue of the function. The program is free to use different conventions (format string, sentinel value) to signal to the callee how many arguments there are. But the code generated for va_start has no way of knowing what convention the program happens to use.

<comment><USER5> Great reference, thanks!

I guess it makes sense to keep a consistent argument passing ABI, but I still find the answer quite sad: to preserve the ability to call functions without prototypes, you pass the arguments in registers and then immediately write them back to the stack.

Putting the number of vectors in %rax/%al seems at odds with the consistent ABI argument. Once you are changing things to require this, it seems like you might as well make some other useful changes as well: like passing the number of arguments and skipping the register to stack conversion.

It would be nice if there was a contortion-free entry point to the x64 printf() that started with the values on the stack. Can vprintf(const char *format, va_list ap) be used in this way instead? Is a 'va_list' just a block of memory containing the arguments?

I guess I need study the article you referred to (and stare at the libc source a while: [https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio- commo...](https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio- common/vfprintf.c;h=c4ff8334b206fdeb3ae1e97ebec203552ca6a1ff;hb=HEAD))

<comment><USER7> > to preserve the ability to call functions without prototypes, you pass the > arguments in registers and then immediately write them back to the stack.

"Back" to the stack is a big assumption. A lot of the time, there is no reason an argument would be on the stack in the first place; or even if it is a spilled variable, it usually wouldn't be in the right place (without some fairly uselessly clever stack layout), so it's just a matter of whether the caller or callee does the write.

</comment></comment></comment></comment><comment><USER8> I prefer NASM-flavored Intel syntax over AT&T; this is mostly a matter of taste, and AT&T is certainly more regular, but the NASM syntax for addressing looks more natural to me:

      lea edi, [eax + myarray + ebx * 4]

Versus AT&T:

      lea myarray(%eax,%ebx,$4), %edi

I had to look up the order of the syntax to write this comment; you can certainly memorize it, but why bother when it can be written more naturally? I wrote the NASM example in the same order for ease of comparison, but it can be shuffled around in any order as long as the expression simplifies to a valid addressing mode.

When using AT&T syntax, I also find it cleaner to drop the size suffix (movq vs mov) from the instruction whenever the size can be inferred from a register. It is still necessary in some cases that are ambiguous (e.g. mov (mem), $imm), so I suppose for teaching purposes, it might not hurt to always include it.

By the way, the 32-bit x86 ABI is much simpler than x86-64, so if you're learning assembly language for the first time, x86-64 might not be the easiest place to start. x86-64 also has some unintuitive behavior like zero-extending 32-bit mov (mov ax, 0x1234 does not modify the high part of eax, but mov eax, 0x12345678 clears the top half of rax).

<comment><USER9> Yeah, someone brought up the almost the same exact example on the programming subreddit. What I don't like about the x86 ABI is that it feels deprecated to me. Like knowing 68k or MIPS feels useless to me, relative to knowing the ABIs of more mainstream devices like x86-64 or ARM.

<comment><USER2> x86 32-bit is far from "deprecated", you can do a lot with 32 bits already (especially if you're writing in Asm).

MIPS may not be as visible as ARM but it's still used in a ton of embedded devices - like routers.

</comment></comment></comment><comment><USER10> This was _really_ helpful. I'm just getting started with assembly, and trying to hack together simple programs has so far always resulted in a segfault (8-byte offset, I know now!). Well and thoroughly written, too; I love articles like this.

<comment><USER9> Well I wrote this article just for programmers like you! I'm glad you found it useful. When I learned these four points I made, I knew I had to share. If you had further questions, I'd be more than happy to follow up.

</comment></comment><comment><USER11> I know very little Assembly Language, but what I recall is that you can skip the libc dependency on Linux if you just run the system call yourself.

So the tiny snippet at the top will become, for instance:

        .text
        .globl _main
        _main:
          subq $8, %rsp
          movq $0, %rdi
          movq $1, %rax
          movq $2, %rbx
          int $0x80

The last three lines choose the 'exit' system call¹, load the number 2 to be its argument, and make the call. Then you can get an executable like so:

        as nothing.s -o nothing.o

        ld nothing.o -o nothing -e _main

Then you can run it and check the return value.

¹ [http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls....](http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html)

<comment><USER12> I would advise against interrupt-based syscalls in for x86 platforms in linux... a lot of optimization work has been done for x86-32 via vDSO (and, afaik, x86-64 interrupt-based syscalls are just there for compatibility reasons, but I've been wrong before)

For linux x86-64 syscalls, proper way is to use "syscall" instruction. For linux x86-32 stuff, best way is to make a call via vDSO with "call _$gs:0x10 " (hopefully i didn't butcher AT&T syntax) so the kernel can dictate (via the vDSO) the best way to actually get you to the point of performing the syscall.

and, to your point, I recommend that anyone disassemble their code compiled with libc (and look at the differences between linux, os x, _bsd, whatever)... it gets really interesting how much is added and how each OS handles it.

<comment><USER11> Awesome! Thank you for your advice.

Either way, I am proceeding with the rest by using what someone else recommended I do, which is use `gcc -nostartfiles`. Looking at gcc in verbose mode reveals an ld command line I could use to run his code without modification:

        ld nothing.o -o nothing -e _main -dynamic-linker /lib64/ld-linux-x86-64.so.2 -lc

For some reason, `/lib/ld64.so.2` is not linked to `/lib64/ld- linux-x86-64.so.2` even though `ld` on Linux seems to look there by default (and fails because none of the mainstream distributions make that link).

</comment></comment></comment><comment><USER13> Hahaha, the intro is (probably unintentionally) ironic. They talk about the "compiler" getting in the way of what is truly happening down below. But x86-64 is just as much of a intermediate language, and because of the madness of microcode, reordering, caches, hyperthreading, and a hundred other things, it is not all that good of a description of what is really happening inside the processor.

<comment><USER9> Excellent point. Michael Abrash's Graphics Programming Black Book is filled with absolutes about certain instructions or groups of instructions being faster than others, but nowadays there are so many complex interactions like the ones you describe. Unfortunately, I feel that those complexities are used as justification to dissuade the learning of assembly language.

<comment><USER14> It should actually be used as a justification to persuade: you can usually write x86 assembly in any way that comes to mind and as long as data access (load/store) is the same across these variants the CPU will take the same number of cycles to execute them due to the crazy amount of optimization in the modern architectures.

<comment><USER15> Unless I'm misunderstanding what you are saying, this is not true. Instruction selection and data dependencies play a big role in the performance of a routine.

What is indeed true is that the x86(-64) ISA alone does not give you enough information to predict performance accurately. Furthermore, due to the interactions between the different subsystems (e.g, caches, OoO buffers, etc) it is essentially impossible to determine performance with cycle-accuracy. But it is still possible to have a first-order approximation, for a given microarchitecture, of what is going on underneath the CISC mask.

</comment></comment></comment></comment><comment><USER14> For more in-depth information on different ABIs (Clang isn't covered but follows GCC pretty closely), see Manual #5 [1] of Agner Fog's optimization manuals.

[1] [http://agner.org/optimize/#manual_call_conv](http://agner.org/optimize/#manual_call_conv)

<comment><USER9> Nice recommendation. Someone mentioned it as well on proggit: [http://www.reddit.com/r/programming/comments/24gpqp/lets_wri...](http://www.reddit.com/r/programming/comments/24gpqp/lets_write_some_x8664/)

</comment></comment><comment><USER16> I have always been very interested in learning x86 (or _64) assembly. Is there a proper guide I can follow say over the summer?

<comment><USER17> Try "Practical x64 Assembly and C++":

\- [http://www.whatsacreel.net76.net/asmtutes.html](http://www.whatsacreel.net76.net/asmtutes.html)

\- [https://www.youtube.com/playlist?list=PL0C5C980A28FEE68D](https://www.youtube.com/playlist?list=PL0C5C980A28FEE68D)

Covers x86-64, MMX, SSE2/3/4, AVX.

The author, Chris Rose, has also written a free e-book: "Assembly Language Succinctly" \-- (PDF) [https://www.syncfusion.com/Content/downloads/ebook/Assembly_...](https://www.syncfusion.com/Content/downloads/ebook/Assembly_Language_Succinctly.pdf)

HTH!

</comment></comment><comment><USER18> x86-64 is quite nice, even reminds me somewhat of my 68000 days. I played with x86-64 relative addressing a while ago. (see the 'edit' a bit lower for a working example):

[http://stackoverflow.com/questions/3250277/how-to-use-rip- re...](http://stackoverflow.com/questions/3250277/how-to-use-rip-relative- addressing-in-a-64-bit-assembly-program)

</comment><comment><USER19> Please don't put for loops in Makefiles.

<comment><USER9> because...

</comment></comment><comment><USER20> Learn assembly from someone who doesn't understand assembly! Get the real Comp Sci I experience!

<comment><USER9> I think some of the best hackers are self taught. The US university system is a racket, and I have 10 books I could recommend that would teach you more.

<comment><USER21> If you have recommendations for books on amd64 assembly -- ideally ones that focus on running under a free Unix stack (Linux, FreeBSD, etc.) rather than a Microsoft stack where the books address such things -- I'd love to see them. I did a very little bit of playing with real mode x86 assembly back when MS-DOS was my day-to-day OS, but that's a mite dated now.</comment></comment></comment>


How to get a good night's sleep - <AUTHOR> https://www.vox.com/platform/amp/science-and-health/2018/8/24/17670582/how-to-sleep-better-tips-advice <comment><AUTHOR> the consensus among the specialists I spoke to was that you should try to get your sleep stability right first, and make sure that you're getting consolidated sleep and not waking up all the time.

To do that, you have to implement basic sleep hygiene, which is not drinking caffeine after midday, or exercising too late, or drinking alcohol before bed, and just eating sensibly.

Do these things and you'll be less likely to wake up with your brain looking for another fix. And if doing natural things like this doesn't work, then it might be wise to consult with a specialist or a doctor.</comment>


The Gang of Four is Wrong and You Don't Understand Delegation - <AUTHOR> http://www.saturnflyer.com/blog/jim/2012/07/06/the-gang-of-four-is-wrong-and-you-dont-understand-delegation

<comment><USER2> From Design Patterns (first edition):

> Delegation is a way of making composition as powerful for reuse as > inheritance [Lie86,JZ91]. In delegation, _two_ objects are involved in > handling a request: a receiving object delegates operations to its > _delegate_. This is analogous to subclasses deferring requests to > superclasses. But with inheritance, an inherited operation can always refer > to the receiving object through the "this" member variable in C++ and "self" > in Smalltalk. To achieve the same effect without delegation, the receiver > passes itself to the delegate to let the delegated operation refer to the > receiver.

Sounds like they're perfectly clear and correct to me. As the author of the post points out the GoF don't actually show examples of delegation in the book and I don't recall them using the term much, so I don't see how they're perpetrating any misinformation here.

> In JS we can assign a prototype: the equvalent of the parent slot in Self.

No, .prototype is not equivalent to a parent slot in Self. It's closer to a traits object, I think. The unstandardized __proto__ property is equivalent to a parent slot in JS.

> Yeah, Design Patterns showed examples in Java. And Java can't do delegation. > So is that a valid argument for rewriting the meaning of a term?

Design Patterns is older than Java. Maybe later editions use it, but the original version used C++ and Smalltalk.

Otherwise, good troll post, original author. I'm sure you'll get lots of traffic and people noticing your book. Well played!

<comment><USER3> Thanks for clarifying. I had most of it written before posting and had forgotten the code samples. My copy of Design Patterns is packed up for a move. I've update it to refer to C++.

Actually, people have visited, but few have stayed to read. My goal is to clarify the concept. I did plenty of research before writing this including asking Lieberman and others about it. I first wondered how everyone's notion could be wrong and doubted that my understanding was correct.

This is a term that others have attempted to clarify as well [http://javalab.cs.uni- bonn.de/research/darwin/delegation.htm...](http://javalab.cs.uni- bonn.de/research/darwin/delegation.html)

<comment><USER4> If you agree with munificent, then perhaps you could soften your title and introduction to say that many people confuse what the GoF meant, not that the GoF are wrong.

<comment><USER3> good point. I'll verify the citation and update it.

</comment></comment></comment></comment><comment><USER5> The td;lr of this post: this article is misguided according to usage, the history of the word "delegation", and the principles of good software design.

One of the points of design patterns is to define a common language. The benefit of this is that it helps people understand one another. The fact that delegation as discussed in GoF is what everyone understands delegation to be is good enough reason to continue using the word "delegation" that way and to force him to find a new word for what he wants to say. Even if his definition was first.

But his definition was NOT first. Sure, someone may have first used the term in OO programming in his sense of the word. But the word "delegation" has long-standing usage in the English language. It means, "Doing this is now your responsibility." In English there is no automatic implication that the person to whom things are delegated necessarily has access to the person who did the delegating. In practice, of course, there is. Which is why the software analogs include that. But in the real world it is clear when you intend to refer a question back to the original person, and when you do not. Therefore the long established and universally understood definition does NOT indicate that the person to whom you delegate has the option of choosing to intercept any and all questions you ask.

So which behavior is preferable?. If I delegate to you, and then need to be aware of all of the methods that you define, all of your methods, both public and private, become part of the surface of the API between us. However the whole point of modularity is to have limited APIs between you and your components. Enlarging the API may be easier and more convenient, but it entwines code into spaghetti and is bad for your code base. So good software design says that of the two possible definitions of "delegation" we are comparing, we should prefer the one that makes it clear in the delegated to method when exactly it intends to go back to the delegated object versus when it is trying to send messages to itself. And the version that does that is the version that the Gang of Four used.

Therefore he is wrong to say that delegation should be redefined to mean what he means. He is wrong to say that his definition is better grounded in the history of the word "delegation". And he's dead wrong that implementing his version of the word "delegation" is better software design than the current definition.

<comment><USER3> I never said delegation should be redefined. In fact I'm pointing out that the GoF did the redefining. In the history of Object-oriented programming "delegation" means what it was described to be. I never said that any particular implementation is "better software design". Please show me where you got these things that I supposedly said.

<comment><USER5> You admit that today in common usage and implementation in various languages, "delegation" means what the GoF described it as. Language is defined by usage, so that is the current definition.

You are insisting at this point that we should only use the first definition ever proposed for the word in software at this point. That would be redefining it. It would also create confusion.

I do not dispute that GoF already redefined the word. That's historical fact. However what they defined it as is a concept that is better software design than the thing defined in the historical definition that you want us to go back to. Thus what they are calling delegation is not just different, but _better_.

To reduce jargon, it is good that we try to limit how many words get special meanings in software. And it is therefore good to only give that treatment to particularly useful concepts. Which means to me that what GoF defined "delegation" to be is more deserving of having its own word than the original concept.

Hopefully that clarifies why I call your attempt to go back to the original definition "redefinition", and why principles of good software design make the GoF definition more compelling.

</comment></comment></comment><comment><USER6> Delegation is such a commonly-used English word that you don't _get_ to have a monopoly on its definition. If I have two classes and one delegates to an instance of the other, then it's delegation.

Just because Lieberman tried to give it a more refined definition in the context of OOP doesn't mean that the less refined use is incorrect. You don't get to take away my English words.

<comment><USER3> Lieberman invented this term. It did not exist prior to his work. I have confirmed this with Lieberman himself as well as Jim Coplien and David Ungar.

The Design Patterns book sought to clarify our language yet it has this error. I'm seeking to clarify our language.

<comment><USER6> He did not invent the term. "Delegate" and "delegation" have been around a lot longer than computers. Here's a definition:

Delegate. Verb: Entrust (a task or responsibility) to another person, typically one who is less senior than oneself: "he delegates routine tasks".

It's not hard to see how that would be analogous to a variety of situations in computing.

If you want a term to be more pure, think of something more creative.

Edit: That's not to take away from your point that the GoF actually cited Lieberman in their use of delegation. If they misunderstood his intention, sure raise that point.

<comment><USER3> In programming terms, he did. I appreciate that it is an English language word and was initially what I thought it meant. But when he applied the term he meant it specifically. Otherwise, we already have a term for this: forwarding.

So why not argue about people using "delegation" when they just mean "forwarding"?

<comment><USER6> Alright, let's take it for a spin. What do you call the thing that you're forwarding to? The endpoint? The "nextLinkInChain"? Delegate seems pretty natural to me in most domains, but as you say, I've been poisoned by GoF.

<comment><USER3> I'm planning to follow up in another post, but Gunther Kniesel coined the term "consultation" ([http://javalab.cs.uni- bonn.de/research/darwin/delegation.htm...](http://javalab.cs.uni- bonn.de/research/darwin/delegation.html)) and I've used a generic "attendant" term to refer to the other object.

Here's an excerpt from my take on the 2 characteristics of consultation (or what is typically called "delegation") in my book

\---- The first is the connascence of method names between collaborating objects. Connascence refers to the point and type of coupling between objects where a change in one object requires a change in the other. Consultation occurs when the message recipient forwards a message to another object which handles the response to the same message. A calculator would receive a balance message and forward that message to an account which responds to balance. Rails' implementation of delegate does include a caveat that the message might be prefixed before it is forwarded, but the implementation is still connascent by method name. The second aspect of consultation is that the message recipient makes no modifications to the algorithm for handling the response. \----

I wrote to Lieberman to ask his opinion and he sided with NOT introducing the "consultation" term. But his reason was not because our misguided understanding of delegation is correct, his reason was because we already have a name for this: forwarding. The quote above is from my argument about why I think it is valuable to use the term "consultation".

</comment></comment></comment></comment></comment></comment><comment><USER7> So he's redefining delegation in your own sense (implied by his strange titlebait "The Gang of Four is Wrong") and then criticizing everyone else post hoc?

I fail to see how this deserves any upvotes.

<comment><USER3> I'm the author. I'm not redefining delegation. I'm pointing out that the Gang of Four, who cited Henry Lieberman who created the term, described it incorrectly. You can read the citations in the Design Patterns book and see exactly what they got wrong. Here's a link to Lieberman's work [http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De...](http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html)

</comment></comment><comment><USER8> Many people agree on the words proposed by GoF, but not on the details of the meaning, and this is a frequent source of misunderstandings and useless debates. Over the years I have gone from fan of the book to considering it a net negative force in software engineering, a failed attempt that many people still believe in. (The other failure of the book is in educating people to blindly believe that applying a given pattern is always a good solution because, hey, it's a pattern)

If you look at the details of the patterns as examples rather than definitions, and treat on the book as a general description of common situations, problems and approaches, then all is well.

<comment><USER9> In my experience, GoF is most useful in that it says, "Patterns exist in software architecture as much as they do in physical architecture."

The rest is details.

</comment></comment><comment><USER10> If both definitions of 'delegation' end up having the same purpose, does it really matter? Why should I care that Rails' 'delegate' isn't exactly how some guy in 1970 would've written it?

This whole "object-orientation" bent in the Ruby community lately just feels like a crusade, with people thumping on old OO books, each proclaiming theirs is the "true way". And, usually, like in this example, it doesn't even matter because their code ends up doing exactly the same thing with little real-world gains in readability or ease of understanding.

<comment><USER11> One of the traits that allows us to be competent programmers is a pedantry about technical terminology. Why overload the concept of message forwarding with a second term if what that term was originally coined to describe is a useful paradigm?

I had never heard of this distinction, however it immediately made sense to me because I've run into this case in Ruby where using a ruby "delegate" object actually was much more verbose than I had envisioned because of all the context I had to bring over to the delegate object one way or another. In the event I decided "delegation" was not right because the implementation necessarily violated the Law of Demeter.

So yeah I think pragmatically it does matter.

<comment><USER5> I agree that there are cases where pedantry is necessary for programmers. That does not mean that pedantry is necessarily valuable.

In this case a distinction is being drawn that would make "delegation" mean something that is worse from the point of view of good software design, which would leave the thing that is better software design without its commonly understood name. Doing this would create negative value.

<comment><USER11> I'm not following your point. I'm saying that true delegation as defined by the article is in fact a useful tool for good software design. Maybe not as broadly useful as standard message forwarding, but something which deserves its own term.

<comment><USER5> Delegation as defined by the article makes every method call made by the delegated to class part of the programming interface that you need to be aware of when choosing to delegate. Delegation as defined by GoF makes only a specified set of callbacks be part of that interface.

That says that delegation as defined by GoF does more to promote modularity than the original definition, and therefore is more often going to be preferred in good software design over that defined by the article.

This is not to say that there aren't cases where what the article promotes is not convenient. Violating modularity is usually convenient. But that is a convenience that we should always be wary of.

</comment></comment></comment></comment></comment><comment><USER12> i don't know about you but i'm getting sick and tired of these "marketing" posts with sensational titles.

if you have a book to sell just say so, so we can directly skip your post.

<comment><USER13> I'm getting sick of them as well. Most of them follow the same formula by having a declarative statement pointing out that someone is either wrong or doesn't understand something or this that or the other will never work. They seem to be pretty popular on here though as many of them have lots of comments.

</comment></comment><comment><USER6> Terminology arguments aside, I remember at least one occassion where I really wanted this in a GoF pattern.

I had an interface Repo, with methods getA() and getB(). I wanted to overlay a transparent cache a la Proxy (<http://en.wikipedia.org/wiki/Proxy_pattern>, note its use of "delegate" in its description).

So I had implementations CachingRepo and DataStoreRepo, the first would cache recent calls and the latter would make real calls. CachingRepo would have an instance of Repo that it delegates to on a cache miss.

The issue was that DataStoreRepo.getA() relied on getB(). In a non-Lieberman delegation strategy, that B would always come from the data store, not my cache.

If I understand correctly, in Lieberman delegation getB() could return the cached values, because its "self" would point to the CachingRepo, not "this" in a Java sense.

It's not impossible to do this in Java, there's just not language support for it. The wiring would be cumbersome. Thanks for introducing me to Lieberman's work, but I'll stick with the de facto standard usage of "delegation".

</comment><comment><USER14> Correct me if I am wrong, but it seems to me that (Lieberman) delegation is quite a dangerous concept when applied to the most popular object oriented languages. You're effectively calling another object's methods and masquerading yourself as that object, or to put it another way you're exposing all of your privates and implementation details to another object. Hence it is much more dangerous, and potentially quite incorrect, than just forwarding.

The only safe way I can see this being done is by adding a reference to object A when calling/forwarding a method on object B. But that's just forwarding with extra data.

Maybe I haven't worked enough with fully dynamic languages, but I don't really see much or any benefit to doing 'Lieberman' delegation, over and above other options.

<comment><USER15> Liberman deleation is fine-grained multiple inheritence. If I say I'm delegating the implementation of method foo to object bar, it sounds unsafe. If I say I'm inheriting the implementation of method foo from object bar, it seems safer, albeit not "classical OO."

<comment><USER14> Thanks, that makes far more sense to me.

</comment></comment></comment><comment><USER16> In my experience most implementations either have a way of binding the context per method (JavaScript), or use a loose convention of passing the sender as the first argument (Objective-C).

It seems like the Ruby libraries cited are the real issue, rather than a fundamental misconception of the concept of delegates or indeed inversion of control as a whole.

</comment><comment><USER17> God bless that OO dreamers!

Always witty, and always far away from their evading (and silver :)) target...

</comment><comment><USER18> he's just selling a book, relax

</comment><comment><USER19> Maybe the need of a Design Pattern means that the language is not powerful enough.

PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp." <http://www.norvig.com/design- patterns/>

<comment><USER19> Discussion about this here: [http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...](http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures)</comment></comment>