Am I the only one with doubts about .NET for commercial apps?

[Guest]

Hello

Just like everyone else, I am excited about how easily one can create Windows applications with the .NET platform, but for shareware, I have some serious reservations

1. Your code can be easily decompiled. This would make it very difficult to implement any sort of license restrictions on your app, because anything you write can be easily viewed and cracked. This also removes any privacy for your intellectual property

2. Jim Hubbard, in a previous post, informs me that there is really no way to prevent someone from reusing one of your private assemblies in their own application! I imagine that someone could simply remove your trade marks and names, and slap on their own

So far, I have found only these two weaknesses, but these are BIG weaknesses.

Am I alone in thinking that .NET just isn't ready for commercial software development? Or can someone point out something that I haven't yet come across that mediates these weaknesses

.NET is all the rage, but I have yet to see these points seriously discussed

Sincerely
Rich.

 

[Daniel O'Connell [C# MVP]]

Hello,

Just like everyone else, I am excited about how easily one can create
Windows applications with the .NET platform, but for shareware, I have
some serious reservations.

1. Your code can be easily decompiled. This would make it very
difficult to implement any sort of license restrictions on your app,
because anything you write can be easily viewed and cracked. This also
removes any privacy for your intellectual property.

2. Jim Hubbard, in a previous post, informs me that there is really no
way to prevent someone from reusing one of your private assemblies in
their own application! I imagine that someone could simply remove your
trade marks and names, and slap on their own.

So far, I have found only these two weaknesses, but these are BIG
weaknesses.

Am I alone in thinking that .NET just isn't ready for commercial
software development? Or can someone point out something that I haven't
yet come across that mediates these weaknesses?

The problem is that both of these are pretty much not new. While its a touch
harder to do in unmanaged code, no licensing restrictions you add there are
going to stand up any better(thousands upon thousands of cracks for
unmanaged apps come out every year, every major game gets cracked). The most
effective protection scheme I've heard of was from...autodesk I think, which
used a dongle that the program used as a lookup table. It took some doing
but even that was eventually emulated, IIRC. Intellectual property is
mostly a matter of legality, not security. When you ship your application,
in any format, if someone wants it they will take it. While I personally
can't read x86 assembly worth a damn, I've known people who could read it
better than they ould English. .NET just takes away that particular false
sense of security by making it clearer how easy it is to do.

Often times, all that stops someone from using your dll's is that they don't
have the call signatures...given time they will figure them out if they want
them(and possibly publish them). Now, what about COM objects? The user
pretty much has access to them as well...where is the security there?

Again, its something that is apparent in .NET, but certainly not new or
unique.

You can make reusing your assemblies a bit harder by using identity demands,
it'll raise the bar a litlte but it won't make a difference, IMHO.

.NET is all the rage, but I have yet to see these points seriously
discussed.

You should go to google groups and start looking up obfustication and
diassembly. This topic has actually been discussed quite throughly, I've
participated in atleast 3 or 4 myself.

 

[Jim Hubbard]

Keep in mind that Microsoft has publicly stated its goals of "software
as a service" including the goal of making the Microsoft Office suite a
service by the year 2010.

Make no mistake about it, although .Net has tremendous advantages over
the old Visual Studio products, .Net was written by Microsoft for Microsoft.
The fact that they can push it on their customers at a profit is just icing
on the cake.

No need crying over spilled development tools. The thing to do now is
to learn how to use the new tools in a productive and profitable manner. As
I see things, copying the "software as a service" model that Microsoft is
implementing is the only way to go. And, not just because we have no other
choice...

As a shareware authors will attest, shareware (and even retail software)
is easily ripped off. (Just check www.keygen.us or www.cracks.am or
www.astalavista.com. If a software title is remotely popular, you can find
a crack for it on one of these sites.)

Although I disagree with Microsoft's handling of VB.Net, placing part of
your software on an inaccessible server is the only way to guarantee that
you get paid. Microsoft recently made $9 billion in sales for a single
year's software sales, which is admittedly a lot of money. But, it lost $3
billion to software thieves - which is also a lot of money.

This is what is driving Microsoft's (and savy shareware/retail
developers) to the "software as a service model".

See the news lately that Bush is pushing for all homes in the US to have
broadband access by 2007? Don't think that Microsoft had a little hand in
that, or that the globalization of the software workforce pushed it a
little?

If you study .Net a little, you'll see that it is very simple to deliver
zero deployment applications (yes, actual Windows forms-type applications -
NOT the limited web pages we are used to) via a web server and web services
that allow you to actually get paid for your hard work.

Currently, the lack of broadband access limits the number of potential
customers, but that will soon change. Are you ready?

Jim Hubbard

Hello,

Just like everyone else, I am excited about how easily one can create

Windows applications with the .NET platform, but for shareware, I have some
serious reservations.

1. Your code can be easily decompiled. This would make it very

difficult to implement any sort of license restrictions on your app, because
anything you write can be easily viewed and cracked. This also removes any
privacy for your intellectual property.

2. Jim Hubbard, in a previous post, informs me that there is really

no way to prevent someone from reusing one of your private assemblies in
their own application! I imagine that someone could simply remove your
trade marks and names, and slap on their own.

So far, I have found only these two weaknesses, but these are BIG weaknesses.

Am I alone in thinking that .NET just isn't ready for commercial

software development? Or can someone point out something that I haven't yet
come across that mediates these weaknesses?

 

[Jon Skeet [C# MVP]]

Just like everyone else, I am excited about how easily one can create
Windows applications with the .NET platform, but for shareware, I
have some serious reservations.

1. Your code can be easily decompiled. This would make it very
difficult to implement any sort of license restrictions on your app,
because anything you write can be easily viewed and cracked. This
also removes any privacy for your intellectual property.

2. Jim Hubbard, in a previous post, informs me that there is really
no way to prevent someone from reusing one of your private assemblies
in their own application! I imagine that someone could simply remove
your trade marks and names, and slap on their own.

So far, I have found only these two weaknesses, but these are BIG
weaknesses.

I don't believe they really are.

See http://www.pobox.com/~skeet/csharp/faq/#obfuscation

Am I alone in thinking that .NET just isn't ready for commercial
software development? Or can someone point out something that I
haven't yet come across that mediates these weaknesses?

.NET is all the rage, but I have yet to see these points seriously
discussed.

A good counterexample is Java. It's got exactly the same "problem", but
it seems to be pretty commercially popular, doesn't it?

 

[Mike McIntyre [MVP]]

Hello Rich,

For your point 1, use an obfuscator.

http://www.vbdotnetheaven.com/Code/Sept2003/2171.asp

http://www.ftponline.com/reports/vslivesf/2004/torok/

For examples see Salamander at
http://www.remotesoft.com/salamander/obfuscator.html and Dofuscator at
http://preemptive.com/products/dotfuscator/index.html.

----------------------------
For point 2, there are built in capabilities in the .NET Framework for
controlling/security access to an assembly. If implemented correctly some of
the capabilties provide a great deal of protection.

http://www.ftponline.com/wss/2002_10/magazine/columns/security/

Sophisticated .NET hackers are finding ways past some of the built in
capabilities. Dan Appleman wrote an inexpensive eBook that provides
excellent advice on how to project against them:

Hijacking .Net Vol 2: Protecting Your Code
by Dan Appleman

---------------------------

Securing your applications is a process of 'hardening' your application by
using layers of projection. Obfuscation is one layer. Using the .NET
Framework's capabilities provide more layers. Ideas such as those provided
by Dan Applemen add more.

You can add your own layer(s) too. For example, some of your class
contructors and/or methods can be written to accept one or more encrypted
parameters that only your application can generate.

--
Mike

Mike McIntyre
Visual Basic MVP
www.getdotnetcode.com

Hello,

Just like everyone else, I am excited about how easily one can create

Windows applications with the .NET platform, but for shareware, I have some
serious reservations.

1. Your code can be easily decompiled. This would make it very

difficult to implement any sort of license restrictions on your app, because
anything you write can be easily viewed and cracked. This also removes any
privacy for your intellectual property.

2. Jim Hubbard, in a previous post, informs me that there is really

no way to prevent someone from reusing one of your private assemblies in
their own application! I imagine that someone could simply remove your
trade marks and names, and slap on their own.

So far, I have found only these two weaknesses, but these are BIG weaknesses.

Am I alone in thinking that .NET just isn't ready for commercial

software development? Or can someone point out something that I haven't yet
come across that mediates these weaknesses?

 

[David Sworder]

1. Your code can be easily decompiled. This would make it very
difficult to implement any sort of license restrictions on your app, because
anything you write can be easily viewed and cracked. This also removes any
privacy for your intellectual property.
<<<<<<<<

I'm not saying that your argument doesn't have merit, but I guess I've
never really understood the big scare about people decompiling .NET apps.
It's very unusual that a piece of logic in a WinForms app is so incredibly
revolutionary that "hackers" are going to want to reverse engineer it. There
may be a few exceptions to this like if you've developed some fantastic data
compression algorithm -- and in such cases, you can move such code to
unmanaged C++ if you want (even then, your algorithm wouldn't be fully
protected).

Even if someone DID decide to decompile your obfuscated .NET code, what
would he do with it? Would he copy the code into his own project, recompile
it, and then try to compete with you by selling it? Selling stolen code is
just too risky. It's almost ALWAYS easier for a competitor to just redesign
your app on his own without trying to reverse engineer your code. For
example, if I wanted to design my own peer-to-peer file swapping app, I
wouldn't attempt to decompile Kazza and try to reverse engineer the code --
I'd just look at the Kazza *functionality* via the UI and design my own app
from scratch.
2. Jim Hubbard, in a previous post, informs me that there is really no
way to prevent someone from reusing one of your private assemblies in their
own application! I imagine that someone could simply remove your trade
marks and names, and slap on their own.
<<<<<<<<<<

I don't think that this is true. I've seen discussions in this newsgroup
that indicate contrary. There is a way to sign your assemblies in such a way
that they can only be called by other assemblies that have a particular
signature. Scan this newsgroup for more info on this topic...

David

 

[Niki Estner]

What kind of applications do YOU write???
I spent a few years developing signal processing/image processing
applications, and I can tell you: finding out how an algorithm works isn't
half as easy as you seem to think. But getting good hints e.g. from
un-obfuscated mathod names (like "Fourier" or "Median") can really make this
too easy.
I guess the same would apply to highly optimized graphics engines as they
are found in computer games (if they were written in managed code) or
proprietary communication standards or high-speed-databases... - virtually
every piece of code that required thought when it was written.

Niki

 

[David Sworder]

What kind of applications do YOU write???

Financial apps... essentially every piece of analytical logic I use has
been around for decades or can be copied out of an article or book.

I spent a few years developing signal processing/image processing
applications, and I can tell you: finding out how an algorithm works isn't
half as easy as you seem to think.

Probably true... but then again, I know nothing about signal
processing/image processing. Do you think that if you gathered a bunch of
signal processing experts together in a room and showed them your app,
they'd be SO impressed with your algorithm that they'd say to themselves
"wow, I've never seen anything like that! Instead of creating our own
similar algorithm, let's reverse engineer her code, recompile it into our
own app, and SELL it!"
Please don't misinterpret my tone here. I'm not being sarcastic. If this
actually applies to you, then hey, congratulations! ... and you're right,
you'd better look for a sophisticated way to protect your algorithm.

I guess the same would apply to highly optimized graphics engines as they
are found in computer games (if they were written in managed code)

I'll buy that argument. For example, I remember when ID Software
released "Doom." Other developers were genuinely amazed. I remember them
asking "how did ID Software do that?"... but that was written in C/C++,
*not* managed code.

proprietary communication standards

I don't know... It seems like the hacks against com standards have been
done by using a sniffer to examine network traffic, not by reverse
engineering code. I suspect that the spammer that figured out how the
"proprietary" Windows messenger service worked did so by examining network
traffic, not by trying to decompile the messenger service EXE.

or high-speed-databases...

...but these aren't written in .NET managed code (but they presumably
will be at some point). I assume you're talking about databases like SQL
Server and Oracle? If I were writing my own high speed database, I'd turn to
books, articles, and classes on database theory. I educate myself the same
way the designers of SQL Server did. This would be vastly more effective
than trying to decompile the .EXEs of a competitor's product.

virtually
every piece of code that required thought when it was written.

This is a gross exaggeration! Yesterday I wrote a helper app that waits
for a file to arrive, reads it, does some analysis, and uploads the results
to a database. This app "required thought," but should I worry about someone
reverse engineering my code and discovering:
a) I used a FileSystemWatcher to wait for the file
b) I used an SqlConnection object to connect to the database and called
some methods against an IDbCommand object to upload the data
c) I used some well-known algorithms (well known in financial analyst
circles) to perform the analysis that can be looked up on Google and read in
*plain English* (as opposed to reading them in unobfuscated decompiled
cryptic C# code.)

My app required thought, but any competitor who wanted to duplicate my
efforts would be better off reading some financial analysis articles and the
documentation for ADO.NET and FileSystemWatcher than he would trying to
decompile my app, unobfuscate it, etc.

I'm not claiming that my situation applies to everyone. If your
signal/image processing logic is truly awesome and warrants protection, so
be it. If you're designing encryption logic for the dept of defense, don't
use .NET. Same would be true if you're designing a revolutionary 3D game
engine that is so frigging' unique that it isn't just a derivative of the
techniques taught in any of the "Teach Yourself 3D Game Programming" books
at Barnes and Noble... what I *am* saying is that a very large fraction of
the apps out there don't fall into this category and the authors of some of
these apps have decided to use C++ instead of C# simply because they're
worried about someone reverse engineering their precious code -- and I think
that's a shame.

David

 

[Jon Skeet [C# MVP]]

What kind of applications do YOU write???
I spent a few years developing signal processing/image processing
applications, and I can tell you: finding out how an algorithm works isn't
half as easy as you seem to think. But getting good hints e.g. from
un-obfuscated mathod names (like "Fourier" or "Median") can really make this
too easy.
I guess the same would apply to highly optimized graphics engines as they
are found in computer games (if they were written in managed code) or
proprietary communication standards or high-speed-databases...

There are certainly a *few* cases where the algorithm itself is most of
the work. I don't think it covers what most developers write, however.

- virtually every piece of code that required thought when it was written.

I spend relatively little time thinking about coding. Coding is
relatively easy. Designing the system in the first place - what object
should have what responsibility, etc - is the more demanding part, in
my experience.

 

[Jon Skeet [C# MVP]]

If you're designing encryption logic for the dept of defense, don't
use .NET.

I certainly *hope* that very few governments are using encryption
algorithms which are only secure because the algorithm isn't known.
That way, trouble lies. Encryption schemes should rely on the secrecy
of some other piece of information (the key, essentially) - *not* the
obscurity of the algorithm.

 

[Ray Cassick \(Home\)]

1. Use an Obfuscator. That is not 100% but then again NOTHING is 100% if
there is someone out there that REALLY wants to use your stuff without your
permission.

2. Consider signing your stuff so at least then others will know that their
stuff is not your stuff. Also consider maybe writing most of your stuff in
managed code but then keeping the proprietary things in non-managed DLLs if
you are really worried.

The bottom line is that NOTHING is 100%, not even unmanaged code. The trick
is keeping 99% of the honest people honest.

Hello,

Just like everyone else, I am excited about how easily one can create

Windows applications with the .NET platform, but for shareware, I have some
serious reservations.

1. Your code can be easily decompiled. This would make it very

difficult to implement any sort of license restrictions on your app, because
anything you write can be easily viewed and cracked. This also removes any
privacy for your intellectual property.

2. Jim Hubbard, in a previous post, informs me that there is really

no way to prevent someone from reusing one of your private assemblies in
their own application! I imagine that someone could simply remove your
trade marks and names, and slap on their own.

So far, I have found only these two weaknesses, but these are BIG weaknesses.

Am I alone in thinking that .NET just isn't ready for commercial

software development? Or can someone point out something that I haven't yet
come across that mediates these weaknesses?

 

[David Sworder]

I certainly *hope* that very few governments are using encryption
algorithms which are only secure because the algorithm isn't known.
That way, trouble lies. Encryption schemes should rely on the secrecy
of some other piece of information (the key, essentially) - *not* the
obscurity of the algorithm.

yeah, ok.. my bad.. was WEP cracked due a bad algorithm?

on a side note, I'd like to point out that in the movie SWORDFISH, Hugh
Jackman was able to break 512 bit encryption in his head. Hugh is very smart
that way.

 

[Niki Estner]

...
Probably true... but then again, I know nothing about signal
processing/image processing. Do you think that if you gathered a bunch of
signal processing experts together in a room and showed them your app,
they'd be SO impressed with your algorithm that they'd say to themselves
"wow, I've never seen anything like that! Instead of creating our own
similar algorithm, let's reverse engineer her code, recompile it into our
own app, and SELL it!"
Please don't misinterpret my tone here. I'm not being sarcastic. If this
actually applies to you, then hey, congratulations! ... and you're right,
you'd better look for a sophisticated way to protect your algorithm.

I didn't say I'm a signal processing genius - but it does take time to find
good algorithms; Time spent testing, reading books, optimizing; Or spent
decompiling.
To stick to your example: if I spent a month on an algorithm, those "signal
programming gurus" would probably need a week or so to do the same; Or a
day, using a decompiler.

I'll buy that argument. For example, I remember when ID Software
released "Doom." Other developers were genuinely amazed. I remember them
asking "how did ID Software do that?"... but that was written in C/C++,
*not* managed code.

What's your point?
Do you think Doom wasn't disassembled?
Or do you think it wouldn't have been, if it would have been managed code???

I don't know... It seems like the hacks against com standards have been
done by using a sniffer to examine network traffic, not by reverse
engineering code. I suspect that the spammer that figured out how the
"proprietary" Windows messenger service worked did so by examining network
traffic, not by trying to decompile the messenger service EXE.

Ok, maybe this example wasn't that good.

...

This is a gross exaggeration! Yesterday I wrote a helper app that waits
for a file to arrive, reads it, does some analysis, and uploads the results
to a database.

Did you spend a moment thinking whether this task is possible? Whether it
can be done by a computer?
Well, for charachter, speech or face recognition you usually do have to
spend a lot of time thinking about what's possible and what isn't.

Again, I don't claim I ever developed any "impressive" algorithms of that
kind - merely ones that work more-or-less.
But then again, look at the OCR, speech or face processing market, and you
won't find too many "impressive" products - only ones that work
more-or-less...

...
I'm not claiming that my situation applies to everyone. If your
signal/image processing logic is truly awesome and warrants protection,

Awesome? Probably not.
But it's surely more work developing it than copying it...

... a very large fraction of
the apps out there don't fall into this category and the authors of some of
these apps have decided to use C++ instead of C# simply because they're
worried about someone reverse engineering their precious code -- and I think
that's a shame.

Well you said in your first post you didn't understand the scare of
decompilation - I hope I could clarify that scare a little bit, because I do
share it.

And, take my word for it - there probably are some Oracle programmers out
there disassembling some SQL server code right now as we speak ;-)

Niki

 

[David Sworder]

I didn't say I'm a signal processing genius - but it does take time to
find

good algorithms; Time spent testing, reading books, optimizing; Or spent
decompiling.
To stick to your example: if I spent a month on an algorithm, those "signal
programming gurus" would probably need a week or so to do the same; Or a
day, using a decompiler.

Ok, if that's truly the case, then you certainly have a right to be
concerned... but for me and the developers I've encountered, the reverse is
true: It would take competitors much longer to design something comparable
by decompiling/understanding/recompiling an app than it would to just design
it on their own.

What's your point?
Do you think Doom wasn't disassembled?

You mean did people try decompiling the unmanaged EXE to figure out ID's
graphics engine? Geez, I hope not! I guess anything's possible, but I don't
remember seeing a lot of Doom clones springing up until after a) ID released
the source code and b) there were a fair number of public articles published
on the topic. Even if some guy was smart enough to reverse engineer the raw
assembler code for a graphics engine, wouldn't he be taking an *enormous*
legal risk putting that very same code into his own product and reselling it
as an alternative to Doom? In other words, even if it were technically
possible, would it be practical?

Or do you think it wouldn't have been, if it would have been managed

code???

Yes, it WOULD have been if it were managed code... which is my point: If
you (not you personally) have a revolutionary idea for a 3D graphics engine,
then I'll agree with you -- .NET isn't for you.

Again, I don't claim I ever developed any "impressive" algorithms of that
kind - merely ones that work more-or-less.
But then again, look at the OCR, speech or face processing market, and you
won't find too many "impressive" products - only ones that work
more-or-less...

Yeah, but face processing is cutting edge stuff! You've produced some
excellent examples that illustrate how the possibility of decompilation
could be a threat. I just don't think that most app developers fit into that
category.

Awesome? Probably not.
But it's surely more work developing it than copying it...

I guess that's really the crux of the issue. It sounds like you're doing
a lot of work with cutting edge algorithms. For me, most of the code I write
is based upon knowledge and formulas that are public domain. The UI code is
just standard stuff: creating new windows, validation of forms, etc... the
idea that someone would try to reverse engineer this stuff is silly. but for
the stuff you're working on, ok, I guess I understand your point.

And, take my word for it - there probably are some Oracle programmers out
there disassembling some SQL server code right now as we speak ;-)

Has anyone tried to reverse engineer Microsoft Bob? If not, they should.

 

[Daniel O'Connell [C# MVP]]

yeah, ok.. my bad.. was WEP cracked due a bad algorithm?

There is some info at http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
that covers why wep didn't work. I'm no security or cryptography expert so I
won't try to explain it here.

on a side note, I'd like to point out that in the movie SWORDFISH, Hugh
Jackman was able to break 512 bit encryption in his head. Hugh is very
smart
that way.

I wish I could be a movie computer expert...everything is so easy in that
world, I'd be a billionare by now I'm sure.

Have you ever read userfriendly(userfriendly.org)? Somewhere deep back in
the archives one of the characters creates "Hollywood OS 1.0"(or something
like that) which can be hacked with two key presses, everything only takes
one click, etc.

 

[David Sworder]

I wish I could be a movie computer expert...everything is so easy in that

world, I'd be a billionare by now I'm sure.

Have you ever read userfriendly(userfriendly.org)? Somewhere deep back in
the archives one of the characters creates "Hollywood OS 1.0"(or something
like that) which can be hacked with two key presses, everything only takes
one click, etc.

Ha! Yeah, I like the way computers are used in the movies. People have
weird IP addresses like "271.4653.0.41" and the cops can instantly trace
anyone's physical address and phone number using these IP addresses.

 

[Steve McLellan]

There are certainly a *few* cases where the algorithm itself is most of
the work. I don't think it covers what most developers write, however.

True, but it IS the bit that you're selling - anyone can slap a UI on
something. The only IP we have is the algorithm, and unless it's patented,
nothing stops someone decompiling it and incorporating it into their
product. With an algorithm it's relatively easy (once you understand it) to
rewrite it, so copyright doesn't apply. Of course, given an expert in any
algorithmic field, you can generally work out the methods used in a given
piece of software through experimentation and a feel for how different
methods work. A sort of mental decompilation, if you will.

written.

I spend relatively little time thinking about coding. Coding is
relatively easy. Designing the system in the first place - what object
should have what responsibility, etc - is the more demanding part, in
my experience.

For some applications that's true. But commercially that stuff isn't
important to any company producing any cutting edge scientific
applications - the blood and guts (and the bit you pay your people for) is
the algorithm. As it happens at the moment, using managed code for any
number crunching isn't really practical in terms of performance (not to
mention cross platform compatibility) but it will become more of a problem.

Just, sa they say, my two.

Steve

 

[Jon Skeet [C# MVP]]

True, but it IS the bit that you're selling - anyone can slap a UI on
something. The only IP we have is the algorithm, and unless it's patented,
nothing stops someone decompiling it and incorporating it into their
product. With an algorithm it's relatively easy (once you understand it) to
rewrite it, so copyright doesn't apply. Of course, given an expert in any
algorithmic field, you can generally work out the methods used in a given
piece of software through experimentation and a feel for how different
methods work. A sort of mental decompilation, if you will.

That may well be what *you're* selling, but it's not what most people
are selling. The general design isn't something you can easily get from
decompilation, and the mixture of general design and the work involved
in implementation is what most apps are sold for, really.

For some applications that's true. But commercially that stuff isn't
important to any company producing any cutting edge scientific
applications - the blood and guts (and the bit you pay your people for) is
the algorithm. As it happens at the moment, using managed code for any
number crunching isn't really practical in terms of performance (not to
mention cross platform compatibility) but it will become more of a problem.

And sure, for number crunchers that may be a significant problem - but
I don't believe *most* developers are in that situation. I know I've
never written anything which has been particularly impressive in terms
of algorithm. By the time someone has decompiled the code, *understood*
it (without comments or local variable names, and in the case of
obfuscated code, without useful class or method names either for the
most part) they could easily have come up with the same algorithm - if
they'd had the same design to start with.